Client Hints Break Traffic Channel Attribution

[bradymwilliams]

Related: https://github.com/epicweb-dev/epic-stack/issues/580#issuecomment-1936493032

I had migrated from a simple stack on Vercel to the Epic Stack on Fly (❤️ love it) and had assumed I had some redirect breaking channel attribution in GA and spun out on that for a while.

Last week I was looking thru the client hints code and had an A-ha seeing the window.location.reload(); in there. A page reload sets the page referrer to the current page and since client-hinds runs inline at the top of the document, it runs before any analytics does. In the chart below you can see my direct traffic goes to normal levels after I removed the client hint code.

For my site, assuming many others, understanding attribution as accurately as possible is important for verifying success of paid campaigns, social media, emails etc. We should probably document this trade-off and maybe offer some sort of opt-in or manual handle of reload on cookie diff to preserve referrer?

[kentcdodds]

Ah! That explains it.

Yes, we definitely want to document this trade-off asap. But we also should see whether there's a way to preserver the referrer information as part of that reload. I'm open to suggestions.

[kentcdodds]

What if you put the google analytics information ahead of the client hints script? 🤔 Still thinking about this. I guess you'd get users double-counted if we did that though...

[bradymwilliams]

Yeah that would get double counted. I haven't tested but I think we could replace the .reload() with current location + document.referrer in a param and to grab and send that to analytics? I know the fathom will work, but GA4 I'm less confident about overriding event params lately. GA4 is a mess.

let referrer = // get from url param

fathom.trackPageview({
    referrer
});

gtag('set', 'page_referrer', refferer);

Now I've got attribution fixed it'll will be a while before I can reimplement and test things but hope to revisit come march, just wanted people made aware.

[kentcdodds]

Perhaps we could do a server-side redirect instead. I'm pretty sure that would be more efficient as well. The biggest trick is detecting whether the user has disabled cookies altogether, but I think that's something we can address. I'll be looking into this.

[kentcdodds]

I just realized that we can't do a server-side redirect in this case because the server doesn't have the information necessary to set the cookies. That's why we have to do this on the client in the first place 🤦‍♂️

So I think documenting this is probably the best we can do. If you would like to put together an example of how to do this properly as well that would be enormously helpful.

[kentcdodds]

I've just released a new version that will not refresh the page if the users preferences are the same as the fallback values. That's not going to fix everything, but if you have a good idea of what most of your users preferences are, then you should have a lot fewer users triggering a refresh. Unless you are using the time zone client hint, in which case you're out of luck for most users.