The merchant owns consent. We ship defaults that are careful about it
A Rutba storefront used to fire analytics and the Meta pixel on the first page view, in every country, with no notice. Now it asks first where the law expects it — and a shop that runs its own consent tool can take the whole decision over.
· 3 min read
Here is what a Rutba storefront used to do. On the very first page a visitor opened, it loaded Google Analytics, Google Tag Manager, the Meta pixel and any markup the shop had pasted in — in every country, with no notice. Visitors in the EU and the UK, who had never been asked, left with analytics and advertising cookies set.
The pixel was the worst of it. Analytics measures a shop; the pixel is advertising, and advertising is the category consent rules are least forgiving about.
Three kinds of tracker, and they are not the same
The storefront now runs Google Consent Mode v2, as rutba.io does. But treating every tracker the same is how a consent notice becomes decoration, so each kind gets the answer that actually works for it:
| Tracker | Before the visitor answers | If they say no |
|---|---|---|
| Google Analytics and Tag Manager | Told not to use storage, before either loads | Keep reporting, without cookies |
| The Meta pixel | Revoked before it starts — it sends nothing | Still sends nothing, because it has no cookieless mode |
| The shop’s own pasted code | Runs as pasted | Runs as pasted — the shop decides |
The pixel row deserves a note. Analytics can degrade gracefully; the pixel cannot, so it is held entirely until a visitor agrees. Even its fallback image — the version that fires when scripts are off — is only written into the page once consent allows it, because an image request cannot be taken back after it is sent.
Treating every tracker the same is how a consent banner becomes decoration.
Why the shop’s own code is not ours to block
The first version of this change also held back everything a shop had pasted into its pages until a visitor agreed. That was the wrong line. That code is the merchant’s, put there on purpose, and very often it is not tracking at all: a chat widget, a review badge, a fraud check.
Worse, one of the most common things pasted into a shop’s page is the merchant’s own consent tool. Holding it back until consent was given meant it waited, in the EU, for the consent it exists to collect — and silently never ran.
The merchant is the one responsible for how their visitors’ consent is collected; a provider owes reasonable measures. So pasted code runs as pasted, and the visitor’s answer is made observable to it rather than decided for it: it is announced as an event on the page and left where any script can read it. What the merchant’s code does with that is the merchant’s call.
Or take the whole decision over
A shop that already runs its own consent tool does not want two notices competing for the same visitor. So there is a setting that hands consent over entirely: set it, and the storefront shows no notice and sends no consent signal of any kind, and the merchant’s tool is in charge.
It is an opt-out, and that matters. A shop that has never touched the setting gets the built-in notice. Only a merchant who chooses to take consent over does.
