Tracking & Privacy
“We changed the cookie banner and conversions dropped” is one of the most common tracking complaints on Shopify stores running Google Ads, and Consent Mode is usually the mechanism behind it. It doesn't block tracking outright — it changes how much of it Google measures directly versus estimates.
Consent Mode is a signal, not a tracking method of its own. Your consent management platform — the cookie banner and whatever logic sits behind it — tells Google's tags whether the visitor has granted categories of consent, most relevantly ad_storage (whether ads cookies can be set) and analytics_storage (whether analytics cookies can be set). Google's tags read that signal and adjust their own behavior accordingly — they don't decide consent themselves, and they don't override whatever the banner determined.
This means the accuracy of the whole system depends entirely on the CMP sending the right signal, at the right time, in a format Google's tags actually understand. A cookie banner that looks correct to a human visitor can still be wired up wrong at the signal level.
When a visitor declines ad-related consent, the Google Ads tag can't set or read the cookies it would normally use to track that visitor across a session or return visit. It can still send a limited, cookieless signal indicating that an ad interaction and, separately, a conversion event occurred — without attaching the identifiers that would normally let Google connect the two directly.
Google uses that limited signal, combined with patterns from consented traffic on the same account, to statistically model how many of the unconsented visits likely converted. This is worth being honest about: modeling is an estimate, not a recovery mechanism. It can narrow the gap between reported and actual conversions in aggregate, over enough volume and time — it does not reconstruct any individual missing conversion, and it will never claim to have measured a specific visitor's specific purchase. Accounts with low traffic or short reporting windows will see this modeling behave more erratically than high-volume accounts, simply because there's less consented data to model from.
A conversion drop right after a cookie banner change almost always traces back to one of a few implementation issues, rather than Consent Mode itself being broken:
The consent signal fires late. If tags load and start attempting to fire before the CMP has finished initializing and communicating a consent state, they can end up operating on a default — often the most restrictive one — for a meaningful slice of visitors, even those who go on to accept. Tag and consent script order matters here; a banner that loads after the Google tag has already attempted to fire creates a gap the new banner didn't intend.
A stricter default consent state than before. Google's tags support setting default consent values that apply before the visitor makes any choice, and separate values once they do. A banner rebuild that changes the default from granted-until-declined to denied-until-accepted is a deliberate, defensible privacy choice — but it will measurably reduce directly-tracked conversions, because more visitors are now in a denied state for however long it takes them to interact with the banner, if they interact at all.
Basic vs. advanced implementation differences. Google Consent Mode supports more than one depth of implementation, and Shopify stores commonly run one that only loads Google's tags after consent is granted versus one that always loads them and adjusts behavior based on the signal. These behave differently for denied visitors — one produces no signal at all until consent changes, the other produces the limited cookieless signal described above. Which one a given theme or app has actually implemented is worth confirming directly rather than assuming, since the practical effect on modeled conversions differs.
The CMP and Google tags disagree on category names. If the cookie banner app maps its own consent categories to Google's expected signal names incorrectly, Google's tags may never receive a valid signal at all and fall back to the most conservative default regardless of what the visitor actually chose.
It's tempting to treat server-side tracking as a way around consent restrictions, since the event isn't relying on a browser cookie to reach Google. That's not how it works, and no honest implementation claims otherwise. Consent Mode still governs what a server-side event or an Enhanced Conversions payload is allowed to include — a visitor who declined ad-storage consent should have their server-side event sent without the identifying data Enhanced Conversions would normally attach, the same way their browser-side event is sent without ad cookies. Server-side tracking closes a technical gap in how reliably an event reaches Google; it doesn't change who you're allowed to track. We cover what Enhanced Conversions can and can't do in more detail on Enhanced Conversions for Shopify explained.
Attribix ties Google Ads conversion data back to actual Shopify orders, which makes a sudden post-banner-change drop easier to isolate — you can see whether the gap between reported conversions and real orders widened right when the banner shipped, rather than guessing from Google Ads reporting alone. More on how that connection works on Google Ads conversion tracking for Shopify.
Send an inquiry and we'll look at how your cookie banner, consent signals, and Google tags are actually wired together on your store.