If your Meta or LinkedIn results suddenly look weaker, the problem may not be the campaign. It may be the browser. Cookies get stripped, ad blockers block scripts, and network-level changes cut the client-side tags that ad platforms use to see what happened after a click. That is why the Conversions API has moved from a technical add-on to a core piece of performance marketing.
What the Conversions API actually does
At its simplest, a Conversions API is a server-to-server connection. When someone completes a purchase, submits a lead or takes another valuable action, your web server, commerce backend or CRM sends a JSON payload straight to the ad platform’s endpoint. The event never passes through the visitor’s browser.
Meta and LinkedIn call this a Conversions API. TikTok calls it an Events API. Microsoft’s version sends events to capi.uet.microsoft.com, while Google offers server routes through the Google Ads API and the newer Data Manager API. The name changes; the principle is the same.
Matching and deduplication decide whether your data is usable
Ad platforms still need to match a server event to a real user. That usually means hashed email addresses or phone numbers, plus click identifiers. Meta’s specification requires normalised identifiers, with phone numbers formatted to E.164 before SHA-256 hashing. Microsoft recommends storing the latest msclkid per user for about 90 days because the server path makes the advertiser responsible for capturing it.
Deduplication is where many teams lose clean data. Most platforms recommend running the browser pixel alongside the API, so the same action can arrive twice. The fix is a stable event ID on both paths. For example, a browser purchase and a server purchase carrying the same event ID within the platform’s window should count once. If the IDs differ, inflated revenue teaches automated bidding the wrong lesson.
What to do about it
- Run both signals. CAPI is a supplement to the pixel, not a replacement, at least for now.
- Standardise event IDs. Use one naming format across browser and server events so deduplication works.
- Hash first-party data properly. Normalise phone numbers, then hash email and phone fields with SHA-256.
- Treat consent as your problem. Server delivery changes the transport, not the legal basis for personal data.
- Watch the endpoint rules. Platforms differ on batch limits, timestamp age and invalid events.
CAPI, ECAPI and enhanced conversions are not the same
The IAB Tech Lab’s ECAPI 1.0 is a shared event format finalised in May 2026. A Conversions API is a platform-specific endpoint. Server-side tagging is the architecture that can send those events. Enhanced conversions is Google’s hashed first-party data feature that supplements tags. Keeping the labels straight prevents you from buying the wrong integration.
The bigger picture: less signal, more responsibility
Server-side tracking restores signal lost to browser restrictions, but it is not a magic fix. An IAB guide from late 2025 said two-thirds of advertisers reported improved ROAS after implementation, though that is self-reported. Meta claims a 17.8% lower cost per result for advertisers with a web Conversions API set-up. Treat vendor statistics as directional, not audited.
The landscape is still moving. Meta launched a one-click setup in April 2026, OpenAI added a Conversions API for ChatGPT ads in May 2026, and Safari 27 is expected to block some Bing and LinkedIn tracking endpoints at the network level. Meanwhile, ad blockers have started naming server-side tag manager subdomains, and courts have ruled that moving data to a server does not remove GDPR obligations.
None of this changes the core takeaway: automated bidding optimises against the conversions it can see. If you are not sending server events, you are letting browser limitations decide where your budget goes.
Source: PPC Land
