Why does a consent banner reappear on a subdomain?

Usually because the consent cookie was set as host only, so other subdomains cannot read it, or because the CMP is configured differently on that host. Each subdomain looks correct alone, which is why a cross domain test with one browser session is needed to find it.

What cookie scope lets subdomains share consent state?

The consent cookie generally needs its domain attribute set to the registrable domain, with appropriate path and security flags, so sibling subdomains can read it. Exact configuration depends on your CMP and security policy, and should be tested in production.

Should every subdomain show the same banner?

The experience should be consistent, but the key requirement is shared state, not identical pixels. A visitor's recorded choice and preferences must be readable and honoured on every host they reach in a session.

How often should cross subdomain consent be audited?

After any CMP, checkout, or domain change, and on a recurring automated check. Deployments on a single host are the common trigger for a break that only appears when a visitor crosses between subdomains.

Auditing Consent Inside Mobile App Webviews: The Banner Nobody Owns

October 30, 2026

Stores open inside app webviews where the website banner behaves differently, consent state does not sync, and tags fire before any choice. How to audit a surface teams forget.

A store does not only live in browsers. It opens inside the webviews of shopping apps, social apps, and the brands own app, and in that environment the consent setup often behaves like a different site. Cookies and storage are partitioned differently, the banner may be suppressed by the app, or shown twice, and the consent state a customer set in their browser does not follow them into the app.

Ownership is the first problem. The web team assumes the app team handles in app consent. The app team assumes the website banner handles itself. Between those two assumptions, tags fire.

What actually differs in a webview

Storage in webviews can be ephemeral or partitioned, so a choice made on Monday may be gone on Tuesday, and the banner returns until the customer is trained to accept anything to make it stop. Banner fatigue inside an app is not a consent strategy; repeated prompts that wear people down are exactly what regulators criticise when they examine how consent was obtained.

Firing order matters more than the banner itself. Instrument the webview the way you would a browser: load a product page from the app, before touching any consent control, and record which marketing and analytics tags fire. If the answer is all of them, the banner in that environment is decoration, whatever it does on the open web.

Audit it as a separate surface

Give the webview its own line in the consent audit. Test on the real app, on a real phone, with a fresh install state: first open, choice recorded, choice surviving a force close and reopen, withdrawal route reachable, and the same checks inside any in app browser the app uses for external links, which can be a third environment hiding inside the second.

Sync the record back. Consent given or withdrawn in the app has to reach the same consent record the website writes to, keyed to the account where the customer is logged in. Two independent consent states for one person is a defect, and it surfaces the first time they withdraw in one place and get marketed at from the other.

Decide who owns it, in writing

End the audit with an owner, named, for consent in app surfaces, and a release rule: any app update that changes webview configuration, storage, or the set of embedded store pages triggers a consent retest. Webview behaviour changes inside app releases that the web team never sees.

That single rule prevents the most common failure mode, which is not a bad decision but a silent platform change three app versions ago that nobody connected to the banner.

Frequently asked questions

Why does consent behave differently in an app webview?

Webviews partition or clear storage differently from browsers, are configured by the app, and do not inherit the customers browser consent state. The banner and its records must be tested in that environment specifically.

What is the first thing to check in a webview audit?

Which tags fire before any consent choice is made. If marketing and analytics tags fire on first load, the banner is not controlling anything in that surface.

Should app and web consent share one record?

Yes, wherever the customer is identifiable, especially when logged in. Separate, unsynced consent states lead to marketing continuing after a withdrawal in the other surface.

Who should own in app consent?

A named owner, agreed between the app and web teams, with a rule that webview or storage changes in app releases trigger a consent retest. Unowned surfaces are where consent fails.