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="https://aesirx.io/solutions/analytics/j-avascript">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="https://aesirx.io/solutions/analytics/j-avascript">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="https://aesirx.io/solutions/analytics/j-avascript">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="https://aesirx.io/solutions/analytics/j-avascript" target="_blank" rel="noopener">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="https://aesirx.io/solutions/analytics/j-avascript" target="_blank" rel="noopener">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

Blog Aesirx

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.

Unlocking the Power of First-Party Analytics: Reduce Risk and Boost Attribution

EU Omnibus narrows consent-free processing, adds six-month do-not-reask, and introduces browser refusal signals, keeping most third-party stacks consent-bound.

The Omnibus & Consent: What Changes and What Doesn’t

The Omnibus & Consent: What Actually Changes - and What Still Doesn’t

 EU Omnibus shifts device access under GDPR, adds browser refusal signals, and keeps third-party analytics and ads firmly consent-required across most real-world stacks.

India’s DPDP Rules strengthen consent on the surface but allow AI training to bypass it through ‘research’ exemptions, creating major accountability gaps.

India weaponizes notice and consent

India weaponizes notice & consent - and then lets AI slip into ‘research’

India’s DPDP Rules build strict consent requirements, yet AI training can skip them under ‘research’, creating a major gap in privacy protection.

