How to Fix Lost GCLID with Google Analytics 4 Consent Mode

Track Google Ad Conversions with Cookie Consent Managers


Hi!
We’re now integrating explicit consent cookie banners for our customers.
That means that the analytics code will definitely not be fired on the first pageload when the gclid is passed on and would usually be written to the Analytics cookie.
The consent might be given later on that page or on subsequent pages.
How do we achieve that the gclid information doesn’t get lost and can be picked up by analytics later in the session?
Thank you!
Details
code_implementation

Locked

The short answer is:

What is the most effective way to persist gclid across pages when initial cookie consent is denied?

The most robust and compliant solution to persist the gclid and attribute conversions correctly, despite delayed cookie consent, is to implement server-side tracking using Google Tag Manager (GTM) Server Container hosted on a platform like Stape or Google Cloud Platform (GCP), combined with Google’s Consent Mode and the Google Analytics Measurement Protocol and Google Ads API for final conversion reporting.

On the first page load, even with consent denied for ad_storage and analytics_storage, the gclid present in the URL is captured by the GTM web container’s Conversion Linker tag and sent as a first-party cookie to your custom-domain tagging server (Stape).

This bypasses most browser restrictions, as the server is running on a first-party context.

When the user later grants consent, the server uses the persisted gclid and the Google Analytics Measurement Protocol to correctly send the full-fidelity data, including attribution, or the Google Ads API for direct conversion reporting, ensuring accurate linking of the conversion to the original ad click.

The long answer is:

The problem of losing the Google Click Identifier (gclid) arises because the client-side Google tags, which typically read the gclid from the URL and write it to a cookie, are blocked from firing until explicit consent is given, which may happen on a subsequent page or after a significant delay.

This is an issue of client-side tag dependency on user consent for cookie access.

The technical and cost-effective solution is to decouple the initial gclid capture from the user’s browser-side cookie-setting permissions by shifting to a server-side tracking architecture using Google Tag Manager Server Container hosted on a platform like Stape or GCP.

Hereโ€™s the breakdown: First, you must implement Google’s Consent Mode in your GTM Web Container, which dynamically adjusts tag behavior based on the user’s consent status.

Second, you configure your GTM Web Container to send all events, including the initial Page View (or a dedicated GCLID_Capture event) to your custom-domain Tagging Server (Stape/GCP).

Crucially, the Conversion Linker tag on the client-side must be configured to fire on all pages, even when ad_storage is denied, but with its cookie-setting function respecting the consent signal (Advanced Consent Mode).

However, the real advantage comes from the server.

The Conversion Linkerโ€™s first-party cookie-writing mechanism can be made more resilient against Intelligent Tracking Prevention (ITP) and similar browser restrictions when its request goes to a first-party custom domain, which is what Stape provides.

When the request, which includes the gclid from the URL, hits your Stape server, a GA4 Client in the server container processes it.

The gclid, passed in the URL parameter, is captured and stored on the server-side, perhaps in a first-party cookie on the user’s browser via the tagging server’s response, or in the server’s data store, regardless of the initial analytics_storage and ad_storage status.

When the user eventually grants consent on the same or a later page, a new event is sent to the server.

The server-side tags for Google Analytics 4 and Google Ads Conversion Tracking then retrieve the previously persisted gclid and enrich the event data.

The server then uses the Google Analytics Measurement Protocol to forward the complete event data to Google Analytics 4, ensuring the session and conversion are correctly attributed.

For robust Google Ads conversion reporting, the conversion event can be sent directly using the Google Ads API, using the previously saved gclid for a definitive, server-to-server match.

This server-side approach is cost-effective because it uses existing Google technology (GTM/GA4) and affordable cloud hosting (Stape/GCP), resulting in better data quality and less dependency on ever-changing client-side browser rules, ultimately improving campaign optimization and ROI.

Additionally, leveraging the BigQuery API allows you to export your GA4 data to BigQuery for advanced, long-term analysis, correlating the server-side tracked conversions with other business data for a complete picture.

About The Author