Shopify Server-Side Tracking: What Consent Cannot Gate

Key Takeaways

Google's own documentation states the Shopify integration works through "direct server-to-server communication", sending "conversion data directly from your store's server to Google Ads, complementing traditional browser-based tagging methods" — a path your cookie banner does not sit on.
The scope is currently one event. Google states: "Currently, only purchase conversions driven by Shopify's 'Checkout completed' event are supported by this integration. Support for other events will come later."
Shopify's Customer Privacy API is "a browser-based, JavaScript API" that applies consent decisions "to Shopify-managed surfaces, like pixels, audiences, and checkout" — which is precisely why it is the wrong instrument for a transmission that never enters a browser.
Google's dedicated page on obtaining user consent in Shopify tells merchants to "Use a CMP that integrates with Shopify's Customer Privacy API" and does not mention server-to-server transmission anywhere.
Our position: stop treating this as a banner problem. The server leg is a lawful-basis, transparency and vendor-record question — and because Google documents an off switch, leaving it on needs to be a decision you made, not one you inherited.

Introduction

Your consent banner is configured properly. A shopper in Dublin rejects analytics and marketing, your CMP records the refusal, and Shopify's Customer Privacy API dutifully reports that this visitor cannot be tracked. Every script in the page respects it.

Then the order completes — and whether that purchase still travels to Google is a question your entire consent stack cannot answer.

It cannot answer it because the route runs from Shopify's servers to Google's, never touching the browser where your consent tooling lives. Stores using the Google & YouTube app have had that server-to-server path since a 2026 rollout reported by the trade publication PPC Land, and neither company has published guidance on how consent governs it.

This guide covers what that path actually carries, why your banner cannot gate it, which legal question replaces the consent question, and how to audit it this week.

This is informational content, not legal advice.

What Is Shopify's Server-Side Tracking Feed to Google?

It is a direct connection between Shopify's servers and Google's, carrying completed-purchase conversions without passing through the shopper's browser. Google describes it as "direct server-to-server communication" that sends "conversion data directly from your store's server to Google Ads, complementing traditional browser-based tagging methods."

That last word matters: complementing, not replacing. The browser-based tags you already know about keep running. This is an additional leg, and it is the one your tooling cannot see.

What Google Actually Documents

Google's Ads Data Manager help page is the authoritative description, and it is narrower than the commentary around it. Three things are stated plainly.

First, the import is automatic: "Your Shopify conversions are automatically imported to your Google Ads account via Data Manager." Second, the scope is a single event: "Currently, only purchase conversions driven by Shopify's 'Checkout completed' event are supported by this integration. Support for other events will come later." Third — and most useful to a merchant — there is a documented way out. Google describes deactivating it by editing conversion measurement events in the Google & YouTube app settings and choosing "Don't measure in linked account" for the Checkout completed event.

One event, automatically imported, with a switch. Worth knowing all three before deciding anything.

What This Article Does Not Claim

Trade press reported in August 2026 that four additional browser-side events would begin flowing on 17 August. We checked: Shopify's public changelog carries no entry about the Google & YouTube app, GA4 events, the Data Manager API or server-side purchase sharing, and neither Google's Merchant Center conversion-tracking page nor its Shopify consent page mentions it. So we are not building anything on that date, and neither should you until it appears in documentation you can cite to a regulator.

The verifiable part is enough on its own.

Because consent gating, as implemented on Shopify, is a browser mechanism. Shopify's Customer Privacy API is documented as "a browser-based, JavaScript API that you can use to verify data processing permissions or build a cookie consent banner", applying consent decisions "to Shopify-managed surfaces, like pixels, audiences, and checkout". A backend transmission is none of those things.

Where the Customer Privacy API Stops

The API splits consent into four granular processing purposes — preferencesProcessingAllowed, analyticsProcessingAllowed, marketingAllowed and saleOfDataAllowed, the last covering the sharing of data with third parties for behavioural advertising. Shopify's older userCanBeTracked method, which the documentation now files under a legacy-reference warning, spelled the consequence out in terms the current granular purposes keep but no longer restate: "If userCanBeTracked is set to false, then the following behaviour must be observed: No persistent, non-essential cookies should be set" and "No data should be emitted to third-party platforms."