India’s Consent Loophole Lets AI Exploit Data

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
Browser and OS signals are great in the EU for saying “no,” but they’re not enough to give a valid, informed, granular “yes” under GDPR and ePrivacy Directive. The media-services carve-out in the leaked Omnibus makes the whole promise weaker because the biggest trackers can just ignore the signal. And we still need first-party CMPs to actually enforce, log, and prove what the user decided.
This is for DPOs, privacy lawyers, policy people, and anyone maintaining a compliant CMP who now wonders “do we still need this?” (short answer: yes).
</div>
Most people are ready to celebrate: “finally, browser signals will kill consent banners.” But, I'm not celebrating yet.
The <a href="https://www.linkedin.com/posts/ronnikc_leaked-gdpr-omnibus-on-simplification-activity-7393503310764433408-47CN" target="_blank" rel="noopener">leaked “Digital Omnibus” draft</a> finally says the quiet part out loud: yes, the EU wants browsers and mobile OSs to send a machine-readable privacy choice - and yes, websites should respect it. Good. That’s long overdue.
But in the same text we see three moves:
<ol>
<li aria-level="1">more terminal-equipment access gets pulled into GDPR logic instead of staying in the very clear ePrivacy Directive 5(3);</li>
<li aria-level="1">there is a specific exemption for media services from having to honour those machine-readable signals;</li>
<li aria-level="1">and nothing actually solves the hardest EU problem: how to express an explicit, informed, granular “yes”.</li>
</ol>
So let’s unpack it.
<h2>Browser signals are perfect for “no”</h2>
What California and Colorado have done is smart: one signal → global opt-out. California even goes further and now requires all browser makers and mobile OS suppliers to support these signals. That’s powerful because it blocks processing at the point of origin - before AdTech, before SDKs, before sharing.
That logic also fits perfectly in the EU context for rejection:
<ul>
<li aria-level="1">ePrivacy Directive 5(3): don’t store/read on the device without consent.</li>
<li aria-level="1">Browser signal says: “don’t.”</li>
<li aria-level="1">Site doesn’t load anything = compliant.</li>
</ul>
So far, so good.
<h2>But browser signals cannot express a valid EU “yes”</h2>
The current and proposed approaches are category-based - “marketing”, “analytics”, maybe “personalisation.” That is not what EU law calls “freely given, specific, informed and unambiguous” consent.
Why?
<ul>
<li aria-level="1">it’s too coarse: a real site has 10–20 different third parties and purposes;</li>
<li aria-level="1">it’s not contextual: GDPR consent is for this controller and this purpose, not a generic “marketing on the whole internet”;</li>
<li aria-level="1">it has no information layer: a signal can’t show what will actually be loaded.</li>
</ul>
Even if, in the future, a browser/OS standard tried to define more granular signals, it still can’t magically know every script, SDK, tracker or conditional load a specific website might trigger at runtime. Consent has to be tied to the actual controller’s stack at that moment - something only a site-level, first-party CMP can present.
So a browser signal that says “accept marketing” would not meet GDPR + ePD 5(3) standards for an explicit, informed, granular yes. In Europe, browser signals are a great “no” - they are not (yet) a lawful “yes.”
“Browser signals are an excellent EU ‘no’. They are not a lawful EU ‘yes’.”
<h2>Consent categories were invented by CMPs, not by law</h2>
Somewhere along the way we all started acting as if EU law said “ask for functional / analytics / marketing.” It didn’t. CMP vendors did, to make banners look tidy.
Also: “consent for technically necessary technologies” is not a legal requirement. If it’s truly necessary under ePD 5(3), you don’t need consent. Asking for it is UX theatre.
So if anyone now imagines that a machine-readable “accept analytics” header suddenly equals valid EU consent, that’s backwards. The law never asked us to group everything into 3 boxes.
“Consent categories were invented by CMP vendors, not by EU law.”
<h2>Processing starts at device access - anonymising later doesn’t fix it</h2>
We still see this pattern in “privacy-friendly” analytics:
<ol>
<li aria-level="1">the script accesses the device → processing has started</li>
<li aria-level="1">the data is sent off</li>
<li aria-level="1">the vendor anonymises / pseudonymises / aggregates</li>
<li aria-level="1">the vendor says: “now it’s compliant”</li>
</ol>
But the legal issue was in step 1–2. If you accessed terminal equipment without valid consent, you can’t wash that away later. This is exactly where browser signals are useful: they can stop step 1 entirely.
<h2>The media-services exemption is the giveaway</h2>
The leaked text says: everyone should honour the machine-readable choice… except media services (with a vague nod to journalistic freedom) as seen in the leaked draft.
Since when did journalistic freedom include the right to collect and share our data with AdTech, data brokers and BigTech?
This is exactly the sector that currently shows “we need consent for our 895 partners so you can read this article.” Under the draft, that sector would be allowed to ignore a browser/OS “no.” That’s not simplification - that’s a lobby carve-out.
“If media can ignore the signal, we didn’t simplify - we just wrote the lobby carve-out into law.”
<h2>Where this leaves first-party CMPs</h2>
Even if the EU ships browser/OS signals:
<ul>
<li aria-level="1">many users will never set a signal;</li>
<li aria-level="1">controllers will still need granular consent for multiple vendors/purposes;</li>
<li aria-level="1">media may be allowed to ignore the signal;</li>
<li aria-level="1">and someone still has to enforce, record, and prove the choice.</li>
</ul>
That’s exactly why our <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">data model for consent is first-party</a>; and we already support GPC: so when the browser says “no,” we can actually stop processing; and when the user really wants to say “yes,” we can do it in a way that is contextual, informed, explicit and auditable.
Browser signals don’t kill first-party CMPs - they kill the bad habit of loading everything before consent.
“This is still the right direction - device-level signals + first-party enforcement - but it has to bind everyone.”
If you’re a DPO / privacy counsel looking at this leak: treat browser/OS signals as an excellent rejection mechanism, not as a magic “user accepted everything” flag. Keep your first-party CMP as the authoritative, contextual, auditable layer&nbsp;
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Browser signals are great for saying “no,” but not a valid, informed, granular “yes” under GDPR and ePD. First-party CMPs remain essential for compliance.

Browser Signals Won’t Replace Consent

Browser Signals Won’t Replace Consent (and the Omnibus Draft Shows Why)

Browser privacy signals help block unwanted tracking but can’t give valid, informed consent under GDPR or ePD. Site-level, first-party CMPs remain crucial.

