I came across another article[1] on this and they state to "Never use UTM parameters on internal links (e.g., homepage sliders, internal banners, or internal links on blog posts). Clicking on those internal links will cause the current session to end and a new session to start—attributing the new session to the source/medium used on the internal link." [1] https://cxl.com/blog/utm-parameters/
How to use UTM parameters to grow your audience
31–40 of 57 posts
Re: How to use UTM parameters to grow your audience
#32“Grow your audience” is a stretch here. Better to say “...to see where traffic comes from.” If you want to go a step further and see which traffic sources lead to form completions (like newsletter or app signups), I made a utility that captures UTM parameters and then inserts them into any form submitted during that session: https://github.com/gkogan/sup-save-url-parameters
Nice work! Have you considered using localStorage instead of sessionStorage so it works across browser tabs as well?
Re: How to use UTM parameters to grow your audience
#33Earlier quoted context omitted.
Just to add to Peter's comment, the one issue with links via email/newsletters is that they show up as 'direct' traffic with no referral, so they are about impossible to link back to anything w/o the utm params.
You can make a dummy page for each email link that simply redirects to the correct page with the proper tracking information.
Re: How to use UTM parameters to grow your audience
#34Earlier quoted context omitted.
Yea, that combined with the User Activity API is incredibly handy. Especially useful to pull out when some anomaly occurs, and stakeholders suddenly want a particular conversion under the microscope (an unexpected enterprise user, unusually large order value, an unexpectedly frequent recurring customer, etc). That said, all of the browsers are becoming so aggressive about cookie management that relying on the Google-…
In the near future tracking won't be as easy as throwing a script from Facebook into a blog header. I wonder where it's leading. One guess I had is people will be plugging in web service calls to get the info behind the scenes and generate a first party cookie. Not sure if that capability exists yet but it does sound like your first link so I'll have a read, thanks. Edit: I had a look through that first link, nice ha…
And many of them offer a hybrid approach called CNAME cloaking[1], where you CNAME a subdomain on your host to the analytics/marketing system. That way you still leverage their infrastructure but they gain access to the first-party context. Here[2] is an example of that for Adobe Analytics.
Google Analytics doesn't officially support a CNAME implementation, so the above doesn't apply. The cookie service I referenced in the parent comment is a workaround for that. The GA code is still all third-party, but you create an internally hosted microservice that will set cookies when called out to. You hit that service (even via a third party tool like Google Tag Manager), it sets an appropriately named first party cookie in it's response, and you suppress GA from triggering it's usual cookie-setting properties (which would overwrite the first party cookie and get hit with ITP restrictions).
That said, ad networks are a different beast entirely. Some of them offer a CNAME cloaking implementation option, but it's less common than you'd expect. And few if any of them allow internal proxying of the tracking data. There's simply too much potential for fraud and too little trust between parties. "Offline" conversion tracking is pretty commonly supported though, which involves having a site capture a click identifier that an ad network appends to an ad click, then in an out-of-band process, upload conversion activity to the ad network using that click id as a key. Precludes the super invasive browser-side tracking, while still allowing for attribution and media effectiveness analysis.
[1] https://dev.to/dnsadblock/cname-cloaking-or-how-are-we-being...
[2] https://docs.adobe.com/content/help/en/id-service/using/refe...
Re: How to use UTM parameters to grow your audience
#35I don't understand why we have to store the entire dataset in the URL, when something like ?utm_id=1 (mapped to the others in some database) would do. It's stuff like this that prevents average users from "getting" URLs; they don't know what UTM is and assume it is important to get to the information. This garbage breaks the UX of the internet.
You don't have to; GA actually does support precisely the scenario you're proposing - you can use a random campaign key/identifier in a utm_id field, and upload a custom dataset mapping to GA that contains the details to map to the other utm fields. This[1] support article walks through the process. You just rarely ever see it because marketing execution is already an operational nightmare at most places (even more s…
Re: How to use UTM parameters to grow your audience
#36I don't understand why we have to store the entire dataset in the URL, when something like ?utm_id=1 (mapped to the others in some database) would do. It's stuff like this that prevents average users from "getting" URLs; they don't know what UTM is and assume it is important to get to the information. This garbage breaks the UX of the internet.
There is no need to, but doing it with id numbers would add a lot of friction on the content creator's side so that's why it isn't like that. The 'some database' is the problem - who owns it? Right now I can add whatever UTM parameters to any links I send without keying it into a database system, submitting a CR to the IT team, submitting it to Google, or any other nonsense. Details will be collected immediately whet…
Re: How to use UTM parameters to grow your audience
#37Earlier quoted context omitted.
In the near future tracking won't be as easy as throwing a script from Facebook into a blog header. I wonder where it's leading. One guess I had is people will be plugging in web service calls to get the info behind the scenes and generate a first party cookie. Not sure if that capability exists yet but it does sound like your first link so I'll have a read, thanks. Edit: I had a look through that first link, nice ha…
For purely analytics systems, it's already pretty easy to leverage server-side calls or an internal proxy service to route figures, which does truly mask where the data is going (but should still be disclosed in your privacy policy). And many of them offer a hybrid approach called CNAME cloaking[1], where you CNAME a subdomain on your host to the analytics/marketing system. That way you still leverage their infrastru…
Re: How to use UTM parameters to grow your audience
#38Earlier quoted context omitted.
You don't have to; GA actually does support precisely the scenario you're proposing - you can use a random campaign key/identifier in a utm_id field, and upload a custom dataset mapping to GA that contains the details to map to the other utm fields. This[1] support article walks through the process. You just rarely ever see it because marketing execution is already an operational nightmare at most places (even more s…
Thanks for the explanation. This really does makes sense.
Then on the receiving end, you use lookup tables or functions to decode the various aspects of the key, and explicitly define the relevant utm parameters in the call to Google Analytics (which it natively supports as an alternative to implicitly sniffing them from the URL string). Or if your encoding scheme is simple enough, you can send the key directly to GA and use Advanced custom filters[1] to decode the utm parameters there.
[1] https://support.google.com/analytics/answer/1033162?hl=en
Re: How to use UTM parameters to grow your audience
#39Earlier quoted context omitted.
Just to add to Peter's comment, the one issue with links via email/newsletters is that they show up as 'direct' traffic with no referral, so they are about impossible to link back to anything w/o the utm params.
You can make a dummy page for each email link that simply redirects to the correct page with the proper tracking information.
Re: How to use UTM parameters to grow your audience
#40Earlier quoted context omitted.
Thanks for the explanation. This really does makes sense.
One other thing to note is that there are a few alternatives which tend to be a bit more feasible to implement (and sustain). Namely, using a single campaign key but leverage an encoding scheme for the key/id rather than a randomly generated one. That way it can be parsed at collection time and every permutation doesn't have to be predefined in a dataset ahead of time. Then end users can still self-service link creat…