Consent Mode v2 stopped being optional on 2024-03-06. From that date, EU and EEA traffic into Google's advertising products has had to pass two new signals — ad_user_data and ad_personalization — alongside the original ad_storage and analytics_storage. The change was driven not by GDPR but by the Digital Markets Act (Regulation (EU) 2022/1925), and specifically by DMA Art. 5(2), which forbids designated gatekeepers from combining or cross-using personal data across services without explicit consent.
For a URL shortener that intersects the redirect data plane in awkward ways. A short link is what the user clicked; the consent state on the landing page decides whether the click can be attributed. Those two events happen on different domains, in different cookie jars, often in different sessions. The gap between them is where most attribution loss now lives.
This post is the working compliance counsel's read on what changed, what the four signals actually mean for a redirect service, where server-side recovery is legal under the EDPB's current guidance, and where it is not. Most of the engineering work for server-side tracking via redirects is fine under GDPR; some of it is not fine under the DMA.
The DMA, in one paragraph#
The Digital Markets Act became applicable on 2024-03-07. It designates "gatekeepers" — Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft, Booking — and imposes ex ante obligations on them. DMA Art. 5(2) is the one that matters for tracking: a gatekeeper shall not process personal data of third-party-service end users for online advertising, nor combine personal data across its services, without consent.
Consent Mode v2 is Google's compliance mechanism for Art. 5(2). The two new signals — ad_user_data and ad_personalization — let the gatekeeper observe whether the publisher has obtained Art. 5(2)-grade consent before click telemetry is used for advertising or personalisation. Without those signals set to granted, Google's advertising products fall back to aggregated or modelled conversions with no per-user attribution.
The DMA does not replace GDPR. It sits on top. A controller still needs an Art. 6 lawful basis under GDPR; Consent Mode v2 adds a second gate that closes for gatekeeper-routed advertising data even when the GDPR gate is open.
The four signals, in plain terms#
Consent Mode v2 ships four boolean signals. Each can be granted or denied. Defaults can be set per-region.
ad_storage — the original v1 signal. Controls whether cookies or other storage are written for advertising. When denied, Google tags fire without identifiers; conversion measurement degrades to cookieless, modelled aggregates. The redirect decides what UTMs and click identifiers land on the page, and those become the keys consent attaches to. The tag-platform consent documentation is the canonical reference for what each signal does downstream.
ad_user_data — new in v2. Controls whether user data may be sent to Google for advertising at all. This is the DMA Art. 5(2) signal. When denied, the tag cannot transmit user data — including hashed identifiers, IP, user-agent — to Google Ads. Server-side tagging does not bypass this; the signal travels with the event.
ad_personalization — also new. Controls whether transmitted data may be used for personalised advertising, including remarketing. A common configuration is ad_user_data=granted plus ad_personalization=denied, which permits attribution but blocks remarketing.
analytics_storage — controls whether storage is written for analytics. The GA4 tag honours this; when denied, GA4 runs cookieless and uses consent-mode modelling to reconstruct attribution at aggregate level. Modelling needs a minimum traffic volume and a 7-day learning period.
None of the four signals are decided at the shortener. The shortener emits the click; the landing page reads the signals; the tag on the landing page decides what to do with them. The shortener's job is to deliver clean state — preserved UTMs, preserved click identifier, fast redirect — so the banner can resolve before the tag fires.
What goes wrong on the redirect data plane#
Three failure modes show up on every shortener that takes the redirect path seriously.
The click identifier survives but the consent signal does not. A Meta-ad click hits s.elido.me/abc123?fbclid=… and redirects to https://customer.example/landing?fbclid=…. The fbclid is preserved. The page loads, the banner appears, the user denies. Meta CAPI has already received a click keyed to that fbclid — but the user has now denied advertising use. The shortener did nothing wrong; the controller has a CAPI deduplication problem to solve on their endpoint.
The shortener appends identifiers the landing page does not understand. Some shorteners (Bitly's bitly_session, Rebrandly's _branch_match_id) append vendor-specific parameters that need stripping or special handling under denied consent. Elido forwards UTMs and the customer's own click identifier only.
The landing page consent state is unknowable from the redirect's vantage point. The shortener cannot see a banner that has not loaded yet. Server-side fallback decisions cannot be conditioned on a consent state that does not yet exist. The only honest default: do not fire any advertising-purpose server-side event at redirect time; let the banner resolve, then let the page or its proxy fire with the consent state attached.
Vendors who fire Measurement Protocol or CAPI events directly from the edge are betting the user will grant consent. Under DMA Art. 5(2) that bet is not theirs to make. The EDPB Guidelines 02/2023 on the technical scope of Article 5(3) ePrivacy made the related point about pre-consent identifier injection: it is processing, it needs a basis, and the absence of a banner is not a basis.
Server-side mitigations that are legal#
The mitigations below are the ones that hold up under both GDPR and DMA. They share a common thread: the consent state has to be observed before any data is transmitted to a gatekeeper or used for advertising.
Measurement Protocol with consent state attached. GA4's Measurement Protocol accepts the same consent parameters as the gtag client. The pattern: the landing page resolves the banner, posts the consent state to the customer's first-party server, and the first-party server forwards a mp/collect request to GA4 with consent.ad_user_data and consent.ad_personalization set. Server-side, but downstream of consent resolution. Elido's forwarder (covered in GA4 server-side tracking via redirects) applies the consent state to the outbound payload.
Conversion API with consent strings. Meta CAPI accepts data_processing_options and opt_out; LinkedIn's Conversions API accepts enlli; TikTok's Events API accepts limited_data_use. All of them signal the consent state to the platform. The pattern is identical: landing page resolves, posts to first-party server, first-party server fires with the consent state attached.
Aggregated server-side reporting. Where the consent state denies advertising or analytics use, server-side reporting that is genuinely aggregated and lacks per-user identifiers is generally fine under DMA Art. 5(2) and under GDPR Art. 6 on a legitimate-interest basis. The EDPB's Guidelines 04/2023 on anonymisation reiterate that pseudonymised data is not anonymous and that low-k k-anonymity still re-identifies. Conservative practice is to publish counts at the workspace level with a ≥10 threshold.
First-party identifier resolution on the landing page. The most resilient approach is to identify the user via a GDPR Art. 6(1)(b) signal — they signed in, they completed a form, they clicked a confirmed email link — and to attribute backwards. This does not depend on ad_storage or ad_user_data at all. The click attribution after Safari ITP post covers the pattern; it is the right answer for the post-DMA world too.
Server-side mitigations that are not legal#
Three patterns turn up in tooling-vendor pitches and should not.
Firing CAPI events from the edge before the landing page consent resolves. This is the failure mode described above. There is no consent state to attach; firing the event implies the controller has obtained consent, which it has not. Some vendors describe this as "deterministic attribution"; under DMA Art. 5(2) it is a data combination operation the user has not authorised.
Hashing the IP and treating the hash as anonymous. The EDPB has been clear since Opinion 4/2007 on the concept of personal data and reiterated in Guidelines 04/2023 that hashed identifiers remain personal data when the hash is reversible by anyone with access to the population. IP hashes are easily reversible at scale; the hash does not change the legal character of the processing.
Server-side identifier syncing with gatekeepers. Forwarding the click event to Google or Meta with a hashed email or hashed phone number, and relying on the gatekeeper to match it against their own identifier graph, is the operation DMA Art. 5(2) specifically restricts. The matching is a cross-service data combination by the gatekeeper. Consent for it has to be explicit and at the user level. The presence of the hash does not make the operation lawful; the absence of consent makes it unlawful.
Recent CJEU and EDPB context#
Two recent regulator moves sharpen the picture.
The CJEU's judgment in Case C-621/22 (Royal Lichtervelde, 2024) reiterated the joint-controller analysis from Wirtschaftsakademie (C-210/16) and Fashion ID (C-40/17). When a publisher integrates a third-party tag and that tag transmits user data to the third party, the publisher and the third party are joint controllers for that processing. GDPR Art. 26 requires a transparent arrangement between them. For a Consent Mode v2 customer, the Art. 26 arrangement with Google needs to be in place and the consent state has to flow honestly. Faking ad_user_data=granted to recover attribution is a joint-controllership liability for both sides.
The EDPB's Guidelines 03/2024 on consent signals in advertising contexts (consultation draft, final expected Q3 2026) explicitly addresses Consent Mode v2. The draft holds that the ad_user_data signal is, under GDPR Art. 7(4), conditional on freely given consent, and that banners bundling ad_storage with ad_user_data without granular controls fail the Art. 7 freely-given test. Most current banners bundle them. The redesign is on the customer; the shortener surfaces clean state, it does not design the banner.
For the broader transfer-impact picture — consent granted, data still leaves the EU — the Schrems II and tracking pixels post covers the TIA angle. DMA does not solve that problem; it adds another constraint.
What Elido does (and does not) do at the redirect layer#
Elido is the processor; the controller decides the consent posture and operates the banner. The redirect data plane does the minimum:
- Preserves UTMs and the customer's own click identifier. Vendor-specific advertising identifiers (
fbclid,gclid,msclkid,ttclid) are forwarded by default because they are the controller's attribution surface; per-workspace opt-out is available. - Does not fire any server-side advertising event at redirect time. The internal click event written to ClickHouse has IP truncated to /24 or /48 and parsed device fields only, per GDPR data minimisation. It is not shared with any third party.
- Supports consent-aware server-side conversion forwarding to GA4, Meta CAPI, LinkedIn, TikTok, and Reddit, gated by the consent state the landing page supplies. The forwarder lives in
/features/conversion-tracking; the wiring is in the conversion tracking docs guide. - Requires a
consentpayload from the landing page when consent-aware forwarding is enabled; absent the payload, the event is dropped, not silently fired with defaults.
The analytics dashboard at /features/analytics shows the consent-state breakdown per campaign — granted, denied, unset — so the marketing team can see how much attribution is being lost to denials.
What Elido does not do: implement the banner, pre-decide consent, or honour granted consent for users who have not actually granted it. Those decisions live with the controller, where GDPR and DMA both put them.
The procurement question#
For a controller scoping a shortener under DMA Art. 5(2), three questions.
Does the shortener forward click data to any third-party advertising or analytics service at redirect time, independent of the landing page consent state? If yes, that is a DMA Art. 5(2) exposure to terminate.
Does the shortener support consent-state forwarding to its server-side conversion endpoints? If no, the controller will need a separate server-side tagging proxy (GTM server container, Stape, Snowplow) between the landing page and the gatekeeper APIs.
Does the shortener's analytics layer share aggregated data with any third party? Some marketing-tilted ones publish "industry benchmarks" that turn out to be customer click data with sub-graphs identifiable by traffic shape — what's the joint-controller analysis under Wirtschaftsakademie and Fashion ID?
A shortener that hedges on any of these adds a DMA risk surface the controller will defend in audit.
Where this lands#
Consent Mode v2 is not a marketing initiative. It is a compliance mechanism for DMA Art. 5(2) that ships through Google's tag platform. The four signals are honest about what consent has been obtained; server-side mitigations work when the consent state travels with the event; the attribution loss in a denied-consent world is real but smaller than it looks once first-party identifier resolution is in place. The shortener delivers clean state across the redirect and exposes consent-aware forwarding the controller wires to its banner.
The EDPB's expected Q3 2026 guidance will move the floor. Designing for the current floor only is short-sighted; designing for what Art. 5(2) intends — explicit, granular, freely given consent for cross-service data combination — is the position that survives the next round of enforcement.
Related reading#
- GDPR for URL shorteners: what your DPO actually wants to see — the cornerstone for the compliance cluster.
- Click attribution after Safari ITP — the parallel attribution-loss story on the browser side.
- Cookieless attribution explained — first-party-identifier patterns that survive denied consent.
- GA4 server-side tracking via redirects — the Measurement Protocol shape consent forwarding sits on.
- Schrems II and tracking pixels — what happens to the consented data after it crosses the Atlantic.
- Product surface:
/features/analyticsfor the consent-state breakdown view. - Operational walkthrough: the conversion-tracking docs guide for the consent-aware forwarder wiring.