A standalone JavaScript version that gives every platform full first-party compliance control.
NEW YORK, NOVEMBER 7, 2025 – AesirX has launched the standalone JavaScript version of its Consent Management Platform (CMP), expanding first-party compliance beyond WordPress. With AesirX CMP JS 1.0.0, businesses and developers can now deploy the same trusted AesirX consent framework on any platform, including Shopify, Magento, Next.js, Drupal, or custom stacks.
This release extends AesirX’s first-party architecture to every environment, giving full control over consent data, logic, and analytics while keeping everything stored securely within the domain owner’s infrastructure. The result is faster performance, transparent data flows, and supports compliance with global privacy regulations such as GDPR, ePrivacy Directive, CCPA, and PDPL.
The update introduces a suite of tools that make compliance faster, simpler, and more accurate, designed for teams managing multiple sites or agencies maintaining client privacy setups across regions.
What’s new for AesirX CMP JS 1.0.0
<h2>1.&nbsp;First-Party Control&nbsp;</h2>
Stay in control of your data, directly from your own domain.
<a href="cmp_js_hardlink" target="_blank" class="undefined text-success">AesirX CMP JS</a> stores all consent data within your own infrastructure via the AesirX First-Party Server. This means your consent and analytics events never leave your domain, giving you faster load times, privacy-first compliance, and complete transparency over every data flow.&nbsp;
Why it matters: By removing third-party dependencies, you reduce legal exposure under laws like the ePrivacy Directive 5(3) and GDPR, while maintaining accurate insights for analytics and performance.
<h2>2.&nbsp;Admin CMP PWA</h2>
Manage every aspect of your CMP securely, all in one place.
A new dashboard to manage everything – from banners to logic, ID Verification, and automated compliance text. Built with a familiar, modern interface, so you can navigate and configure consent settings intuitively. It also includes User Handling for secure access and smoother team collaboration.
Why it matters: It transforms consent management from a technical task into an accessible, user-friendly process that fits naturally into everyday workflows.
<img src="https/api.aesirx.io/images/2-manage-every-aspect-of-your-cmp-securely-all-in-one-place.png" alt="2-manage-every-aspect-of-your-cmp-securely-all-in-one-place.png" width="942" height="512" />
<h2>3.&nbsp;AI Privacy Advisor</h2>
Understand what’s really happening on your site and automatically generate privacy documentation based on real scan data.
The AI Privacy Advisor analyzes your website before and after consent to detect cookies, trackers, and beacons. It then creates draft documentation – including Domain Categorization, Cookie Declaration, Privacy Policy, and Consent Request – ready for review and publishing.&nbsp;
Why it matters:&nbsp;This turns hours of manual compliance work into a guided process you can validate in minutes. Every scan reflects your actual setup, giving you a transparent, privacy-first overview that supports global privacy laws, including GDPR, ePrivacy Directive, and CCPA frameworks.
<h2>4.&nbsp;Consent Modal</h2>
Deliver compliant user consent experiences.
The new <a href="cmp_js_hardlink" target="_blank">Consent Modal in AesirX CMP JS </a>offers two configurable modes for modern privacy needs:
<ul>
<li aria-level="1">Default Consent Mode enforces full pre-consent blocking, preventing data from being processed prematurely (a common issue in Google Consent Mode 2.0 setups).</li>
</ul>
<ul>
<li aria-level="1">Decentralized Consent Mode takes this a step further by extending control to users through decentralized consent records, giving individuals transparency.</li>
</ul>
You can then customize text, from consent messages and cookie declarations to rejection responses, ensuring consistent brand language and legal accuracy across all client projects.
Why it matters: It simplifies compliance across regions while preventing data collection before consent, helping you deliver a consistent and trustworthy user experience.
<h4>Default Consent Mode improves on Google Consent Mode 2.0…”</h4>
<ol style="list-style-type: lower-alpha;">
<li aria-level="2">That’s a strong statement and you’ve been publicly telling people Consent Mode sends data on first hop.</li>
<li aria-level="2">I’d rephrase to something like: “Default Consent Mode enforces pre-consent blocking end-to-end, unlike typical Consent Mode 2.0 setups that allow initial pings.”</li>
<li aria-level="2">Same idea, less likely to trigger “prove it” comments.</li>
</ol>
<h2>5.&nbsp;Consent Log</h2>
Gain full visibility into user consent activity with audit-ready reporting.
The Consent Log provides a detailed history of every user’s consent action, including approvals, rejections, withdrawals, and timestamps so you always have verifiable proof for regulators or client audits. Each record is automatically stored and can be easily exported for documentation or compliance review. The dashboard view offers flexible filters by day, week, or month, along with visual charts that display revoked, accepted, rejected, opt-out, and granular consent trends.&nbsp;
Why it matters: This makes it simple to track changes over time, demonstrate accountability, and deliver transparency to your clients.
<h2>6.&nbsp;Consent Logic &amp; GPC Compliance</h2>
Configure how consent behaves under each legal framework without coding.
Consent Logic gives you control over when tracking activates based on regional privacy laws:
<ul>
<li aria-level="1">Opt-In Mode (EU) – No tracking runs until explicit consent is given, supporting GDPR and ePrivacy Directive 5(3).</li>
<li aria-level="1">Opt-Out Mode (California) – Tracking is active by default but easy to opt out, aligned with CCPA and similar frameworks.</li>
</ul>
The same interface includes GPC Compliance, which detects and respects Global Privacy Control signals. When enabled, it automatically disables non-essential cookies for users sending a “Do Not Sell or Share” preference.
You can enable or disable GPC support, upload the gpc.json file, and update your Privacy Policy with the built-in templates for quick setup.
Why it matters: It applies the correct privacy rules automatically and honors browser-level privacy signals, reducing manual work while meeting global compliance standards.
<h2>7.&nbsp;Geo-Handling</h2>
Automatically apply the right consent mode for each visitor’s region.
The Geo-Handling feature uses browser language and time-zone detection to decide which consent logic should apply automatically – Opt-In or Opt-Out. Runs fully client-side, no third-party geo-lookup before consent.
Enable Geo-Handling for Consent Mode to adapt consent behavior across countries in real time. The rule builder supports AND / OR logic, allowing precise combinations such as applying EU Opt-In for en-GB visitors and U.S. Opt-Out for en-US. You can also allow local overrides for more complex deployments.
Why it matters: It removes the need for separate regional setups, so that every visitor automatically receives the correct consent experience for their location, saving time, reducing errors, and keeping every client site globally compliant.
<img src="https/api.aesirx.io/images/7-automatically-apply-the-right-consent-mode-for-each-visitors-region.png" alt="7-automatically-apply-the-right-consent-mode-for-each-visitors-region.png" width="942" height="512" />
<h2>8.&nbsp;ID Verification</h2>
Add privacy-preserving verification gates for age and country without handling personal data.
The ID Verification feature uses zero-knowledge proof (ZKP) technology to confirm user age or residency through the <a href="https://www.concordium.com/wallet/end-users" target="_blank" rel="noopener" class="undefined text-success">Concordium ID wallet</a>. Visitors can verify eligibility for access or content restrictions while keeping their personal information private — the website never sees or stores identity details.
Users without a wallet can easily create a Concordium ID using a passport or driver’s license, with verification completed instantly through cryptographic proof.
The interface includes a message preview, allowing teams to customize how verification requests appear to users for a clear, compliant, and consistent experience.
Why it matters: It enables privacy-safe verification without collecting sensitive data, helping sites meet age and regional access requirements while maintaining user trust and legal compliance.
<h2>9.&nbsp;Consent Analytics</h2>
Track and visualize how users interact with your consent settings.
The Consent Analytics dashboard provides clear insights into consent behavior across categories and regions. View accepted and rejected consents per category, analyze trends by country, and monitor user overrides over time.
For a deeper view, reports can be filtered by region and consent type, helping teams understand user preferences and adjust consent strategies for better compliance and engagement.
Why it matters: It turns compliance data into actionable insight, helping you measure transparency, improve consent UX, and demonstrate accountability across every domain.
AesirX CMP JS 1.0.0 redefines how businesses and agencies manage privacy compliance across platforms. It gives teams full control of consent and data handling within their own infrastructure, streamlining setup, ensuring consistency across client sites, and enabling faster, compliant deployments at scale, all with a first-party foundation built for performance and trust.
Download AesirX CMP JS 1.0.0: Bring first-party consent control to any platform and experience the future of compliant, privacy-first web development.
<a href="https://github.com/aesirxio/consent#readme" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm text-white btn btn-success text-success">Download CMP JS 1.0.0</a>

