.svg)
Server-side tracking has become the go-to infrastructure for marketing and analytics teams seeking better data quality, improved page performance, and greater control over what is sent to vendors. The shift away from the client side is well underway, and for good reason.
But server-side setups come with a common criticism: they're opaque. In a client-side implementation, browser developer tools and network inspectors could at least show you which tags fired and when, giving compliance teams a starting point for verification. Server-side tags fire from a server that the end user can't access, which means the traditional verification toolkit stops working. Regulators and DPOs are increasingly asking whether server-side tags are actually firing with the right consent. Until now, that question was hard to answer without significant technical effort.
We think that criticism is valid, and we built something to address it. Event Consent Monitoring gives you continuous, automated, per-tag consent visibility for every event flowing through your sGTM container, directly inside the Addingwell console, with no extra implementation required.
Server-side tracking and the consent visibility gap
Server-side infrastructure has become the default choice for leading publishers, advertisers, and agencies adopting sGTM to achieve better data quality, reduce dependence on third-party cookies, improve page performance, and gain greater control over what is sent to vendors.
In a client-side setup, tags load directly in the user's browser. In a server-side setup, that same logic runs on a remote server, out of reach of any browser-based tool. This confirms the broader shift away from traditional third-party trackers on websites and apps, and toward infrastructure that gives companies more control over their data.
The opacity problem follows directly from how server-side works. Consent signals travel with each request, but whether they're being correctly read, mapped, and respected for each tag is invisible without access to raw server logs. That gap can have real consequences, as a misconfigured vendor mapping or a CMP that isn't loading before tags fire can go undetected for weeks.
The rise of Google Consent Mode is itself an acknowledgment of this. The largest vendors in the advertising ecosystem are explicitly concerned about the consent status of the data they receive. Google Consent Mode enforces tag behavior based on consent signals, but it doesn't tell you whether that enforcement is working correctly. Detecting a misconfiguration still requires someone to go looking for it.
Opening the server-side black box with Event Consent Monitoring
Didomi sits at a unique position in the sGTM ecosystem. Addingwell by Didomi processes every event flowing through the customer's container, and those requests carry the Didomi consent cookies in the request header. That combination (simultaneous access to the tracking payload and the consent signal) enables genuine per-tag, per-event consent monitoring.
Our new Event Consent Monitoring feature uses that position to provide a continuous, automated view of consent compliance for every individual tag dispatch, something no other sGTM platform currently offers.
In concrete terms, this allows organizations to:
- See what was fired, for which event, with which consent status, per tag and per vendor, over time.
- Detect misconfigurations automatically, including missing vendor mappings, the CMP not loading before tags fire, incorrect trigger setups, and wrong cookie names.
- Prove compliance with an auditable record you can share with your DPO or show to a regulator, without writing a single SQL query.
This technology works with two consent sources, automatically routed based on the tag template type:
- For templates mapped to Didomi vendors (Meta CAPI, LinkedIn CAPI, TikTok CAPI, and others), it reads the Didomi consent cookies directly from the request.
- For Google Consent Mode templates (GA4, Google Ads, Floodlight, and others), it reads the Google Consent Signal parameter. No additional configuration is needed beyond the standard prerequisites.
Every tag firing is assigned one of five consent statuses: Granted, Denied, No Token (consent signal absent or missing), No Vendor (template not yet mapped to a Didomi vendor), or Exempted (the template has been legally marked as not requiring consent).
That granularity makes it possible to distinguish between a consent refusal, which may be entirely expected behavior, and a genuine misconfiguration that needs to be fixed.
Why we built Event Consent Monitoring (and for whom)
When Didomi acquired Addingwell, the clear vision was that server-side could be a privacy-preserving technology if consent is correctly implemented and verified end-to-end: the Consent Management Platform handles collecting user consent, and the server-side tagging platform executes tags based on that consent.
Event Consent Monitoring closes that loop by making the whole chain auditable.
Without it, there's a structural gap: The Data Privacy Officer (DPO) can pull a dashboard from the CMP showing opt-in and opt-out rates, and the tagging team can review the sGTM container configuration, but neither provides continuous, production-level evidence that the right tags fired, or didn't fire, for the right events, with the right consent, on any given day.
That gap matters more than it used to. DPOs and privacy authorities are increasingly scrutinizing server-side setups and pointing to your CMP configuration is no longer enough; regulators expect production-level evidence.
The granularity and transparency provided by Event Consent Monitoring also matter to marketing and performance teams, who often find themselves caught between a DPO requesting compliance evidence and an agency or tagging team that can't produce it quickly.
The feature gives marketing managers a dashboard they can point to. When a number drops, they can see exactly which templates are affected and bring that evidence to whoever needs to fix it.
How does Event Consent Monitoring change things for you?
The impact depends on where your expertise and scope sit within your organization.
If you're a technical integrator or agency partner running sGTM implementations for clients, Event Consent Monitoring lets you verify your implementation at handoff and monitor it continuously with no extra effort. Issues that would previously take hours of log diving to diagnose, such as a wrong trigger, a missing vendor mapping, or a CMP not loading in time, are surfaced automatically with the root cause and a recommended fix, without opening a support ticket.
If you're a marketing or performance manager, Event Consent Monitoring translates a technical compliance question into something you can act on. The consent implementation overview shows the percentage of tags firing with valid consent across all your Didomi vendor and Google Consent Mode templates, and flags the most affected tags if attention is needed. You go into your next DPO review with monitoring data instead of assurances.
If you're a DPO or compliance officer, Event Consent Monitoring provides what an audit actually requires: a documented, continuous record of consent compliance at the production level. Per-tag, per-vendor, over time, with configuration changes preserved so the historical record reflects what was actually happening at the time, not what the container looks like today.
In all three cases, Event Consent Monitoring allows teams to stop discovering consent problems when a regulator surfaces them, and start catching them the day they appear, bringing server-side tagging and privacy to a new level.
Ready to see it in action? Log in to your Didomi or Addingwell console to get started, or chedule a demo with our team to learn more:
{{talk-to-an-expert}}
