TL;DR: If your Cookie/Consent vendor is a hosted SaaS that prices by traffic, the vendor must measure traffic. Not after consent. Before. That billing requirement forces vendor-side telemetry at the exact moment the user is supposed to have a choice - which collides with consent-before-collection in the EU/UK, and becomes even sharper in Vietnam under Decree 356 where web behavioral tracking is treated as sensitive data. If your stack needs to “phone home” to bill you, you’re not buying compliance. You’re buying a liability design.
Most CMP compliance claims collapse the moment you open the Network waterfall.
The real compliance test is not what the banner says.
It’s what your site transmits before the user has a choice.
“If your CMP vendor sells ‘compliance’ by the visitor, your compliance starts by violating consent.”
And here is the part agencies, DPOs, and site owners keep missing:
If your consent vendor sells CMP as a hosted SaaS and prices by traffic (visitors/sessions), the vendor must measure traffic.
Not “after consent”. Before.
Because you can’t invoice what you can’t count.
That single billing requirement creates a structural conflict with consent-before-collection across the EU/UK - and now even more sharply in Vietnam under Decree 356.
Who this is for: anyone shipping or deploying web-facing code into other people’s sites - CMP vendors, “cookie compliance” SaaS providers, analytics and tag-manager stacks (GA4/GTM, TikTok, Meta, CDPs), and the agencies, DPOs, and site owners who keep inheriting the risk when that code executes before a provable affirmative choice.
Why this is happening: the “billing telemetry” paradox
A website’s tracking stack is usually optional.
A SaaS consent stack is not.
In a typical SaaS CMP deployment:
- The CMP script is loaded from the vendor’s infrastructure (their CDN / domains).
- The vendor needs to enforce plan limits (sessions, visitors, properties, geos, features).
- The vendor provides “traffic / consent reporting” dashboards.
- The vendor operates the infrastructure that serves the CMP and sees the traffic by design.
So even if the banner claims “we only deploy strictly necessary trackers before consent”, the architecture often still involves vendor-side telemetry to:
- count unique visitors / sessions,
- record impressions,
- enforce consumption tiers,
- power reporting and optimization,
- troubleshoot and support the account.
That telemetry is data processing.
In practice, vendor telemetry rides on standard HTTP request data (IP, user-agent, device/browser metadata, timestamps, request identifiers) - which is exactly what unique counting and account enforcement rely on.
The hard line: “Consent UI” is not “consent-before-collection”
A compliant flow is brutally simple:
Load nothing that phones home → get a real choice → load only what was chosen → log it first-party.
Most cookie/consent stacks fail because they confuse interface with sequence.
A banner can be beautifully designed and still be non-compliant if the page already:
- calls third-party domains,
- fires pixels,
- runs tag managers,
- loads analytics libraries,
- or transmits telemetry to the CMP vendor itself
before the user takes an affirmative action.
EU reality: ePrivacy Directive 5(3) is technology-neutral
In the EU, the “cookie rule” is not a cookie rule.
ePrivacy Directive Article 5(3) governs storing or accessing information on a user’s terminal equipment and is interpreted as technology-neutral. Guidance keeps reinforcing that it covers more than classic cookies.
Security logging may be necessary, but it does not turn vendor-side traffic metering/product analytics into ‘necessary’ pre-consent tracking.
So if your “consent” solution itself triggers any non-essential storage/access or similar tracking techniques - directly or indirectly - you are relying on a story regulators have been dismantling for years:
“We displayed a banner, therefore pre-consent data flow is acceptable.”
It isn’t.
UK reality: PECR still requires consent for non-essential tracking
The UK structure is similar: PECR requires consent for non-essential cookies and similar technologies (with narrow exemptions). UK GDPR then applies when personal data is processed.
So the same paradox shows up:
If the CMP vendor is collecting telemetry to operate a consumption-priced SaaS, that processing must be justified. And “we’re doing it to bill the customer” is not a magic exemption - especially if it happens before a user can choose.
Vietnam just raised the stakes: Decree 356 turns “web behavioral data” into sensitive data
This is the part most international vendors are not ready for.
Decree 356 (effective 1 January 2026) explicitly lists data tracking behavior and activities in cyberspace services as sensitive personal data.
Read that again.
If your website uses:
- Google Analytics / GA4
- TikTok Analytics / Pixel
- Meta Pixel
- Google Tag Manager (as the orchestrator)
- CDPs and customer event pipelines
- session replay / heatmaps
- attribution and ad measurement
- many fraud / risk tools that profile behavior
…you are processing behavioral tracking data in the category the decree calls out.
“At minimum, the collection occurs at the moment the requests/events are generated - not when reports are viewed.”
Which means the usual “this is just analytics” line stops working in Vietnam.
And it gets worse for SaaS stacks: cross-border exposure becomes a first-order risk when the tooling is hosted outside Vietnam and receives Vietnamese visitor data by default through network calls.
When the vendor’s purpose is not your purpose
Most teams label the CMP vendor as a “processor” and move on. That shortcut is exactly how non-compliant SaaS consent stacks survive procurement.
Because in a typical hosted CMP model, the vendor isn’t only processing data to deliver your instructions. The vendor also processes visitor data to serve its own independent purposes - and that changes the role analysis.
If the vendor determines purposes such as:
- traffic-based billing and usage enforcement (counting visitors/sessions/pageviews to invoice and police plan limits)
- vendor-side telemetry and product analytics tied to your visitors (service performance, feature usage, “banner impressions”, debugging)
- vendor reporting/optimization driven by visitor events (dashboards, benchmarking, experimentation)
…then the vendor is not just “your processor” in the narrow sense. The vendor is making decisions about why certain data is collected and how it is used for the vendor’s business operations.
That is the hallmark of (at minimum) joint controllership for those specific processing purposes.
“When the vendor’s purpose is not your purpose, ‘processor’ becomes a shortcut”
And this is where the liability sits:
- A SaaS CMP vendor that collects or receives personal data for its own purposes cannot hide behind “we’re just a tool.”
- Contract language that tries to push everything onto the website owner does not change the factual question regulators ask: who decided the purposes and essential means of processing?
- If the vendor’s infrastructure receives data pre-consent to support the vendor’s own metering/telemetry/reporting, then the vendor carries direct accountability for that processing.
Joint controllership applies at least to the vendor’s independent purposes (metering/telemetry/optimization), regardless of how the rest of the stack is contracted.
“If the vendor’s infrastructure receives data pre-consent for metering/telemetry, the vendor carries direct accountability.”
Last week’s article“€100 Per Cookie: The New Unit Economics of Non-Compliance”, explains why this matters now: courts are starting to price unlawful device-boundary events as compensable harm - and the spotlight lands on the vendor whose code executed before proven consent, not on the banner screenshot.
The practical takeaway is simple:
If the vendor’s purpose is not your purpose, it is not purely processing “on your behalf.”
So the compliance assessment must include: vendor purposes, vendor endpoints called pre-consent, what data is transmitted by default (IP/UA/metadata), and whether those flows can be eliminated by switching to a first-party / self-hosted deployment.
If your CMP cannot operate without “phoning home” first - especially for traffic metering - then you don’t have a consent layer. You have a vendor-operated data collection layer with a banner attached.
SaaS CMPs price by “consumption” - so the vendor must measure your users
Here’s the non-negotiable logic: if a consent vendor charges based on traffic, the vendor must be able to count traffic.
“You can’t invoice what you can’t measure.”
That means measurement is not a side feature. It’s a structural requirement of the SaaS business model.
And the market is explicit about this. The biggest CMP vendors publicly price by usage meters like:
- Average daily visitors (OneTrust)
- Sessions (Usercentrics Advanced CMP)
- Monthly Unique Visitors (MUV) (Didomi)
- Page views per month (consentmanager.net)
- Pageviews/month (CookieYes)
So when a website loads a hosted CMP script from the vendor, the vendor’s platform is inherently designed to see and meter the full denominator of visitors/sessions/pageviews - not only those who later click “Accept.”
“A usage meter is not a claim - it’s an operational requirement. If the vendor charges on it, the vendor must compute it.”
The only way a traffic-priced CMP avoids pre-consent vendor processing is if metering happens entirely first-party (customer-side) and the vendor never receives visitor-level telemetry before consent - which is not how hosted CMP SaaS is typically delivered.
That’s why “our banner says we don’t do anything before consent” is not the test.
The test is whether any data is processed/disclosed before the user has a choice - and consumption pricing makes that risk predictable.
The only pattern that scales across EU/UK/VN
If you want a setup you can defend in audits, procurement, and disputes:
- CMP must run first-party (your domain / your storage / your infrastructure)
- no third-party calls before consent (not just “no cookies”)
- consent logs stored first-party (not in the vendor’s cloud as the default)
- optional: on-prem / local hosting where cross-border exposure matters (like the VN Data Law)
This is not ideology.
It’s risk control.
“Consent is not UI. Consent is runtime. If you can’t prove the boundary, you don’t have compliance.”
Check what your site does before the user chooses
If you’re an agency: stop inheriting your clients’ liability.
Make “no third-party calls before consent” a non-negotiable delivery standard.
If you’re a DPO/lawyer: audit the network waterfall, not the banner text.
If you own the site: scan your site and look at what loads before any click.
If you want to check if your (or your clients’) website is collecting data prior to consent, use our free privacy scanner to test it.
Thanks to everyone pushing this debate forward. We need far more awareness of technical compliance - not just legal theory or banner screenshots. The fastest way to raise the bar is simple: measure what actually loads before consent, then fix the architecture - not the wording.
Have you ever audited your CMP in DevTools before clicking anything?
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO @ AesirX.io
