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

Blog Aesirx

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

Blog Press Release Aesirx

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.

Age Verification Without Surveillance

NEW YORK, DECEMBER 12, 2025 – AesirX Analytics 1.0.1 adds Tag Event Value Mapping, so you can assign metric and engagement values to first-party Tag Events directly in the Tag Manager.
The UX Flow now shows a total metric value per journey (UTM + Tag Events) in a new “Metric value” column, while UX Visitor Detail shows the UTM Event first, each Tag Event with its metric value, and a total metric value per session so you can see exactly what high-value visitors did.&nbsp;
Together with 1.0.0’s UTM Value Mapping this gives you full-flow scoring from campaigns to on-site actions today, and prepares the ground for adding conversion-type values next - all inside your own first-party analytics stack running on the AesirX First-Party Server.
<img src="https/api.aesirx.io/images/images/whats-new-for-aesirx-analytics-1-0-1.png" alt="whats new for aesirx analytics 1 0 1" width="942" height="206" />
<a href="https://aesirx.io/blog/aesirx/aesirx-analytics-v1-0-0-introducing-utm-value-mapping" target="_blank" rel="noopener">AesirX Analytics 1.0.0 introduced UTM Value Mapping</a> - a way to attach real value to campaigns inside your own first-party analytics stack. Instead of just counting clicks, you could finally ask: “How much is this UTM-driven visit worth to us?”
AesirX Analytics 1.0.1 is taking the next step: Tag Event Value Mapping. You can assign metric values and user experience engagement values to on-site actions and see them inside User Experience Flow and Visitor Detail.
Where 1.0.0 focused on where users come from (campaigns), 1.0.1 focuses on what they do on your site (tagged events). Together, they give you an end-to-end view of journey value: from first touch to on-site micro-conversions.
<h2>First-party Tag Events: not just “clicks”, but signals of intent</h2>
AesirX Analytics already lets you track Tag Events for things like:
<ul>
<li aria-level="1">Button clicks and CTAs</li>
<li aria-level="1">Form submits and newsletter signups</li>
<li aria-level="1">Video plays or scroll depth</li>
<li aria-level="1">Add-to-cart actions and other micro-conversions</li>
</ul>
These events live in our first-party tag management and JS Collector, controlled by your consent rules in AesirX CMP.
In 1.0.1, we let you turn those events into explicit metric and engagement values - so “Newsletter signup” isn’t just an event in a list, it might be “worth 20 points” in your model, while “Product page view” might be worth 5, and “Add to cart” worth 40.
<img src="https/api.aesirx.io/images/images/tag-event-value-mapping.png" alt="tag event value mapping" width="962" height="529" />
<h2>Tag Event Value Mapping: scoring the actions that matter</h2>
The new Tag Event Value Mapping feature (under Behavior → Tag Value Mapping) lets you:
<ul>
<li aria-level="1">Choose which Tag Events you want to score (by tag name or ID).</li>
<li aria-level="1">Assign a metric value (e.g. 10, 25, 100) to each event.</li>
<li aria-level="1">Assign an additive user experience engagement score (e.g. 10, 25, 100) to each event.</li>
</ul>
You can either define these rules centrally in the Tag Value Mapping screen, or:
Set metric values directly when you create a Tag.
That means when your implementer adds a new tag to track a key action, they can also say “this is a 50-point event” right there. No more back-and-forth between code, spreadsheets, and analytics configuration.
<h2>UX Flow now shows UTM + Tag Event value end-to-end</h2>
UX Flow is the main lens of <a href="https://aesirx.io/solutions/analytics" target="_blank" rel="noopener">AesirX Analytics </a>- it shows every real user journey as a visual flow, with an Engagement Score for each path.
With 1.0.1, UX Flow becomes value-aware:
<ul>
<li aria-level="1">If a visitor comes from a UTM campaign:
<ul>
<li aria-level="2">We show a UTM Event as the first step in their flow, with its UTM metric value (from 1.0.0).</li>
</ul>
</li>
<li aria-level="1">As they move through your site:
<ul>
<li aria-level="2">Every Tag Event appears in the flow with its metric value.</li>
</ul>
</li>
<li aria-level="1">For each flow, we calculate a total metric value:
<ul>
<li aria-level="2">Total metric value = (UTM value) + (sum of all Tag Event values)</li>
</ul>
</li>
<li aria-level="1">Engagement Score is now computed from the engagement values of UTM + Tag Events in the flow.</li>
</ul>
<img src="https/api.aesirx.io/images/images/UX_Flow_now_shows_UTM__Tag_Event_value_end-to-end.png" alt="UX Flow now shows UTM Tag Event value end to end" width="962" height="346" />
In the UI this means:
<ul>
<li aria-level="1">A new “Metric value” column in the UX Flow overview, so you can sort flows not just by visits or engagement, but by total score.</li>
<li aria-level="1">In the flow detail view, you can see:
<ul>
<li aria-level="2">The UTM origin event as the first step (if present)</li>
<li aria-level="2">Each Tag Event with its metric value</li>
<li aria-level="2">A summary of the total metric value for that flow.</li>
</ul>
</li>
</ul>
You go from “this journey is busy” to “this journey is worth 130 points to us, and we know exactly which events created that value.”
<img src="https/api.aesirx.io/images/images/UX_Visitor_Detail.png" alt="UX Visitor Detail" width="962" height="528" />
<h3>UX Visitor Detail: see the story at the single-visitor level</h3>
Sometimes you need to drill down to a single visitor/session to understand what happened.
In UX Visitor Detail, AesirX Analytics 1.0.1 now:
<ul>
<li aria-level="1">Shows the UTM Event (campaign origin) as the first row in the visitor’s activity list, with its metric value (if any).</li>
<li aria-level="1">Shows each Tag Event with its metric value in a dedicated column.</li>
<li aria-level="1">Displays a total metric value for that visitor/session in the side panel.</li>
<li aria-level="1">Engagement Score for that session reflects UTM + Tag engagement values.</li>
</ul>
This makes it easy to answer questions like:
<ul>
<li aria-level="1">“What did this high-value visitor actually do?”</li>
<li aria-level="1">“Which sequence of events drove this 100+ point journey?”</li>
<li aria-level="1">“Are our best journeys coming from the campaigns we think they are?”</li>
</ul>
And because all of this runs on first-party event data, controlled by AesirX CMP, you don’t have to leak this level of detail to external ad platforms to get these insights.
<h3>From campaigns to conversions: closing the loop</h3>
1.0.1 is a key step in a bigger plan:
<ul>
<li aria-level="1">1.0.0 - UTM Value Mapping
<ul>
<li aria-level="2">Assign value to where users come from (campaigns, sources, mediums).</li>
</ul>
</li>
<li aria-level="1">1.0.1 - Tag Event Value Mapping
<ul>
<li aria-level="2">Assign value to what they do on your site (tagged actions and micro-conversions).</li>
</ul>
</li>
<li aria-level="1">Next step - Conversion type value mapping
<ul>
<li aria-level="2">Assign value to specific conversion events (e.g. orders, completed signups) and fold that into the same metric system.</li>
</ul>
</li>
</ul>
Once conversion-type values are added, we’ll have a full circle:
UTM value (origin) + Tag Event value (journey) + Conversion value (outcome) all inside a single first-party, consent-aware analytics stack.
<h2>Still first-party</h2>
Nothing changes about the AesirX fundamentals:
<ul>
<li aria-level="1">Tag Events are still first-party, collected by the <a href="https://aesirx.io/solutions/analytics/j-avascript" target="_blank" rel="noopener">AesirX JS Collector</a>, not 3rd-party tags.</li>
<li aria-level="1">All data is still stored and processed on your <a href="https://aesirx.io/solutions/first-party-server" target="_blank" rel="noopener">First-Party Server</a>.</li>
</ul>
What 1.0.1 adds is simply more meaning to the events you’re already collecting - so UX Flow and Visitor views can prioritize the journeys and actions that actually matter to your business.
<h2>Release notes summary (v1.0.1 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: Tag Event Value Mapping (Behavior → Tag Value Mapping) 
</td>
<td>
<ul class="mb-0">
<li>Assign metric values and UX engagement values to first-party Tag Events.</li>
<li>When creating or editing a Tag, you can define its metric value and engagement value.</li>
<li class="mb-0">Saving the Tag automatically creates/updates the corresponding Tag Event Value Mapping rule.</li>
</ul>
</td>
</tr>
<tr>
<td>
New: UX Flow integration (UTM + Tag metric values) 
</td>
<td>
<ul class="mb-0">
<li class="mb-0 mt-0">UX Flow overview gets a new "Metric value" column showing the total metric value per flow (sum of UTM + Tag Event metric values).</li>
</ul>
</td>
</tr>
<tr>
<td>
New: UX Visitor Detail integration (per-visitor value) 
</td>
<td>
<ul class="mb-0">
<li>In UX Visitor Detail, show the UTM Event as the first row (when present), with its metric value and engagement value.</li>
<li>Show each Tag Event row with its metric value.</li>
<li class="mb-0">Show a total metric value per visitor/session (sum of UTM + Tag Event metric values in that session).</li>
</ul>
</td>
</tr>
</tbody>
</table>
</div>
<h2>How to get AesirX Analytics</h2>
Get AesirX Analytics and turn every campaign into measurable value.
➡ Setup guide
<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>
Explore our ecosystem at: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX Analytics v1.0.1 lets you assign metric and engagement values to Tag Events directly in the Tag Manager for more accurate insights

Tag Event Value Mapping in AesirX Analytics

Upgrade with Tag Event Value Mapping—add metric and engagement values to first-party Tag Events to improve scoring and analytics precision

Assign Engagement Values to Tag Events Easily

AesirX Analytics v1.0.1: Tag Event Value Mapping and Full-Flow Metric Scoring

AesirX Analytics v1.0.1 adds Tag Event Value Mapping: assign metric and engagement values to first-party Tag Events directly in the Tag Manager

AesirX Analytics v1.0.1: Tag Event Value Mapping

TL;DR: Clients don’t buy traffic, they buy outcomes. If your analytics can’t show how much value each visit, journey, and campaign creates, you’re forced to defend your work with vanity metrics instead of business impact.
If you’ve ever presented a monthly report to a client, you know this moment.
You walk them through the numbers: sessions are up, bounce rate is down, click-through looks healthy. The graphs are trending in the right direction, the dashboard is “green,” and then the CMO leans back and asks:
“Okay… but what did this actually do for us?”
And suddenly, all those neat metrics feel strangely thin.
Traditional analytics is incredibly good at counting - visits, pageviews, clicks, time on page. But it’s much weaker at answering the questions that matter to an agency owner or marketing lead:
<ul>
<li aria-level="1">Which campaigns create our best customers, not just the most sessions?</li>
<li aria-level="1">Which journeys are really moving people toward revenue, not just making dashboards busy?</li>
<li aria-level="1">Where should we invest the next dollar of our client’s budget?</li>
</ul>
That gap is exactly why we’ve been reshaping <a href="analytics_js_hardlink" target="_blank">AesirX Analytics</a> around a different starting point:
Don’t measure how busy your site is. Measure how much value each visit creates.
“Clients don’t buy traffic. They buy outcomes. Your analytics should reflect that.”
<h2>Traffic is a noisy signal, value is a clean one</h2>
“More traffic” used to be a reasonable proxy for “more business”. In a world with cheap clicks and little competition, that was often true.
Today, it’s easy to buy traffic and hard to buy attention.
You can spend all month driving people to a landing page, proudly show that sessions doubled… and still not move the needle on qualified leads, pipeline, or sales. The raw numbers don’t tell you who was close to buying, who actually took meaningful steps, or which journey turned anonymous visitors into revenue.
From an agency perspective, that creates three problems:
<ul>
<li aria-level="1">You end up explaining why a “small” campaign is more important than a noisy one.</li>
<li aria-level="1">You’re forced to optimize toward what the tool can measure easily (clicks, sessions), not what really matters (quality, intent, outcome).</li>
<li aria-level="1">Your own strategic work - positioning, UX, message, content architecture - gets flattened into “traffic went up or down.”</li>
</ul>
The reality is simple: traffic is a noisy signal for value. If you want to be taken seriously as a strategic partner, you need to bring something cleaner into the conversation.
<h2>What it actually means to “measure value”</h2>
“Value” sounds abstract until you break it into the two things you actually care about in day-to-day work:
<ol>
<li aria-level="1">Business value - what a visit is worth in economic terms.</li>
<li aria-level="1">Engagement value - how strongly a user is interacting with the experience.</li>
</ol>
In <a href="analytics_js_hardlink">AesirX Analytics</a>, this becomes two parallel tracks:
<ul>
<li aria-level="1">A metric value, which can be thought of in money terms (e.g., “this visit is worth around $10”) or as a numeric score that represents business impact.</li>
<li aria-level="1">An engagement score, which captures how “deep” or “serious” the interaction is from a UX perspective.</li>
</ul>
Think about a typical B2B or e-commerce site your agency works on. Some actions are clearly more valuable than others:
<ul>
<li aria-level="1">Browsing a blog article is a light touch.</li>
<li aria-level="1">Landing on a high-intent product page shows more interest.</li>
<li aria-level="1">Signing up to the newsletter is a commitment.</li>
<li aria-level="1">Viewing pricing, starting a trial, requesting a demo or adding to cart are all strong buying signals.</li>
</ul>
In a value-based model, you stop treating all of those events as equal. You recognize that your client’s business has a hierarchy of intent, and you encode that into the analytics layer by assigning:
<ul>
<li aria-level="1">A metric value to each key action (e.g., a newsletter signup might be “worth” more to the business than a simple page view).</li>
<li aria-level="1">An engagement value to reflect how much that action tells you about the user’s interest level (e.g., someone who hits pricing and then a trial page is more engaged than someone who just skims a blog).</li>
</ul>
Now combine that with the source. A visit from a branded search ad may start with a higher metric value than a random social click. A visitor coming from a carefully nurtured email sequence may earn a higher engagement score from the moment they arrive than cold display traffic.
Once you attach both kinds of value to campaigns and on-site actions, a few things change:
<ul>
<li aria-level="1">A session is no longer “one visit”. It becomes a series of value events where metric value and engagement build up over time.</li>
<li aria-level="1">A journey isn’t just “four pages and two clicks”. It becomes a story you can read: where value was created, where interest spiked, and where it dropped.</li>
<li aria-level="1">A campaign stops being “1,200 sessions” and starts being “this many visits that, on average, created this much business value at this level of engagement.”</li>
</ul>
The goal here isn’t mathematical perfection. It’s narrative clarity.
You gain a language for impact that a client can understand in one sentence:
&nbsp; &nbsp; &nbsp; &nbsp;“We increased average session value on your key funnel by 37% and pulled more users into high-engagement journeys,”
which lands very differently from:
&nbsp; &nbsp; &nbsp; &nbsp;“We reduced bounce rate by 2.1%.”
“A journey isn’t ‘four pages and two clicks’ - it’s a sequence of value events that either moves someone closer to revenue, or it doesn’t.”
<h2>How a value model changes agency work</h2>
Once you start looking at flows, campaigns and visitors through a value lens, your day-to-day priorities quietly shift.
You stop opening analytics to ask, “What got the most traffic?” and you start asking much sharper questions:
<ul>
<li aria-level="1">Which journeys generate the highest average metric value?</li>
<li aria-level="1">Which entry points consistently lead into those journeys?</li>
<li aria-level="1">Which campaigns feed high-engagement flows, even if they’re not the biggest on volume?</li>
</ul>
When you have both metric value and engagement score, patterns appear that you simply couldn’t see before.
You notice that some of your top-traffic pages are basically dead ends. They look great on a “Top Pages” report, but when you look at value, they’re almost flat: people pass through, click a bit, and leave without doing anything that matters. The metric value barely moves; the engagement score stays shallow.
Then you notice the opposite: quiet little journeys that hardly anyone talks about, but that punch far above their weight. A specific blog post that tends to lead people to a high-intent product page, then to pricing, then to a contact form. Not many visitors, but every time someone takes that path, both the metric value and the engagement score spike.
In <a href="analytics_js_hardlink">AesirX Analytics</a>, UX Flow is where that becomes visible: you see each user experience flow as a line in a list, with its sessions, total and average metric value, and how engaged those visitors were. Open a flow and you see the detailed visitor paths that make it up. For an agency, those quiet, high-value flows are where you really earn your retainer:
<ul>
<li aria-level="1">They’re the journeys you want to send more traffic into.</li>
<li aria-level="1">They’re the journeys your CRO team should be polishing first.</li>
<li aria-level="1">They’re the journeys you call out in client reports: “We found this path, it delivers your highest-value sessions with the strongest engagement, and we’re now restructuring campaigns and UX to send more people through it.”</li>
</ul>
On the flip side, a value model lets you have an honest conversation about waste. When a channel is loud but low-value, the story is obvious: lots of sessions, weak metric value, shallow engagement. You’re no longer arguing from opinion or gut feeling; you’re showing the value profile of that traffic in a model you and the client agreed on.
That doesn’t just make you look better in meetings. It changes the decisions you make: what to scale, what to fix, and what to stop doing altogether.
“A value model turns ‘busy’ analytics into a map: it shows you which journeys to scale, which to fix, and which to stop caring about.”
<h2>Real-time visibility: seeing value as it forms</h2>
There’s another benefit to building your analytics around value instead of volume: you can watch it as it happens, not just in end-of-month reports.
Real-time analytics becomes genuinely useful the moment you stop staring at a counter that says “Active users: 47” and start asking a different question:
“Which of these sessions is actually creating value right now?”
Imagine sitting with a client during a launch or a seasonal campaign. Instead of a vague widget with a single number, you’re looking at a live list of visitors where each row shows:
<ul>
<li aria-level="1">where they came from (campaign or referrer),</li>
<li aria-level="1">which page they’re currently on,</li>
<li aria-level="1">and a session metric value that grows as they take high-value actions.</li>
</ul>
Some sessions flicker into life, pick up a little value and then stall. Others climb steadily as the visitor moves through your best flows: high-intent pages, key interactions, signups, add-to-cart, checkout steps. You can almost see the story unfolding in real time.
Suddenly, “real-time analytics” isn’t a novelty graph in the corner of a dashboard. It’s a live view of value creation.
You see immediately if:
<ul>
<li aria-level="1">a campaign that looked great on paper is actually feeding low-value sessions in practice;</li>
<li aria-level="1">a UX issue on a high-value path is blocking people right now, not just “according to last month’s report”;</li>
<li aria-level="1">a particular segment - for example, visitors from a specific email list or partner - reliably turns into your best, highest-value traffic when they show up.</li>
</ul>
And because the same value model also feeds into UX Flow and Visitor Detail, you’re one click away from understanding why those sessions look the way they do: which actions drove value, where engagement peaked, where it dropped.
It’s the difference between watching how busy your site is and watching the health of your pipeline in real time.
“Real-time becomes powerful the moment you stop counting visitors and start watching where value is forming in front of you.”
<h2>Why we built AesirX Analytics around value</h2>
In <a href="analytics_js_hardlink" target="_blank">AesirX Analytics</a>, we decided early on that this value lens should not be an afterthought in a spreadsheet - it should be baked into how the product sees the world.
That’s why the core concepts are built to support you as an agency or marketing team:
<ul>
<li aria-level="1">Campaigns aren’t just labels. You can attach explicit metric and engagement value to the UTM-tagged traffic you send, so flows and visitors inherit those values from the moment they land.</li>
<li aria-level="1">On-site actions aren’t just events. Tag Events can carry both metric and engagement values that reflect what matters to your client’s business - from light micro-engagements to strong signals like signups and add-to-carts (visit, actions and conversion type events).</li>
<li aria-level="1">Journeys and visitors are scored, not just counted. UX Flow and Visitor views don’t just show paths and timestamps; they show how value accumulates across the journey so you can recognize high-value patterns immediately.</li>
<li aria-level="1">Real-time isn’t just a vanity number. The live visitors view doesn’t stop at “4 users on site now” - it shows live session value based on the same model, so you can see which current sessions are truly worth paying attention to.</li>
</ul>
All of this runs on a first-party stack, because you shouldn’t have to trade privacy or control in order to understand your own value creation.
The point isn’t to make analytics more complicated. The point is to make your work easier to explain and easier to steer.
When you can see value clearly, decisions that used to be political or opinion-driven suddenly become obvious: invest here, fix this flow, stop wasting money over there.
“The point isn’t to track more data; it’s to see clearly where value is created so you can move more of it in the right direction.”
<h2>Bringing this back to your own practice</h2>
If you’re leading an agency or a marketing team, you don’t have to rebuild your entire reporting stack tomorrow. You can start very small and still feel the difference.
Begin by picking just a handful of key actions in your main funnel - the pages and events that actually matter to your client - and agree on rough metric and engagement values for them. Then look at your main acquisition channels and give them a simple value scale too: which ones tend to bring in people who behave like buyers, and which ones mostly bring noise?
Once you’ve done that, open your analytics and read your journeys and visitors through that lens. Ask yourself: which combinations of source + actions are producing the most valuable sessions, and which flows look busy but shallow?
Even an imperfect value model is better than none. It gives you a language for impact that clients immediately understand and a filter for where to focus limited time and budget. It turns “we did a lot of activity” into “this is where your business is actually created.”
If you like the idea of analytics that’s built around this from the ground up - where campaigns, events, flows and real-time visitors all speak the same value language - that’s exactly the experience we’re designing in <a href="analytics_js_hardlink" target="_blank">AesirX Analytics</a>.
If you think this approach to a more meaningful analytics experience would help your agency show clearer value to your customers, try AesirX Analytics on a 2-week trial and see what it changes in your reporting.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

AesirX Analytics tracks the value each visit, campaign, and journey creates, giving clear business impact insights instead of vanity metrics.

Measure value, Not just traffic

Measuring value, not traffic, reframes analytics around outcomes. It highlights which journeys and campaigns create real business impact instead of empty activity.

NEW YORK, DECEMBER 5, 2025 – AesirX today announces the release of AesirX Analytics v1.0.0, introducing UTM Value Mapping, a feature that assigns real monetary value to campaigns directly inside a first-party analytics stack.&nbsp;
This milestone shifts the focus from AesirX CMP – strengthening their consent-before-tracking model and building out their standalone JS version – back to analytics, giving organizations a compliant way to quantify marketing performance without third-party tracking.
This turns analytics from a passive reporting layer into a source of verified business intelligence: one where every click, visit, and campaign carries a measurable contribution, defined by the organization that owns the data, not by a third-party platform.
<h2>The problem: traffic is easy, value is hard</h2>
Most analytics tools will tell you how many sessions came from:
<ul>
<li aria-level="1">utm_source=facebook</li>
<li aria-level="1">utm_medium=cpc</li>
<li aria-level="1">utm_campaign=bf2025</li>
<li aria-level="1">utm_content=ad-1</li>
<li aria-level="1">utm_id=001</li>
<li aria-level="1">utm_term=this-product</li>
<li aria-level="1">website=aesirx.io</li>
</ul>
But they won’t tell you, in a clean, controllable way:
<ul>
<li aria-level="1">What each visit from that campaign is worth to your business.</li>
<li aria-level="1">How to standardize and document your UTM usage over time.</li>
<li aria-level="1">How to avoid the mess of Facebook, facebook, fb, FB-ads and other naming chaos.</li>
</ul>
So teams fall back to:
<ul>
<li aria-level="1">Manually updated UTM spreadsheets.</li>
<li aria-level="1">Internal “UTM calculators” to generate URLs.</li>
<li aria-level="1">A lot of guesswork when someone asks: “What did this campaign actually generate in value, not just clicks?”</li>
</ul>
AesirX Analytics already offers first-party UTM tracking and a built-in UTM generator. With UTM Value Mapping, they’re closing the loop:
<img src="https/api.aesirx.io/images/images/1-you-can-now-assign-fiscal-values-to-your-utm-campaigns-and-see-the-impact-directly-in-your-reports.png" alt="1 you can now assign fiscal values to your utm campaigns and see the impact directly in your reports" width="942" height="350" />
<h2>What’s new for AesirX Analytics 1.0.0?</h2>
In AesirX Analytics 1.0.0, you’ll find a new option under the Tracking menu:
Tracking → UTM Value Mapping
This lets you create simple, readable rules like:
<ul>
<li aria-level="1">“Every visit with utm_source=facebook and utm_campaign=bf2025 is worth 5 USD”.</li>
<li aria-level="1">“Every event where utm_medium=email and event type = signup is worth 20 EUR”.</li>
</ul>
Each rule has:
<ul>
<li aria-level="1">Conditions based on UTM parameters.
<ul>
<li aria-level="2">utm_source, utm_medium, utm_campaign, utm_term, utm_content,utm_id,utm_term,website</li>
</ul>
</li>
<li aria-level="1">Optional context (e.g. landing page, event type).</li>
<li aria-level="1">A value (numeric amount).</li>
<li aria-level="1">A currency (e.g. USD, EUR, VND).</li>
<li aria-level="1">A value type (per visit, per event, etc.).</li>
</ul>
Once configured, AesirX Analytics automatically:
<ol>
<li aria-level="1">Matches incoming sessions/events to your value rules.</li>
<li aria-level="1">Assigns the defined value in the selected currency.</li>
<li aria-level="1">Aggregates this into your UTM and campaign reports.</li>
</ol>
You’ll be able to see, inside AesirX Analytics:
<ul>
<li aria-level="1">Total value per UTM campaign, source, medium.</li>
<li aria-level="1">Average value per visit for each campaign.</li>
<li aria-level="1">Value per event (e.g. signup, lead submission, etc.).</li>
</ul>
<img src="https/api.aesirx.io/images/images/2-all-of-it-computed-in-your-first-party-analytics-stack-with-no-extra-scripts.png" alt="2 all of it computed in your first party analytics stack with no extra scripts" width="942" height="350" />
<h2>Built-in UTM hygiene: less chaos, more control</h2>
UTM spreadsheets became popular not for calculations, but for control: they limit parameter values, record created links, and turn internal codes into readable labels. AesirX have brought those benefits into their Analytics.
<h3>1. Controlled UTM parameter values</h3>
When you define value rules, each UTM field is backed by:
<ul>
<li aria-level="1">Dropdowns with existing values already seen in your data.</li>
<li aria-level="1">The option to add new values in a controlled way.</li>
</ul>
That means you can standardize on:
<ul>
<li aria-level="1">utm_source=facebook (instead of 10 different variants).</li>
<li aria-level="1">utm_medium=cpc, utm_medium=email, etc.</li>
</ul>
This reduces typos and keeps your reporting clean over time.
<h3>2. Documented UTM links - no more mystery URLs</h3>
AesirX’s existing UTM generator already lets you create tracking URLs. With the new release, you can treat it as your internal UTM library:
<ul>
<li aria-level="1">View a history of generated UTM links.</li>
<li aria-level="1">See when they were created and for which campaign.</li>
<li aria-level="1">Optional: attach a default value rule directly when generating a link.</li>
</ul>
That means you no longer need a separate “UTM sheet” just to remember what you launched last quarter - AesirX keeps that history for you.
<h3>3. Human-readable labels for complex setups</h3>
In more complex environments, UTM values may look like this:
<ul>
<li aria-level="1">utm_campaign=bf25_cpc_1234</li>
<li aria-level="1">utm_source=g</li>
</ul>
To make that usable, AesirX Analytics lets you define aliases/labels such as:
<ul>
<li aria-level="1">bf25_cpc_1234 → “Black Friday 2025 - CPC Search”</li>
<li aria-level="1">g → “Google Ads”</li>
</ul>
Reports can then show:
Black Friday 2025 - CPC Search (bf25_cpc_1234)
<img src="https/api.aesirx.io/images/images/3-human-readable-labels-for-complex-setups.png" alt="3 human readable labels for complex setups" width="942" height="350" />
<h2>Connecting campaign value with UX Flow engagement</h2>
If you’re already using AesirX Analytics, you know that UX Flow is the heart of the product.
UX Flow lets you open up your site and see:
<ul>
<li aria-level="1">How visitors actually move through your pages.</li>
<li aria-level="1">Where they engage (actions, events).</li>
<li aria-level="1">Where they convert or drop off.</li>
</ul>
Every flow is given an Engagement Score based on:
<ul>
<li aria-level="1">Actions (scroll depth, clicks, time on page, etc.).</li>
<li aria-level="1">Events (signups, form submissions, downloads).</li>
<li aria-level="1">Conversions (purchases, key goals).</li>
</ul>
With UTM Value Mapping, you can now use your UTM rules not only to assign fiscal value, but also to influence how engagement is scored for different flows.
<h3>1. Why this matters</h3>
Not all engagement is equal. A long session from a random organic visit might be interesting, but a shorter session from a high-value campaign that leads to a qualified lead or purchase may be much more important.
By attaching both monetary value and optional Engagement weight to specific UTM campaigns and mediums, you can:
<ul>
<li aria-level="1">Boost the Engagement Score of flows that come from strategic campaigns.</li>
<li aria-level="1">See which paths through your site are not just busy, but genuinely valuable.</li>
<li aria-level="1">Prioritize UX improvements on flows that really move the needle.</li>
</ul>
<h3>2. How it works in practice</h3>
<ol>
<li aria-level="1">You define a UTM value rule, for example:
<ul>
<li aria-level="2">utm_source = facebook, utm_campaign = bf2025</li>
<li aria-level="2">Value: 5 USD per visit</li>
<li aria-level="2">(Optional) Engagement weight: +10 points</li>
</ul>
</li>
</ol><ol start="2">
<li aria-level="1">When someone lands on your site with that campaign:
<ul>
<li aria-level="2">AesirX Analytics assigns the 5 USD value in your reports.</li>
<li aria-level="2">UX Flow calculates a base Engagement Score for that session.</li>
<li aria-level="2">Then it applies your UTM Engagement weight, resulting in an adjusted Engagement Score.</li>
</ul>
</li>
</ol><ol start="3">
<li aria-level="1">In the UX Flow view, you can:
<ul>
<li aria-level="2">See which flows are driven by that campaign.</li>
<li aria-level="2">View both the base and UTM-adjusted Engagement scores.</li>
<li aria-level="2">Filter or focus on flows where both engagement and campaign value are high.</li>
</ul>
</li>
</ol>
<img src="https/api.aesirx.io/images/images/4-the-result-is-a-much-clearer-picture-of.png" alt="4 the result is a much clearer picture of" width="942" height="350" />
And, because everything is still running on your first-party AesirX stack, you keep full control over how value is defined, how engagement is scored, and how those insights are used - without handing detailed behavioral value data back to third-party ad platforms.
<h2>Performance marketing without abandoning privacy</h2>
From the beginning, AesirX has taken a different approach:
<ul>
<li aria-level="1">First-party - your data stays on infrastructure you control.</li>
<li aria-level="1">Consent-before-tracking - aligns with GDPR and ePrivacy Directive 5(3), not work around them.</li>
<li aria-level="1">Pragmatic for marketing - believes data should be useful.</li>
<li aria-level="1">UX Flow - reveals user paths and the actions that drive results.</li>
</ul>
UTM Value Mapping is a direct extension of that philosophy:
<ul>
<li aria-level="1">You decide what a visit, signup, or lead from a given campaign is worth.</li>
<li aria-level="1">You model that inside your own analytics - without exposing those values to third-party ad platforms.</li>
<li aria-level="1">You keep the flexibility to refine values as your understanding improves (e.g. adjusting lead value by channel).</li>
</ul>
<h2>Architectural change: CMP and Analytics are now split</h2>
<a href="https://aesirx.io" target="_blank" rel="noopener">AesirX</a> has made an important architectural decision existing users should be aware of.
Until now, AesirX Analytics PWA also contained consent flows. With this release:
<ul>
<li aria-level="1">They have removed the consent flows from the Analytics PWA.</li>
<li aria-level="1">All consent UX and logic now live in the standalone JS version of AesirX CMP, within the CMP PWA.</li>
<li aria-level="1">Going forward, CMP and Analytics will be fully split as two independent solutions.</li>
</ul>
<h3>What this means for you</h3>
<ul>
<li aria-level="1">If you only need CMP / consent management, you can run AesirX CMP JS and the CMP PWA without touching Analytics.</li>
<li aria-level="1">If you only need first-party Analytics, you can run AesirX Analytics without embedding CMP flows.</li>
<li aria-level="1">If you want both, they are designed to work together, but you’re no longer forced into a monolithic “all-in-one” setup.</li>
</ul>
This gives more flexibility to deploy the pieces that fit your current stack, integrate with other systems, and evolve from basic consent management to full first-party analytics at your own pace.
Notice: For users of the original Unified (Analytics + CMP) freemium version for WordPress and Joomla, AesirX will be updating and splitting the original version into independent solutions for First-Party Consent Management and Analytics in near-future offering a freemium base for small business owners and organizations that can not afford to invest in the full pro versions.
<h2>Release notes (v1.0.0 summary 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: UTM Value Mapping 
</td>
<td>
Assign fiscal values and currency to UTM campaigns and events, so reporting reflects business impact instead of clicks.
</td>
</tr>
<tr>
<td>
Improved: UTM tracking and generator as an internal UTM library
</td>
<td>
Standardize and document campaign links without spreadsheets, reducing errors and naming inconsistencies.
</td>
</tr>
<tr>
<td>
New: Alias/label support for complex UTM values
</td>
<td>
Translate technical UTM strings into readable campaign names, making reports clear for marketing and leadership teams.
</td>
</tr>
<tr>
<td>
New: UTM Value Mapping → UX Flow Engagement Scoring 
</td>
<td>
Connect campaign value to user journeys, prioritizing flows that deliver measurable business outcomes.
</td>
</tr>
<tr>
<td>
New: User Handling in PWA
</td>
<td>
Better manage authenticated user interactions for more accurate analytics tied to real engagement.
</td>
</tr>
<tr>
<td>
New: Size and speed optimization of the Analytics JS Collector
</td>
<td>
Faster load times and reduced script weight for improved site performance and cleaner data collection.
</td>
</tr>
<tr>
<td>
Change: Consent flows removed from Analytics PWA and moved into standalone AesirX CMP JS (CMP PWA)
</td>
<td>
Run analytics or consent independently, with no forced bundling or monolithic deployments.
</td>
</tr>
<tr>
<td>
Change: CMP and Analytics now split into independent solutions
</td>
<td>
Adopt either product on its own or combine both as needed, aligning implementation with your existing stack.
</td>
</tr>
</tbody>
</table>
</div>
<h2>What’s next</h2>
AesirX Analytics now enters active go-to-market as a mature first-party alternative. Upcoming releases will expand:
<ol>
<li aria-level="1">Deeper value attribution views / reporting (per channel, per funnel step).</li>
<li aria-level="1">Extended integration to first-party tag management directly in the first-party stack.</li>
<li aria-level="1">Combined UTM and Tag value attribution and reporting .</li>
</ol>
For anyone using UTM links today, UTM Value Mapping answers the question that finally matters: which campaigns actually create value, and by how much, all inside your own first-party analytics, aligned with your consent and compliance model.
<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>
Explore our ecosystem at: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX Analytics 1.0.0 assigns real monetary value to UTM campaigns using first-party data, delivering accurate ROI without third-party trackers.

AesirX Analytics 1.0: UTM Value Mapping

AesirX Analytics v1.0.0: Introducing UTM Value Mapping

 Blog Analytics

AesirX Analytics v1.0.0 introduces UTM Value Mapping to assign real monetary value to campaigns using first-party data, without third-party trackers.

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
The Belgian DPA’s Inspection Service has <a href="https://www.linkedin.com/posts/petercraddock_redacted-decision-on-privacy-friendly-analytics-activity-7401295349233123328-zpns" target="_blank" rel="noopener">dismissed a complaint</a> against a “privacy-friendly analytics” provider by claiming JavaScript in RAM is not “storage” under Article 10/2 (the Belgian cookie rule implementing ePrivacy Directive 5(3)) and that IP addresses here are not personal data, a view that ignores how modern browsers and tracking actually work.
</div>
<h2>The case in one paragraph - and who the Inspection Service is</h2>
The decision at the centre of this discussion comes not from the Belgian DPA’s Litigation Chamber (which issues binding decisions and fines), but from its Inspection Service - the DPA’s investigative arm. The Inspection Service examines complaints, runs investigations, and then decides whether to pursue a case further or close it. In this matter, it concluded that there was no sufficient evidence of GDPR infringement and that the cookie rules (Article 10/2 of the Belgian Data Protection Act, implementing Article 5(3) ePrivacy Directive) did not apply in the way the complainant alleged.
In public commentary, the case has been framed as a success story for “privacy-friendly analytics”. My view is almost the opposite: it’s a textbook example of what happens when an authority reasons about digital technology from the dictionary up instead of starting with how browsers and tracking actually function today.
For DPOs, privacy lawyers and privacy engineers, it’s worth unpacking why.
<img src="https/api.aesirx.io/images/images/if-you-risk-model-depends-on-js-in-ram-not-being-storage-youre-building-on-sand.png" alt="if you risk model depends on js in ram not being storage youre building on sand" width="942" height="400" />
<h2>What the Inspection Service actually decided</h2>
From the (heavily redacted) translated ruling, the reasoning can be summarised in three steps:
<h3>1. On ePrivacy Directive / cookie rules (Article 10/2 of the 2018 Act)</h3>
<ul>
<li aria-level="1">The complaint argued that JavaScript tracking scripts were placed on the user’s terminal equipment without consent, contrary to Article 5(3) ePrivacy Directive (as implemented by Article 10/2).</li>
<li aria-level="1">The Inspection Service responded that JavaScript “runs in volatile memory” and that such memory is not “storage” within the meaning of the cookie rule. Dictionaries were cited to define “to store” as “to keep for later use”, with an emphasis on a future-use time component and on non-volatile storage.</li>
<li aria-level="1">On that basis, executing JavaScript in RAM did not qualify as “storing information” on the terminal equipment.</li>
</ul>
<h3>2. On GDPR / personal data</h3>
<ul>
<li aria-level="1">The provider acknowledged processing IP addresses but argued that it could not realistically identify individuals based on IP alone, especially as a US-based company dealing with Belgian ISP data.</li>
<li aria-level="1">The Inspection Service, relying on Breyer and the more recent SRB judgment, accepted that in this context IP addresses were not personal data for this controller, because identification would require disproportionate effort.</li>
</ul>
<h3>3. On procedure and interest</h3>
<ul>
<li aria-level="1">The complaint was also criticised for lack of concrete evidence, questionable territorial scope and for essentially pursuing an “actio popularis” (public interest complaint) rather than a personal grievance.</li>
<li aria-level="1">Using its discretion, the Inspection Service decided not to investigate further, while leaving open the possibility of revisiting the matter if better-documented complaints are filed in future.</li>
</ul>
On paper, this might look neat and pragmatic. In practice, it rests on a version of the web that no longer exists.
<h2>ePrivacy Directive 5(3): why “storage vs memory” is the wrong battle</h2>
Article 5(3) of the ePrivacy Directive - now embedded in Article 10/2 of the Belgian Data Protection Act - was drafted to be technology-neutral. It doesn’t talk about cookies, RAM, or hard drives. It talks about:
“storing information, or gaining access to information already stored, in the terminal equipment of a subscriber or user”.
The Inspection Service tries to carve out a safe harbour for JavaScript by insisting that:
<ul>
<li aria-level="1">JavaScript is “just code” executed in the browser’s runtime;</li>
<li aria-level="1">it resides only in volatile memory;</li>
<li aria-level="1">therefore, it doesn’t meet the “stored for later use” criterion, and the cookie rule doesn’t apply.</li>
</ul>
There are two problems with this.
<h3>The law already moved beyond cookies</h3>
For more than a decade, European regulators have treated Article 5(3) as covering any technique that writes data to, or reads data from, a user’s device - including device fingerprinting based on browser and DOM attributes, cached resources, and other “cookie-less” identifiers.
The European Data Protection Board’s latest guidance on the technical scope of Article 5(3) makes several key points:
<ul>
<li aria-level="1">“Storage” means placing information on any electronic storage medium that forms part of the user’s device. It does not exclude RAM or CPU cache.</li>
<li aria-level="1">There is no minimum duration for storage. Even very short-lived writes can fall under Article 5(3) if they are used to track or identify users.</li>
<li aria-level="1">JavaScript that instructs the browser to send identifiers or behavioral data back to a remote server is one of the canonical examples of operations that do fall within the scope.</li>
</ul>
In other words, the Inspection Service is trying to reopen a door that the EDPB has spent years closing.
Browsers in 2025: you can’t separate execution from storage
Technically, the decision’s distinction between “memory” and “storage” just doesn’t align with how browsers work today:
<ul>
<li aria-level="1">When your browser fetches <a href="https://analytics.example/script.js" target="_blank" rel="noopener">https://analytics.example/script.js</a>, that resource is stored - in the HTTP cache, in RAM, sometimes on disk - so it can be executed and re-used.</li>
<li aria-level="1">The JavaScript engine compiles the script and holds it in memory as bytecode or machine code; the browser then creates and updates data structures in the DOM and JS heap to represent everything from the page layout to user events, performance metrics and device characteristics.</li>
<li aria-level="1">Modern tracking is heavily based on reading and writing those in-memory structures: screen size, font lists, canvas rendering output, audio fingerprinting, pointer movements, scroll depth, etc.</li>
</ul>
From the user’s perspective, there is no meaningful difference between:
<ul>
<li aria-level="1">a third-party script that drops an HTTP cookie and reads it later; and</li>
<li aria-level="1">a third-party script that reads a constellation of DOM and API values and uses them to single out their device across visits.</li>
</ul>
Both are invisible. Both are initiated remotely. Both involve accessing information on the device that the user did not explicitly request to be used for tracking.
<img src="https/api.aesirx.io/images/images/the-browser-is-the-real-tracking-surface-not-just-the-cookie-jar.png" alt="the browser is the real tracking surface not just the cookie jar" width="942" height="350" />
<h3>The device boundary is what matters</h3>
Once you take the device boundary seriously, the “JavaScript in RAM is not storage” line becomes a semantic distraction. The real question under Article 10/2 is:
<ul>
<li aria-level="1">Does this operation place information on, or access information from, the user’s terminal equipment?</li>
<li aria-level="1">Is it strictly necessary for the service the user requested?</li>
<li aria-level="1">If not, has the user given valid consent?</li>
</ul>
JavaScript-based analytics and optimization code clearly answer “yes”, “no”, and “usually no” to those three questions. The fact that some of the moving parts live in RAM is irrelevant to the protection the law is trying to provide.
The same pattern repeats on the GDPR side.
<h2>GDPR and IP addresses: identifiability in a data-broker world</h2>
On the GDPR side, the Inspection Service leans on Breyer and SRB to conclude that the IP addresses processed by the analytics provider are not personal data in this context, because:
<ul>
<li aria-level="1">the provider is based in the US;</li>
<li aria-level="1">it would have to approach a Belgian ISP to obtain subscriber details;</li>
<li aria-level="1">given time, cost and effort, that is not “reasonably likely” to happen.</li>
</ul>
This again feels tidy on paper, but it ignores both the case law and the realities of today’s data ecosystem.
On the GDPR side, the Inspection Service leans on Breyer and SRB to conclude that the IP addresses processed by the analytics provider are not personal data in this context, because:
<ul>
<li aria-level="1">the provider is based in the US;</li>
<li aria-level="1">it would have to approach a Belgian ISP to obtain subscriber details;</li>
<li aria-level="1">given time, cost and effort, that is not “reasonably likely” to happen.</li>
</ul>
This again feels tidy on paper, but it ignores both the case law and the realities of today’s data ecosystem.
<h3>Breyer never required the controller to stand alone</h3>
In Breyer, the Court of Justice held that dynamic IP addresses can be personal data for a website operator even when only the ISP has the extra information needed to name the user. What matters is whether there are legal and practical means reasonably likely to be used to identify the person - including via third parties.
The test is explicitly contextual:
<ul>
<li aria-level="1">you look at the means available to the controller (and others),</li>
<li aria-level="1">not just at what the controller currently chooses to do.</li>
</ul>
Reading Breyer as “if it would be annoying to ask an ISP, the IP isn’t personal data” is a misinterpretation.
<h3>SRB is about real pseudonymisation, not “we promise not to look”</h3>
SRB adds nuance by clarifying that data can stop being personal for a specific recipient if it is properly pseudonymised and that recipient has no realistic way to reverse it or to link it back to an individual.
In the analytics scenario, however, the provider is receiving raw IP addresses as part of HTTP traffic and using them as part of attention and performance statistics. There is no separate key, no independent holder of the mapping, no cryptographic barrier.
Equating that situation to the pseudonymisation in SRB conflates two very different kinds of processing.
<h3>The missing piece: IP intelligence and data brokers</h3>
More importantly, the decision treats Belgian ISPs as the only route from IP to identity. That might have been plausible in 2005. It is not in 2025.
Today:
<ul>
<li aria-level="1">IP-intelligence providers offer rich enrichment APIs: location, connection type, organization, sometimes even household-level and business-level attributes.</li>
<li aria-level="1">Data brokers and DMPs combine IP-level signals with cookies, device IDs, login data and purchase histories to build audience segments and identity graphs.</li>
<li aria-level="1">Many AdTech and analytics tools integrate directly into this ecosystem.</li>
</ul>
A serious “reasonable means” analysis has to ask:
<ul>
<li aria-level="1">Could the analytics provider, in practice, enrich IP addresses via these services?</li>
<li aria-level="1">Could they join IP logs with other identifiers they hold (user accounts, email hashes, device IDs) to establish a profile over time?</li>
<li aria-level="1">Are those steps materially more burdensome than the other processing they already undertake?</li>
</ul>
If the answer is “yes, and this is standard industry practice”, then the claim that IP addresses are “non-personal” because an ISP isn’t involved starts to look like wishful thinking.
<img src="https/api.aesirx.io/images/images/in-2025-trating-ip-addresses-as-non-personal-in-adtech-style-analytics-is-wishful-thinking-not-risk-management.png" alt="in 2025 trating ip addresses as non personal in adtech style analytics is wishful thinking not risk management" width="942" height="400" />
<h3>Singling out is already impact</h3>
Even if you set aside the subscriber identity question, there’s a more fundamental point: if the provider can single out a visitor and take decisions about them - adjust bids, tailor content, infer interests - then, in every meaningful sense, they are dealing with that person as a data subject.
Recent case law and guidance keep coming back to this: data that does not obviously name someone can still be personal if it allows consistent singling out in a realistic ecosystem context. That is exactly what IP-plus-behavioral analytics does.
<h2>What DPOs and privacy professionals should take away</h2>
It would be easy for controllers and vendors to treat this Inspection Service decision as a convenient shield:
<ul>
<li aria-level="1">“Our scripts run in memory; that’s not storage under Article 10/2.”</li>
<li aria-level="1">“We only see IP addresses; those aren’t personal data for us.”</li>
</ul>
If you are responsible for compliance, that path is dangerous.
Here are the practical lessons I’d suggest:
<ol>
<li aria-level="1">Anchor your device-side analysis in Article 5(3)’s purpose, not in storage semantics. Start with the terminal equipment boundary: what information do your scripts read and write on the user’s device? Is it strictly necessary for what the user asked you to do? If not, treat it as subject to consent, regardless of whether the bits live in RAM or on disk.</li>
<li aria-level="1">Treat IP+behavioral data as personal by default in analytics. Given the current state of IP-intelligence and data-broker markets, assuming “non-personal” status for IP-based analytics is a weak compliance position. If a vendor wants to claim their IP-level data is effectively anonymised, they should have a rigorous, documented identifiability assessment that goes far beyond “the ISP has the subscriber file”.</li>
<li aria-level="1">Don’t outsource your technical analysis to case snippets. Authorities can be wrong on the tech - especially when decisions are made early in the process by investigative bodies like the Inspection Service rather than by a fully reasoned Litigation Chamber judgment. Use such cases as prompts to sharpen your own analysis, not as permission to stop thinking.</li>
<li aria-level="1">Document your own “reasonable means” assessment. For key data types (IP addresses, device IDs, pseudonymous IDs, hashed emails, consent strings), write down how they could realistically be linked to an individual in your ecosystem, what controls you have in place, and why you consider residual risk acceptable or not.</li>
</ol>
If your current analytics setup can’t meet these conditions, treat this as a signal that you need to redesign, not as a sign that you’ve found a clever legal carve-out.
<img src="https/api.aesirx.io/images/images/authorities-can-be-wrong-on-the-tech-and-when-they-are-dpos-cant-simply-copy-paste-their-reasoning-into-dpias.png" alt="authorities can be wrong on the tech and when they are dpos cant simply copy paste their reasoning into dpias" width="942" height="400" />
<h2>The safer pattern: first-party, block-before-consent</h2>
Ultimately, the best way to avoid fragile arguments about “is this really personal data?” or “does this really count as storage?” is to change the architecture, not the story.
For web analytics, that means:
<ul>
<li aria-level="1">First-party by design: run consent management and analytics on your own domain, with your own first-party server or platform. Avoid unnecessary third-party calls and piggy-backing by AdTech scripts.</li>
<li aria-level="1">Block-before-consent: default to blocking all non-essential tracking technologies - not just cookies, but pixels, JavaScript tags, fingerprinting scripts and beacons - until you have explicit, informed consent.</li>
<li aria-level="1">Minimize and segregate identifiers: shorten IP retention windows, strip or coarse-grain location, avoid joining analytics data with marketing profiles unless you have a very strong legal basis and clear user expectation.</li>
<li aria-level="1">Logically and technically separate analytics used for own-path statistics from any cross-site advertising or profiling purposes. Treat the latter as high-risk and consent-driven.</li>
</ul>
This pattern does not magically make every legal question disappear. But it dramatically reduces the reliance on edge-case interpretations like “RAM is not storage” or “IPs are not personal data for us”, and it aligns much better with the trajectory of EU regulation.
<h2>Why this case is a warning, not a template</h2>
The Belgian Inspection Service decision is not the end of the story on privacy-friendly analytics. But it is a useful cautionary tale.
When DPAs - or parts of them - start from semantic comfort rather than from how the web and the data-broker ecosystem actually function in 2025, they risk creating decisions that are easy to quote and dangerous to rely on.
As DPOs and privacy professionals, our job is to bridge that gap: to bring the technical reality into the legal analysis, and to design systems where compliance doesn’t depend on hoping that JavaScript in RAM somehow doesn’t count.
Because on a real user’s laptop or phone, it absolutely does.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

 Belgium’s DPA case shows why treating JavaScript in RAM and IP analytics as exempt from consent is risky. Modern tracking makes these arguments unsafe to rely on.

When Regulators Forget How Browsers Work: the Belgian Analytics Case

When Regulators Forget How Browsers Work: Lessons from the Belgian “Privacy-Friendly Analytics” Case

The Belgian “privacy-friendly analytics” case exposes outdated views on RAM, IP data, and consent. Modern browsers make these compliance shortcuts dangerous.

Belgium’s Analytics Ruling Shows Why Old Privacy Assumptions No Longer Work

Data is the new type of “capital,” helping businesses increase their competitiveness.
Ronni K. Gothard Christiansen’s interview with Vietnam Economic Times / VnEconomy on Vietnam’s new Personal Data Protection Law (PDPL) has just been published.
The article explains why PDPL means businesses must start treating personal data as a new kind of regulated capital - and why “track first, ask later” will no longer be acceptable once the Law and its Guiding Decree are in full force from January 1st 2026.
<h3>Key themes in the article:</h3>
<ul>
<li aria-level="1">PDPL + the Law on Data as the new legal “stack” for data in Vietnam.&nbsp;</li>
<li aria-level="1">Consent-before-tracking architectures instead of silent cookies, pixels and SDKs.</li>
<li aria-level="1">Behavioural data being treated as sensitive personal data.</li>
<li aria-level="1">The reality that more than 90% of .vn websites are not yet technically ready.</li>
<li aria-level="1">How Vietnam can turn compliance into a sovereign data advantage and become a regional model in Asia.</li>
</ul>
AesirX are proud to contribute from the web-facing technical side (consent, tracking, cross-border flows, first-party data).&nbsp;
For internal and non-web data governance, Ronni strongly recommends working with local firms who live and breathe PDPL and the Law on Data.
<h3>Read the full eMagazine article</h3>
Vietnam Economic Times / VnEconomy: <a href="https://vneconomy.vn/luat-bao-ve-du-lieu-ca-nhan-du-lieu-la-loai-von-moi-giup-tang-canh-tranh-cho-doanh-nghiep.htm?utm_source=chatgpt.com"></a><a href="https://vneconomy.vn/luat-bao-ve-du-lieu-ca-nhan-du-lieu-la-loai-von-moi-giup-tang-canh-tranh-cho-doanh-nghiep.htm">https://vneconomy.vn/luat-bao-ve-du-lieu-ca-nhan-du-lieu-la-loai-von-moi-giup-tang-canh-tranh-cho-doanh-nghiep.htm</a>

VnEconomy Interview: Personal Data Protection Law and Data as the New Capital

Interview with AesirX founder Ronni K. Gothard Christiansen on Vietnam’s Personal Data Protection Law and why personal data is becoming regulated capital.

VnEconomy Interview: Personal Data Protection Law

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
The Digital Omnibus quietly creates a powerful “own path” lane for first-party, controller-only audience measurement. If you rebuild your analytics and consent stack to stay inside that lane, you can run privacy-preserving, consent-free measurement on your own infrastructure, reduce consent fatigue, shrink third-party risk, and still give marketing real value attribution - instead of donating your data to AdTech and BigTech.
</div>
The European Commission’s Digital Omnibus proposal is being sold as “simplification”: fewer banners, clearer rules, less friction for users.
Hidden inside that political packaging is something much more interesting for anyone who cares about compliance and performance: a narrow but powerful lane for first-party, controller-only audience measurement. If you architect your stack correctly, you can run analytics and user experience flows without consent where they fit inside that narrow 88a lane - and without handing your data to AdTech, data brokers, or BigTech.
This article is written for agencies, in-house marketing leaders, DPOs and C-level decision-makers who now have to translate the Digital Omnibus into concrete changes in their real MarTech stack and business as it goes from proposal to final legislation.
The Commission calls it “own path.” In practice, it’s an invitation to completely rethink how we build analytics, consent, and marketing infrastructure.
Most stacks today sit outside that lane, which is why they’re stuck with banners, dark patterns and security risk.
This article is about that re-architecture: what the new Article 88a actually does, how it interacts with ePrivacy Directive 5(3), what “own path” means in a real MarTech stack, and why a fully first-party analytics setup can reduce consent fatigue without turning into a mass data giveaway to third parties. Along the way, I’ll use our own AesirX CMP and the upcoming AesirX Analytics 1.0.0 release and AesirX First-Party Server as a concrete example of what this looks like in production - not as a sales pitch, but as a proof that the pattern is implementable today and what benefits it offers.
“The Digital Omnibus doesn’t remove consent. It rewards those who design systems that need it less.”
<h2>Article 88a and ePrivacy Directive 5(3): What Actually Changes</h2>
Under the Omnibus, device-level access and tracking moves into a new Article 88a GDPR. This article is very narrow: it only allows processing of personal data “on or from” a user’s device when it is strictly necessary for things like transmitting communications, delivering a service explicitly requested by the user, providing the controller’s own aggregated audience measurement, or ensuring security and maintenance.
Everything else - especially third-party analytics, advertising, social pixels, and cross-service profiling - is pushed back into the world of lawful bases, where for non-essential tracking the only realistic basis remains prior consent.
So ePrivacy Directive 5(3) does not magically disappear, but the centre of gravity shifts. In practice, 88a is likely to become the lens through which regulators and courts are going to judge most tracking technologies, because the majority of web tracking involves personal data in one way or another.
That means the Omnibus isn’t saying “goodbye banners.” It’s drawing a bright line:
<ul>
<li aria-level="1">Stay inside a narrow lane of first-party, controller-only, aggregated measurement, and you can run without consent.</li>
<li aria-level="1">Step outside that lane - into third-party stacks, user-level profiling, re-marketing, or data sharing - and you are back in consent territory, with all the usual requirements.</li>
</ul>
For organisations and their advisors, the question stops being “Can we get rid of the consent banner?” and becomes “Which parts of our stack can we shift into the own-path lane - and which parts must remain behind a proper consent flow?”
For a focused legal and technical breakdown of how the Omnibus reshapes cookies, consent, tracking technologies and browser signals specifically, see the <a href="https://www.linkedin.com/pulse/omnibus-consent-what-actually-changes-still-doesnt-christiansen-ky63c/" target="_blank" rel="noopener">10-page deep dive</a> I published last week.
<h2>Signals, Cool-Downs and Why Banners Don’t Vanish</h2>
The Omnibus also introduces two important mechanisms that directly impact consent UX:
<ul>
<li aria-level="1">First, browser or operating system signals that let users say “no tracking” or “no direct marketing” at the device level.</li>
<li aria-level="1">Second, a six-month cool-down: if a user refuses a given purpose, you can’t just keep pinging them every visit with the same request.</li>
</ul>
This is clearly aimed at dark patterns and “consent spam.” It recognises that constantly nagging people into saying “yes” is not a sustainable model and forces controllers to remember and respect a user’s “no” for a meaningful period.
But it does not magically transform those signals into valid consent for complex, multi-purpose stacks.
Consent in EU law must still be freely given, specific, informed, and unambiguous. A generic browser toggle cannot carry information about concrete purposes, specific vendors, retention periods, or international transfers. So while signals are powerful as a way to stop tracking at the source, they cannot serve as a shortcut to “yes”.
In practice, that means:
<ul>
<li aria-level="1">You still need a first-party consent interface that explains who you are, what you’re doing, and which third parties (if any) you involve.</li>
<li aria-level="1">You must learn to live with fewer opportunities to ask, because of the six-month cool-down.</li>
</ul>
Again, this is where the first-party own path becomes so valuable. If you move your audience measurement into that lane, you don’t need to ask for consent for that layer at all. You reserve the “ask” for the places where you really need it - advertising, retargeting, advanced profiling, social integrations - and you make those requests more honest and less frequent.
“Signals are a powerful ‘no’. They’re not a magical ‘yes’ for a broken stack.”
<h2>What a First-Party “Own Path” Stack Looks Like</h2>
So what does “own path” look like in an actual MarTech stack?
Legally, the conditions are simple but strict: the data must be processed only by the controller (or genuinely controlled processors), used solely for that controller’s own aggregated audience measurement, and implemented in a way that respects device-level restrictions.
Technically, that translates into three core design decisions:
<h3>First-Party CMP</h3>
Your Consent Management Platform must run under your own domain and storage. It must treat all tracking technologies - not just cookies - as in-scope: pixels, SDKs, scripts, local storage, fingerprinting techniques, everything. And crucially, it must be able to block third-party technologies until a valid “yes” exists, while letting own-path analytics operate without asking.
In our case, that’s the <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX CMP</a> JS layer, which runs first-party and is capable of gating third-party stacks based on consent while letting first-party measurement operate within the Article 88a lane.
First-Party Analytics and UX Flows
Instead of outsourcing analytics to GA4, tag managers, or SaaS dashboards, you deploy a first-party JS collector that sends data to your own backend, under your domain or under infrastructure you control. The measurement is designed as aggregated audience analytics, not as a cross-site identity graph.
For us, this is <a href="https://aesirx.io/solutions/analytics" target="_blank" rel="noopener">AesirX Analytics</a> 1.0.0 (Release coming December 4th): a JS collector plus a PWA analytics UI that runs against a first-party backend, with no data shipped to BigTech or AdTech.
<h3>First-Party Server and Data Storage</h3>
Data is stored in a database that is fully under your control: self-hosted, or in infrastructure where you dictate terms and locations. There is no “free” or “freemium” third-party analytics vendor quietly reusing your data to train their own models or enrich other clients.
The moment you start feeding a third-party ecosystem that reuses or repurposes your data, you leave the own-path lane. That’s why the architecture matters as much as the legal theory.
For us this is <a href="https://aesirx.io/solutions/first-party-server" target="_blank" rel="noopener">AesirX First-Party Server</a> that ensures full ownership of the data remains in the first-party lane.
When these three pieces are in place, your audience measurement stops being a consent-gated, third-party service and becomes an integral part of your own technical stack. It sits neatly inside the Article 88a carve-out, while anything that genuinely goes beyond own-path measurement remains behind a proper consent flow.
In concrete terms, that means no extra cookies, no cross-site IDs, and no silent “phone home” calls to BigTech - just first-party data processed on infrastructure you own or govern.
<h2>From Visits to Value: First-Party Attribution That Actually Helps Marketing</h2>
At this point, many marketing teams ask a reasonable question:
“If we move away from GA4 and big-platform dashboards, can we still measure value - not just visits?”
The answer is yes, but the design is different.
In AesirX Analytics, we'll introduce UTM Value Mapping and Event Tags Value &amp; Attribution Mapping specifically to address this. Instead of sending raw e-commerce and revenue data to third-party platforms, the site owner defines value rules in the first-party analytics system itself.
Here’s how it works conceptually:
<ul>
<li aria-level="1">You define which UTM combinations, campaigns, or event tags are valuable to your business and by how much. That can be a monetary value per visit, a value per event, or a scoring system that fits your funnel.</li>
<li aria-level="1">Those rules live in your first-party analytics backend, not in a remote ad platform.</li>
<li aria-level="1">The analytics engine calculates total and average value per campaign, per source, per flow, and it uses that to enrich your UX Flow reporting.</li>
</ul>
Instead of “we had 1,000 visits from this campaign,” you see “this flow generated X in mapped value and Y in engagement score.”
All of this happens without additional third-party scripts, without “phone home” commerce integrations, and without exporting those values to ad networks. The intelligence stays on your side of the table.
“First-party analytics is not about having less data. It’s about keeping your most valuable data under your own control.”
From a legal standpoint, you’re still in the own-path lane: you’re measuring your own audiences, with your own tools, for your own purposes. From a business standpoint, you’ve just given your marketing team a meaningful alternative to third-party dashboards that also satisfies the DPO.
<h2>Less Consent Fatigue, Not a Data Free-for-All</h2>
The Commission’s impact assessment assumes that a large number of European sites will be able to remove their consent banners entirely under the new regime. I’m sceptical of that assumption, given how most live stacks look today.
Real-world scans of national domains still show a majority of sites loading third-party scripts before consent, routing traffic through tag managers that bootstrap everything, and sending behavioural data to multiple ecosystems in parallel. Those setups cannot simply “declare” themselves first-party own-path. They are structurally tied to third-party architectures.
But that doesn’t mean the positive vision is wrong. It means there is real work to do.
If you do the work and move your measurement into a true own-path stack:
<ul>
<li aria-level="1">You genuinely reduce consent fatigue, because you only ask for consent when you actually cross a legal and architectural boundary.</li>
<li aria-level="1">You avoid the mass hand-over problem, because your behavioural and value data no longer feeds into other people’s models by default.</li>
<li aria-level="1">You can explain the difference to users clearly: “This is our own measurement, running on our own infrastructure. We only ask for consent when we involve third parties.”</li>
</ul>
This is also where attack surface and third-party risk come in. Every external script, SDK or SaaS integration you embed is a new supply-chain risk. If that vendor is compromised, your site can be compromised. If their defaults are weak, your security posture suffers. If they mishandle data, you inherit the problem as the controller.
By moving to a first-party own-path architecture, you are not just cleaning up your legal basis. You are shrinking your attack surface and simplifying your ISO 27001 story: fewer subprocessors, fewer external domains executing code in your users’ browsers, and more control over where data flows.
“Treat third-party tracking as a security risk, not just a marketing convenience, and the case for own-path architectures writes itself.”
<h2>How Agencies, DPOs and C-Levels Can Prepare</h2>
If you work in an agency, in-house marketing, a DPO office, or at C-level, the question is how to turn all of this into a plan.
If you leave the stack as it is - third-party tags everywhere and analytics outside your control - you stay stuck with noisy banners, unresolved cross-border issues, and an attack surface you can’t really defend to a regulator or your board.
The first step is brutally honest stack mapping. List what you actually load on your sites and apps today: which scripts fire before any consent is captured, which tools send data to third parties, which vendors act as processors, and which behaviours you can realistically redesign as first-party measurement.
Next, identify your own-path potential. Audience measurement and UX flows are obvious candidates. So are certain security and maintenance signals that can be scoped tightly to 88a. Anything that fundamentally exists to feed external advertising ecosystems does not belong here.
Then, re-architect your measurement layer first. That means adopting a first-party analytics solution, deploying a JS collector under your own origin, and actually configuring value and attribution mapping in the analytics backend so your marketing team doesn’t feel blind the minute you let go of GA4.
In parallel, strengthen your first-party CMP for everything that remains outside the lane: advertising, retargeting, social embedding, and advanced profiling. Respect browser/OS signals as a hard “no”. Honour the six-month cool-down on refusals. And make sure consent prompts are built around clear, purpose-based communication - not nudges and tricks.
Finally, document your approach. Regulators and auditors will want to see how you draw the line between own-path and consent-based processing. That means being able to show not only your privacy policy, but also your technical architecture, your data flows, and your CMP configuration.
In our own work at AesirX, we’re formalising this pattern end-to-end: a first-party CMP; a first-party analytics suite (JS collector, Analytics PWA, First-Party Server) with UTM and Event Value Mapping; a first-party server and a clear separation between own-path measurement and consent-gated third-party stacks. But again, the important thing is not our product names - it’s the architecture and governance pattern itself.
<h2>Using the Best Part of the Omnibus - Carefully</h2>
I have plenty of concerns about other parts of the Omnibus package, especially where it risks weakening protection in favour of certain media and platform actors. But I also think it would be a mistake for the privacy and compliance community to ignore the positive opportunity here.
The first-party own-path lane for aggregated audience measurement is a chance to align incentives:
<ul>
<li aria-level="1">Users get fewer, better-designed consent prompts and far less invisible data leakage.</li>
<li aria-level="1">Organisations get a clearer legal framework, better security posture, and freedom from perpetual AdTech dependency and a potential option for dropping 3rd parties entirely.</li>
<li aria-level="1">Marketing teams keep the insights they need, but through a model that is sustainable and defensible.</li>
</ul>
The price of admission is architectural: you have to stop treating analytics as a free external service and start treating it as part of your core infrastructure. You have to invest in a consent stack that actually blocks what it says it blocks. And you have to get serious about third-party risk.
If you’re willing to do that work, the Omnibus can be more than a political compromise. It can be the push that finally moves the web from surveillance-by-default to first-party, consent-when-needed by design.
That’s the direction we’re building towards. And it’s the direction I’d encourage agencies, DPOs, and C-levels to explore now - before the Omnibus stops being a proposal and starts being your enforcement reality.
If you want to see a concrete architecture map, I’m happy to walk you through ours.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO @ <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

The Digital Omnibus opens a legal “own path” for first-party analytics. AesirX shows how to reduce consent fatigue, cut third-party risk, and keep real attribution.

The First-Party “Own Path”: Turning the Digital Omnibus Into a Real Advantage

Discover how the Digital Omnibus creates a legal “own path” for first-party analytics, reducing consent fatigue and third-party risk while preserving attribution.

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

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

AesirX Analytics v1.0.1: Tag Event Value Mapping and Full-Flow Metric Scoring

Measure value, Not just traffic

AesirX Analytics v1.0.0: Introducing UTM Value Mapping

When Regulators Forget How Browsers Work: Lessons from the Belgian “Privacy-Friendly Analytics” Case

VnEconomy Interview: Personal Data Protection Law and Data as the New Capital

The First-Party “Own Path”: Turning the Digital Omnibus Into a Real Advantage

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data