Tracking query string and page view workflow issues - Single page application with hash routing

Develop, Build & Integrate APIs & Integrations
1

We have a single page application using hash routing and we can’t remove the hash from the URL at this time.

There are a couple of issues currently.

Note: disregard the “,” in my URL examples. As a new user I’m not allowed to submit a post with more than 2 links.

1. The Hubspot emails are adding the tracking query string before the hash in our URL rather than adding it to the end of the URL.

Example:

a. The link is getting generated as - website,com/homepage/?utm_campaign=foo&utm_source=bar#/
b. The link should be - website,com/homepage/#/?utm_campaign=foo&utm_source=bar
c. From what we can tell, it’s more of a cosmetic issue, but we’re looking into if it affects any of our other third party tracking and we’d like to resolve it regardless, if possible.

2. We’re trying to do some abandon order/order complete workflows based on what pages the customer views, but Hubspot won’t recognize page view events in the workflow due to the hash route.

The page view will show up in the contact activity history, but the hash routing we’re using is somehow failing to allow “page view” triggers in workflow. The only URL I can make work for page view trigger in a workflow is the home page (probably because all other pages have their path after the hash).

Example:
If the URL is website,com/homepage/#/order-details

a. I can trigger something with “Contact has viewed a URL containing website,com/homepage”
b. But I can’t trigger something with “Contact has viewed a URL containing /order-details” (even though the contact activity history shows I viewed that page)

We have some ideas for possible workarounds, but I was wondering if anyone had thoughts on if these would work.

1. Solution idea for query string
During the page load, Would there be any issue will nulling out the query string values AFTER the hubspot scripts have run?

Our thought is that it’s ok to strip out the Hubspot query string after all the scripts have run, but we’d like some confirmation that it won’t break anything.

2. Solution idea for page view triggers in a workflow
We aren’t doing anything special in the hubspot scripts to track page view events that we can tie directly to a user, but I’m thinking there might be a way to do this so I was hoping for some guidance any any functions we should look into?

Would these three work for what we need to trigger page view in workflows?
Set Page Path - developers.hubspot.com/docs/methods/tracking_code_api/set_page_path
Track Page View - developers.hubspot.com/docs/methods/tracking_code_api/track_page_view
Identify visitor - developers.hubspot,com/docs/methods/tracking_code_api/identify_visitor

Any thoughts or insight would be much appreciated! Thanks!

2

Hi @ryan.arhart, Happy to help out here. I’ve spoken with Audrey, Ron and Cooper about both issues you’ve stated above. I’ll address them as thoroughly as possible here:

  1. For your first issue where UTM parameters are being added between the hashes in your URL, this is expected and is a rule of the web. According to this stackoverflow article, the rules of RFC 3968 state that all hashes should come after query strings. The RFC resource refers to the URI generic syntax that all URIs follow. This behavior cannot be altered. You could write some JavaScript to remove the query parameters when the URL changes. Since you can’t remove query strings without reloading the page, you’ll need to detect a change in the URL and then remove, or have the page reload right away to get rid of them. You should be able to check if the URL has changed, then remove the query string. Or, it will just have to have those query strings there.
  2. For your second question, since Regex takes a bit longer to evaluate, and HubSpot will reject the contact if it takes more than 1 second to determine if the condition is true, I’d probably not suggest using that method. Also, RegEx is confusing
    exploding_head.png
    . That said, if you get it to work, then more power to you! You’re on the right path with your suggestion in that for SPAs we suggest using the Set Page Path and Track Page View functions. How this could work is you could use a JS function to grab the last part of the URL, set the page path with the Set Page Path function, then store it in the tracker with the Track Page View function. An example is shown on the overview page here. For your particular use case, you could listen for a change in the URL again as per what I wrote for 1, then run the Set Page Path and Track Page View functions on that.
// Assuming URL is: https://online.chrobinson.com/freightquote/?querystringshere#/free-quote/pickup
window.location.hash is #/free-quote/pickup

window.addEventListener("hashchange", function(){
 var url = window.location.hash;
 _hsq.push(['setPath', url]);
 _hsq.push(['trackPageView']);
});

Something like the above should work.

Let me know if you have questions about this.

3

Thanks for the response! All of those suggestions make sense.

For the tracking code before the #, I get it, but ultimately we can’t change it due to the infrastructure of the tools we’re building off of. Wish we could remove it, but we can’t. The good news is, after lots of testing, the utm in the middle of the URL appears to be only cosmetic. No issues using the site so we’re ok with it for now and we can revisit the removal of the query string and refresh of the page if necessary.

Also, after lots of trial and error, I found out that regex won’t work for us anyway. I was able to get it to work for the home page, but even if I wrote it correctly, the workflow wouldn’t recognize any part of my URLs past the #. And actually, none of the page view options in the workflow will recognize anything after the # is what I ultimately found out.

I was able to get page views working in my workflow by creating custom events in the analytics tools. I was able to use * as wildcards there and it even pickup portions of the URL past the #! So, at least I can correctly trigger if/then branches based on page views which was my biggest concern.

And thanks for the example code for tracking the page views for SPAs!

I appreciate the help!

4

Awesome @ryan.arhart, glad to hear you were able to get this going for you. Events are a good way to get this done since you can just attach event listeners to those buttons you have so segmentation based off those Events works well.