Support fix for rogue referral problem

[everyx]

More detail : nuxt/nuxt#6366

[pi0]

Hi @everyx @LuXDAmore. I'm so sorry it was stalled. Do you mind making a pull-request for feature support? Can be conditionally added here using new option like pushOriginalLocation (i would suggest turning off by default). Adding some docs would be also perfect.

[LuXDAmore]

Thank you @pi0 and @wusongliang for the PR,

Is there anything else I can do to help you? 😄

[everyx]

@LuXDAmore @pi0 @wusongliang

After testing on real projects, I found that the rogue referral problem is not a problem, the whole solution from Ahava's blog is wrong, and the solution from David Vallejo of fix tracker name is the final answer to solve this problem.

So I will close this issue, If people wants to save the OriginalLocation, they can using a pure GTM solution with Custom HTML and default {{ Page URL }}fallback or use a Custom Javascript Variable.

[sahava]

@everyx could you elaborate why the solution "is wrong"?

Setting the tracker name is very risky - GTM doesn't isolate hits from trackers when firing Universal Analytics hits. There are no hit-scoped settings only tracker-scoped settings. That's why GTM sets a unique tracker name for every tag, to avoid values from leaking from hit to hit.

When you set the tracker name across your tags, it means that all settings set by one tag are inherited by the next. This leads to huge problems when using any of the following:

• Non-interactive events, as the nonInteraction field value leaks to the subsequent Page View tags, leading to non-interactive Page Views and thus sessions that timeout prematurely (and have a 100% Bounce Rate).
• customTask that modifies the sendHitTask, as each tag uses the modified sendHitTask rather than a fresh task set for the newly created tracker (which no longer exists because you are recycling an older tracker).
• Hit-scoped custom dimensions, as those dimensions will be set on all subsequent tags as well that use the same tracker name.
• Any other hit-scoped fields you do not want to inherit to other tags.

Setting the location field is most certainly not wrong, and frankly it's a bit insulting to see someone jump to that conclusion after "testing on real projects". The originalLocation solution has been implemented for over 4 years across thousands upon thousands of SPAs without issues.

[sahava]

Here's my overview of why the Tracker Name setting is risky: https://www.simoahava.com/gtm-tips/be-careful-with-the-tracker-name-setting/

As you can see, GTM itself discourages with a very visible warning from setting Tracker Name.

[everyx]

Hi, @sahava , sorry I don't know why, but when I follow your solution in this article, I also have some wrong Organic Search with Google Analytics Event, and everything get work when I use the solution from David Vallejo of fix tracker name

[sahava]

Then the reason is elsewhere. From GA's POV, both setting the location and setting the tracker name have the exact same end result: the campaign info is preserved across SPA transitions.

Typical mistakes are having the originalLocation rewritten into dataLayer with every page transition (it should only be written once: when the page is first loaded), or forgetting to add the location and page fields to even a single GA tag - they need to be in all GA tags.

Neither David's or my solution protects the campaign against things like page reloads (as they preserve the referrer but reset the URL) or browser's back-forward cache.

I recommend setting the originalLocation fix as a configurable option. Users can still opt-in to the tracker name solution, keeping in mind the caveats I listed above. Those that don't want to risk data leaks or that don't want the overhead of having to remember to reset hit-scoped dimensions in all new and old GA tags, can use the originalLocation setup instead.

[everyx]

Then the reason is elsewhere. From GA's POV, both setting the location and setting the tracker name have the exact same end result: the campaign info is preserved across SPA transitions.

Typical mistakes are having the originalLocation rewritten into dataLayer with every page transition (it should only be written once: when the page is first loaded), or forgetting to add the location and page fields to even a single GA tag - they need to be in all GA tags.

Neither David's or my solution protects the campaign against things like page reloads (as they preserve the referrer but reset the URL) or browser's back-forward cache.

I recommend setting the originalLocation fix as a configurable option. Users can still opt-in to the tracker name solution, keeping in mind the caveats I listed above. Those that don't want to risk data leaks or that don't want the overhead of having to remember to reset hit-scoped dimensions in all new and old GA tags, can use the originalLocation setup instead.

@sahava Thanks, I noticed that google suggest Do not update the document location, maybe I have encountered some special situations and must use this setting.

[sahava]

That link is about setting up Google Analytics tracking with the analytics.js snippet (non-GTM). What it basically means is that if a unified tracker name is used then you should never update the location field. The analogy to GTM is that if you choose to use David's solution, you shouldn't update the location field.

But the problem is that analytics.js by default works differently from GTM, as I've explained above. GTM creates a single tracker for every hit, and that's why the location field needs to be overridden to appear as if GTM is using just a single tracker across all hits without having to set the tracker name, which is very risky.

[LuXDAmore]

Thanks You @sahava ,

Your explanation is incredibly accurate, I think it's a common mistake that many can fall into..

@everyx I've seen this PR is related to the issue, so i'm linking it here just as a reminder for future purposes.

🚀

[everyx]

@sahava After another test, I found the problem is location should place in global, if only set location to original location in pageview tracking, it will break by any another cutom event without location setting. :)