<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; I scanned 173 nominees across 10 categories and, after deduplication, analyzed 137 unique domains using client-side evidence captured before consent. Only 22 nominees land in a low-risk range of 0-4 pre-consent findings, which means 151 out of 173 are still non-compliant by a conservative measure - 87.28%. The headline is not which vendor is popular; it’s that “consent before tracking” is still not the default operating mode in Danish e-commerce. The good news is that a meaningful group now shows zero or near-zero pre-consent evidence, proving correct gating is possible in real commerce stacks.
</div>
<h2>Progress, but still systematic data abuse before consent</h2>
This is the 4th year I’m auditing the top nominees in the Danish E-Commerce Awards. The reason I keep doing it is simple: e-commerce is where “growth” and “compliance” collide in real life - and it’s also where the gap between what companies claim and what their sites actually do becomes measurable.
This is not a niche compliance debate. This award is a benchmark for what Denmark calls “best practice” in e-commerce. That’s why it matters whether the winners are building trust - or quietly bypassing it.
This is also why the organizer matters. When Dansk Erhverv - Digital Handel positions these nominees as “the best of Danish e-commerce”, it becomes a benchmark for what the industry normalizes - including in a time where Denmark is debating digital independence and trust.
This year I want to highlight two things at the same time. First, we are finally seeing a meaningful group of nominees with zero or near-zero pre-consent evidence. Second, the broader dataset still shows that the default operating mode across the industry is to load tracking before consent.
“Only 22 out of 173 nominees land in a low-risk range. The remaining 87.28% still leak before consent.”
<h2>What the study measures</h2>
The award list contains 173 nominees across 10 categories. Because some nominees appear in multiple categories, the list contains duplicates. After deduplication, the dataset covers 137 unique website domains.
Unless otherwise stated, scans were performed using the AesirX Privacy Scanner (hosted in Germany), based on the EDPS Inspection Tool / Website Evidence Collector engine. For automated processing, 172 scan result URLs were generated and deduplicated to 136 unique domains, and one domain (henosia.com) is included through manual HAR-based handling due to an application error. On Henosia, the HAR shows one first-party analytics beacon (PostHog-ingest style) and zero cookies.
The analysis is limited to client-side evidence captured by scanner/HAR: network requests classified as beacons and cookies set or observed before a valid consent signal. Sites are not assessed for server-side tracking, proxying, masking, or other circumvention techniques. Actual data collection may therefore exceed what is reflected in these results.
<img src="https/api.aesirx.io/images/images/what-this-analytics-covers-and-why-it-matters.png" alt="what this analytics covers and why it matters" width="942" height="610" />
<h2>The legal foundation in Denmark</h2>
The compliance baseline in Denmark is not a grey-zone “risk assessment” exercise. It is governed by two different legal pillars and two different authorities.
GDPR is implemented via Databeskyttelsesloven and enforced by Datatilsynet. If you process personal data for marketing measurement and tracking, you need a lawful basis that matches reality, and if you rely on consent, that consent must be freely given, specific, informed, unambiguous, and withdrawable.
The terminal equipment rule is ePrivacy Directive Article 5(3), implemented in Denmark via cookiebekendtgørelsen and governed by Digitaliseringsstyrelsen. This rule is binary: storing or accessing information on the user’s device requires prior consent unless it is strictly necessary for the service the user explicitly requested.
That “strictly necessary” exception is narrow. It is not a blanket justification for attribution, marketing optimization, telemetry, profiling, enrichment, or vendor-side measurement. If tracking beacons and/or non-essential cookies are observed before a valid consent signal, the implementation fails the “consent before access/storage” requirement under cookiebekendtgørelsen, and it will often also fail GDPR requirements for valid consent.
In practice, GDPR asks whether your processing is lawful; ePrivacy Directive 5(3) asks the simpler question first: did you access the device for non-essential purposes before consent - yes or no.
Read the full <a href="https://digst.dk/media/oy1btb02/faellesvejledning-med-datatilsynet.pdf" target="_blank" rel="noopener">joint guidelines on cookies and tracking technologies</a> from Datatilsynet and Digitaliseringsstyrelsen.
<h2>The headline finding: 87.28% still non-compliant</h2>
Here is the conservative classification that matters for any serious discussion.
Only 22 out of 173 nominees score in a low-risk range. Conservatively, 0-4 findings is a low-risk range and a reasonable proxy for likely compliance in this dataset.
The remaining 151 nominations are classified as non-compliant under cookiebekendtgørelsen (ePrivacy Directive Article 5(3)) in Denmark and/or Databeskyttelsesloven (GDPR), because they trigger tracking evidence prior to a valid consent signal.
This is the core narrative point. Not “which vendor is most common”. Not “which CMP is trending”. The baseline question is: does tracking start before consent - yes or no.
<img src="https/api.aesirx.io/images/images/domain-compliance-findings.png" alt="domain compliance findings" width="942" height="1101" />
<h2>Why this keeps happening in e-commerce</h2>
The recurring cause is not ignorance of the law - it is the way e-commerce stacks are assembled. Templates ship with tag managers and marketing widgets enabled by default, teams inherit “measurement-first” setups from agencies, and vendor stacks are increasingly bundled so telemetry, attribution, personalization, reviews, and email marketing are fused together. The result is predictable: tracking initializes first, and consent logic is asked to retroactively justify what already happened.
The law does not allow retroactive gating. If the first network requests and device identifiers appear before consent, the implementation is structurally non-compliant - even if the banner looks polished.
<h2>What still loads before consent</h2>
This is where the technical reality becomes uncomfortable, because it shows how the modern marketing stack behaves by default.
<h3>1) Tag infrastructure and tracking endpoints still fire pre-consent</h3>
In the deduplicated dataset of 137 unique domains, the Top Beacon Hosts table counts how many unique domains triggered at least one pre-consent request to each host and how frequently those hosts appear across the dataset.
A major signal remains that Google Tag Manager loads pre-consent on 92 out of 137 domains, which is 67.15%. That is not a “minor configuration edge case”. It is the default operating mode.
“If your first request is a tag manager, your consent logic is already chasing a train that left the station.”
<img src="https/api.aesirx.io/images/images/top-10-beacons-loading-before-consent.png" alt="top 10 beacons loading before consent" width="960" height="540" />
In other words, the industry’s default architecture is still “tag manager first, consent later” - which is backwards under ePrivacy Directive 5(3).
<h3>2) Tracking cookies are still being set pre-consent</h3>
The Top Cookies table counts cookie families observed across unique domains, filters out obvious platform/essential cookies and common consent cookies, and focuses on tracking identifiers that appear prior to consent.
That matters because ePrivacy Directive 5(3) is not “cookie theatre”. It’s device access. If tracking cookies are set before consent, the implementation fails the baseline.
“If tracking cookies are set pre-consent, the compliance discussion is already over.”
&nbsp;<img src="https/api.aesirx.io/images/images/top-10-tracking-cookies-set-before-consent.png" alt="top 10 tracking cookies set before consent" width="960" height="540" />
These identifiers are not “technical necessity”. They are marketing infrastructure, and when they appear pre-consent the implementation fails the baseline regardless of what the banner claims.
<h3>3) The consent layer is often part of the leak</h3>
This point is easy to misunderstand, so I’ll state it precisely.
The Top CMP table does not measure “CMP presence”. It measures pre-consent third-party calls to CMP-provider infrastructure that were classified as beacons in the export. In the deduplicated dataset (N=137 domains, including Henosia via HAR), at least one of the Top CMP providers was observed loading pre-consent on 97 out of 137 domains, which is 70.80%.
If a consent vendor processes data or accesses terminal equipment prior to consent for vendor purposes, such as telemetry, geo-IP lookups, or pixel trackers, that is not “technical necessity” on behalf of the visitor under GDPR and ePrivacy Directive 5(3). The consent mechanism becomes part of the non-compliant data flow.
“A consent layer that phones home before consent is not a gate. It’s part of the tracking.”
<img src="https/api.aesirx.io/images/images/top-5-cmp-consent-providers-observed-loading-pre-consent.png" alt="top 5 cmp consent providers observed loading pre consent" width="960" height="540" />
A consent layer that triggers vendor-side processing pre-consent turns compliance into theatre, because the “gate” is already exchanging data before the visitor decides.
A growing part of this problem is bundling. Vendors increasingly ship CMP, analytics, marketing automation, widgets, and CDNs as one stack. That makes implementation easier, but it also blurs purposes and recipients, and it creates pressure to treat vendor telemetry as “necessary”. The strict necessity test is about what the visitor requested - not what the vendor needs for attribution, invoicing, enrichment, or product analytics.
<h2>Worst and best: the spread tells the truth</h2>
I rank domains by total observed pre-consent activity (beacons + cookies). The purpose is not drama. The purpose is to show the distance between “we can’t” and “we did”.
<h3>Top 10 Non-Compliant</h3>
This list ranks the highest observed pre-consent totals. The unit is unique nominee domains in the final deduped dataset (n=137), and totals are calculated from client-side evidence observed before consent.
&nbsp;<img src="https/api.aesirx.io/images/images/top-10-worst-offenders.png" alt="top 10 worst offenders" width="960" height="540" />
These are not outliers. They are what happens when the stack is allowed to initialize marketing infrastructure before consent.
<h3>Top 10 Best (lowest observed)</h3>
This list ranks the lowest observed totals. “0” does not prove compliance. It means no tracking-classified beacons or tracking cookie identifiers were observed pre-consent in the captured client-side evidence, and server-side/proxy/masking was not assessed.
This matters because it proves the industry excuse is wrong. It is possible to build an e-commerce stack that does not leak by default.
<img src="https/api.aesirx.io/images/images/top-10-best-lowest-total-pre-consent.png" alt="top 10 best lowest total pre consent" width="960" height="540" />
These are the proof cases. They show that you can run serious commerce without pre-consent leakage, if you gate properly and keep telemetry in check.
<h2>A note on the “Best e-commerce case” nominees</h2>
For the Best e-commerce case nominees, the scanned domain reflects the customer/case implementation presented. The scan is used as an indicator of the solution’s ability to support compliance with Danish and European requirements, including Databeskyttelsesloven (GDPR) and cookiebekendtgørelsen (ePrivacy Directive Article 5(3)).
That means the scan is not just a comment on a brand. It is also a signal about the implementation model being showcased as “best practice”.
<h2>Banners don’t create compliance - architecture does</h2>
The e-commerce industry needs to stop treating this as a copywriting problem and start treating it as an engineering property.
The simplest compliance test in Denmark is still the most powerful: does your site store or access tracking identifiers on the device or call tracking endpoints before consent - yes or no. That is cookiebekendtgørelsen implementing ePrivacy Directive 5(3), and it is governed by Digitaliseringsstyrelsen. If you process personal data for tracking and rely on consent that is not freely given, informed, and specific, that is GDPR via Databeskyttelsesloven, governed by Datatilsynet.
This year’s dataset shows two truths at once. A small group proves compliant gating is feasible. The majority proves that the default is still systematic pre-consent tracking.
And if we don’t call that what it is, the industry will keep polishing banners while the data flows remain unchanged.
And that is exactly why the award benchmark itself has to be part of the discussion.
<h2>Digital independence vs data doping: the contradiction in plain numbers</h2>
Denmark is having a serious debate about digital independence from US BigTech. That is exactly why it’s hard to read this dataset without calling out the hypocrisy: Google Tag Manager loads pre-consent on 67.15% of top nominees. That is not “digital leadership”. That is a structural dependency - and it’s incompatible with the story Denmark tells itself about taking control of its digital future.
I’m not asking an award show to act as a regulator. I’m asking an industry organisation to stop treating “growth at any cost” as excellence when it conflicts with Danish law and public trust. If an awards benchmark ignores GDPR and ePrivacy Directive 5(3) year after year, it doesn’t just reflect the market - it trains the market.
This is a question for Dansk Erhverv - Digital Handel and for Brian Mikkelsen: do we want Danish digital leadership to mean sovereignty and trust - or just better optimization on top of illegal tracking?
“If 67.15% of ‘top’ nominees load GTM before consent, the award isn’t measuring excellence - it’s measuring how well data doping performs..”
If Denmark wants digital leadership, we must stop awarding stacks that treat consent as a decorative layer on top of default surveillance.
<h2>Full findings and category tables</h2>
I’m publishing the full results as a PDF carousel so you can verify everything without taking my word for it.
The carousel includes the complete Top 20 nominee tables for all 10 categories, plus the cross-category summary tables: Top 10 Beacons, Top 10 Cookies, Top 5 CMPs, Top 10 Non-Compliant, and Top 10 Compliant / Lowest observed.
Use it like a reference deck: open your category, find the nominee, and you’ll see immediately whether tracking starts before consent.
<div>pdflink:https://api.aesirx.io/images/Blog/Danish_E-Commerce_Awards_2026.pdf</div>
<h2>What you can do next</h2>
If you want to check your own site, start with the same method this study uses: measure what loads before consent. Run your domain through the <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">AesirX Privacy Scanner</a> and review the client-side evidence (beacons and cookies) that appears before a valid consent signal.
If the scanner shows pre-consent tracking evidence, you already have the diagnosis: consent gating and configuration are broken under ePrivacy Directive 5(3), and the GDPR consent story will often also fail because the processing begins before any valid choice exists.
Start there. If your pre-consent findings are 0-4 you’re likely in a good place. If not, you have a concrete engineering problem to fix.
If you want a prioritized remediation plan you can hand to developers or an agency, the <a href="https://aesirx.io/services/privacy-review" target="_blank" rel="noopener">Technical Privacy Review</a> converts evidence into fixes - what leaks, why it leaks, and what to change first.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Danish E-Commerce Awards 2026

