{"id":140,"date":"2026-07-22T09:21:00","date_gmt":"2026-07-22T07:21:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=140"},"modified":"2026-10-24T00:50:00","modified_gmt":"2026-10-23T22:50:00","slug":"ga4-server-side-gtm-the-migrate-from-javascript-managed-client-id-feature-explained","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-analytics\/ga4-server-side-gtm-the-migrate-from-javascript-managed-client-id-feature-explained\/","title":{"rendered":"GA4 & Server-Side GTM: The “Migrate from JavaScript Managed Client ID” Feature Explained"},"content":{"rendered":"

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.<\/p>\n

Separate the two settings<\/h2>\n

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

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

\n\"Comparison
JavaScript Managed and Server Managed are identification modes. The additional migration option concerns the transition; the outgoing client ID requires verification.<\/figcaption><\/figure>\n

What migration is intended to preserve<\/h2>\n

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. Already deleted or expired identifiers cannot be recovered through this setting.<\/p>\n

Describing migration as \u201cconverting the old cookie into FPID while keeping the GA4 identity identical forever\u201d is insufficient. The forwarded client_id<\/code> 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.<\/p>\n

HttpOnly provides a specific protection<\/h2>\n

HttpOnly<\/code> prevents direct access to the cookie from page JavaScript, for example through document.cookie<\/code>. This reduces simple cookie theft in some XSS 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.<\/p>\n

Two years in Safari is not guaranteed<\/h2>\n

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. FPID is not a universal ITP bypass.<\/p>\n

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.<\/p>\n

Test the transition deliberately<\/h2>\n
    \n
  1. Save the current container version and settings. Start with a separate test measurement setup.<\/li>\n
  2. Use a profile with an existing client ID and a fresh profile. Compare incoming IDs, response cookies and outgoing GA4 client IDs.<\/li>\n
  3. Test subsequent page views, existing FPID cookies, expired or removed identifiers, rejection and withdrawal separately.<\/li>\n
  4. Include every event route: browser events, server-side purchases, Measurement Protocol where applicable and multiple domains. Different IDs can split the same journey.<\/li>\n
  5. After a controlled release, monitor users, sessions and campaign assignment by browser against the actual rollout date.<\/li>\n<\/ol>\n

    An identifier change can weaken historical continuity. That does not mean every visit must become a new user or every conversion must become \u201cDirect \/ None.\u201d Other identity signals, campaign parameters and reporting settings affect the outcome.<\/p>\n

    \n

    Questions and answers<\/h2>\n

    Is migration always required?<\/h3>\n

    Keeping JavaScript-managed identification requires no FPID migration. An established measurement setup moving to Server Managed warrants specific transition testing. A new setup without existing identifiers has no such legacy population.<\/p>\n

    Does the identifier survive deletion of all cookies?<\/h3>\n

    A deleted FPID cookie is no longer available to the server. Recognition through other permitted signals is a separate matter; FPID alone does not restore the deleted identifier.<\/p>\n

    Is the internal migration algorithm fully established here?<\/h3>\n

    No. Public Google introductory documentation explains server cookies and processing but does not specify every internal transition case. Testing the deployed GA4 client version therefore remains part of the migration.<\/p>\n<\/div>\n

    \n

    Sources<\/h2>\n