Moving GA4 Visitor IDs to the Server: The Tag Manager Migration Option

The GA4 client in server-side Google Tag Manager receives measurement requests and prepares events for server tags. Client identification determines the browser identifier in outgoing GA4 data. Changing that identifier can affect user counts, session association and longer-term analysis.

Separate the two settings

JavaScript Managed uses the client ID supplied by the browser. The usual _ga cookie contains that identifier alongside format components: GA1.1.123456789.1680000000 is a cookie value, while 123456789.1680000000 is the client ID within the value. A client ID is not a reliable identity for a person.

Server Managed uses a server-managed identifier, typically stored in the FPID cookie. An HTTP response sets this cookie, which remains stored in the browser. The additional Migrate from JavaScript Managed Client ID option concerns the transition from existing browser identifiers; the checkbox does not itself select the management mode.

What migration is intended to preserve

For an existing measurement setup, migration is intended to avoid an abrupt change of existing client IDs. This is neither a retrospective merger of all identifiers nor a guarantee of unchanged attribution, meaning the assignment of a conversion to a marketing source. Already deleted or expired identifiers cannot be recovered through this setting.

Describing migration as “converting the old cookie into FPID while keeping the GA4 identity identical forever” is insufficient. The forwarded client_id is what matters. Before changing production settings, comparison of incoming and outgoing identifiers in the deployed client version must establish how existing IDs, fresh profiles and existing FPID cookies are handled.

HttpOnly provides a specific protection

HttpOnly prevents direct access to the cookie from page JavaScript, for example through document.cookie. Cross-site scripting (XSS) means that injected malicious code runs in a website’s context. HttpOnly reduces simple cookie theft in some of these attacks. The website does not become immune to XSS: malicious code can still modify page content or initiate requests. An analytics identifier is also different from a login session cookie.

Two years in Safari is not guaranteed

A configured expiry date does not guarantee actual retention. WebKit can also restrict cookies set in HTTP responses: detected third-party CNAME or IP cloaking triggers a seven-day cap. Private sessions, cookie deletion and browser settings can further reduce availability. ITP is WebKit’s Intelligent Tracking Prevention, a set of browser measures that limit tracking. FPID does not bypass these measures in every situation.

Testing must cover the first-party endpoint, cookie domain, path, HTTPS and actual browser responses. Consent requirements still apply to storing and using the identifier.

A controlled transition test

1. The current container version and settings are saved first. Initial tests use a separate measurement setup.
2. A profile with an existing client ID and a fresh profile provide two test cases. The comparison covers incoming IDs, response cookies and outgoing GA4 client IDs.
3. Separate tests cover subsequent page views, existing FPID cookies, expired or removed identifiers, rejection and withdrawal.
4. The test covers every event route: browser events, server-side purchases, Measurement Protocol where applicable and multiple domains. Different IDs can split the same journey.
5. After a controlled release, monitoring compares users, sessions and campaign assignment by browser with the actual rollout date.

An identifier change can weaken historical continuity. That does not mean every visit must become a new user or every conversion must become “Direct / None.” Other identity signals, campaign parameters and reporting settings affect the outcome.