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 on Returns Portals and Order Tracking Pages

October 31, 2026

Returns and tracking are often run by third party tools on their own subdomains, loaded with their own trackers, and left out of the main consent audit. Bringing them into scope.

The returns portal is where a store sends its least happy customers, and it is frequently the least audited part of the consent setup. A third party tool, on a subdomain or an external domain with the stores branding, loading its own analytics and support scripts, and presenting a consent experience that bears little resemblance to the one on the main site, if it presents one at all.

Order tracking pages have the same shape: a specialised provider, a page the shopper visits repeatedly, and data flowing to parties the main consent banner never mentioned. An audit that covers the storefront and checkout and stops there has covered the part of the business that was already being watched.

Map the estate before auditing it

List every customer facing property the brand operates or brands: storefront, checkout, returns, tracking, help centre, loyalty, gift card balance, booking tools. For each, record the domain, the provider, and whether the main consent setup actually runs there. In most businesses that list contains at least one surprise, usually a tool bought by a service team that never went through the main consent process.

Shoppers do not experience these as separate estates, and neither does a regulator asking where their data went after a return. The returns flow collects names, addresses, order numbers, and reasons for returning, which is a richer set than a casual browse, and it deserves to be inside the same consent and records discipline as checkout, not outside it because a vendor hosts it.

What to check on the portal itself

Load the returns portal in a fresh profile and watch the same things as on the main site: what loads before any choice, what cookies are set, whether a consent notice appears, and whether choices made on the main site are respected or ignored. A portal that re-asks, or that never asks and tracks anyway, has broken the continuity a shopper was promised when they chose on the storefront.

Check the vendors defaults specifically. Many returns and tracking tools enable their own product analytics, session tooling, or marketing pixels by default, configured by an onboarding flow that a busy team clicked through. The stores consent position then depends on settings nobody remembers choosing, in a dashboard nobody has opened since launch.

Put portals in the contract and the calendar

At renewal, and ideally at purchase, require the provider to support your consent setup: honouring signals from the main site, suppressing their own tracking until consent, and documenting what they collect for their own purposes as a processor or otherwise. Providers who serve many merchants have usually built these controls already. They are just not switched on by default, because switching them on is the merchants job.

Add the portals to the regular audit calendar with the same refusal test used on the storefront, run at the same time, by the same person. Consent drift happens one vendor update at a time, on exactly the pages nobody visits from inside the business. A calendar entry is a dull defence, and it is the one that works.

Frequently asked questions

Why are returns portals a consent risk?

They are often third party tools on separate domains with their own trackers and defaults, left out of the main consent setup. They also collect rich personal data: names, addresses, order details, and return reasons.

Do consent choices on the main site apply on a returns portal?

They should, and shoppers reasonably expect continuity. Test whether the portal respects stored choices, re-asks, or ignores consent and tracks anyway. Each outcome needs a deliberate fix, not an assumption.

What should we ask returns and tracking providers?

To honour consent signals from the main site, suppress their own tracking until consent, document what they collect and for what purpose, and expose those controls clearly rather than leaving onboarding defaults in place.

How often should portals be audited?

On the same calendar as the main storefront, with the same refusal test in a fresh profile, and after any vendor update or renewal. Drift happens on the pages internal teams visit least.