Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove UA client ID from stub attribution #14406

Open
Tracked by #13238
stephaniehobson opened this issue Apr 3, 2024 · 4 comments
Open
Tracked by #13238

Remove UA client ID from stub attribution #14406

stephaniehobson opened this issue Apr 3, 2024 · 4 comments

Comments

@stephaniehobson
Copy link
Contributor

stephaniehobson commented Apr 3, 2024

** ⚠️ Wait for July 2024 ⚠️ **

The UA/GA3 code will stop working at the end of June. At that time we will not have a UA stub attribution ID to log anymore and should remove the code that captures and sends it.

Let @willdurand know when this is complete so he can remove the corresponding code from stub attribution.

@alexgibson
Copy link
Member

@stephaniehobson if the UA/GA3 code will stop working at the end of June, shouldn't we remove the check before that happens as opposed to after? Or is there a reason why we should wait?

@stephaniehobson
Copy link
Contributor Author

There's some people who are still relying on custom reports in the GA3 interface. I wanted to leave it as long as possible. Still, mid-June should be okay. I'll confirm in the migration channel and assign an earlier start date if I can.

@alexgibson
Copy link
Member

alexgibson commented Apr 16, 2024

There's some people who are still relying on custom reports in the GA3 interface.

My main concern would be if something in our attribution code blows up, should the GA3 code suddenly stop working. If we can set a date to remove this code before the end of June, that would ease the risk I think.

@stephaniehobson
Copy link
Contributor Author

I've asked in #ga4-migtation-2024 on Slack if we can start mid-June. The main concerns seems to be with YoY comparison for the KBR - but if the Big Query sync stops before June we don't have it anyway.

Not to mention the other costs with running the code in parallel. Hopefully we can solve this with planning and math 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants