Defining Users - Switching to Server Managed Client Identification

[Ross_Hopkins]

I saw this post on LinkedIn yesterday and found it really interesting: 𝗛𝗼𝘄 𝗮𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗰 𝗚𝗔𝟰 𝗲𝘃𝗲𝗻𝘁𝘀 𝗾𝘂𝗶𝗲𝘁𝗹𝘆 𝗿𝘂𝗶𝗻 𝘆𝗼𝘂𝗿 𝘀𝗲𝗿𝘃𝗲𝗿-𝘀𝗶𝗱𝗲 𝘁𝗿𝗮𝗰𝗸𝗶𝗻𝗴 | Alex Ignatenko

I replied to the post, and I didn’t feel my questions were answered in full:

We don’t have automatic events enabled, but the discussion around adopting the FPID cookie challenged me. Our GA4 reporting identity is set to “Blended”, and our sGTM GA4 client is set to “JavaScript Managed” for Cookies and Client identification:

With that being the case, how have people handled the switch from JavaScript to FPID cookie identification? Is it a case of just accepting all users will be “New” in reports for a while, even if they would be returning if JS was still selected?

And again, if user_id is set when a user logs into an account, how does that factor into managing the change?

To put it bluntly, I want to understand if FPID is “better” here. I have worked with Stape a lot (thanks @Alex !) and I am extremely grateful for the support, but our Direct / Missing Data attribution volume is still so high, I am always looking for ways to minimise.

[jeppe_Nielsen]

If you hard switch to serverside managed client id, its true you will probably see a spike in users in GA4, because people will get counted as new even tho they are not.

I usually use set it to server managed client id, and then also tick the box “migrate from javascript managed client id” . This way new users get the FPID and old users will keep on with JS managed client id and you will avoid spike in users etc.

I dont know if this was your question