Read that second rule and the tension is obvious. It is a strong statement — and it is addressed to code executing in the browser context the API governs. When that gate closes on a browser-side vendor the effect is immediate and visible, which is what makes Klaviyo's onsite tracking go quiet on a properly configured store. Whether Shopify applies the same rule to its own server-to-server export is exactly what neither company has written down.

We want to be precise here, because the gap is documentary, not proven behaviour. We are not claiming the server feed ignores refusals. We are claiming something narrower and more awkward: Google's own Shopify consent guidance is silent on this path. That page tells merchants "If you're using the Google & YouTube app for conversion tracking and have set up your CMP, consent mode should work automatically" and to "Use a CMP that integrates with Shopify's Customer Privacy API." Fetched in full, it never mentions server-to-server transmission and never addresses what happens when a customer refuses. The server leg is documented on one Google page and the consent rules on another, and the two do not reference each other.

Practitioners noticed. Covering the July 2026 rollout, the trade publication PPC Land quoted Glenn Vanderlinden asking simply, "How do they deal with consent?" and Javier Garijo observing, "Shopify doesn't store consent states so not sure how they will handle that." A merchant had reached the same wall earlier: on 29 January 2025 a Shopify Community post described trying to check consent for server-side order processing and finding the buyer_accepts_marketing field "is false for almost all order records in a store, so I realized I can't rely on it." It went effectively unanswered.

The ePrivacy Boundary: Terminal Equipment or Server Transfer

The legal analysis shifts with the plumbing, and this is where most merchant guidance goes wrong by assuming one rulebook covers everything.

Article 5(3) of the ePrivacy Directive — the provision your cookie banner exists to satisfy — attaches to storing or accessing information on a user's terminal equipment. The EDPB's Guidelines 2/2023 on the Technical Scope of Art. 5(3) of the ePrivacy Directive, Version 2.0, adopted on 7 October 2024, are explicit about what triggers it. At paragraph 63 the Board writes that where identifiers are collected on websites, "the entity collecting is instructing the browser (through the distribution of client-side code) to send that information. As such a 'gaining of access' is taking place and Article 5(3) ePD applies." At paragraph 44 it draws the other edge of the line: use of information "would not constitute a 'gaining of access to information already stored' in the meaning of Article 5(3) ePD as long as the information does not leave the device, but when this information or any derivation of this information is accessed, Article 5(3) ePD would apply."

Our practical read, offered as ours and not as a Board ruling: the browser leg is squarely Article 5(3) territory because client-side code instructs the device. A transmission originating from Shopify's servers, of order data the merchant already lawfully holds, is not a fresh act of accessing the shopper's device — so the consent-for-storage-and-access rule is not the operative control there. The EDPB has not addressed this specific ad-platform pattern. Until it does, the conservative read is that the server leg is governed by the GDPR proper rather than by ePrivacy, which changes which question you have to answer, not whether you have to answer one.

What Lawful Basis Applies Instead?

If Article 5(3) is not the gate, the GDPR still is. Disclosing customer purchase data to Google is a processing operation, and it needs a lawful basis under Article 6, transparency under Articles 13 and 14, a record of the disclosure, and a transfer analysis, since the recipient is a US advertising platform.

This is a harder question than the banner one, which is probably why it gets skipped. Three things are worth settling in writing:

Name the basis. If you are relying on consent for advertising-related sharing, and your consent is collected by a browser banner that does not govern this leg, then the basis and the mechanism do not match. That mismatch is the finding a regulator would write up, not the transmission itself.
Disclose the recipient. Your privacy policy needs to say that completed-order data goes to Google. A shopper reading it should not be surprised by the Data Manager path.
Record it. The disclosure belongs in your record of processing activities as a named transfer to a named recipient, with the purpose and the retention position attached — the same discipline any data map worth keeping applies to every other vendor.

