Consent Is a Design Parameter
When a user declines, the tag behaves differently. That is not a failure state, it is the system working as intended. The problem is not that you cannot measure without permission, it is not having built the signal architecture that works alongside the constraint.
Google designed Consent Mode for exactly this case. The framework answers one question: when you cannot write a cookie, which signals can still be collected, and what can be learned from them?
In order: the Consent Mode signal architecture, cookieless tracking parameters, the Conversion Linker move to localStorage, the modeled conversions mechanism, Enhanced Conversions, and finally the external approaches such as sGTM, tag gateway and CNAME.
Consent Mode V2: A Signal Architecture by Design
The two modes are best understood through their technical behaviour.
Basic mode: no Google tag fires until the banner is accepted. If the user declines, no signal at all is collected for that session.
Advanced mode: the tag fires in every case. Without consent, however, the tag does not:
- Write cookies (none, including
_gaand_gcl_aw) - Fingerprint
- Pick up cross-site tracking
Instead it does:
- Send a ping to the URL (which page was visited, browser type, page category)
- Communicate consent state through the
gcsparameter - Communicate the pre-consent default state through the
gcdparameter
The gcs and gcd Parameters
gcs (Google Consent State) encodes consent state in a two character code:
| gcs value | Meaning |
|---|---|
| G100 | ad_storage and analytics_storage denied |
| G110 | analytics_storage granted, ad_storage denied |
| G111 | Both granted |
| G000 | Consent not yet collected (pending) |
| G1— | The site does not require consent for that type |
The parameter is appended to every request going to Google’s servers. Even with no cookie, the context the measurement happened in is recorded. Modeled conversions are built on top of these signals.
gcd (Google Consent Default) encodes the default consent state at page load. In advanced mode the correct structure is to set the default to denied and update it from the user’s choice:
// At the top of the page, before any tag runs
gtag("consent", "default", {
ad_storage: "denied",
analytics_storage: "denied",
ad_user_data: "denied",
ad_personalization: "denied",
wait_for_update: 500,
});
// When the CMP grants consent
gtag("consent", "update", {
ad_storage: "granted",
analytics_storage: "granted",
ad_user_data: "granted",
ad_personalization: "granted",
});The wait_for_update: 500 value covers the banner load delay. Depending on CMP performance it can be tuned between 300 and 1000 ms.
Cookieless Conversion Tracking: wbraid and gbraid
gclid is the ad click parameter appended to the URL. But gclid is cookie based: on arrival it is stored in the _gcl_aw cookie, and at conversion time that cookie is read. Safari ITP can cap that cookie at 24 hours, and without consent it cannot be written at all.
On the Safari side there is a second mechanism, and it does not shorten cookie lifetime, it removes the parameter entirely. Apple’s Link Tracking Protection strips known click parameters from the address before navigation happens. Because the parameter never reaches the site, catching it server side is not possible either; moving to server side does not close this loss. The scope is narrow: Private Browsing, plus links opened from the Mail and Messages apps. It does not run in regular Safari sessions by default, only when the user turns advanced protection on for all browsing. Apple does not publish which parameters get stripped; the finding that gclid is one of them rests on practitioner testing, and several independent sources report the same result.1 That UTM parameters pass through untouched is consistent with WebKit’s own example. I collected which browser trims which parameter, and what that means for gateway design, in the anatomy of a URL for tracking.
Google answered this problem with two parameters: wbraid and gbraid2.
| Parameter | Scenario | Mechanism |
|---|---|---|
| gclid | Standard web conversion | Cookie (_gcl_aw) |
| gbraid | iOS web-to-app conversion | URL parameter, processed server side |
| wbraid | App-to-web conversion | URL parameter, processed server side |
The mechanism column should not say “cookie independent”, because that is not true: Google’s own page says that when wbraid arrives, the Google tag still sets a first-party cookie on your domain.2 The link itself is established through the URL parameter, but the cookie does not drop out of the picture.
The wbraid and gbraid values stay in the URL parameter and do not need to be written to a cookie to link the click. Google Ads processes these parameters server side. When consent is declined the cookie cannot be written, but the URL parameter is still there, and Google’s server can attribute the conversion from it.
Looking at an ad click URL is enough to see these parameters. Having the Conversion Linker tag active is what keeps them correctly preserved.
Conversion Linker and localStorage
Conversion Linker is the component of the Google tag ecosystem responsible for preserving ad click parameters. Capturing and storing gclid, wbraid and gbraid, and preserving them across page and domain boundaries, is its core function.
In November 2024 Conversion Linker behaviour changed: ad click information is now written to localStorage in addition to the cookie3.
localStorage does not travel to the server and is not subject to the 24 hour cap ITP applies to cookies. The click attribution window widens accordingly.
How does that localStorage write interact with consent? When ad_storage=denied, Conversion Linker writes no cookie; how the localStorage write is affected by consent mode is not clear in Google’s documentation. Technically localStorage is not a cookie, but it would be expected to fall under “ad storage”. To verify the actual behaviour you have to watch the localStorage write from the Tag Assistant Network tab.
Modeled Conversions: A Statistical Approach With Visible Limits
Advanced mode signals and wbraid/gbraid data feed Google’s modeled conversions engine. The mechanism is this:
- The behaviour pattern of consenting users is observed (observed conversions)
- Users in a similar context (page type, device, campaign) who did not consent are identified
- A statistical model estimates the likely number of conversions for the non consenting segment
- That estimate is added to Google Ads reports as a modeled conversion
Important limits:
- Modeled and observed conversions are not shown separately in Google Ads reports
- Google does not explain how the model works; quality varies with segment size and data richness
- At low consent rates or low traffic volume, model reliability drops
- The model is a statistical estimate, not individual user tracking
Two of these limits are given in Google’s own documentation with a number and a direction, so they deserve to stand on their own.
Modeling depends on an eligibility threshold. A modeled conversion is not created for every declined visit. The threshold itself is not consistent across Google’s own documentation. The consent mode modeling page looks for seven hundred ad clicks over a seven day period, per country and domain grouping, and draws no distinction between basic and advanced implementation.4 The newer modeling guide gives one hundred clicks per day instead, and states that this condition is required for basic implementation but not for advanced.5 Both pages are live, so quoting a single number as the rule is misleading. What holds in practice is this: modeling does not kick in on every account, and where it does not, the declined volume never appears in the report at all. That is why the expectation that “we moved to advanced mode, the loss will close” may not be met on a low volume account. Before applying the threshold to your own account, check the date of the page and which implementation type it is talking about.
The model is built to undercount. Because the goal is to avoid overestimating, some conversions that did in fact happen are not counted, and Google states this explicitly.4 So the modeled number does not carry a risk of overestimating. That it is a mathematical lower bound is not guaranteed; the documentation states only the direction of the model.
There is one more detail on the reporting side. Modeled conversions sit inside the Conversions column and flow into every sub-report that uses that column.4 They have no separate column or segment, so they cannot be tied to a specific order either. For anyone comparing a conversion report against the store’s own order records, this volume is an item that has to come off the denominator from the start.
Enhanced Conversions: Data the User Volunteers
Enhanced Conversions hashes the first-party data a user leaves at conversion time (email, phone) and sends it to Google. There is no cookie dependency, so attribution can be established through an email match even when the GCLID cookie has expired or was never written6.
The legal frame: this is data the user gave voluntarily (the email entered at checkout). But the user is expected to have been informed that it will be passed to Google for advertising purposes, which means ad_user_data consent should have been collected. Technically it needs no cookie, legally it needs permission to process data.
How It Works
User data is pushed to the dataLayer at conversion time:
dataLayer.push({
event: "purchase",
user_data: {
email_address: "user@domain.com", // SHA-256 is done by Google
phone_number: "+905xxxxxxxxx", // E.164 format
},
ecommerce: {
transaction_id: "ORDER-123",
value: 299.99,
currency: "TRY",
},
});The raw email does not go to Google; the SHA-256 hashing is done by the Google tag in the browser. Google matches that hash against the user records in its own system.
Precondition: user data has to exist at the conversion point. Guest checkout, purchase without an email, or forms where phone is optional do not supply data in this scenario.
There are two more limits, and both change the setup decision.
It does not work on clicks carrying gbraid or wbraid. The Google Ads API documentation states this plainly: enhanced conversions for web does not support these clicks.7 So the orders that received these parameters instead of a click ID, because ATT permission was not granted on iOS, cannot be recovered through enhanced conversions either. That group is only reconciled in Google’s own reporting, not in your measurement layer. This also explains why the wbraid and gbraid rows stand apart in the table above: the price of cookieless tracking is that those orders are not visible at row level on your side.
The setup method is no longer a choice. Two changes landed through 2026: from April, user provided data is accepted simultaneously from the site tag, from Data Manager and from the API connection; and from June the two separate features on the web and lead side merged into a single on-off setting.8 Older setup notes that suggest choosing between the tag and the API need updating.
sGTM, Tag Gateway, BigQuery and CNAME
Some technical approaches sit outside the consent boundary but inside an area that affects browser privacy measures.
sGTM and First-Party Cookie Writing
sGTM is a server container running on your own subdomain (gtm.yoursite.com). The cookies it writes with a Set-Cookie header are not JavaScript cookies but HTTP cookies, so the seven day cap ITP applies to cookies written with JavaScript does not apply to them directly.
That much is true, but left on its own it misleads. WebKit’s own documentation says: ITP detects third-party CNAME cloaking and third-party IP address cloaking, and caps the expiry of any cookies set in the HTTP response of those requests at seven days as well.9 So writing server side does not grant an exemption independent of where the subdomain resolves.
Two conditions follow in practice. If the subdomain is bound by CNAME to a vendor’s domain, the seven day cap comes back; that is already the subject of the CNAME cloaking section below. And if the subdomain resolves directly to an IP, what decides it is whether that IP counts as the same party as the main domain’s IP. WebKit publishes the criterion for that comparison: two addresses are considered different parties if one is IPv4 and the other IPv6, if both are IPv4 and the length of the common subnet mask is less than sixteen bits, or if both are IPv6 and the common mask is less than sixty-four bits.9 The same paragraph also states that the detection is heuristic and may change in the future, so a setup tuned to the exact edge of the threshold is leaning on a number that is not fixed.
There is a distinction that gets confused often here: the comparison is between the server IPs that the main domain and the tag serving subdomain resolve to. It has nothing to do with the visitor’s IP, so features that change the visitor’s address, such as iCloud Private Relay, do not enter this calculation. Their effect shows up not in cookie lifetime but in IP based geographic enrichment, deduplication and bot filtering.
So “we installed sGTM, the cookie lifetime problem is solved” is not a verifiable sentence on its own. A default Cloud Run setup comes with its own IP range, so it most likely does not provide that alignment. Verification is done by measurement: after installation, look at how many days the cookie actually lives in Safari. On the Chrome side there is also a four hundred day upper bound for every cookie carrying an explicit expiry, in force since M104.10
ITP is a browser privacy measure. sGTM technically disables it. That sits outside the consent question (ITP’s purpose is not consent, it is preventing cross-site tracking), but it does affect a privacy decision the browser made on the user’s behalf.
On consent it is clear: sGTM writes no cookie when ad_storage=denied. It does not violate consent rules. It technically gets around the privacy measure ITP targets, and that part is debatable.
The undisputed value of sGTM: managing Consent Mode signals, Enhanced Conversions and third-party platform integrations such as Meta CAPI centrally in a single server layer. For multi-platform setups the operational advantage is large.
Google Tag Gateway
A second option on the same axis. The Google tag loads from your own domain, and measurement requests go to your own domain first and are forwarded to Google from there.11 Setup requires a CDN or load balancer that can forward requests; Google lists Cloudflare, Akamai, Fastly and Google Cloud, and recommends pairing it with sGTM for the most durable setup.
The gain here comes from the same place as with sGTM: because the request is answered from your own domain, the cookie can be written server side. So the condition above applies here too, and is in fact easier to skip over. Google’s documentation makes no explicit commitment about cookie lifetime; what is promised is signal recovery, not cookie lifetime. The two should not be treated as the same thing.
BigQuery Raw Data Export
The GA4 BigQuery export provides, at event level, the data the UI serves aggregated. Nothing changes on the consent side: modeled events for users who did not consent are flagged as modeled in BigQuery too.
The BigQuery export does not change measurement quality, it increases analysis flexibility. Installed with the wrong expectation (recovering data without consent) it will disappoint.
CNAME Cloaking
CNAME cloaking means running a third-party tracker under a first-party domain through a DNS CNAME record. The browser’s tracker blocking list cannot recognise the domain, because the domain looks like yours.
IAB Europe and browser vendors consider this approach unethical12. It can be run with Consent Mode but it solves no consent problem; it uses DNS manipulation to hide the tracker. Not recommended in production.
Implementation Priority
The three layers do not have to be implemented at once. Where to start depends on budget allocation and existing infrastructure.
1. Consent Mode V2 Advanced (the mandatory starting point)
A policy requirement for Google Ads accounts with EU traffic. Without the integration, remarketing and audience targeting are disabled for EU traffic. If a CMP is already active the technical cost is low: the consent default setting in GTM and the CMP’s update call.
Verification: do the gcs parameter and the consent command appear in the Google Tag Assistant Network tab?
Implementation note: always call the consent update before a page transition, on the page where the user gave permission. A late update causes session_start loss in GA4. If the call is made right before page unload, the browser can cancel the network request.
2. Enhanced Conversions (if there is a Google Ads budget)
A priority if user data is collected at the conversion point (checkout, signup form, demo request). ad_user_data consent must have been collected. A completed Google Ads conversion tracking setup is a precondition.
3. sGTM (multi-platform or scale)
If there is a Google plus Meta or another platform combination, sGTM infrastructure can be used to manage consent signals centrally at high traffic volume. The upfront cost is high but every layer ends up managed from one place.
Which Structure, When
| Layer | Consent compliance | Grey area | Precondition |
|---|---|---|---|
| Consent Mode V2 Advanced | Fully compliant | No | CMP active, GTM installed |
| wbraid / gbraid | Fully compliant | No | Google Ads + Conversion Linker |
| Modeled conversions | Fully compliant | No | Advanced mode active |
| Enhanced Conversions | Compliant (ad_user_data needed) | No | User data at the conversion point |
| sGTM first-party cookie | Consent compliant, ITP debatable | Partly | Server infrastructure, subdomain, subdomain not hidden behind a CNAME |
| Google tag gateway | Fully compliant | No | A CDN or load balancer that can forward requests |
| BigQuery export | Fully compliant | No | GA4 BigQuery connection |
| CNAME cloaking | Debatable | Yes | Not recommended |
The post where I covered the structural effect of consent and GDPR on measurement explains the legal background of this table in detail. The one on data discrepancies between analytics platforms shows how modeled data creates inconsistency between GA4, Google Ads and real conversion figures.
June 2026: A Change of Control Point
From 15 June 2026, Google is consolidating the data controls between GA4 and Google Ads. The change raises the importance of the signal architecture above directly.13
The role of Google Signals narrows. Until now Google Signals controlled both signed-in user data in behavioural reporting and Google Ads cookie/ID collection. From 15 June, Signals will control behavioural reporting only. Control of Ads data collection moves entirely to Consent Mode.
The gcs/gcd parameters and the consent default structure in this post become more critical. The “CMP active, GTM installed” precondition in the table above is no longer enough. The CMP must pass all four consent parameters (ad_storage, ad_user_data, ad_personalization, analytics_storage) correctly. Signals will no longer act as a fallback.
Ads personalization moves too. Later in 2026 the layered ads personalization settings in GA4 (account, property, Ads link, event) will be removed. The ad_personalization consent parameter becomes the single control point. This directly affects remarketing audiences and DV360/SA360 integrations.13
The detailed preparation guide and checklist is the reference for this transition.
Footnotes
-
Apple does not publish the list of stripped parameters. Private Browsing 2.0 only describes the class: “query parameters that have been identified as being used for pervasive cross-site tracking granular to users or clicks”. That
gclidbelongs to that class rests on practitioner testing; AppsFlyer’s iOS 17 bulletin reports that in its own testsgclidandfbclidwere stripped while UTM parameters were preserved. ↩ - Updates to campaign measurement in iOS 14 and later, Google Analytics Help. The direction verbatim: “For web to app measurement, the parameter is known as GBRAID, and for app to web measurement, it’s known as WBRAID.” The first-party cookie sentence is on the Google Ads page instead: Updates to iOS 14 campaign measurement, “To support this new parameter, the Google tag (gtag.js), Google Tag Manager (gtm.js), and Google Analytics (analytics.js) with a linked Google Ads account will set a new first-party cookie on your domains by default.” ↩ ↩2
- Conversion Linker storage update, Google Tag Manager Help ↩
- About consent mode modeling, Google Ads Help. The eligibility threshold verbatim: “a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping”. The same page also states that the model aims to avoid overestimating and that as a result “some conversions that in reality occurred may not be accounted for.” Modeled conversions appear in the Conversions column and flow into the sub-reports that use it. ↩ ↩2 ↩3
- Conversion modeling for consent mode (Google Ads Help). The threshold verbatim: “Have an ad click threshold of 100 clicks per day, per country and domain grouping. This eligibility condition is required for basic consent mode implementation but not for advanced implementation.” ↩
- About enhanced conversions for web, Google Ads Help ↩
- Manage online click conversions, Google Ads API. The error table states that enhanced conversions for web is not supported for clicks carrying gbraid or wbraid: “Google Ads does not support enhanced conversions for web for these conversions.” ↩
- Updates to your enhanced conversions settings, Google Ads Help. From April 2026 user provided data is accepted simultaneously from site tags, from Data Manager and from API connections; from June 2026 web and lead enhanced conversions merged under a single setting. ↩
- Tracking Prevention in WebKit, the “CNAME and Third-Party IP Address Cloaking Defense” section. Verbatim: “ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days.” The criterion for the comparison is not on that page but in the “Defending Against Cloaked First Party IP Addresses” section of Private Browsing 2.0: “two IP addresses are considered different parties if any of the following criteria are met: 1. One IP address is IPv4, while the other is IPv6. 2. If both addresses are IPv4, the length of the common subnet mask is less than 16 bits. 3. If both addresses are IPv6, the length of the common subnet mask is less than 64 bits.” The same place notes that the detection is heuristic and may change: “Detection of third-party IP addresses is heuristic, and may change in the future.” ↩ ↩2
- Cookie expiration limited to 400 days, Chrome for Developers. Since M104 (August 2022) cookies cannot carry an expiry further out than four hundred days. Session cookies with no explicit expiry are out of scope. ↩
- Set up Google tag gateway for advertisers with your content delivery network, Google Ads Help. The tag loads from your own domain and measurement events are sent to your own domain and forwarded to Google from there. ↩
- IAB Tech Lab: CNAME cloaking anti-fraud framework ↩
- Google Analytics Help: Updates to Google Analytics Data Controls (Google Signals role change, Consent Mode consolidation, ads personalization and IP address flow updates) ↩ ↩2
- 01 Consent Mode V2 Advanced collects signal through a URL ping and the gcs parameter instead of writing cookies when consent is declined; this is the mechanism Google designed for the scenario
- 02 wbraid and gbraid are cookieless parameters that link a conversion for iOS and Safari users without a cookie
- 03 Since November 2024 Conversion Linker also writes ad click information to localStorage, so click attribution survives past cookie expiry
- 04 Enhanced Conversions hashes the data a user leaves at conversion time (email, phone) with SHA-256 and builds cookie independent attribution; first-party data stays inside the legal frame
- 05 sGTM first-party cookie writing gets around the ITP JavaScript cookie cap, but the exemption is not unconditional: when WebKit detects third-party CNAME or IP cloaking it caps server-set cookies at seven days too. The ethical and legal reading of it is a separate open debate
+ What is the measurement difference between Consent Mode V2 basic and advanced?
In basic mode no tag fires until consent is given; if the user declines, that session is entirely invisible. In advanced mode the tag fires in every case, but without consent it writes no cookie and only sends a URL ping carrying the gcs parameter. Advanced mode collects the signal that feeds Google's modeled conversions engine, basic mode does not.
+ What do the wbraid and gbraid parameters do?
They are the cookieless conversion tracking parameters Google built for iOS and Safari. gclid is cookie based and subject to the ITP cap. gbraid (web-to-app conversions) and wbraid (app-to-web conversions) arrive as URL parameters and are processed server side. Calling them cookie independent is still not accurate: Google's own page says that when wbraid arrives, the Google tag continues to set a first-party cookie on your domain. Running them alongside gclid matters most on ecommerce sites with heavy iOS traffic.
+ How reliable are modeled conversions?
Modeled conversions are not individual user data, they are a statistical estimate derived from the pattern of users who did consent. Google does not disclose the model, and its quality varies with segment size and industry data. Google Ads reports do not separate modeled from observed conversions; that lack of transparency is a well known criticism.
+ Does Enhanced Conversions need consent?
The data Enhanced Conversions sends (a hash of email or phone) is data the user left at conversion time. But sharing it with Google requires the user to have been told their data will be processed for advertising purposes, which means ad_user_data consent is expected. Technically it needs no cookie, legally it needs permission to process data.
+ Is sGTM first-party cookie writing ethical?
sGTM writes a Set-Cookie header from your own subdomain, and the seven day cap ITP applies to JavaScript cookies does not apply to those cookies directly. But the exemption is not unconditional: WebKit's own documentation says that when third-party CNAME cloaking or third-party IP address cloaking is detected, the lifetime of cookies set in the HTTP response is capped at seven days as well. So where the subdomain resolves is what decides it. ITP is a privacy measure and sGTM technically disables it. That sits outside the consent question but inside the privacy debate. CNAME cloaking is the clearer grey area: it uses DNS manipulation to stop the browser recognising the tracker, and IAB considers it unethical.
+ What does a BigQuery raw data export give you?
The GA4 BigQuery export delivers, at event level, the data the UI shows aggregated. If Consent Mode is active, modeled events for users who did not consent are flagged as modeled in BigQuery too. A raw export does not improve measurement quality; it gives analysis and segmentation flexibility. It does not move the consent boundary, it lets you analyse more deeply within it.