Blog Aesirx

An independent audit of Danish E-Commerce Awards nominees shows 87.28% still trigger tracking before consent, despite GDPR and ePrivacy rules.

NEW YORK, FEBRUARY 6, 2026 - AesirX release Analytics Pro for WordPress, an advanced first-party analytics platform designed to deliver deeper visibility into campaigns, visitor behavior, and real business outcomes.
Most analytics tools still depend on third-party tracking stacks that are increasingly blocked, distorted, and difficult to govern. This leaves teams working with incomplete data and reports centered on surface-level metrics such as pageviews and clicks rather than meaningful performance results.
AesirX Analytics Pro for WordPress runs entirely in a true first-party setup, keeping analytics data under the site owner’s control by default. Built for compliance-first measurement, privacy and governance are embedded directly into the architecture rather than added as afterthoughts. 
The Pro version builds on <a href="https://aesirx.io/solutions/analytics/freemium/wordpress" target="_blank" rel="noopener">AesirX Analytics Freemium</a>, adding advanced reporting, real-time visibility, and value-focused insights for teams that require deeper measurement and faster decision-making.
<h2>From Volume Reporting to Outcome-Driven Analytics</h2>
Traditional analytics excels at counting visits, clicks, and pageviews but struggles to explain what actually drives business impact. For WordPress site owners looking for better insight without third-party tracking stacks, marketing and growth teams that need real-time campaign clarity, and agencies managing multiple sites at scale, surface-level metrics often fall short.
AesirX Analytics Pro shifts measurement toward outcomes by combining engagement scoring with metric value mapping across campaigns and on-site actions. Instead of treating all visits equally, each session becomes a sequence of value events that reflect intent, interaction depth, and meaningful results.
This allows teams to clearly see which campaigns generate high-quality journeys rather than just high traffic, which user flows consistently move visitors closer to conversion, and where friction causes value to stall or drop off across the site. By connecting acquisition sources with on-site behavior and outcomes, Analytics Pro delivers a unified view of performance that supports faster, more informed decision-making.
<h2>How AesirX Analytics Pro Changes Day-to-Day Measurement</h2>
Reliable data without third-party loss AesirX Analytics Pro improves data reliability by operating in a true first-party environment rather than relying on third-party tracking stacks that are often blocked or restricted by browsers and privacy tools. This results in more complete visibility into real visitor activity, helping teams base decisions on accurate performance data instead of distorted or partial reports.
Deeper visibility into visitor journeys Instead of viewing behavior as disconnected pageviews and isolated events, Analytics Pro reveals complete user paths across pages and flows. Teams can see how visitors progress through the site, where engagement strengthens, and where drop-offs occur, making it easier to identify high-impact journeys and areas that need improvement.
Real-time insight into live activity With built-in real-time reporting, teams can monitor active visitors as they interact with the site. Current pages, traffic sources, and live session value are visible as actions happen, allowing faster responses to campaigns, launches, and content changes without waiting for delayed reports.
Clearer conversion performance Analytics Pro highlights where visitors exit journeys and where meaningful actions take place. By visualizing drop-off points and conversion paths, teams can pinpoint friction within funnels and prioritize improvements that directly influence results.
Outcome-focused, value-based measurement Through UTM Value Mapping and Tag Event Value Mapping, Analytics Pro connects campaigns and on-site actions to business impact rather than just traffic volume. Sessions become sequences of value events, enabling teams to understand which sources and behaviors truly contribute to outcomes.
Smarter UX and content prioritization Engagement scoring shows how deeply visitors interact with different journeys and experiences. This allows teams to focus optimization efforts on flows that demonstrate strong interest and meaningful interaction instead of relying solely on popularity metrics like pageviews.
Privacy-first data ownership and control All analytics data is collected, stored, and processed within a first-party architecture, keeping it under the site owner’s control by default. This supports stronger governance and compliance-first measurement without dependence on third-party analytics services.
Fast deployment for WordPress teams Analytics Pro is delivered through a WordPress plugin, enabling teams to activate advanced analytics without coding. Installation and setup are streamlined so organizations can begin collecting meaningful insights quickly.
Scalable analytics without traffic limits Unlike many analytics platforms that introduce volume-based pricing and hidden thresholds, Analytics Pro supports growth without traffic caps. Teams can scale reporting across larger sites and higher traffic levels without unexpected costs.
<h2>Feature Highlights</h2>
Key capabilities in AesirX Analytics Pro for WordPress include:
<div class="table-responsive">
<table class="table table-bordered">
<tbody>
<tr class="bg-primary-stroke-2">
<td style="text-align: center;">Feature</td>
<td style="text-align: center;">Benefit</td>
</tr>
<tr>
<td>Pro dashboards</td>
<td>A clear snapshot of key performance metrics including real-time active users, visitors, top pages, locations, browsers, events, and tracking.</td>
</tr>
<tr>
<td>Real-time analytics</td>
<td>Live visibility into active visitors, current pages, and session value as meaningful actions happen.</td>
</tr>
<tr>
<td>UTM Value Mapping</td>
<td>Connect campaigns directly to business outcomes instead of relying on traffic volume alone.</td>
</tr>
<tr>
<td>Tag Event Value Mapping</td>
<td>Assign value to on-site actions such as clicks, signups, and conversions to understand which behaviors matter.</td>
</tr>
<tr>
<td>User experience views</td>
<td>Visualize every user journey and see which flows generate real value through scored paths.</td>
</tr>
<tr>
<td>Behavior analytics</td>
<td>Understand which pages hold attention, where users drop off, and how visitors move through the site.</td>
</tr>
<tr>
<td>Visitor analytics</td>
<td>Compare engagement across devices, platforms, and regions to spot performance issues and high-value segments.</td>
</tr>
<tr>
<td>First-party architecture</td>
<td>All data is collected, stored, and processed in a privacy-first structure without reliance on third-party analytics services.</td>
</tr>
<tr>
<td>Acquisition analytics</td>
<td>See how visitors arrive via channels, search engines, and campaigns, and which sources drive meaningful engagement.</td>
</tr>
</tbody>
</table>
</div>
<h2>How to get AesirX Analytics Pro for WordPress</h2>
AesirX Analytics Pro for WordPress is now available, giving teams a first-party, privacy-first analytics platform built around value rather than vanity metrics.
1. Install the plugin: <a href="https://github.com/aesirxio/wordpress-analytics-pro-plugin/releases" target="_blank" rel="noopener">Download and install the AesirX Analytics plugin</a> for WordPress.
2. <a href="https://signup.aesirx.io/" target="_blank" rel="noopener">Register your account</a>: Log in using your AesirX Shield of Privacy ID to activate your trial.
3. Configure analytics settings: Add your license key and start viewing data in the dashboard.
Get AesirX Analytics and turn every campaign into measurable value.
➡ <a href="https://github.com/aesirxio/wordpress-analytics-pro-plugin/releases" target="_blank" rel="noopener">Download Plugin</a>
To learn more, visit: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX Launches Analytics Pro for WordPress, Bringing First-Party, Value-Based Measurement to Growing Teams

Blog Press Release Aesirx

AesirX Analytics Pro for WordPress delivers first-party, privacy-first analytics with real-time insights, user journeys, and value-based measurement.

