For years, getting the GA4 client ID into a GTM variable meant parsing the _ga cookie with custom JavaScript — a brittle approach that broke whenever Google changed cookie formats or when users had ad blockers that modified cookie values. Analysts shared snippets, warned each other about edge cases, and patched the breakages when they appeared.
In January 2026, Google quietly shipped the fix: three new built-in GTM variables that expose GA4’s client ID, session ID, and session number directly — no cookie parsing required.
What the Three New Variables Do
Client ID (GA Client ID)
Returns the GA4 client ID — the anonymous identifier assigned to a browser/device. This is the value previously extracted from the _ga cookie (the part after GA1.1.).
Format returned: 1234567890.1234567890 (two numeric segments)
Use cases:
- Sending client ID to your CRM for cross-system user stitching
- Including client ID in server-side Measurement Protocol calls to ensure they match browser-side events
- Passing client ID to Google Ads for Enhanced Conversions matching
- Storing in a form hidden field so offline conversions can be tied to online sessions
Session ID (GA Session ID)
Returns the current session’s unique identifier. In GA4’s model, a session is identified by the combination of user_pseudo_id + session_id — this variable gives you the session-specific part.
Format returned: Unix timestamp of when the session started (e.g., 1737456789)
Use cases:
- Sending session ID to server-side systems for attribution lookup
- Correlating GA4 sessions with server logs or backend events
- Passing to ad platforms for server-side conversion deduplication
Session Number (GA Session Number)
Returns how many sessions this user has had on your site — 1 for first visit, 2 for second visit, and so on.
Format returned: Integer (e.g., 3)
Use cases:
- Segmenting events by first session vs. returning sessions
- Triggering different tags or content personalisation rules based on visit depth
- Enriching CRM records with engagement depth data
How to Enable the Variables
- Open your GTM container
- Variables → Configure (Built-In Variables section)
- Scroll to the Utilities section — you’ll find the three new variables listed:
- GA Client ID
- GA Session ID
- GA Session Number
- Check the box next to each you want to use
- They’re immediately available in tag fields, trigger conditions, and other variable references as
{{GA Client ID}},{{GA Session ID}},{{GA Session Number}}
No custom JavaScript, no regex, no cookie parsing. Done.
Replacing the Old Cookie-Parsing Workaround
If you currently use a custom JavaScript variable to extract the client ID from the _ga cookie, you can now replace it entirely. The old approach looked something like this:
// Old custom JavaScript variable — fragile and maintenance-prone
function() {
var cookie = document.cookie;
var ga = cookie.replace(/^.*;\s*_ga\s*=\s*/, "").replace(/;.*$/, "");
var gaParts = ga.split(".");
if (gaParts.length >= 4) {
return gaParts[2] + "." + gaParts[3];
}
return null;
}
This breaks when:
- The
_gacookie hasn’t been set yet (ad blocker, first page load race condition) - There are multiple
_gacookies from cross-domain scenarios - Google changes the cookie format (which they have done historically)
- The user deletes cookies mid-session
The new built-in variable reads directly from GA4’s internal state — not from the cookie — so it’s reliable even in scenarios where the cookie hasn’t been written yet.
Practical Use Case: Passing Client ID to Your CRM
One of the most common uses for the client ID is tying GA4 sessions to CRM contacts — when a user submits a form, you capture their client ID and store it against their CRM record. Later, when they convert offline (phone call, in-person visit), you can tie the offline conversion back to their original online session.
GTM Setup
-
Create a new GA Client ID built-in variable (checkbox as above)
-
In your form submission tag, add the client ID as a custom parameter:
Tag: GA4 Event — form_submit
Event parameters:
client_id → {{GA Client ID}}
session_id → {{GA Session ID}}
session_number → {{GA Session Number}}
- In your form’s hidden fields (if you’re submitting to a backend):
Add a hidden field via Custom HTML tag on form load:
<script>
document.getElementById('ga_client_id').value = '{{GA Client ID}}';
document.getElementById('ga_session_id').value = '{{GA Session ID}}';
</script>
This sends the GA4 identifiers with every form submission, making them available in your CRM system.
Use Case: Server-Side Measurement Protocol Matching
When you send events via the GA4 Measurement Protocol (server-side), they must include the correct client_id to be attributed to the right user in GA4 reports. Previously, you’d need to capture and store the client ID from the browser and pass it server-side — the tricky part was reliably extracting it in the first place.
With the new built-in variable, here’s the clean flow:
- User lands on your site → GTM fires,
{{GA Client ID}}becomes available - On checkout or form submit → send
client_idto your server (via form hidden field, AJAX, or dataLayer) - Server stores the client ID with the order
- On order confirmation webhook → server sends Measurement Protocol event with the stored
client_id
# Server-side purchase event with correct client_id
import requests
def send_purchase_event(order, ga_client_id):
payload = {
"client_id": ga_client_id, # captured from browser via GTM variable
"events": [{
"name": "purchase",
"params": {
"transaction_id": order["id"],
"value": float(order["total"]),
"currency": "GBP",
"items": [...]
}
}]
}
requests.post(
"https://www.google-analytics.com/mp/collect"
"?measurement_id=G-XXXXXXXX&api_secret=XXXXXXXX",
json=payload
)
The client_id from {{GA Client ID}} is now reliable — no risk of cookie-parse failures corrupting your server-side events.
Use Case: Session Number–Based Trigger Logic
The session number variable enables trigger conditions based on how many times a user has visited:
Example: Show a “returning visitor” offer only from the second session onwards
- Create a trigger condition:
{{GA Session Number}}greater than1 - Apply this trigger to a tag that shows a returning-visitor-specific banner or personalisation
Example: Fire a different ad conversion tag for first-time vs. returning purchasers
Trigger A: purchase event AND {{GA Session Number}} equals 1 → fire "New Customer" conversion tag
Trigger B: purchase event AND {{GA Session Number}} greater than 1 → fire "Returning Customer" conversion tag
This kind of session-depth logic used to require custom JavaScript and cookie inspection. Now it’s a two-field trigger condition.
Things to Know
The variables require GA4 to be initialised. These built-in variables read from GA4’s internal state, which means a GA4 Configuration tag (or gtag('config', ...) call) must have fired on the page before the variables return values. If your event tag fires before GA4 initialises, the variables may return undefined.
Best practice: Ensure your GA4 Configuration tag has higher priority than event tags (Priority 10 vs. 0 in GTM tag settings).
Cross-domain note: The client ID from {{GA Client ID}} reflects the ID in the current domain context. In cross-domain setups, confirm you’re reading the ID from the right domain context before passing it server-side.
This is a small but genuinely useful update that removes a category of fragile custom code from GTM containers. If you maintain a custom _ga cookie parser variable, it’s worth replacing it with the built-in equivalent in your next GTM deployment.