.svg)
As cookie deprecation, stricter browser settings, and the use of ad blockers increase, collecting quality marketing and analytics data becomes more difficult. And if you have users in California, you might also have concerns about the California Invasion of Privacy Act (CIPA), the 1967 wiretapping law, being used in lawsuits claiming that certain tags and cookies violate privacy protections.
So how do you make sure that you are properly collecting data, respecting user choices, and meeting the compliance requirements wherever your users are, all while still reaching your audiences and growing your brand?
In this article, we talk about why it’s important for tagging to be part of the privacy conversation and how Didomi's Consent Management Platform (CMP) and Addingwell's server-side tagging (SST) infrastructure, when deployed together, give you the consent priority you need for meeting compliance without sacrificing the data you need for growth.
The current state of tagging
Every year, browsers tighten what client-side scripts are allowed to do. Third-party cookie restrictions, script-blocking defaults, and stricter tracking-prevention rules aren't going away as new regulations and user behavior fundamentally change how users interact with web pages.
Client-side tag managers were built for a browser-first web, and their limitations are causing two major problems:
- Dead-end data: the culmination of changes in technology, behavior, and legislation means that some of the data you collect currently doesn't just underperform but stops being usable altogether. Anywhere from 45% to 70% of your data is lost before it gets to you, making it hard for your campaigns to reach your audience and your analytics to really understand what’s going on.
- Compliance risks: third-party scripts running on your websites may have unregulated access to page data, allowing them to collect data even if the user has opted out using the consent banner or even before the user has interacted with the banner at all. This type of un-consented data sharing is the preface for many recent CIPA lawsuits.
As such, many organizations are switching to server-side tagging, moving tagging scripts off the browser. The benefits are plentiful, providing things like better first-party data and even faster page speeds while helping with some of the data loss and compliance issues of client-side tagging.
But not all server-side tagging managers are the same, with platform-hosted and some first-party managed server solutions creating a sort of black box, which limits some of the advantages of server-side tagging and could create more headaches for legal and privacy teams rather than fewer.
So what do you do? Well, treat server-side tagging as both a marketing and a privacy practice. Align your server-side tracking with the rest of your privacy posture through connecting with your consent management platform and prioritizing consented data flows.
How do consent management and server-side tagging work together
Most likely, you are using a CMP for collecting consent and then passing that signal along to your tagging manager. And perhaps you have taken control of your tags with a server-side tagging solution. These solutions are often bought and evaluated as separate line items, but they solve halves of the same problem. A CMP without a server-side enforcement layer produces consent records that vendors may or may not respect. A server-side tagging layer without a robust CMP has nothing reliable to enforce.
But in practice, how do the two systems work together?
1. User interacts with consent banner
The moment that a user interacts with the consent banner, the CMP builds an internal consent state. This includes a per-purpose, per-vendor map of what was accepted or rejected, such as allowing analytic cookies or denying personalization.
2. CMP generates strings and cookies
The CMP converts all data from this event into a standard format called a string. The metadata in the string includes what the user consented to, timestamps, and other data such as purpose-based permissions, bitfields, and CMP identifiers. Depending on the CMP, the user’s location, the type of data, or other factors, the string can differ. The most common strings are the TCF and GPP strings, which were created by IAB to help standardize these signals and make it easier for parties to share data in a compliant way.
The CMP also writes its own consent cookie, containing the consent string or a set of purpose flags. This is what makes consent persistent, meaning the same user doesn't get re-prompted on every page load, and so anything running on the site (including a server-side tagging container on that same first-party domain) can read it later without needing JavaScript to re-ask the CMP.
3. CMP sends payload
The CMP sends a single HTTP request to the server-side container including the CMP cookie and a payload, which includes:
- Other first-party cookies
- HTTP headers (i.e. user agent, referrer, IP address)
- Event data (URL, event name, parameters)
- Consent signal (in string form)
- Identifiers
- Consent mode flags (if using Google Consent Mode)
The CMP cookie is what makes consent state reach the server (it's automatic, browser-enforced, no script required), while the payload carries the more detailed, structured version of that consent plus the actual event data the tag needs to act on.
4. Server-side container decodes string
Your tagging container parses whatever arrived with the request. When you set up your server-side tagging solution, you select which tags to fire depending on the event data. So for every tag scheduled to fire, the container checks to make sure that the correct criteria has been met. This evaluation should be done tag by tag, not as a single all-or-nothing switch.
This per-tag evaluation is exactly why server-side setups are often described as more resilient than client-side gating. A misconfigured or malicious script client-side could theoretically fire before consent checks apply, but on the server, nothing should fire to a third party until that specific tag's consent requirement is independently confirmed.
5. Container fires, modifies, or drops each tag
Once a tag has been evaluated against the data included in the event payload, the tagging container makes a decision on what to do. If consent was given, the tag fires and provides third parties with the appropriate information.
If only partial consent was given or if you configure your tags to not share certain information, your tagging container can strip down the data before sending it to third parties. You could also add information to certain tags to improve the quality of the data being shared, but only if it doesn’t need additional consent.
If no consent has been given or the data does not meet the right requirements, the tag does not fire at all and third parties do not receive anything.
This simplified timeline of signal sharing between CMPs and tagging container highlights how they interact with each other. But not all solutions are created equal, making it harder to maximize your ad spend and marketing campaigns while still meeting compliance regulations. The best way to do that is with solutions designed to integrate.
The gold standard: Didomi x Addingwell
Pairing Didomi's CMP with Addingwell's server-side infrastructure decouples your data pipeline from browser volatility and brings your marketing, privacy, and legal teams to a single source of truth. Consent is captured once, at the source, in a format built for regulatory accuracy. Enforcement happens once, server-side, in a way that isn't at the mercy of a user's browser configuration. The result is a pipeline where "what the user agreed to" and "what actually happens to their data" are the same thing, and not two systems that need periodic reconciliation.
Didomi’s CMP makes it easy to collect and track consent from your users no matter where in the world they are. Adding or removing a third-party tool, changing a country-specific configuration, or adjusting wording in the banner can now be done by a marketer, engineer, or even a privacy officer. With Didomi, you get the consented data you need to power the rest of your business from every event.
You can easily set up Addingwell's server-side tagging container to receive event data and its consent metadata, and it acts as the enforcement point. Rather than relying on each individual marketing or analytics tool to correctly interpret a consent string, the server-side container applies the rule once. If a user hasn't consented to analytics tracking, the event is filtered or anonymized before it ever reaches the analytics vendor. If they've consented to advertising but not to a specific third party, that vendor simply doesn't receive the call.
This has three practical effects for teams running the combined stack:
- Increased compliance posture: Instead of auditing dozens of vendor tags for consent compliance, you audit one server-side layer that knows what to do with every tag.
- Improved data quality: Because the server-side container isn't subject to browser-level blocking, you stop losing legitimate, consented events to ad blockers and tracking prevention, without collecting anything the user didn't agree to.
- Simplified vendor management: Swapping or adding a marketing tool means updating the server-side configuration, not re-implementing consent logic inside a new client-side script.
The ultimate synergy: Event Consent Monitoring
Earlier this year, Didomi released the Event Consent Monitoring feature that 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.
Addingwell processes every event flowing through your container, and those requests carry the Didomi consent cookies in the request header. This combination (simultaneous access to the tracking payload and the consent signal) enables genuine per-tag, per-event consent monitoring, breaking open the server-side black box. With Event Consent Monitoring as part of your CMP + server-side tagging data flow, you get:
- Automatic consent analysis: metrics show whether a server-side GTM implementation is correctly applying consent choices and spotlight the consent compliance of individual events.
- Detected misconfigurations: Google Consent Mode and Didomi CMP configuration with server-side implementation is faster, easier, and validated. See exactly where consent and tags don’t match and easily fix it.
- Consent insights: real-time visibility into your data sharing provides better privacy governance, breaking the traditional blackbox of unverifiable consent.
Together, Didomi's CMP and Addingwell's server-side tagging solutions give teams a single source of truth for consent and where that consent has traveled. We’ve seen organizations significantly increase their tracking coverage and consent rates, up to 70% in some cases.
At Didomi and Addingwell, this is the problem we work on. Didomi orchestrates consent, helping organizations collect, store, and operationalize user choices across their properties. Addingwell operates at the server layer, with an approach built on the third form, a server-side infrastructure that remains fully under the advertiser's control, is vendor-agnostic, with editable logic, and has transparent data flows.
The thesis behind both is that in a market that is moving toward simplicity through delegation, there is a distinct and growing need for organizations that want to understand and prove what they do with data, not just configure it and hope.
- Julien Decroix, Co-Founder of Addingwell by Didomi (source: Didomi blog)
If you would like to learn more about how Didomi and Addingwell solutions work together to drive better website tagging while meeting regulations, check out Event Consent Monitoring or talk to one of our experts:
{{talk-to-an-expert}}
.avif)