Shopify Is Your Processor, Except Where It Is Not

Here is the second thing worth knowing this week, and it is one most merchants have never read.

The standard framing — you are the controller, Shopify is your processor — is correct for the core of what Shopify does, and Shopify's Data Processing Addendum says so. But that same document, last updated 7 July 2026, carries an Appendix E that switches the relationship for one category of features. It states that "Shopify shall act as a Data Controller or Business when You receive the Enhanced Services as defined in Section 9.2 of the Terms of Service", and that Shopify "will process Your Customer Personal Data as a Data Controller or Business under Applicable Data Protection Laws in order to provide, develop and improve analytics, product customization, advertising and other services." The merchant does not stop being a controller either: "You are a Data Controller of Your Customer Personal Data and shall individually determine the purposes and means of Your processing of Your Customer Personal Data."

Shopify's Terms of Service, last updated 1 August 2026, define Enhanced Services at Section 9.2 as features "that incorporate data and information from customer interactions with Your Store, with other Merchants, and with Shopify". The setting behind them has a name and an off switch: "You may disable the setting that powers Enhanced Services ("Shopify Network Intelligence")... which prevents us from using additional customer Personal Data for Enhanced Services going forward."

If it stays on, Shopify assigns you duties. Its help documentation tells merchants in the EEA, UK and Switzerland to "Obtain consent from customers to see ads based on their activity in your store, with other merchants, and with Shopify, and provide them with the ability to withdraw their consent." It also requires you to "Include a link to Shopify's Consumer Privacy Policy in your privacy policy, and post a link to your privacy policy prominently in your store", and to "Explain to visitors that their information will be shared with Shopify and other third parties that may be located in other countries."

Those are not suggestions from a blog. They are obligations your platform has documented and assigned to you, sitting in a help-centre page most merchants have never opened.

And here is the asymmetry that makes this article's central point concrete. For Network Intelligence, Shopify does state the consent position: "If you're using Shopify's automated privacy settings (for example, cookie banner and/or opt out page) or third-party tools that are properly integrated with the Customer Privacy API, then Shopify respects the customer's consent choices on your site in Shopify Network Intelligence." That is a clear, documented commitment. It is also exactly the sentence the Google server-to-server feed has no counterpart for — which is why the two belong in separate rows of your compliance file, with separate answers, rather than being waved through together.

The same controller-versus-processor question decides who answers a subject access request, which is why it is worth getting right beyond the advertising context — our guide to DSARs across marketplaces and multichannel stores works through that split in detail.

How to Audit This in Your Store

A focused pass, in the order that surfaces problems fastest:

Open Google & YouTube app settings and look at conversion measurement events. Google documents the Checkout completed event and the "Don't measure in linked account" option here. Record what you find before changing anything.
Check Settings → Customer privacy for Shopify Network Intelligence. Note whether it is enabled and which apps depend on it.
Compare the two legs. Write down, for each, what it sends and what gates it. The table below sets out the comparison.
Read your own privacy policy against the three Shopify requirements quoted above. Most policies fail the Consumer Privacy Policy link.
Add Google to your record of processing as a recipient of completed-order data, with the purpose and lawful basis named.
Decide, and date the decision. Whichever way you go, a dated note explaining why beats a configuration nobody remembers choosing.

	Browser leg	Server leg
What carries it	Client-side tags and pixels	Shopify's servers to Google, via Data Manager
What Google documents	Browser-based tagging and enhanced conversions	"direct server-to-server communication"
Events	Multiple browser events	"Checkout completed" only, today
Gated by your CMP	Yes, via the Customer Privacy API	Not documented by either company
How to switch off	Consent refusal, CMP configuration	"Don't measure in linked account" in app settings

Common Mistakes

1. Treating the consent banner as proof of compliance. This is the worst of them, because it is the one that feels finished. A correctly configured CMP is evidence about the browser leg and says nothing about the server leg. If your compliance file contains a banner screenshot and nothing else, it documents half the data flow.