AesirX Launches Analytics Pro for WordPress

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; Functional AI is the antidote to both hype and harm: narrow scope, bounded permissions, verifiable outcomes, and lower waste. That same model can help a child communicate - translating weak signals into understood intent - and it can make complex platforms like WordPress safer to deploy and configure with AI. That’s sustainable AI: bounded by purpose.
</div>
My favorite use of AI isn’t “write me anything.” It’s: help me understand what a human is trying to express when the human can’t get it across in the usual way.
My daughter, Ida Marie, cannot speak, and she can’t use sign language in a conventional way. She has a small set of signals. One of them is raising her finger - sometimes it feels like 200 times a day - for her it means: “I want to say something.” But most of the time, we still can’t decode what the “something” is.
That experience forces a very different view of AI: not as a replacement for humans, but as a bridge for human limitations - a tool that turns weak signals into understood intent.
“When a person can’t communicate, AI should translate the signal - not harvest the person.”
And that’s the bridge to the rest of this story: the best AI systems will not be the broadest ones. They’ll be the ones with tight scope, careful permissions, and measurable impact - because that’s how you create trust.
Which brings us to WordPress.
<h2>WordPress “Agent Skills” is a signal of platform maturity</h2>
<a href="https://wordpress.org/news/2026/01/new-ai-agent-skill/" target="_blank" rel="noopener">WordPress introducing “Agent Skills”</a> is meaningful because it’s not just “AI inside WordPress.” It’s WordPress starting to define a contract for AI execution: what actions are permitted, where they can run, and how outcomes can be validated.
That matters because most AI-in-the-dashboard features fail in the same way: they stay in the “advisor” role. They can suggest, but they can’t safely do - and they can’t prove the result. WordPress is now moving toward the pattern that mature systems eventually converge on:
<ul>
<li aria-level="1">Abilities describe what can be done in a structured way.</li>
<li aria-level="1">Skills describe where and how it can be executed safely.</li>
<li aria-level="1">A sandbox (like Playground) creates a disposable environment to test changes without risking production sites.</li>
</ul>
This is subtle, but foundational: it’s the difference between AI that drafts opinions and AI that operates inside guardrails. In practice, it means an agent can (eventually) do things like: create a clean test instance, install a plugin set, change configuration, run checks, roll back, and document what happened - all without turning your live site into a lab.
“Bounded AI is a sustainability strategy: fewer watts, fewer mistakes, more trust.”
And that’s why this is bigger than “WordPress gets AI.” It’s WordPress positioning itself as an environment AI can reliably operate within - because reliability requires three things: permissions, isolation, and verification.
Once a platform has a safe execution surface, you can build bounded, functional agents that do one job end-to-end: observe → propose → apply → verify. Not “general AI,” but AI with a job description.
In WordPress, that’s especially workable because so much of the site’s behavior flows through a small set of control points (plugins, hooks, and script loading), which makes ‘bounded change + measurable result’ realistic.
One of the most obvious jobs inside WordPress is also one of the most neglected: making third-party behavior visible and controllable. Because the modern WP site isn’t a single system - it’s a constellation of plugins, tags, embeds, CDNs, and “just one more script” decisions. That sprawl is why configuration drifts, and why humans lose track of what actually runs on the page.
That’s the use case we focused on in our AI Privacy Advisor inside <a href="https://aesirx.io/solutions/consent-management-platform/wordpress">AesirX CMP Pro for WordPress</a> - as a functional workflow, not a chatbot: it scans what loads before consent, scans again after consent, proposes WordPress-native blocking rules, and generates draft privacy/cookie/consent text based on observed reality - then you can verify the change by re-running the scan.
<h2>The real problem: websites don’t know what they run</h2>
If you want a practical definition of “functional AI,” it’s this:
Turn a messy system into an observable system.
Most websites (especially WordPress sites) can’t answer a simple operational question with confidence: “What exactly executes on first page load - and what changes after a user makes a consent choice?”
That’s not because teams don’t care. It’s because modern sites are assembled from moving parts: plugins, tag managers, embedded widgets, A/B tools, CDN scripts, marketing pixels, chat tools - and they change constantly. Over time, the site becomes a system that behaves, but is no longer understood.
And this is where compliance breaks down, not at the banner layer, but at the runtime layer: pre-consent execution happens by default, and nobody can reliably prove what fired, when, and why.
“The web’s privacy failure is operational drift at scale.”
When we ran our July 2025 <a href="https://aesirx.io/blog/aesirx/36000-danish-business-websites-just-violated-gdpr" target="_blank" rel="noopener">privacy scan of 36.496 Danish business websites</a>, the most important takeaway wasn’t “people wrote bad policies.” It was that at scale, the web behaves like an un-audited runtime - and the measurements showed a high rate of risk and pre-consent third-party loading patterns at ~73% of the scanned sites. That’s not a Denmark or EU-only phenomenon; in our VN work, we repeatedly see the same failure modes, often at higher baseline rates (~90%).
So the question isn’t “how do we write better privacy policies?” It’s: how do we continuously align what the site does with what the site claims - without turning every change into a manual forensic exercise?
That’s the kind of job functional AI is good at: narrow scope, repeatable checks, measurable before/after outcomes - and no need for surveillance.
<img src="https/api.aesirx.io/images/images/functional-ai-is-the-opposite-of-surveillance-ai.png" alt="functional ai is the opposite of surveillance ai" width="942" height="619" />
<h2>Functional AI is the opposite of surveillance AI</h2>
If AI is broad, hungry, and “always learning,” it tends to push toward extraction. That’s the business model of surveillance: more inputs, more profiling, more inference, more risk.
Functional AI is narrow by design: fixed job, bounded permissions, explainable changes, verifiable outcomes.
The point isn’t to be impressive. The point is to be reliable
“Functional AI isn’t smaller ambition - it’s bigger responsibility.”
And there’s a sustainability angle too: broad models running everywhere invite wasted compute. Functional AI is inherently more “energy honest” - because it doesn’t need infinite context to do a single job well.
Now combine those ideas with the consent compliance problem: you don’t need an AI that can philosophize about privacy. You need one that can do a boring, critical workflow consistently.
Which leads to a practical definition of “useful AI” for websites:
Show me what loads before consent. Show me what loads after consent. Help me align configuration and documentation with what actually happens.
That’s the concept behind our AI Privacy Advisor.
<h2>The AI Privacy Advisor: making compliance observable</h2>
Consent compliance fails when it becomes a document-only exercise. “Functional AI” changes the approach: it treats compliance as system state. It’s essentially a before/after experiment harness for consent.
The <a href="https://aesirx.io/features/ai-privacy-advisor">AI Privacy Advisor</a> workflow is straightforward and intentionally limited:
<ul>
<li aria-level="1">Scan the site before consent to detect third-party requests, scripts, beacons, and high-risk technologies.</li>
<li aria-level="1">Scan again after consent to see what changes when the user opts in.</li>
<li aria-level="1">propose platform-native controls (in WordPress terms) that can block what must not load pre-consent.</li>
<li aria-level="1">Generate drafts for the required texts (privacy policy sections, cookie/technology declaration, and consent language) based on the observed behavior, not generic templates.</li>
<li aria-level="1">Keep the scope bounded: it’s not “AI that does everything,” it’s “AI that does this job and proves it”.</li>
</ul>
This is also where the WordPress “Agent Skills” direction becomes relevant: the future of trustworthy AI on platforms is “reason → permission → execute → verify.” Privacy is exactly the kind of domain that demands that structure.
And that circles back to why I started this newsletter with my daughter.
<img src="https/api.aesirx.io/images/images/the-ai-privacy-advisor-making-compliance-observable.png" alt="the ai privacy advisor making compliance observable" width="942" height="443" />
<h2>From consent to communication: AI that earns trust</h2>
I’m building privacy tools because the internet has normalized “extract first, explain later.”
But I’m also thinking about AI for the same reason I think about privacy: human dignity.
When <a href="https://ida-marie.io/" target="_blank" rel="noopener">Ida Marie</a> raises her finger, the world treats it like noise because it can’t decode the signal. Functional AI could be the bridge - not by “knowing everything,” but by being trained for a narrow purpose: interpret her signals, help translate intent, and let her be understood.
“Assistive AI and privacy AI share the same moral constraint: the goal is empowerment, not extraction.”
That’s the same ethical structure I want in privacy compliance AI:
<ul>
<li aria-level="1">Do something specific</li>
<li aria-level="1">Do it verifiably</li>
<li aria-level="1">Do it without turning people into telemetry</li>
</ul>
So yes - the AI Privacy Advisor is a product feature. But the deeper idea is broader and, I think, more important:
The future of sustainable AI isn’t bigger. It’s bounded. Bounded in scope, bounded in permissions, bounded in power consumption - and bounded by purpose.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Explore functional AI with bounded scope and verifiable outcomes, and how WordPress and AesirX use it to make privacy compliance observable.

When AI is useful, it’s usually narrow

Discover how narrowly scoped AI delivers measurable value in privacy compliance, and how AesirX and WordPress make consent, data use, and compliance outcomes transparent and auditable.

Narrow AI, Real Results: Making Privacy Compliance Verifiable on WordPress

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:&nbsp; 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.
</div>
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.
<img src="https/api.aesirx.io/images/images/the-billing-telemetry-paradox.png" alt="the billing telemetry paradox" width="942" height="619" />
<h2>Why this is happening: the “billing telemetry” paradox</h2>
A website’s tracking stack is usually optional. A SaaS consent stack is not.
In a typical SaaS CMP deployment:
<ul>
<li aria-level="1">The CMP script is loaded from the vendor’s infrastructure (their CDN / domains).</li>
<li aria-level="1">The vendor needs to enforce plan limits (sessions, visitors, properties, geos, features).</li>
<li aria-level="1">The vendor provides “traffic / consent reporting” dashboards.</li>
<li aria-level="1">The vendor operates the infrastructure that serves the CMP and sees the traffic by design.</li>
</ul>
So even if the banner claims “we only deploy strictly necessary trackers before consent”, the architecture often still involves vendor-side telemetry to:
<ul>
<li aria-level="1">count unique visitors / sessions,</li>
<li aria-level="1">record impressions,</li>
<li aria-level="1">enforce consumption tiers,</li>
<li aria-level="1">power reporting and optimization,</li>
<li aria-level="1">troubleshoot and support the account.</li>
</ul>
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.
<img src="https/api.aesirx.io/images/images/that-telemetry-is-data-processing.png" alt="that telemetry is data processing" width="942" height="574" />
<h2>The hard line: “Consent UI” is not “consent-before-collection”</h2>
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:
<ul>
<li aria-level="1">calls third-party domains,</li>
<li aria-level="1">fires pixels,</li>
<li aria-level="1">runs tag managers,</li>
<li aria-level="1">loads analytics libraries,</li>
<li aria-level="1">or transmits telemetry to the CMP vendor itself</li>
</ul>
before the user takes an affirmative action.
<h2>EU reality: ePrivacy Directive 5(3) is technology-neutral&nbsp;</h2>
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.
<h2>UK reality: PECR still requires consent for non-essential tracking</h2>
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.
<img src="https/api.aesirx.io/images/images/decree-356-impact.png" alt="decree 356 impact" width="942" height="494" />
<h2>Vietnam just raised the stakes: Decree 356 turns “web behavioral data” into sensitive data</h2>
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:
<ul>
<li aria-level="1">Google Analytics / GA4</li>
<li aria-level="1">TikTok Analytics / Pixel</li>
<li aria-level="1">Meta Pixel</li>
<li aria-level="1">Google Tag Manager (as the orchestrator)</li>
<li aria-level="1">CDPs and customer event pipelines</li>
<li aria-level="1">session replay / heatmaps</li>
<li aria-level="1">attribution and ad measurement</li>
<li aria-level="1">many fraud / risk tools that profile behavior</li>
</ul>
…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.
<img src="https/api.aesirx.io/images/images/different-purpose-role-mapping-changes.png" alt="different purpose role mapping changes" width="942" height="703" />
<h2>When the vendor’s purpose is not your purpose</h2>
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:
<ul>
<li aria-level="1">traffic-based billing and usage enforcement (counting visitors/sessions/pageviews to invoice and police plan limits)</li>
<li aria-level="1">vendor-side telemetry and product analytics tied to your visitors (service performance, feature usage, “banner impressions”, debugging)</li>
<li aria-level="1">vendor reporting/optimization driven by visitor events (dashboards, benchmarking, experimentation)</li>
</ul>
…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:
<ul>
<li aria-level="1">A SaaS CMP vendor that collects or receives personal data for its own purposes cannot hide behind “we’re just a tool.”</li>
<li aria-level="1">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?</li>
<li aria-level="1">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.</li>
</ul>
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.”
<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
Last week’s article“<a href="https://www.linkedin.com/pulse/100-per-cookie-new-unit-economics-non-compliance-christiansen-2kzgc/" target="_blank" rel="noopener">€100 Per Cookie: The New Unit Economics of Non-Compliance</a>”, 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.
</div>
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.
<img src="https/api.aesirx.io/images/images/saas-cmps-price-by-consumption-so-the-vendor-must-measure-your-users.png" alt="saas cmps price by consumption so the vendor must measure your users" width="942" height="614" />
<h2>SaaS CMPs price by “consumption” - so the vendor must measure your users</h2>
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:
<ul>
<li aria-level="1">Average daily visitors (OneTrust)</li>
<li aria-level="1">Sessions (Usercentrics Advanced CMP)</li>
<li aria-level="1">Monthly Unique Visitors (MUV) (Didomi)</li>
<li aria-level="1">Page views per month (consentmanager.net)</li>
<li aria-level="1">Pageviews/month (CookieYes)</li>
</ul>
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.
<img src="https/api.aesirx.io/images/images/traffic-metered-cookie-consent-vendors.png" alt="traffic metered cookie consent vendors" width="942" height="614" />
<h2>The only pattern that scales across EU/UK/VN</h2>
If you want a setup you can defend in audits, procurement, and disputes:
<ul>
<li aria-level="1">CMP must run first-party (your domain / your storage / your infrastructure)</li>
<li aria-level="1">no third-party calls before consent (not just “no cookies”)</li>
<li aria-level="1">consent logs stored first-party (not in the vendor’s cloud as the default)</li>
<li aria-level="1">optional: on-prem / local hosting where cross-border exposure matters (like the VN Data Law)</li>
</ul>
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.”
<h2>Check what your site does before the user chooses</h2>
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 <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free privacy scanner</a> 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 &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Why traffic-based cookie and consent tools require pre-consent measurement, creating structural conflicts with consent-before-collection rules.