AesirX CMP JS v1.0.0: First-Party Consent for Every Website

Blog Press Release Aesirx

AesirX CMP JS 1.0.0 brings first-party consent control to any platform, delivering faster, compliant, and privacy-first data management for all websites.

AesirX CMP JS v1.0.0 – First-Party Consent Tool

<div class="px-4 px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR:
ISO 27001 may be risk-based, but pre-consent tracking is binary - if your site loads non-essential third parties before consent, you’re simply non-compliant, and because that’s externally visible and repeatable it can undermine your ISMS, so real compliance in 2025 means enforcing consent-before-access in code, keeping it first-party, scanning continuously, and fixing findings before an auditor sees them.
</div>
Too many organizations still treat <a href="https://www.iso.org/standard/27001" target="_blank" rel="noopener">ISO/IEC 27001</a> like a force field: “we have our ISMS, we passed the audit, so we’re covered.” That illusion breaks the moment someone can technically document that your public website is loading third parties, setting non-essential cookies, or transmitting identifiers to vendors before you have a valid legal basis.
That’s the uncomfortable truth: ISO 27001 is risk-based, but ePrivacy/GDPR device access is binary. And when you have a binary failure that is reproducible, visible from the outside, and contradicts your stated controls, it stops being “just marketing tech” and starts being a potential nonconformity.
This is the gap we need to close.
<h2>Binary vs. Risk-Based Compliance</h2>
ISO 27001 lives in a world of risk appetite, likelihood, impact, and corrective actions. You can accept certain risks, defer others, and show auditors you have a plan.
<a href="https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf" target="_blank" rel="noopener">ePrivacy Directive 5(3)</a> does not live in that world.
If your site accesses or stores information on a user’s device for non-essential purposes before consent, you’re non-compliant. Not “partially,” not “until next sprint,” not “accepted by management.” It’s simply a violation.
So when a website:
<ul>
<li aria-level="1">fires a marketing pixel too early,</li>
<li aria-level="1">lets a CMP vendor phone home for geo/billing before consent,</li>
<li aria-level="1">loads GTM and lets tags run regardless of the user choice,</li>
</ul>
…that’s a binary fail. You can’t paperwork your way around it.
<h2>Why That Matters for ISO 27001</h2>
“Okay, but ISO 27001 is about information security, not cookie banners.” Yes - but 27001:2022 is also about whether your ISMS actually works.
If your policies say “consent before tracking,” and your implementation says “we block,” but a simple scan shows your production site doing the opposite, what you have is a control that is not operating as designed.
Auditors don’t need to become data protection authorities to see that. They only need to see:
<ol>
<li aria-level="1">You defined a control (no non-essential device access pre-consent),</li>
<li aria-level="1">Evidence shows the control not working (third-party calls before consent),</li>
<li aria-level="1">It’s repeatable and has not been corrected.</li>
</ol>
That’s enough to trigger findings. And if the pattern is systemic across multiple sites/brands or ignored over time, it can put pressure on your certification.
“If your policy says ‘consent before tracking’ but the site doesn’t, the control is not operating as designed.”
<h2>How This Gets Exposed&nbsp;</h2>
The scary part is how easy it is to prove.
Anyone - a regulator, a customer doing due diligence, or even a competitor - can:
<ol>
<li aria-level="1">Load your homepage in a clean browser.</li>
<li aria-level="1">Capture network traffic before any consent choice.</li>
<li aria-level="1">List all third-party endpoints, pixels, SDKs, beacons, and cookies.</li>
<li aria-level="1">Compare with what your privacy notice and CMP claim.</li>
</ol>
If what your site does and what your policies say don’t align, the technical reality wins.
Once it’s documented and reproducible, it’s no longer “a small marketing misconfiguration.” It’s evidence that your ISMS isn’t monitoring an actual entry point where personal data leaves your control.
“When a scan can repeatedly show third-party loads pre-consent, it’s no longer a misconfiguration - it’s a systemic failure.”
<h2>The Usual Culprits</h2>
Most organizations don’t fail on purpose - they fail because the web stack is messy. The patterns repeat:
<ul>
<li aria-level="1">CMPs that do their own non-essential requests (geo-IP, telemetry, billing, “is banner needed?”) before consent.</li>
<li aria-level="1">GTM containers that allow tags to fire regardless of consent state.</li>
<li aria-level="1">Chat/UX/CS tools that inject their own trackers.</li>
<li aria-level="1">A/B testing or personalization tools that need to load early to “work.”</li>
<li aria-level="1">Multiple business sites where one is configured correctly and the others are forgotten.</li>
</ul>
Each of these is enough to flip you from “we claim consent-first” to “we actually don’t.”
And yes - if you can scan it once, you can scan it every day. That makes it very hard to argue it’s a one-off.
You can use our free <a href="https://aesirx.io/services/privacy-scanner">Privacy Scanner</a> to test your website before consent and see if you have a problem.
<h2>“We Did a Risk Assessment” Is Not a Shield</h2>
A classic pushback is: “we assessed it, and we accepted the risk.”
That works for information security trade-offs. It does not work for legal prerequisites.
You can’t “risk-accept” unlawful device access just because marketing needed a dashboard. You can’t accept the risk of sending personal data to a third country without a legal basis and expect ISO 27001 to cover it. That’s not residual risk - that’s doing something you’re not allowed to do.
“You can’t risk-accept unlawful device access just because marketing needed a pixel.”
So the only real answer is: fix the technical behavior.
<h2>What Real Compliance Looks Like in 2025</h2>
Let’s make it operational - this is what a grown-up model looks like:
<ol>
<li aria-level="1">Consent-before-access, enforced in code Non-essential scripts, pixels, beacons, storage, and third-party calls are blocked or queued until the user opts in. Not simulated, not “we set denied,” but actually blocked.</li>
<li aria-level="1">First-party by design The consent UI and enforcement live on your domain or in your own first-party infrastructure, so you don’t introduce a new third party just to manage consent.</li>
<li aria-level="1">Continuous web-facing scanning Run automated scans (pre-consent and post-consent) to see what is actually loading. This catches when someone in marketing “just tests something” on Friday.</li>
<li aria-level="1">Closed loop into the ISMS Findings from those scans go straight into your ISMS as incidents / nonconformities → assigned → remediated → verified. That’s what auditors love to see.</li>
<li aria-level="1">Evidence on demand When a DPO, CISO, or auditor asks “are we blocking pre-consent?”, you can show a last-scan report - not only a policy document.</li>
</ol>
This way, your public website becomes part of the monitored surface, not a rogue marketing island that quietly undermines the certification the rest of the company worked for.
<h2>The Strategic Point</h2>
Why push this now? Because the modern stack - AI embeds, server-side GTM, edge/CDN logic, Measurement Protocol, third-party CMPs that “optimize” - all of that can silently re-introduce technical non-compliance even while your policies and DPIAs are still correct.
If you don’t have continuous visibility, your ISO story can be true on paper and false in production.
“In 2025, production wins: what the site actually loads matters more than what the policy says.”
<h2>Turn It Into Evidence</h2>
If you’re responsible for ISO 27001, DPO work, or web privacy, do one thing this week:
Run an external, pre-consent scan of your main site and compare it with what your CMP and policies claim.
If it’s clean - perfect. Document it. If it’s not - don’t argue with it. Treat it like any other nonconformity: log → fix → re-scan → prove.
Do the same the next day, and then the day after again and every day because ISO/IEC 27001:2022 expects continuous performance monitoring of controls, treating web-facing scans as part of that monitoring closes the gap between the ISMS on paper and the behavior of the live site.
That is how we do it in AesirX with <a href="https://aesirx.io/services/privacy-monitoring" target="_blank" rel="noopener">continuous privacy monitoring</a> of our websites and web-facing solutions.
ISO 27001 still matters. It just can’t protect you from a browser that shows the truth.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io">AesirX.io</a>

ISO 27001 isn’t a shield against illegal tracking. Real compliance means first-party consent control, continuous scanning, and fixing issues fast.

ISO 27001 Not Get-Out-of-Jail Card for Illegal Tracking

ISO 27001 isn’t enough—true compliance needs first-party consent, real-time scanning, and fast issue fixes.

Beyond ISO 27001: Real Compliance Starts with Consent

ISO 27001 Is Not a Get-Out-of-Jail Card for Illegal Tracking

Blog Consent Management Platform

ISO 27001 certification doesn’t excuse illegal tracking. Learn why real compliance means enforcing consent-before-access and continuous first-party scanning.

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

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

The Omnibus & Consent: What Actually Changes - and What Still Doesn’t

India weaponizes notice & consent - and then lets AI slip into ‘research’

Browser Signals Won’t Replace Consent (and the Omnibus Draft Shows Why)

AesirX CMP JS v1.0.0: First-Party Consent for Every Website

ISO 27001 Is Not a Get-Out-of-Jail Card for Illegal Tracking

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data