[hbcondo714]

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/

[cosmie]

That's definitely a really common issue. And correcting internal links when that happens is always a painful process - the artificially inflated site traffic figures it creates have likely been celebrated and publicized internally, and correcting the analytics (and the subsequent drop in traffic stats) gets treated as if you actually killed real traffic to the site in the process.

[kirillzubovsky]

Can you use your own domain as the `utm_source` and therefore, even if the session is being reset by an update in source, you will know that the sources is your own domain?

Might even be good, as a way to calculate how well your internal links are working in keeping the users within the property.

For example, put a link at the end of the blog post, and then track how many users clicked it, vs. how many exited on that page.

[cosmie]

The two issues you run into are:

- The primary attribution model in Google Analytics is last non-direct visit prior to <conversion/goal/significant event>. Leveraging the source tracking parameters (utm_*) on internal links obliterates the usefulness of much of the built in attribution-related reporting. Relatively recent enhancements do provide visibility into multi-channel funnel flows, but the capability is compartmentalized into a few purpose-built views and don't filter back to most of the core reporting.

- It also drastically skews engagement-related reporting, overall and at a source level. A new session in GA constitutes a completely new visit. So metrics like visits per user, new vs existing users, average visit duration, pages per visit, etc all get whacked in the process. And understanding user behavior and conversion paths from any given channel becomes somewhere between torturous and impossible, as the actions performed in the "new" session aren't visible when looking at the user flow of the original session.

What you're describing is possible and commonly done, you just can't do it with the utm parameters intended for source tracking without having disastrous side effects. Custom dimensions/metrics[1] or event hits[2] are the intended ways of doing that. For developers, Google's autotrack[3] library is useful for implementing that with fairly minimal dev overhead (mainly, seeding your markup with relevant data- attributes so event hits can be auto-populated and sent). There are also a lot of third party libraries for framework-specific integrations. And for non-developers, Google Tag Manager (or any other tag manager) makes event tracking pretty straightforward to implement without dev coordination.

[1] https://support.google.com/analytics/answer/2709828?hl=en

[2] https://support.google.com/analytics/answer/1033068?hl=en

[3] https://github.com/googleanalytics/autotrack/#overview

[gk1]

Does it still get counted as a new session if the domain is an excluded referrer? I thought not.

In any case, I agree and these workarounds are never worth the data doubt they introduce. There are ways to track internal flows without utm tags.

[cosmie]

That I'm not sure of. My hunch would be

- If you use utm_source=mysite.com by itself it likely would, as the medium would default to referrer and the data sent to GA would be the same as if no explicit parameters were defined.

- If you use utm_medium and set it to anything but referrer, it wouldn't be suppressed. I.e. mysite.com / referrer would get suppressed by the exclusion list and processed as a direct hit, but mysite.com / email would not trigger the exclusion list.

- If you use utm_source=mysite.com, don't use utm_medium (so it defaults to referrer), but leverage other parameters such as utm_campaign, I have no idea how it'd handle that state. I could see it either overriding the exclusion filter due to the explicitly stated campaign, or working like the normal exclusion filter and silently eating the additional utm parameters in the process.

Now I'm curious though - will have to test it out on a dummy property and see what happens!