Server-side tags drop consent unless your code sends it

Most teams that set up consent mode and then move their tags server-side believe the banner choice travels with the event. It travels as far as Google’s own tags. After that, it exists only if your code sends it.

We read the request reference of six server-side conversion APIs. Three can carry a visitor’s “no”: Google’s, Microsoft’s and Pinterest’s. Microsoft treats a missing value as granted. Meta, Snap and LinkedIn have no field for a European visitor who declined, so the only way to honour it is not to send the event.

How consent reaches the server, and where it stops

Google’s server-side Tag Manager documentation is precise about the mechanism. The banner tells the Google tag in the browser. The Google tag adds consent parameters to the HTTP request it sends to your server container. Google product tags in that container read those parameters and adjust what they send. With ad_storage denied, the Google Ads conversion tag stops reading and writing cookies and the remarketing tag stops sending requests.

That is why Google says you only need to set consent mode up in the web container. It is also the limit. The page describes Google’s tags. A server container, or your own backend, that forwards the same purchase to Meta, Microsoft or LinkedIn is building a new request, and that request carries whatever fields your code puts in it.

The consent field in each server-side API

Read from each platform’s developer reference on 2 November 2026. Every cell is in facts above with its source.

API	Consent field	Values	If you send nothing
Google Ads API (click conversion upload)	consent.ad_user_data	GRANTED, DENIED	“Possible” the conversion won’t be attributable
Microsoft Advertising Conversions API	adStorageConsent	G, D	Processed as granted
Meta Conversions API	data_processing_options	LDU only (US states)	Processed normally
Pinterest Conversions API	opt_out (optional)	true / false	Not stated
Snap Conversions API	data_processing_options	LMU (iOS 14.5+ opt-outs), DELETE	Do not set it otherwise
LinkedIn Conversions API	none in the schema	—	Processed normally

Three details in that table deserve a sentence of their own.

Microsoft’s default runs the opposite way to Google’s. Google warns that a conversion uploaded without a consent value may not be attributable. Microsoft states that every event without adStorageConsent is processed as granted. An event sent with D is not used for attribution or retargeting. A server that forwards a declined visitor’s purchase without the field has, in Microsoft’s terms, sent a yes.

Meta’s only processing flag is American. LDU, Limited Data Use, exists for US state privacy laws, and its country field accepts the United States or “geolocate it”. The server event reference has no value that means “this European visitor declined advertising cookies”. The decision is made by sending or not sending.

LinkedIn has nothing to set. The streaming conversion event is a conversion rule, a timestamp, a value, an event ID and the user’s identifiers. Every LinkedIn event your server sends is an event LinkedIn may use.

What this dataset does not cover. It records what each reference documents, not what each platform does internally with an event. TikTok’s Events API and Reddit’s Conversions API are missing because their references render in the browser and returned no field list to a fetch. An empty row is more useful to you than a field name copied from a third-party blog.

One declined visitor, six requests

A visitor in the EU clicks an ad, declines advertising cookies on the banner, and buys. Your checkout writes the order. A server job forwards it to all six platforms with each reference’s sample payload: the order value, the event ID, the hashed email, the click ID where there is one. Nobody adds a consent value, because the team believed consent mode already handled it.

• Google Ads API: consent unset. Google says the conversion may not be attributable.
• Microsoft: no adStorageConsent, so it is processed as granted, and is usable for attribution and retargeting.
• Meta: nothing to set for an EU decline. Processed.
• LinkedIn: no field exists. Processed.
• Pinterest: opt_out absent, so Pinterest is not told.
• Snap: LMU applies to iOS opt-outs, not this case.

In the browser, the same visitor’s decline stopped the Meta pixel and the LinkedIn Insight Tag from firing, if the banner controls them. On the server, the decline did not exist. Three of the six requests cannot carry it, and a fourth reads its absence as consent.

What it does to the numbers

Teams judge a server-side migration by how many more conversions the platforms report afterwards. Part of that lift is real: events that ad blockers and tracking prevention used to stop. Part of it can be the events your banner said no to, now arriving by another route. Both look identical in a platform dashboard. The browser count and the server count only explain each other when you split them by consent state.

Google’s side of the same visitor is the opposite problem. When consent is denied, Google fills the gap with modeled conversions on the browser path. If your server also uploads that visitor’s order through the Google Ads API with no consent value, you have sent Google an event that it may not attribute, for a sale it may already be modelling.

What to do differently

1. Store the consent state on the order. Read the banner’s choice at checkout and write it to the order record, next to the click ID. A server job that runs an hour later cannot ask the browser.
2. Gate per destination in code. Where the API has a field, send it: DENIED to Google, D to Microsoft, opt_out: true to Pinterest. Where it has none (Meta for an EU visitor, LinkedIn), the honest implementation is an if that skips the request.
3. Split the migration lift by consent state before crediting it. If the new server-side conversions come mostly from visitors who declined, you have not recovered measurement. You have moved the consent problem off the page and into your logs.

Skipping the request is the clean case. For the visitors who did say yes, the event you forward still carries a hashed email or phone number. Teams often describe that hash as anonymous. Is it?