Your Cookie Solution Is Not Compliant

Your Cookie Solution Is Not Compliant - Because the SaaS Business Model Can’t Be

Why traffic-based cookie and consent tools inherently rely on pre-consent measurement, creating unavoidable conflicts with consent-before-data-collection requirements.

Why Most Cookie & Consent Tools Are Not Compliant

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR: A German court just put a unit price on unlawful device access: €100 per cookie. That turns “compliance” into unit economics and makes vendor liability scalable. If your SaaS model depends on pre-consent telemetry, billing pings, or “cookie-less” measurement that still runs client-side, you’re not selling compliance - you’re selling liability.
</div>
A German court just did something that will quietly reshape the web-facing technology market.
It didn’t “warn publishers to fix their banners.” It didn’t “remind websites to update their policies.” It didn’t reward the industry’s favorite scapegoat: the messy implementation by someone else.
It put the spotlight where it belongs: on the vendor whose code touched the user’s device without proven consent.
One unlawfully set cookie triggered €100 in non-material damages (<a href="https://www.rv.hessenrecht.hessen.de/bshe/document/LARE260000013" target="_blank" rel="noopener">Higher Regional Court of Frankfurt's December 11 ruling, court ref. 6 U 81/23</a>). The number is small enough to look harmless - until you understand what it does to incentives once it becomes repeatable.
A systemic defect is never “one cookie.” A systemic defect is a pattern. And patterns scale.
So the question I want every agency, MarTech lead, DPO, and SaaS vendor to sit with is not “is €100 a lot?”
It’s this:
If a defect is provable on a site with a million visitors, what does the liability ceiling look like the moment claims become industrialized?
“€100 isn’t the story. The story is that vendor liability is now economically legible.”
Who this is for: anyone distributing client-side code into other people’s websites - CMP vendors, analytics vendors (including “cookie-less”), attribution and personalization tools - and the web agencies/implementers and DPOs who inherit the risk when that code fires pre-consent.
<h2>Germany didn’t produce one signal. It produced a cluster.</h2>
If this were only one Frankfurt ruling, the industry would do what it always does: call it an outlier, wait for appeal, and keep shipping.
But late 2025, Germany didn’t produce a single datapoint. It produced a pattern of court artifacts that all point in the same direction: courts are increasingly willing to price “loss of control” and “feeling of surveillance” as compensable harm - and they’re increasingly willing to treat web-facing vendors as responsible actors when their technology crosses the device boundary - any execution/caching/network instruction that happens - without proven consent.
Frankfurt is the cleanest hook because it’s so legible: €100 for one unlawfully set cookie. Not a regulator fine. A civil damages award that makes unit-economics risk obvious. When a court is comfortable attaching money to a single terminal-equipment event, the entire game changes - because now systematic defects can be turned into systematic claims.
Then you have Munich. Two decisions in December 2025 - both awarding non-material damages (one at €750&nbsp;<a href="https://openjur.de/u/2540283.html" target="_blank" rel="noopener">OLG München, Urteil vom 18.12.2025 – 14 U 2300/25 e</a>, one at €500 <a href="https://openjur.de/u/2540287.html" target="_blank" rel="noopener">OLG München, Endurteil vom 18.12.2025 – 14 U 1314/25 e</a>) in a major “tools” context - reinforcing that courts are not treating this as harmless technical trivia. They’re treating it as a fundamental rights issue with real compensable impact, and they’re comfortable doing it at amounts that immediately change risk calculations for vendors and platforms.
Read that again: within weeks, multiple higher regional courts are handing out damages for covert or uncontrolled tracking-style mechanisms. Different fact patterns, same message.
So if you are a CMP vendor, an analytics vendor, or any “X-as-a-Service” vendor shipping client-side logic into other people’s pages: stop waiting for the perfect legal safe harbor. The courts are already telling you what they will reward and what they will punish.
They will reward systems that can prove a valid boundary existed before the device was touched.
They will punish systems that rely on “we told customers to do the right thing” after the boundary was crossed.
“Germany didn’t just warn the market. It started pricing the intrusion - and the bill lands on vendors.”
<img src="https/api.aesirx.io/images/images/the-old-shield-is-falling.png" alt="the old shield is falling" width="942" height="619" />
<h2>The industry’s old shield is failing: “the customer is responsible”</h2>
For years, vendors protected themselves with a sentence that sounds reasonable until you look at the runtime:
“Publishers are responsible for obtaining consent.”
But a browser doesn’t read your contract.
Your script doesn’t pause because a PDF says “customer must comply.”
A tag fires when it can. An SDK sends events when it’s instructed to. A pixel calls home when it’s loaded. And if the design allows that to happen before a valid user choice exists, the legal risk is not “downstream.” It’s upstream - baked into the product.
This is the key shift: courts are beginning to treat consent not as UI, but as a technical boundary. If the boundary is crossed, “we told customers to do the right thing” stops being persuasive.
Because what the user experiences is not your contractual allocation of responsibility. What the user experiences is your code executing on their device.
“Your JavaScript doesn’t read your contract. Courts are starting to notice.”
<h2>Should every web-facing vendor be nervous?</h2>
It’s tempting to file this under “AdTech problems.”
That’s a mistake.
The same liability logic is relevant anywhere a vendor supplies client-side logic that interacts with a device, measures behavior, or transmits data off-site.
Consent vendors. Analytics vendors. Heatmaps. A/B testing. Personalization. Fraud tooling. “Performance monitoring.” Even “privacy-friendly” measurement stacks.
Because the risk is not “whether you call yourself privacy-first.” The risk is whether your system can be made to cross the device boundary without valid consent and without provable accountability.
And that brings me to the most persistent myth in web privacy.
<h2>The most dangerous sentence in analytics marketing: “we don’t use cookies, so consent isn’t required”</h2>
This week, Plausible Analytics chimed in on <a href="https://x.com/PlausibleHQ/status/2009535726107677010?s=20" target="_blank" rel="noopener">a thread on X</a> with what is probably the most common positioning in the “privacy-friendly analytics” category:
<ul>
<li aria-level="1">We don’t store or access information on the user’s device</li>
<li aria-level="1">We don’t use cookies or persistent identifiers</li>
<li aria-level="1">We only produce aggregated statistics after the request reaches our servers</li>
<li aria-level="1">Therefore, Article 5(3) isn’t triggered and explicit consent isn’t required</li>
</ul>
This is exactly the type of claim that sounds clean, simple, and “engineer-friendly.”
It’s also exactly the type of claim that breaks when you apply modern technical reality and current regulatory thinking.
Because privacy compliance is not a vibe. It’s not a blog post conclusion. It’s not a legal memo that relies on a simplified technical premise.
Privacy compliance is a property of what actually happens in the browser - including execution, caching, network calls, and the fact that modern tracking is not limited to “cookies.”
“Cookie-less is not consent-less - and it’s definitely not liability-less.”
<h2>The technical reality many analytics platforms try to skip</h2>
When you ship a JavaScript analytics tag, you are distributing executable logic to the user’s device. That logic is cached, executed, and used to instruct the device to make measurement calls. Even if you avoid “persistent identifiers,” you still have a system that:
<ol>
<li aria-level="1">runs on the terminal equipment, and</li>
<li aria-level="1">instructs the terminal equipment to transmit tracking-relevant information back to a server.</li>
</ol>
And this is exactly where a lot of “cookie-less” narratives become fragile.
Because the core legal question is not: “Did you set a cookie?” The core legal question is: “Did your mechanism involve storage/access on the device or instruct the device to send back identifiers or tracking information - even temporarily - as part of measurement?”
That’s why “we only aggregate after the request reaches our servers” is not the escape hatch it sounds like.
Aggregation is what you do after the fact. The trigger is what happens at the device boundary.
And if you want a practical demonstration that this is not just theoretical, look at Plausible’s own documentation push: “Run Plausible as a first-party connection … to bypass adblockers.”
Read that again slowly.
They’re explicitly advising customers to proxy the analytics endpoint through the customer’s domain name to evade user controls - not to change the underlying technical action, but to make it harder for users to block.
Now, I’m not making a moral argument here. I’m making a liability argument:
If your compliance narrative relies on “we don’t do device operations that trigger the rule,” while your own docs promote techniques to bypass blockers that target exactly those device-level operations, you are walking customers into a risk posture while advertising it as safety.
<img src="https/api.aesirx.io/images/images/if-a-privacy-feature-bypasses-user-controls-compliance-is-already-compromised.png" alt="if a privacy feature bypasses user controls compliance is already compromised" width="942" height="262" />
<h2>Even if you debate 5(3), GDPR still applies when the script loads</h2>
Let’s say someone wants to argue endlessly about whether a specific implementation triggers the terminal equipment rule. Fine. You can debate that.
But the moment a browser loads a SaaS analytics script and sends requests, the vendor receives what it receives:
IP address. User agent. Request metadata. Timestamp. URL paths. Referrers. Network identifiers. And in many real deployments, even more.
That is processing. That requires a lawful basis. That requires transparency that matches reality. And it requires you to stop hiding behind language like “anonymous” when what you really mean is “we don’t call it an identifier.”
This matters because vendor liability is not going to be limited to “cookie placement.” It is going to expand through the broader accountability doctrine that courts are increasingly comfortable applying: the party with the clearest visibility and control cannot hide behind the party with the least.
Which brings us to the second German signal that should terrify SaaS vendors.
<h2>The burden-of-proof trap: vendors built systems only they can explain</h2>
The web stack has a structural asymmetry: users cannot see what vendors do behind the curtain.
They don’t know where events go. They don’t know who receives them. They don’t know how they’re joined, retained, enriched, or shared. They don’t know whether “aggregated” means “immediately aggregated” or “event-level stored and aggregated later.”
But vendors know.
And courts are increasingly unwilling to accept “blanket denials” when the defendant is the only party who can provide the specifics.
This is where centralized SaaS becomes a litigation liability: your strongest product advantage - your control and visibility - becomes the reason you can’t shrug and say “not our problem.”
“Your data platform is a product advantage - until it becomes a litigation disadvantage.”
<h2>When the data model is the business model</h2>
Now let’s talk about the thing most people avoid because it cuts too close to how the market makes money.
Consent-as-a-Service. Analytics-as-a-Service. Compliance tooling-as-a-Service. Attribution-as-a-Service. Personalization-as-a-Service.
These models share a structural temptation: to be commercially viable, they want data early, and they want it reliably, even when the user says “no.”
And when vendors feel the law tightening, they reach for the same escape hatch: necessity.
Here’s the problem: under both GDPR and the terminal-equipment rule in ePrivacy Directive (Article 5(3)), necessity is assessed from the user’s (data subject’s) perspective - not the vendor’s business model. “Necessary” does not mean “necessary for product metrics, billing, diagnostics, attribution, or growth.” It means necessary to deliver the service the user actually requested - and only what is strictly required to do that.
So the category invents excuses:
<ul>
<li aria-level="1">“Telemetry for service quality”</li>
<li aria-level="1">“Pings for diagnostics”</li>
<li aria-level="1">“We need it for billing”</li>
<li aria-level="1">“We must measure consent to enforce consent”</li>
<li aria-level="1">“We don’t store identifiers; we only measure”</li>
</ul>
…what they are really saying is: our business model needs pre-consent device operations. And that is not a legal basis. That’s a commercial preference.
This is the core contradiction that vendor liability will expose: you can’t justify pre-consent device operations as “technically necessary” when the only thing that makes them “necessary” is the vendor’s revenue model. If the user said “no,” and your stack still needs to run to make your SaaS work, your product isn’t compliant-by-design - it’s consent-hostile-by-design.
If your revenue depends on data you can’t lawfully guarantee, then compliance cannot be a “feature.” It becomes a direct constraint on the business model. And many vendors respond by quietly making compliance optional in practice while advertising it as default.
That is not a “banner problem.” That is a product-market-fit problem under law.
<img src="https/api.aesirx.io/images/images/when-the-data-model-is-the-business-model-non-compliance-isnt-a-bug-its-revenue.png" alt="when the data model is the business model non compliance isnt a bug its revenue" width="942" height="735" />
<h2>It’s not only the EU. The UK, Norway, and Vietnam are moving the same way</h2>
Germany is simply where the court artifacts are currently the loudest.
But the logic is increasingly consistent across jurisdictions:
<ul>
<li aria-level="1">In the EU, the line between “cookie compliance” and “tracking compliance” keeps collapsing into the broader question: what do you do at the device boundary, and can you prove your basis?</li>
<li aria-level="1">In the UK, the same consent-before-tracking dynamics keep reappearing under PECR and UK GDPR accountability.</li>
<li aria-level="1">Norway’s direction under Ekom reforms moves along the same axis: device-level tracking is a legal boundary, not a marketing choice.</li>
<li aria-level="1">Vietnam is now tightening accountability under PDPL and the implementing environment, and any vendor shipping web-facing tracking or measurement into Vietnamese-facing stacks should assume scrutiny will follow the same path: prove what you do, why you do it, and why it’s lawful.</li>
</ul>
Different statutes. Same future: vendors can’t outsource accountability forever.
<h2>The practical conclusion: treat consent as a runtime boundary, or accept that you’re selling liability</h2>
The industry spent a decade turning consent into a UI problem because UI problems can be “fixed” without changing business models.
But courts are increasingly treating consent as what it always was: a boundary around device access, behavioral observation, and invisible power.
So here is the standard that matters now - the only one that will survive hostile examination:
Can you truthfully say your product is designed so non-compliance is hard, not merely discouraged?
Not in your marketing. Not in your contracts. In the runtime.
Because in the vendor-liability era, the only durable compliance posture is the one you can prove when someone is actively trying to break it.
“Consent is not UI. Consent is runtime. If you can’t prove the boundary, you don’t have compliance.”
Agencies: either you standardize this across every client deployment, or you’ll keep being the last person who “installed liability” and then got paid to clean it up later.
If you want to check if your (or your clients) website is collecting data prior to consent use our <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free privacy scanner</a> to test it.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Recent German court rulings put a monetary value on unlawful device access, reframing consent as a runtime boundary with direct vendor liability

100 Eur Per Cookie: The Unit Economics of Non-Compliance

€100 Per Cookie: The New Unit Economics of Non-Compliance

Recent German court rulings assign a monetary value to unlawful device access, redefining consent as a runtime boundary and exposing vendors to direct financial liability.

100 EUR Per Cookie: How German Courts Redefine Consent and Liability

Beyond cookies: the quiet tracking techniques hiding in your browser

Beyond cookies: AesirX explains how fingerprinting, caches, and network signals track browsers, and how to reduce linkability without breaking the web.

Beyond cookies: the tracking hiding in your browser

For digital agencies, web and marketing agencies, privacy professionals, and anyone translating regulation into real-world implementation across CMPs, analytics, tag stacks, UX, attribution, and governance.
<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
2025 didn't "solve consent". It exposed the truth: banners are a symptom of an architecture problem.
So 2026 will reward teams that stop treating privacy as a UI layer and start treating it as infrastructure. The practical route is clear: Own Path (true first-party collection and processing) reduces the need for consent moments because you remove the third-party data export by design. Browser signals then become the scalable way for people to say "no" without having to negotiate with every site, every week, forever. And as ID verification spreads from age checks into communities and marketplaces, the only acceptable standard is verification that does not turn into tracking.
This is not a "privacy vs growth" year. It's a "privacy as the foundation for sustainable growth" year.
</div>
<h2>What 2025 made impossible to ignore</h2>
The big shift in 2025 wasn’t a new CMP feature. It was the slow, unavoidable alignment of three pressures: enforcement risk, signal loss, and trust collapse.
On one side, regulators and courts are not moving toward “consent-lite tracking by default”. They are moving toward narrower lanes where you can operate without consent only when it is genuinely necessary, proportionate, and not repurposed. On the other side, marketing teams are realizing that third-party dependency is a business risk: measurement breaks, attribution becomes guesswork, and your most valuable behavioral data becomes someone else’s asset.
That is why the Digital Omnibus debate matters even if you don’t agree with every clause. It signals a direction: simplification for consumers is only possible if the ecosystem stops relying on opaque third-party chains.
And it also revealed a political tension that will define 2026: if “simplification” excludes the biggest tracking hotspots, then it becomes theatre, not consumer protection.
<img src="https/api.aesirx.io/images/images/simplification-that-ignores-poor-tracking-creates-loopholes.png" alt="simplification that ignores poor tracking creates loopholes" width="942" height="262" />
<h2>2026 Prediction #1: Own Path becomes the agency advantage that actually sticks</h2>
In 2026, “<a href="https://aesirx.io/blog/aesirx/the-first-party-own-path-turning-the-digital-omnibus-into-a-real-advantage" target="_blank" rel="noopener">Own Path</a>” stops being a niche privacy argument and becomes the most pragmatic agency proposition.
Because it answers three client needs at the same time:
<ol>
<li aria-level="1">Compliance becomes simpler when your measurement layer is controller-only, purpose-bound, and not a hidden export to third parties.</li>
<li aria-level="1">Performance becomes more stable because you are not at the mercy of vendor-side changes, script bloat, and shifting rules.</li>
<li aria-level="1">Trust becomes easier to earn because you can truthfully say: “your data stays here”.</li>
</ol>
Own Path, in plain terms, is a decision to stop renting your analytics integrity. Your consent layer is first-party. Your analytics collection is first-party. Your storage is first-party. Your reporting is first-party. Your improvement loop is built on data you legitimately control, instead of side-channel data that flows out through the tag stack.
This is where the narrative shifts from defensive to strategic: the agency that can implement Own Path is not “the privacy agency”. It is the agency that can give a client durable measurement in a world where third-party assumptions are decaying.
<img src="https/api.aesirx.io/images/images/first-party-data-means-better-data-owned-and-controlled-by-you.png" alt="first party data means better data owned and controlled by you" width="942" height="262" />
Own Path solves the biggest part of the problem by removing the third-party export. But it does not solve the rest. As long as a meaningful part of the web still relies on third parties, people will still be asked. That is where 2026 shifts from architecture to enforcement at scale: browser signals become the universal way to say no once, and have it respected everywhere.
<h2>2026 Prediction #2: Browser signals go mainstream, but the real win is the universal “NO”</h2>
<a href="https://aesirx.io/blog/aesirx/browser-signals-wont-replace-consent-and-the-omnibus-draft-shows-why" target="_blank" rel="noopener">Browser signals</a> are finally being treated as the only scalable way to reduce consent fatigue. California is already pushing hard on opt-out preference signals, and that pressure will shape what browsers and operating systems implement globally.
Europe should learn from this. Not by pretending a browser setting can replace informed, contextual consent for complex vendor chains. It can’t.
But as a universal refusal mechanism, browser signals are a gift because they operate at the only layer that can scale.:
<ul>
<li aria-level="1">They respect user agency at the right layer (device/browser).</li>
<li aria-level="1">They reduce repetitive interactions.</li>
<li aria-level="1">They reduce banner manipulation games.</li>
<li aria-level="1">They create a clear default that sites must honor.</li>
</ul>
This is also where the strategy becomes real instead of theoretical:
If we combine Own Path with browser-level refusal, we reduce consent fatigue in a way that survives contact with reality.
<ul>
<li aria-level="1">Own Path removes the need for consent on a huge share of sites because the third-party export disappears.</li>
<li aria-level="1">Browser signals remove the need for endless banner interactions for the remainder because users can say “no” once and have it respected.</li>
<li aria-level="1">Consent becomes a smaller, more meaningful moment, reserved for truly optional third-party activity.</li>
</ul>
That is the only path I see that reduces consent fatigue without weakening consumer rights.
<img src="https/api.aesirx.io/images/images/signals-simplify-ux-cmps-automate-consent.png" alt="signals simplify ux cmps automate consent" width="942" height="262" />
Once ‘NO’ becomes enforceable at scale through browser signals, the next battleground is trust: proving eligibility and humanity without creating a new tracking rail.
<h2>2026 Prediction #3: Age verification expands into proof-of-human, and the privacy bar gets higher</h2>
A lot of people still frame <a href="https://aesirx.io/blog/aesirx/privacy-without-surveillance-age-verification-done-right-with-zero-knowledge-proofs">age verification</a> as a narrow regulatory checkbox. That framing won’t survive 2026.
Age verification is merging into a broader category: human verification and community integrity.
We’re entering a year where AI agents don’t just generate content. They participate. They negotiate. They post. They review. They message. They influence. And if you manage a human community, a marketplace, a support channel, or even a B2B onboarding funnel, you will increasingly face a simple operational question:
“How do we keep human spaces human?”
But this is also where the most dangerous implementation mistake will happen: identity used as a blunt instrument.
If the default becomes “centralized ID checks with linkable trails”, we won’t get safer communities. We’ll get a new surveillance rail that follows people across contexts.
So the standard we should demand is not “verification”. It is arms-length verification:
<ul>
<li aria-level="1">The issuer must not learn where you verify.</li>
<li aria-level="1">The relying party must not learn who you are when they only need eligibility.</li>
<li aria-level="1">Unlinkability must be the default.</li>
<li aria-level="1">Accountability should exist, but only under due process, not continuous monitoring.</li>
</ul>
That is what privacy-preserving technology is for: enabling trust without building a tracking layer.
<img src="https/api.aesirx.io/images/images/verification-should-protect-users-not-enable-surveillance.png" alt="verification should protect users not enable surveillance" width="942" height="262" />
Once you accept that we need proof-of-human and eligibility checks, the next question is what happens after verification. In 2026, AI agents will sit inside the same funnels and communities we are trying to protect. If we respond by centralizing everything in massive cloud models, we trade one risk for another. That is why the next wave is lean AI running inside the first-party boundary.
<h2>2026 Prediction #4: AI agents accelerate, and “lean AI” becomes the sustainable path</h2>
2026 will be full of louder AI. More capable models. More autonomous agents. More “AI inside the funnel.”
But it will also be full of an uncomfortable question: is the cost of running these systems becoming sustainable, economically and environmentally, at the scale everyone is promising?
That pressure will create space for a different approach: lean, self-hosted, single-purpose AI.
Not “general intelligence”. Just highly optimized models that do one job extremely well, cheaply, and privately.
And this connects back to Own Path again: when your measurement is first-party and your infrastructure is under your control, you can run narrowly scoped prediction and optimization without exporting raw behavioral data to third parties. That is how you get intelligence without surveillance.
This is where I think agencies will start differentiating in 2026: not “we integrated an AI vendor”, but “we implemented a capability you can own, audit, and run without leaking your customers.”
In practice this looks like lean models running inside a first-party server for forecasting, anomaly detection, or content classification - without exporting behavioral exhaust.
<img src="https/api.aesirx.io/images/images/the-future-of-ai-belongs-to-lean-private-self-hosted-models.png" alt="the future of ai belongs to lean private self hosted models" width="942" height="328" />
<h2>The privacy stance that will define 2026</h2>
2026 is the year we either harden consumer protection into the infrastructure, or we rebrand surveillance as “simplification” and call it progress.
Own Path is not a marketing slogan. It is the clearest privacy-by-design answer to the real problem: third-party ecosystems turn your website into a data export machine. When you remove that export, you protect consumers and you protect the business. You reduce risk, improve integrity, and regain control of measurement by moving to <a href="https://aesirx.io/first-party-product-suite" target="_blank" rel="noopener">first-party digital marketing solutions</a>.
Browser refusal signals are not about making tracking easier. They are about making user agency real at scale. A universal “NO” that is honored consistently is one of the most practical consumer protections we can implement on the modern web, because it stops the “banner negotiation” game and forces stacks to respect the user’s decision.
And privacy-preserving verification is the only acceptable foundation for the coming proof-of-human era. If we want safer communities without a permanent monitoring layer, we must design verification that proves eligibility without revealing identity, and enables accountability without continuous traceability.
<img src="https/api.aesirx.io/images/images/cmps-are-becoming-automated-policy-signals-and-proof-by-design.png" alt="cmps are becoming automated policy signals and proof by design" width="942" height="328" />
So my prediction for 2026 is not just “more regulation” or “more AI”.
My prediction is that the winning strategy becomes obvious:
<ul>
<li aria-level="1">Own your path.</li>
<li aria-level="1">Respect signals.</li>
<li aria-level="1">Verify without tracking.</li>
<li aria-level="1">Build intelligence without surveillance.</li>
</ul>
Because that combination is not only more compliant. It is a better internet for humans.
Own Path is consumer protection you can ship. Browser signals are agency you can enforce. <a href="https://aesirx.io/features/id-verification" target="_blank" rel="noopener">Privacy-preserving ID verification</a> is trust you can defend.
If you’re a digital agency, a privacy professional, or a team rebuilding stacks for 2026, I’d love to hear what you’re seeing right now:
<ul>
<li aria-level="1">Are clients ready to reduce third-party dependency, or are they still stuck in “we need it because everyone uses it”?</li>
<li aria-level="1">Are you being asked about age verification or proof-of-human already?</li>
<li aria-level="1">Do you think Europe will embrace a universal refusal signal in practice, and close the exemptions that would otherwise swallow the rule?</li>
</ul>
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Own your path in 2026: first-party infrastructure, browser refusal signals, and privacy-preserving verification for sustainable, human-first growth

Own Path, Browser Signals & Human-First Trust

What’s Coming in 2026: Own Path, Browser Signals, and the Return of Human-First Trust

2026 shifts privacy from banners to infrastructure: Own Path data control, browser signals, and verification without tracking for real trust.

Privacy Infrastructure for Human-First Growth

On the evening of December 24th, somewhere high above the clouds, Santa Claus was not in a good mood.
The sleigh was polished. The reindeer were ready. The elves had done their usual magic. But in the workshop, a giant crystal dashboard floated in the air, glowing with numbers… and Santa was squinting at it, unimpressed.
“Look at this, Data Elf,” he grumbled. “Visitors to the Nice List are up 37%. Cookie clicks per chimney are up 12%. Reindeer impressions are at an all-time high. And yet—”
He tapped the glass, and the numbers wobbled.
&nbsp; &nbsp; &nbsp;“—I still don’t know if I’m actually making kids happier this year than last year. This thing just tells me everything is busy.”
The Chief Data Elf (head of North Pole Analytics, naturally) sighed.
“Sir, with respect,” she said, “that’s because you’re still measuring traffic, not value.”
<h2>Santa’s old dashboard problem</h2>
For centuries, the North Pole had been proudly data-driven.
Santa’s original analytics were simple: How many letters received. How many chimneys visited. How many presents delivered.
Over time, the elves added more metrics:
<ul>
<li aria-level="1">Average time per chimney</li>
<li aria-level="1">Cookies consumed per household</li>
<li aria-level="1">Milk conversion rate</li>
<li aria-level="1">Sleigh route efficiency per region</li>
</ul>
The dashboard looked fantastic. Lines went up and to the right. Charts pulsed with activity.
And yet, when Mrs. Claus asked the only question that mattered—
“Did we actually make more children genuinely happy this year?”
—Santa could only shrug.
“We sent more gifts,” he’d say. “We had more visits. The charts are very green.”
“But were they the right gifts?” she would ask. “For the right children? At the right time? In the right homes?”
He didn’t know. The system counted movement. It didn’t really understand meaning.
<img src="https/api.aesirx.io/images/images/santas-old-dashboard-problem.png" alt="santas old dashboard problem" width="942" height="932" />
<h2>Naughty, nice… and everything in between</h2>
The Naughty/Nice List had always been binary.
You were either on the Nice side (green), or the Naughty side (red). One bit of data. One decision.
It was simple… and completely insufficient.
What about the kid who had a rough year, misbehaved sometimes, but spent hours helping a younger sibling? What about the child who was perfectly polite but utterly indifferent to their gifts? What about the teenager who wrote a heartfelt letter in November, then ghosted Santa for the rest of the season?
From Santa’s perspective, the old system looked like this:
<ul>
<li aria-level="1">He knew how many children he visited.</li>
<li aria-level="1">He knew how many presents he dropped down chimneys.</li>
<li aria-level="1">He knew how many cookies he ate (unfortunately).</li>
</ul>
But he didn’t really know:
<ul>
<li aria-level="1">Which visits created the most joy.</li>
<li aria-level="1">Which gifts were quietly regifted, ignored, or traded away.</li>
<li aria-level="1">Which children felt truly seen and understood.</li>
</ul>
He could feel the gap, but the dashboard couldn’t show it.
<h2>Enter metric value and engagement score</h2>
So one chilly morning in December, Data Elf called a workshop.
“We need to stop thinking in Naughty vs Nice,” she said, “and start thinking in value.”
Santa raised an eyebrow. “Value? You mean money?”
“Not exactly,” she said. “I mean two kinds of value:
<ol>
<li aria-level="1">Metric value - how much a visit or gift is worth in terms of real impact: joy, usefulness, long-term memory.</li>
<li aria-level="1">Engagement value - how deeply the child is actually interacting with the North Pole: letters, drawings, traditions, excitement, family rituals.”</li>
</ol>
She spread out a magical scroll.
“Right now, we count visits and gifts. But we don’t distinguish between:
<ul>
<li aria-level="1">A plastic trinket that breaks by January 2nd</li>
<li aria-level="1">A book a child reads ten times and keeps for years</li>
<li aria-level="1">A shared board game that creates three hours of family happiness on Christmas Eve”</li>
</ul>
Santa’s eyes softened. He knew exactly which kind of gift he preferred to give.
“From this year,” the Data Elf said, “every gift and every interaction gets two scores:
<ul>
<li aria-level="1">A metric value score, to measure how meaningful the gift is likely to be.</li>
<li aria-level="1">An engagement score, to measure how strongly the child is leaning into the whole Santa experience.”</li>
</ul>
<img src="https/api.aesirx.io/images/images/enter-metric-value-and-engagement-score.png" alt="enter metric value and engagement score" width="942" height="627" />
<h2>Designing Santa’s new scoring model</h2>
Together with the Toy Strategy Department, they defined a simple model.
<h4>Metric value examples:</h4>
<ul>
<li aria-level="1">Small, generic toy → metric value: 10</li>
<li aria-level="1">Personally requested gift (from a letter) → metric value: 40</li>
<li aria-level="1">Gift that supports a real interest (music, drawing, science) → metric value: 60</li>
<li aria-level="1">Gift that brings the family together (board game, shared experience) → metric value: 80-100</li>
</ul>
<h4>Engagement value examples:</h4>
<ul>
<li aria-level="1">No letter, no message → engagement: 0-5</li>
<li aria-level="1">One quick list of wishes → engagement: 10-20</li>
<li aria-level="1">Hand-written letter with drawings and questions → engagement: 40-60</li>
<li aria-level="1">Ongoing tradition: cookies prepared, stocking hung, family reading Santa stories together → engagement: 70-100</li>
</ul>
Now, a visit wasn’t just:
“Child #4021 in Denmark. Nice List. Delivered present.”
It became something like:
“Child #4021 - high engagement (77), high metric value (85). Long letter, family board game, lots of excitement. Very strong outcome.”
Or, in other cases:
“Child #9812 - low engagement (10), low metric value (15). Generic toy, barely any signal. We showed up… but didn’t really land.”
The Naughty/Nice List was still there (Santa did have standards), but it was no longer the whole story.
Now, each child was a little journey of value and engagement.
<img src="https/api.aesirx.io/images/images/ux-flow-with-aesirx.png" alt="ux flow with aesirx" width="942" height="545" />
The next thing the elves did was overhaul Santa’s main dashboard.
Instead of just showing:
<ul>
<li aria-level="1">“Total children visited: 1,312,453”</li>
<li aria-level="1">“Average cookies consumed: 3.2 per home”</li>
</ul>
the new UX Flow (User eXperience Flow, as the elves called it) showed:
<ul>
<li aria-level="1">Top journeys by total metric value - the routes where Santa created the most joy.</li>
<li aria-level="1">Top journeys by average engagement - the homes where the Santa experience really came alive.</li>
<li aria-level="1">Quiet but powerful paths - low volume, very high value.</li>
</ul>
For example:
<ul>
<li aria-level="1">Flow A: “Santa story → letter written → stocking hung → Santa visit → family game night”
<ul>
<li aria-level="2">Medium number of children.</li>
<li aria-level="2">Very high metric value.</li>
<li aria-level="2">Very high engagement.</li>
</ul>
</li>
<li aria-level="1">Flow B: “Last-minute wishlist → rushed visit → random toy → child shrugs”
<ul>
<li aria-level="2">High volume.</li>
<li aria-level="2">Low metric value.</li>
<li aria-level="2">Low engagement.</li>
</ul>
</li>
</ul>
For centuries, Flow B looked like a success: lots of visits, lots of gifts, lots of cookies.
Now, on the UX Flow board, it looked exactly like what it was: busy but shallow.
Flow A, on the other hand, used to be almost invisible. It didn’t generate more “traffic”, but it created the kind of Christmas Santa actually wanted to give: deep, shared, lasting.
That’s where he told the elves:
“These are the journeys we should design for. These are the homes we should learn from. These are the moments we want more of.”
<h2>Real-time: watching Christmas magic in motion</h2>
On Christmas Eve, when the sleigh finally took off, Santa got his favourite gift: a brand new real-time dashboard.
Gone was the lonely number: “Active chimneys: 4,872”.
Instead, he saw a living map of the world with little glowing dots, each representing a home:
<ul>
<li aria-level="1">Some dots glowed faintly - low engagement, low metric value expected.</li>
<li aria-level="1">Some flickered, uncertain - mid-level engagement, generic presents.</li>
<li aria-level="1">Some shone like stars - high engagement homes where Santa knew his visit would land like a small miracle.</li>
</ul>
As the sleigh soared from house to house, Santa could see the scores updating:
<ul>
<li aria-level="1">A child who had written a letter weeks ago recognised the exact gift they’d wished for: metric value up.</li>
<li aria-level="1">A family gathered around the fireplace to open a board game together: engagement up.</li>
<li aria-level="1">A teenager found a book that made them feel understood: both scores rose quietly but meaningfully.</li>
</ul>
This time, Santa wasn’t just watching “deliveries completed” or “chimneys cleared”. He was watching value being created in real time.
And when the night was over, and he was back by the fire with Mrs. Claus, he could answer her question without hesitation.
“Yes,” he said. “This year, we made more real happiness. Not just more trips.”
<img src="https/api.aesirx.io/images/images/what-does-this-have-to-do-with-analytics.png" alt="what does this have to do with analytics" width="949" height="381" />
<h2>What this has to do with you (and your analytics)</h2>
If you swap out Santa for your agency, the story probably feels familiar.
<ul>
<li aria-level="1">The Naughty/Nice List is your old “conversions vs non-conversions” view.</li>
<li aria-level="1">Chimney visits are your sessions and pageviews.</li>
<li aria-level="1">Cookies consumed are your clicks and impressions.</li>
</ul>
They all tell you that something happened. They don’t really tell you whether it mattered.
A value-based model - with metric value and engagement score for the journeys that count - lets you read your visitors more like Santa now reads his Christmas Eve routes:
<ul>
<li aria-level="1">Quiet flows that lead to deep outcomes become visible.</li>
<li aria-level="1">Noisy flows that consume budget but create almost no joy stand out as waste.</li>
<li aria-level="1">“Real-time” stops being a novelty and becomes a way to see where something meaningful is about to happen.</li>
</ul>
<h2>And AesirX in all of this?</h2>
When we build AesirX Analytics, this is the world we have in mind.
A world where:
<ul>
<li aria-level="1">Campaigns don’t just bring visitors, they bring value profiles.</li>
<li aria-level="1">Events aren’t just logs, they’re signals of intent and depth.</li>
<li aria-level="1">Journeys aren’t lines on a chart, they’re stories of how value and engagement build over time.</li>
<li aria-level="1">Real-time views don’t show random activity, they show where your equivalent of Christmas magic is happening right now.</li>
</ul>
Santa has his own first-party data stack (the elves are very strict about privacy). You should have one too.
If this Christmas you find yourself staring at a dashboard full of busy numbers, maybe it’s time to ask a very Santa-style question:
“Am I measuring visits, or am I measuring value?”
And if you’d like your analytics to feel a bit more like that upgraded North Pole dashboard - where metric value and engagement scores make the story clear - AesirX Analytics is built to do exactly that.
Until then, may your flows be meaningful, your visitors engaged, and your work create the kind of outcomes that would make even Santa nod in approval.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

A Christmas tale on why traffic isn’t enough, and how AesirX Analytics shows real value and engagement so you see which journeys truly matter in real time.

Measure value, not just visitors: A Christmas Tale

Measure value, not just visitors: A Christmas Tale from the North Pole

Discover why traffic alone doesn’t drive growth. Learn how AesirX Analytics reveals real value, engagement, and meaningful user journeys in real time.

Measure Value, Not Just Traffic

NEW YORK, DECEMBER 19, 2025 - AesirX Analytics 1.2.0 introduces Real-Time Visitors, giving you a live window into who is on your site right now, what they are doing, and how much value their session is generating. You can track active user journeys, see pages and actions as they happen, and watch session metric values grow in real time. It turns visitor monitoring from a retrospective report into an active insight you can use immediately.
This capability builds on earlier releases in the AesirX value-measurement stack. Version 1.0.0 added UTM Value Mapping to quantify where visitors originate, and 1.0.1 introduced Tag Event Value Mapping to measure the impact of on-site actions. With 1.2.0, these values now converge into a live session view, transforming raw behaviour into a measurable signal you can see and act on inside your own first-party analytics environment.
In addition to real-time visibility, this release also introduces dedicated conversion value reporting in UX Flow and Visitor Detail views. This makes it easier to distinguish flows that generate genuine conversion outcomes from those that only accumulate visit or action value.
<img src="https/api.aesirx.io/images/images/aesirx-analytics-1.2.0-with-aesirx.png" alt="aesirx analytics 1.2.0 with aesirx" width="942" height="206" />
With AesirX Analytics 1.0.0 and 1.0.1, we gave you the tools to measure value:
<ul>
<li aria-level="1"><a href="https://aesirx.io/blog/analytics/aesirx-analytics-v1-0-0-introducing-utm-value-mapping" target="_blank" rel="noopener">1.0.0 introduced UTM Value Mapping</a> - attach value to where visitors come from.</li>
<li aria-level="1"><a href="https://aesirx.io/blog/press-release/aesirx-analytics-v1-0-1-tag-event-value-mapping-and-full-flow-metric-scoring" target="_blank" rel="noopener">1.0.1 added Tag Event Value Mapping</a> - attach value to what they do on your site.</li>
</ul>
With AesirX Analytics 1.2.0, we’re adding the missing piece: Real-Time Visitors - a live view of who’s on your site right now and how much value their session is generating.
Instead of only seeing value after the fact in reports, you can now watch active visitors, their current pages, and their live session metric value as it grows - all inside your first-party analytics stack.
<img src="https/api.aesirx.io/images/images/ui-of-real-time-.png" alt="ui of real time " width="942" height="500" />
<h2>From a small widget to a full Real-Time view</h2>
Until now, real-time data lived in a small Dashboard widget:
“Real-time Active Users” - showing the number of active users and a few recent pages.
In 1.2.0, we’re promoting that widget into a full view under the Visitors menu:
<ul>
<li aria-level="1">Visitors → Real-Time</li>
</ul>
The same logic that powers the Dashboard widget now drives a full-page Real-Time Visitors list, so you can see not just how many users are active, but who they are and what they’re doing right now.
<img src="https/api.aesirx.io/images/images/from-a-small-widget-to-a-full-real-time-view.png" alt="from a small widget to a full real time view" width="942" height="500" />
<h2>Real-Time Visitors: see active sessions as they happen</h2>
The new Real-Time Visitors view shows a live list of all active sessions within a rolling time window (e.g. last 5 minutes). For each visitor/session you can see:
<ul>
<li aria-level="1">Visitor label - anonymized ID for that session.</li>
<li aria-level="1">Last activity - when we last saw an event (e.g. “25s ago”).</li>
<li aria-level="1">Current/last page - which URL they’re currently on or just visited.</li>
<li aria-level="1">Source - UTM summary (if they came from a campaign) or referrer (e.g. “Direct”, “Google”).</li>
<li aria-level="1">Device &amp; platform - desktop/mobile/tablet and browser.</li>
<li aria-level="1">Country - where the session is coming from.</li>
<li aria-level="1">Session metric value - the total metric value for this session so far, based on UTM + Tag Event values.</li>
</ul>
The big number at the top shows the current active visitors, just like the Dashboard, but now you have the detail to understand what’s actually happening on your site in real time.
<h2>Live session value: powered by UTM + Tag Event mapping</h2>
Because 1.2.0 builds on 1.0.0 and 1.0.1, the Real-Time view isn’t just another “active users” counter - it’s driven by the same <a href="https://aesirx.io/documentation/analytics/how-to/aesirx-analytics-guide-how-to-set-up-tag-event-value-mapping" target="_blank" rel="noopener">value mapping</a> you use in your reports.
For each active session, the Session metric value is:
UTM metric value (campaign origin)
<ul>
<li aria-level="1">sum of all Tag Event metric values (actions during the session so far)</li>
</ul>
That means:
<ul>
<li aria-level="1">If a visitor arrives from a high-value campaign, they start with a higher UTM value.</li>
<li aria-level="1">As they interact with your site - viewing key pages, signing up, adding to cart - Tag Events add more value.</li>
<li aria-level="1">The Real-Time view shows that live score updating as they move.</li>
</ul>
You can literally watch high-value journeys forming while they happen.
<h2>One click to full UX Visitor Detail</h2>
Real-time is great, but sometimes you want the full story.
From Visitors → Real-Time, you can click any visitor row to open the existing UX Visitor Detail view:
<ul>
<li aria-level="1">See the full event timeline for that session.</li>
<li aria-level="1">See the UTM Event (if present) as the first row.</li>
<li aria-level="1">See each Tag Event with its metric value.</li>
<li aria-level="1">See the total metric value and Engagement Score for that session in the side panel.</li>
</ul>
So the Real-Time view is your radar, and UX Visitor Detail is your deep dive - and both run on the same first-party event data and value mapping.
<h2>Built on first-party events, not third-party trackers</h2>
Nothing changes about AesirX fundamentals in 1.2.0:
<ul>
<li aria-level="1">Real-Time visitors are computed from the same first-party events collected by the <a href="https://aesirx.io/solutions/analytics/j-avascript" target="_blank" rel="noopener">AesirX Analytics JS Collector</a>.</li>
<li aria-level="1">Value comes from UTM Value Mapping and Tag Event Value Mapping - not from any external pixels.</li>
<li aria-level="1">All data is stored and processed on your First-Party Server.</li>
</ul>
We’re not adding third-party tags to “get real-time”; we’re simply surfacing what your own first-party stack already knows, in a more actionable way.
<h2>Release notes summary (v1.2.0 highlights)</h2>
<div class="table-responsive">
<table class="table table-bordered">
<tbody>
<tr class="bg-primary-stroke-2">
<td style="text-align: center;">&nbsp;&nbsp;Feature</td>
<td style="text-align: center;">Benefit</td>
</tr>
<tr>
<td>
New: Visitors → Real-Time 
</td>
<td>
Full-page Real-Time view listing active visitors/sessions in the selected time window, with per-session details.
</td>
</tr>
<tr>
<td>
New: Per-visitor real-time metrics
</td>
<td>
Each row shows visitor label, last activity, current/last page, source (UTM/referrer), device, country, and live session metric value (UTM + Tag Event metric values).
</td>
</tr>
<tr>
<td>
New: Conversion Value Field
</td>
<td>
A dedicated "Conversion value" indicator is now surfaced in UX Flow overview and UX Visitor Detail. It separates the metric value of conversion-type events from other interactions, so you can quickly identify high-conversion sessions and flows.
</td>
</tr>
<tr>
<td>
Improved: Dashboard → Real-time Active Users
</td>
<td>
The Dashboard widget now links to the new Real-Time view via "View more", using the same underlying real-time logic and active window.
</td>
</tr>
</tbody>
</table>
</div>
<h2>How to get AesirX Analytics</h2>
Get AesirX Analytics and turn every campaign into measurable value.
➡ Setup guide:&nbsp;<a href="https://aesirx.io/documentation/analytics/install-guide/how-to-set-up-aesirx-analytics-javascript-collector" target="_blank" rel="noopener">https://aesirx.io/documentation/analytics/install-guide/how-to-set-up-aesirx-analytics-javascript-collector</a>
&nbsp;Explore our ecosystem at:&nbsp;<a href="https://www.aesirx.io">https://www.aesirx.io</a>

AesirX Analytics v1.2.0: Real-Time Visitors with Live Session Value

Real-Time Visitors in AesirX Analytics 1.2.0 shows active users, their actions, and growing session value live inside your first-party analytics stack. 

AesirX Analytics v1.2.0: Real-Time Visitors

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
Age verification is becoming mandatory across the internet - but if we implement it wrong, we’ll turn “safety” into a new surveillance layer. “Attribute-only” isn’t enough: the real risks are linkability and phone-home backchannels (network metadata and backend requests that can disclose where and when you verified) that let BigTech or BigGov track you over time. The standard we must demand is arms-length verification: the issuer must not learn where you verify, and the relying party must not learn who you are - only eligibility - with privacy by default and accountability only under due process.
</div>
Age verification is rapidly becoming the new “front door” to the internet. Alcohol delivery. Adult content. Gaming. Social media. Dating. Communities. Even ordinary apps that suddenly get reclassified as “high risk”.
And yes - we have to protect children. We have to reduce grooming, fraud, harassment, scams, and coercion.
But we also have to name the danger plainly:
We are on the verge of solving a legitimate safety problem with a surveillance architecture.
That would be a civilizational mistake. Because once age verification becomes routine, it becomes infrastructure. And once it’s infrastructure, it becomes a tempting lever: not just to verify eligibility, but to monitor behavior, map relationships, and normalize control.
<img src="https/api.aesirx.io/images/images/age-verification-must-not-become-the-next-tracking-spine-of-the-internet.png" alt="age verification must not become the next tracking spine of the internet" width="942" height="350" />
<h2>The uncomfortable truth: “attribute-only” is not the same as privacy</h2>
A lot of people are comforted by a simple promise: “Don’t worry - we only reveal the attribute. Just ‘18+’. Just a yes/no.”
That promise is about proof privacy - what the verifier learns from the cryptographic proof content.
Proof privacy matters. But it is not the whole story.
Because the real privacy failure of modern systems rarely happens in the payload. It happens in the rails around it - the correlation handles, the backchannels, the quiet telemetry, the logs that outlive the user’s life choices.
This is why I keep repeating a line that makes some people uncomfortable:
<img src="https/api.aesirx.io/images/images/zk-can-minimize-what-you-reveal.png" alt="zk can minimize what you reveal" width="942" height="383" />
If a wallet calls home. If an issuer performs status checks. If an SDK reports metadata. If a stable identifier is reused. If a verifier keeps central logs. If OS services become the correlation layer - then “attribute-only” becomes a half-truth.
Not malicious. Just incomplete. And in privacy engineering, incomplete is how surveillance ships.
<h2>Linkability + phone-home: the two silent killers</h2>
To understand whether an age verification system is truly privacy-preserving, you need to look beyond “what data is disclosed” and ask two questions:
Linkability: can the same person be correlated across contexts and sites over time? Phone-home: can a third party learn where and when verification happens via backchannels, wallet services, issuer calls, telemetry, or network metadata?
These are not theoretical edge cases. They are the default failure modes of the modern web.
Even when the proof only says “18+”, the system can still betray you. Not by exposing your credential, but by exposing your context: where you verified, when you verified, how often you verify, and whether you’re the same person across different services. That leakage can happen through issuer status checks and revocation calls, wallet backend dependencies, OS-level attestation rails, quiet SDK telemetry, stable identifiers that were “never meant for tracking”, and verifier logs that outlive the moment. And once those patterns exist, you don’t need the credential contents anymore. You can profile someone from metadata alone.
<img src="https/api.aesirx.io/images/images/privacy-isnt-only-about-what-you-show.png" alt="privacy isnt only about what you show" width="942" height="350" />
<h2>The arms-length standard: how verification should work in a free society</h2>
So what should “<a href="https://aesirx.io/features/id-verification" target="_blank" rel="noopener">ID verification done righ</a>t” actually mean?
It must mean arms-length verification - not as a buzzword, but as a structural principle:
The issuer must not learn which service you’re using. The relying party must not learn who you are. And no intermediary should be able to phone home.
That is the line between safety and surveillance.
It’s also the difference between “we used ZK” and “we built a system that cannot be turned into monitoring”.
This is the vantage point behind what we already implement with <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX CMP</a> + <a href="https://www.concordium.com/solution/id-verification" target="_blank" rel="noopener">Concordium ID</a>, and it’s the lens I use to evaluate any age verification proposal - from “ID upload” to “OAuth login” to national wallets to BigTech wallet proofs.
<h2>Why the common approaches fail people</h2>
These aren’t edge cases; they’re the default incentives.
ID upload fails because it turns a private action into a permanent record: full identity data, stored server-side, logged, leaked, reused. You can’t “unshare” a passport scan once it’s out.
OAuth login (Google/Facebook) fails because it’s linkability-by-design. A central identity provider learns every relying party. A stable account identifier becomes a universal correlation handle. Convenience becomes surveillance.
BigTech wallet ZK proofs can reduce what the relying party sees - but can still leave phone-home and correlation risks through wallet backends, OS services, telemetry, and surrounding rails. Cryptography can be clean while the system still leaks context.
State / national wallet systems can be designed toward privacy - but in reality, implementations vary, and many are still struggling with linkability and phone-home patterns. “No tracking” is often a goal, not a guarantee.
This is why it’s dangerous when anyone publishes simplified grids that imply: “Attribute-only means privacy solved.”
It’s not solved until linkability and phone-home are engineered out.
<h2>What we’re actually building: privacy for the many, accountability for the few</h2>
The future we need is not “anonymous chaos” and it’s not “monitored obedience”.
It’s something more mature: privacy by default, and accountability by due process.
In practice, this is what “arms-length” looks like: the AesirX CMP sits at the interaction point as the website’s first-party gatekeeper, triggering verification only when needed and only for a predicate (“over 18”, “eligible”, “one human per service”). Concordium ID delivers the predicate proof so the relying party receives eligibility - not identity. And the flow is designed so the issuer still doesn’t learn where you verified, because the relying party never becomes a reporting endpoint to an issuer, wallet vendor, or state. Finally, the result can be bound to a domain-scoped pseudonymous session (contextual uniqueness), so you can enforce policy without creating a global identifier that follows people across the internet.
And then comes the part most people get wrong:
We do need accountability - because scammers, groomers, stalkers, and fraud networks exploit low-friction systems.
But accountability must not be built as mass surveillance.
So we anchor accountability so that when there is lawful cause and a formal court process, investigators can trace bad actors. That doesn’t mean building permanent behavioral dossiers on everyone else. It means building a system where bad actors know they can be held responsible - without turning ordinary life into a monitored transaction.
<img src="https/api.aesirx.io/images/images/a-free-internet-requires-privacy-by-d%C3%A8ault.png" alt="a free internet requires privacy by dèault" width="942" height="350" />
This is how you get both: fewer bad actors, and more dignity for everyone else.
<h2>Why this is urgent now</h2>
Age verification mandates are expanding - and once verification becomes routine, it becomes infrastructure. Infrastructure attracts gravity: more integration, more logging, more “just one more” safety feature. In that climate, proposals for VPN restrictions, automated scanning of chat messages, and systematic surveillance stop sounding exceptional and start being framed as “practical”.
This isn’t paranoia. It’s a pattern. If we don’t set the standard now, the standard will be set for us - by the same incentives that normalized surveillance capitalism and mass data brokerage.
And once this infrastructure exists, it won’t stay limited to “adult content” or “alcohol”. Mission creep isn’t a conspiracy; it’s what happens when capability meets power.
So this is my line for 2025:
We can protect minors. We can reduce abuse. We can stop fraud. But we must not build a world where “prove you’re allowed” quietly becomes “prove who you are” - everywhere.
<img src="https/api.aesirx.io/images/images/we-must-take-back-control-of-our-personal-data-from-those-who-seek-to-exploit-it.png" alt="we must take back control of our personal data from those who seek to exploit it" width="942" height="350" />
<h2>Reclaim your privacy</h2>
The cause is bigger than a product. It’s bigger than a wallet, a framework, or a regulation.
It’s a decision about what kind of internet we want to live in.
An internet where you can participate as a human being - not as a continuously monitored subject. An internet where safety does not require surrender. An internet where privacy-preserving technology is not optional “nice-to-have”, but a foundational requirement.
Reclaim your privacy - and demand age verification done right: predicate proofs, arms-length separation, domain-scoped pseudonyms, and accountability only under rule of law.
What’s your red line: linkability, phone-home, or central logs?
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

AesirX explains why age verification is becoming mandatory across the internet, and how doing it wrong turns “safety” into a new surveillance layer.

Reclaim Your Privacy

RECLAIM YOUR PRIVACY

AesirX breaks down age verification laws, privacy risks, and how poor implementation can turn online safety into mass surveillance.

AesirX Affiliate2Earn Program

How It Works

Share Your Link

Referral Signs Up

You Get Rewards

Affiliate Commission Rates

Share2Earn Solutions and Services

Consent Management Platform

Analytics

First-Party Server

Privacy Scanner

Privacy Review

Privacy Monitoring

E-Commerce Scanner

First-Party Product Suite

Alliance for Compliance

Share2Earn Content

Danish E-Commerce Awards 2026

AesirX Launches Analytics Pro for WordPress, Bringing First-Party, Value-Based Measurement to Growing Teams

When AI is useful, it’s usually narrow

Your Cookie Solution Is Not Compliant - Because the SaaS Business Model Can’t Be

€100 Per Cookie: The New Unit Economics of Non-Compliance

Beyond cookies: the quiet tracking techniques hiding in your browser

What’s Coming in 2026: Own Path, Browser Signals, and the Return of Human-First Trust

Measure value, not just visitors: A Christmas Tale from the North Pole

AesirX Analytics v1.2.0: Real-Time Visitors with Live Session Value

RECLAIM YOUR PRIVACY

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data