Consent Mode v2: why the Shopify banner is not enough on its own
Shopify ships its own cookie banner. You find it under Settings, Customer privacy, preconfigured for visitors from the EEA and the UK, and it looks like a finished solution. Then you read the decisive sentence in Shopify's own help centre. The banner governs Shopify specific tools, meaning Shopify cookies and Shopify pixels. Anything running outside that infrastructure keeps running.
So whether that matters depends on your setup. If your Google tracking runs through the Google & YouTube app, the automatic path applies, and Google states that consent mode is automatically enabled once the banner is active. If your tracking runs through your own custom pixel, say with your own Tag Manager container, Shopify does not pass the consent mode signals through automatically. What Shopify documents there is just its own gating, meaning a pixel does not load at all until the permissions it declares are present, and how to read the consent state. Deriving the gtag commands from that is on you. It only happens automatically for app pixels, that is, through the Google & YouTube app or a certified consent app. That gap is what breaks setups in practice. Your banner is up, your Shopify pixels behave, and your own container sits there waiting for a signal that never arrives.
Four Shopify categories, four Google signals
Shopify's Customer Privacy API defines four categories: analytics, marketing, preferences and sale_of_data. On Google's side there are four signals. ad_storage covers advertising cookies and device identifiers, ad_user_data covers sending user data to Google for advertising purposes, ad_personalization covers personalised ads and remarketing, and analytics_storage covers analytics storage. Version 2 added the middle two, and those are the ones missing most often.
There is no official mapping table between the two systems, from Shopify or from Google. The obvious reading, where the Shopify marketing category feeds the three advertising signals and analytics feeds the fourth, circulates in third party documentation but appears in no official documentation. If you are going to rely on it, put it through Tag Assistant first.
The copy and paste trap in Shopify's own tutorial
Shopify's official Tag Manager custom pixel example sets all four consent signals to granted. The detail underneath makes it worse. The block sets them as an update, not as a default, and only after the container has loaded. A default is missing from the example entirely. So there is no starting state at all, and shortly after load everything is bumped to granted regardless of whether the visitor agreed. Shopify qualifies this in a single sentence, saying these example settings might not match what your region's privacy legislation requires.
For EEA traffic you need the opposite. All four signals default to denied before any tag loads, and only the visitor's click on the banner triggers an update. Copy that block unchanged and your consent mode will pass a technical inspection while doing nothing for you legally.
Basic or advanced mode
Basic mode holds the Google tags back until the visitor has decided. Nothing leaves the page beforehand, not even the default status, and Google falls back on a generic model. Advanced mode loads the tags immediately with a default of denied and sends cookieless signals even on refusal, which lets Google build a model tuned to your account. Google has never put a number on how much data that modelling needs.
And nobody at Shopify or Google says which of the two the automatic path implements. A German legal assessment would turn on that single point. If the answer matters to you, your own account is the only place to measure it.
This is a legal call, not just a technical one
Section 25 of the German TDDDG requires consent, meeting the GDPR standard, before information is stored on or read from a user's device. Whether advanced mode is compatible with that, given it sends signals before the decision is made, has not been settled by a German court, and the supervisory authorities have not answered it consistently either. Basic mode is the more conservative option.
Do not make this call inside the marketing team alone. Bring in your data protection officer or your legal counsel and document the outcome. This is a description of the technology, and a legal review is a separate job.
What Google actually enforces
Google's EU user consent policy applies to end users in the EEA, the UK and Switzerland, regardless of where you are based. The policy itself states the consequence in general terms, namely that Google may limit or suspend your use of the product and terminate your agreement. The accompanying help centre gets more specific. There Google describes the process as a manual review by a Google team, allows a reasonable amount of time to make changes, and names the account level measure as suspension of ad personalisation, including remarketing, and of conversion measurement. Separate from all that is the standalone Consent Mode v2 requirement for EEA traffic, in force since March 6, 2024.
What reviewers write up: a banner that is missing or inadequate, no affirmative consent action such as a real confirm button, disclosure of data sharing with third parties that does not go far enough, consent signals implemented badly, and cookies that are already set before anyone has agreed to them.
How to work through it
- Take stock, about 30 minutes. Open Settings, Customer privacy and check whether the banner is active and for which regions. Then Settings, Customer events: which pixels are running at all, and which of them belong to Google?
- Check each banner surface separately. Shopify lets you control display individually for storefront, cart, checkout and customer account pages. Checkout display arrived in February 2025 and is off by default. If you built your setup before that, sessions that start straight in the checkout run with no prompt at all.
- Check your customer account domain. Banners and pixels only work on customer account and order status pages if the domain used for them is a subdomain of your storefront domain, for example account.yourshop.com under yourshop.com. If it sits elsewhere, consent given on the storefront does not apply there.
- Decide on a mode and document it. Basic or advanced, together with your data protection officer. With advanced mode, the cookieless signals belong in your privacy policy.
- With your own container, set the snippet yourself. Default denied on all four signals as the very first command, before the container loader. Then react to the Shopify event that fires when consent is given and send an update. Use the wait parameter so tags do not fire before an asynchronous consent tool has answered.
- Check the withdrawal path. Since February 2025 the Shopify banner can be reopened, so visitors can change their decision without clearing cookies. That was not possible before. If your shop still runs an older configuration, this is something you have to add yourself.
Testing, and why the usual test fails here
The standard route is Google Tag Assistant. You open your shop in it, interact with the banner, and check two states in the consent tab. On the earliest consent event all four signals must appear with a default of Denied. After clicking accept all, the most recent event must show Granted. An empty tab means consent mode is not implemented on the page at all.
On Shopify that test can lie to you. Shopify states explicitly that Tag Assistant's troubleshooting feature is not compatible with custom pixels and does not detect Google tags inside one. Track through a custom pixel and the standard tool reports a failure where there is none. That is what pushes people into a second tracking implementation, and from there straight into the double counting described further up.
You will get further with Shopify's own test feature for custom pixels under Settings, Customer events, with the network tab in your browser developer tools, and with the conversion action diagnostics in Google Ads, where the timestamp of the last recorded conversion tells you whether anything is arriving at all.
A failure pattern worth knowing
The Shopify developer forum documents a case where consent state was set twice, correctly to denied by the privacy app, then unprompted to granted by the pixel belonging to the Google & YouTube app. Shopify escalated the case internally and to Google. In any setup combining the app with a separate consent tool, look at the sequence of events, not just at the end state. If an update flips everything to granted and no user click triggered it, you have found your culprit.
Product data: where Google pulls every field from
On a self hosted shop you maintain an export format and decide which column comes from where. On Shopify the app decides that, and your only control is the fields on the product. Convenient enough, as long as you know which field feeds which Google attribute. Neither Shopify nor Google publishes that mapping in full, so the overview below marks what is documented and what is established convention.
- Title→
titlerequired, 150 characters max, must match the landing page
- Description→
descriptionrequired, 5,000 characters max, no links
- First media item→
image_linkrequired, no watermarks, borders or promotional text
- Variant price→
pricerequired, including VAT in Germany and most of Europe
- Inventory→
availabilityrequired, values in_stock, out_of_stock, preorder, backorder
- Variant barcode field→
gtinnothing else populates it, see below
- Category field→
google_product_categoryvia Shopify's standard product taxonomy
- Product type field→
product_typeconvention, free text field, not the same as Category
- Vendor field→
brandconvention, only documented by feed vendors, verify in your account
- Product ID plus variant ID→
id and item_group_idevery variant is its own offer, the product ID groups them
The precondition behind most missing products
A product only appears in the feed if it is published to both sales channels, Online Store and Google & YouTube. Products created through an import or by an app do not reliably inherit that channel assignment. In Merchant Center this shows up as an unavailable landing page, which sends people hunting through their attributes.
Fix it in bulk under Sales channels, Google & YouTube, Manage products. That view also shows you the sync status per product.
The English options requirement
Shopify's channel requirements contain one sentence that costs non English shops real money. Product options, including variants, need to be in English to sync. That covers option names and values, so Color rather than Farbe, Size rather than Größe, with English values to match.
A German shop naturally sets its options in German and then wonders why variants are missing or whole products never arrive. Switch the options to English in the backend and translate the storefront display through Shopify Markets or the translation tooling, or use a feed app that rewrites them on export. The first route calls for caution. Renaming options can touch variant URLs and theme logic, so test before you commit.
GTIN lives in the barcode field, and only there
On the product page each variant has a barcode field. That value, and nothing else, is submitted as gtin. Not the SKU, not a metafield. Only real manufacturer numbers with 8, 12, 13 or 14 digits and a valid check digit are accepted.
The classic slip is the internal item number landing in the barcode field because it happens to be empty, and Google rejects such offers. Google explicitly bars you from making up, guessing or borrowing values from similar products. The other constant failure is a spreadsheet import that strips the leading zero from an EAN and turns a 13 digit number into a 12 digit one with an invalid check digit. Format the barcode column as text when importing a CSV.
Own brand without a GTIN, the route Google itself recommends
The reflex is to set identifier_exists to no and watch the warnings disappear. Google sees it differently. If you manufacture the product yourself or have no official brand, the recommended route is to use your own shop name as the brand and supply a self assigned mpn. Do that and you do not need identifier_exists at all. The boundary matters. That freedom only applies if you really are the manufacturer. If you resell someone else's goods, you may not invent a part number and have to use the manufacturer's.
The attribute is meant for real exceptions such as handmade one offs, vintage and antique goods, books published before 1970 and certain spare parts. One rule always holds. Never send a GTIN and identifier_exists set to no at the same time.
Applying the attribute to every GTIN warning costs you reach. Products that do have an identifier you fail to submit cannot be matched to Google's catalogue and get limited exposure. Nothing in the interface calls that an error. The status reads as limited performance, and shops live with it for months.
Example shop
That was the second finding at our ceramics shop. Around half the catalogue was missing from Merchant Center because the options are called Größe and Farbe and therefore never synced. The rest ran with identifier_exists set to no, even though the shop has a clear own brand. The right answer here is brand name as brand, an own part number as mpn, and the attribute reserved for the hand thrown one off pieces.
Category, product type and collections do different jobs
The Category field belongs to Shopify's standard product taxonomy and feeds Google's product category. Set it as deep as you can. Google asks for the most specific category available and at least two levels of hierarchy. As soon as you set it, Shopify unlocks matching category metafields such as target gender, age group, colour and size, which happen to be the fields Google requires for apparel and accessories.
The Product type field, by contrast, is a free text field feeding Google's product_type. That is your own categorisation, and a useful segmentation dimension in Google Ads, because you can cut it however your campaign logic needs.
Collections, finally, are not a category tree. A product can sit in any number of them and has no single membership. People arriving from a self hosted shop tend to bring the assumption that category equals feed structure equals campaign structure. On Shopify that assumption does not hold. You build campaign structure from product type, tags and custom labels.
If your shop has been running a while
Shopify's standard product taxonomy is versioned and grows fast. Seven releases have shipped since July 2024, and the May 2026 one alone added more than 2,000 categories. Shopify points out that categories you used previously may have been modified or replaced. Category assignments from before that period are therefore not automatically still valid, and the newly surfaced category metafields sit empty on older products.
Price, tax and shipping
Google requires prices including VAT for every target country except the US and Canada, where tax must stay out of the price attribute. Europe is the default case here, not the exception. In Shopify this hangs on a single switch under Settings, Taxes and duties, labelled include sales tax in product price and shipping rate. Set it wrong for a European shop and you produce systematically wrong feed prices. If you sell into both Europe and the US, the country specific presentation is also controlled through your Markets settings.
On shipping, the limit already mentioned applies. Only rates in the general profile sync. Google's own advice for borderline cases rarely gets quoted. When in doubt, state slightly higher shipping costs in Merchant Center than on your site. Underreported costs trigger an error, overreported ones do not.
With discounts, what matters is where they take effect. Anything that only applies at checkout, so discount codes and automatic discounts, does not show up as a reduced price in the feed. Those belong in a separate promotions data source in Merchant Center, which Google reviews separately and serves as a special offer link. The product feed will never show you a sale price that lives in the cart. Promotional prices you set through the compare at price, where you lower the regular price and keep the old one as a reference, do travel normally as price and sale price.
That split produces the most common price conflict. A discount app lowers the amount shown on the product page while the feed still carries the full one. If a promotion is meant to run permanently, build it into the product price rather than into an app that only does the maths in the cart.
Dates worth putting in your calendar
August 18, 2026: the Content API shuts downIf you only use the Google & YouTube app, Google says there is nothing to do. If you run your own scripts, middleware or an older feed app built on the legacy interface, you have to migrate to the Merchant API before that date.
January 31, 2027: minimum image size of 500 by 500 pixelsUntil then the thresholds stay at 100 by 100 for most categories and 250 by 250 for apparel. Plenty of guides still quote those old numbers. Google has been sending warnings since April 2026. Shops shooting their own product photos are usually fine. Supplier images and image apps that write downscaled versions into the feed are not.
Do not reinstall the app as a reflex
Uninstalling and reinstalling is the most popular troubleshooting reflex and an expensive one on Shopify. As part of the move to the new interface, the format of item IDs changes. Changed IDs count as new items in both Merchant Center and Google Ads. That means fresh review, a reset learning period and no product performance history. Google advises against reinstalling while the migration is running.
Takeaway
The Shopify feed mirrors your product maintenance rather than standing apart from it. Every correction belongs in the product. Anything you repair inside Merchant Center gets overwritten at the next sync.
The disapprovals that hit Shopify shops most often
Diagnostics live in Merchant Center under Products in the Needs attention tab. The prioritised fixes toggle is on by default and hides issues with low impact, which is where missing identifiers, missing size and colour attributes and weak titles pile up. None of that gets a product disapproved. It just gets the product shown less often. The shop looks green and loses impressions anyway, so make a point of turning the filter off at every routine check.
Six patterns come up again and again on Shopify.
Price mismatch between feed and landing pageOn Shopify this is nearly always self-inflicted. Shopify Markets converts the displayed price per country, a currency converter app overwrites it in JavaScript after load, or a discount app lowers the page price while the feed carries the full one. Google requires the prominently displayed currency to match the feed currency.
Out of stock despite having inventoryLocations are the culprit here, not the feed. Shopify only shows a product as available if stock sits at a location enabled for order fulfilment. The reverse case exists too: products at zero quantity with continue selling enabled show as available on the page but out of stock in the feed.
Website not claimedEither the feed uses the myshopify.com domain because the app was connected before the primary domain was set, or a higher-level domain has already been claimed by another, long forgotten Merchant Center account.
Missing or invalid identifiersEmpty barcode field, SKU in the barcode field, a stripped leading zero, an invalid check digit. Google says changes take 24 to 72 hours to appear in diagnostics, so do not go back in after two hours and change things again.
Promotional overlay on the imageBadges like New or a percentage off belong in the theme rather than in the product photo. The first media item becomes your feed image, so it has to stay clean. A recrawl can only be forced by changing the file name.
Misrepresentation at account levelThis one takes down the whole account. The triggers are unclear return and refund terms, insufficient contact details, and no clear disclosure of total costs. Since October 2025 Google explicitly names non-delivery and non-functioning return processes as examples too.
Two sets of structured data on one page
Shopify themes output product markup. SEO, review and rich snippet apps often output a second set. If one block says in stock and the other says out of stock, or the theme lists every variant in a single block, Google reads the wrong value and automatic item updates go wrong along with it.
Run your product page through the rich results test and count how many product objects it emits. There should be one, carrying the price of the preselected variant. Recheck after every theme update, because updates overwrite manual edits without warning.
What SEO guides get wrong about robots.txt
Shopify's default robots.txt contains a dedicated block for the Google Ads crawler, introduced by Shopify's own comment line noting that this crawler ignores the file unless it is named specifically. Google's crawler documentation explains why. This bot ignores the global wildcard user agent and therefore has to be addressed by name. It does evaluate wildcards inside the path rules perfectly normally. Plenty of SEO tutorials suggest replacing the template with hand-written lines. Do that and the block disappears, and Shopify can no longer ship its regularly updated default rules.
The other common piece of advice is to pre-emptively block the variant parameter in the URL. Shopify demonstrably does not block that parameter as of July 2026, and blocking it makes exactly the variant landing pages your feed links to unreachable. Extend robots.txt.liquid additively, use the provided Liquid objects, and fetch the live file after every change.
What happens if it does escalate
For account level problems Merchant Center usually sends a warning email first, with a deadline of either 7 or 28 calendar days depending on the violation rather than a blanket 28 days. During that window products keep running, sometimes with reduced visibility. Google then checks again, and only if something is still unresolved does suspension follow. Every item is pulled from shopping ads and free listings. For severe violations the warning is skipped and suspension is immediate. A review request takes three to seven business days.
Do not request a review straight away
For a preemptive item disapproval caused by a price or availability mismatch, the requested review takes up to seven business days. If problems persist after the second attempt, a waiting period of a week can kick in during which the button is greyed out. It gets longer with every further unsuccessful attempt and cannot be shortened, not even by Google support.
Spot check ten to twenty affected products manually first. Feed price against visible price against structured markup against the amount at checkout, each in the target country's currency. Only submit once all four line up.
Who actually receives the warning
Product data notifications hang off the personal email settings of the individual user, not the account. If only an agency login or a former employee ever enabled them, that warning window runs out with the email unread. Set up at least two people with admin rights and enable notifications for both.