2. Assuming silence means permission. Neither Shopify nor Google documents how consent governs the server path. Undocumented is not the same as approved, and it is certainly not a lawful basis. Write down what you concluded and why; an auditor can work with a reasoned position, but not with an assumption.

3. Switching everything off in a panic. Disabling Network Intelligence disables the features that depend on it, and turning off conversion measurement has real marketing consequences. The point of the audit is a decision with a rationale, not a purge.

4. Leaving the privacy policy alone. Of all the items here, this is the cheapest to fix and the most visible to a complainant. Shopify tells you to link its Consumer Privacy Policy and disclose cross-border sharing. That is an afternoon's work.

5. Filing it under marketing. The person who connected the Google & YouTube app is usually not the person who answers the regulator. Purchase data leaving for an ad platform is a data-protection decision that marketing happens to operate.

How PrivacyForge Helps

The recurring failure here is not ignorance of the law — it is that the data flow is invisible in the place where compliance is recorded. PrivacyForge's data mapping keeps Google as a named recipient of completed-order data, with the purpose, lawful basis and transfer position attached, so the server leg appears in your record of processing rather than living in an app setting nobody revisits.

Consent records cover the other half: what a given visitor actually chose, when, and under which banner version, kept as evidence rather than as browser state. And because the controller-versus-processor split decides who answers a subject access request, our DSAR workflow lets you record which recipients received a customer's data, which is the question that follows the moment one arrives.

None of it makes the configuration decision for you. It makes the decision visible, dated, and defensible.

Frequently Asked Questions

Does Shopify send data to Google even if the customer rejects cookies?

Neither Shopify nor Google documents the answer. Google describes the Shopify integration as "direct server-to-server communication" from your store's server, and its Shopify consent guidance covers only browser-based tagging through a CMP wired to Shopify's Customer Privacy API. Because the server path never enters the browser, a client-side refusal has no documented effect on it. Treat it as an open question to resolve in writing, not an assumption.

What data does Shopify's server-side feed send to Google?

Completed-purchase conversions, and currently nothing else. Google states that "only purchase conversions driven by Shopify's 'Checkout completed' event are supported by this integration. Support for other events will come later." The import happens automatically for stores using the Google & YouTube app, so the absence of a setup step in your records does not mean the feed is inactive.

How do I turn off Shopify's server-side conversion sharing with Google?

Google documents the path: edit conversion measurement events in your Google & YouTube app settings and select "Don't measure in linked account" for the Checkout completed event, or remove the custom conversion IDs and labels. Before switching it off, note the marketing consequence — conversion measurement feeds bidding. Record the decision and its date either way.

Does Google Consent Mode apply to server-side tracking on Shopify?

Google's Shopify consent page addresses Consent Mode in the browser, saying consent mode "should work automatically" where a CMP is set up, and instructing merchants to "Use a CMP that integrates with Shopify's Customer Privacy API." That page makes no mention of server-to-server transmission. Until Google documents the interaction, treat Consent Mode as covering the browser leg only.

Is Shopify a controller or a processor of my customers' data?

Both, depending on the feature. Shopify's Data Processing Addendum, last updated 7 July 2026, states in Appendix E that "Shopify shall act as a Data Controller or Business when You receive the Enhanced Services as defined in Section 9.2 of the Terms of Service." For core store processing it acts as your processor. You remain a controller throughout, determining the purposes and means of your own processing.

Conclusion

The uncomfortable part of this is not that Shopify added a server-side feed. It is that the control most merchants trust — the banner, the CMP, the Customer Privacy API — was built for a route this data does not take, and nobody said so.

So treat the two legs as two problems. The browser leg is a consent problem, and your existing tooling handles it. The server leg is a lawful-basis, transparency and record-keeping problem, and it needs a written position rather than a toggle. Open your Google & YouTube app settings, check whether Network Intelligence is on, and put Google in your record of processing as a recipient of completed-order data. If you change nothing else this week, change the privacy policy — Shopify has already told you what it needs to say.

Sources

#Shopify #consent management #server-side tracking #GDPR #ePrivacy