Over the past decade, the digital landscape has dramatically changed. Early measurement tools were designed to collect data with little thought for privacy. Today, however, regulatory changes (like GDPR and CCPA) and browser innovations – such as Apple’s ITP 2.3 and Mozilla’s cookie blocking – have reshaped data tracking. In this environment, the Conversion API emerges as a solution to maintain data accuracy and improve ad optimization.
Please note: While GDPR, CCPA, and similar regulations impact tracking capabilities, the Conversion API is not a method to send data about users who did not give consent. Its primary purpose is to address technological limitations in client-side tracking.
Why Conversion API?
Traditional client-side tracking, which relies on JavaScript pixels, has become less reliable. Browser restrictions and cookie limitations (for example, first-party cookies being shortened to seven or even 24 hours on some devices) hinder marketers’ ability to track conversions accurately. The Conversion API addresses these challenges by allowing businesses to send both web and offline event data directly from their server to ad platforms, bypassing the restrictions that affect client-side data collection. This means better data accuracy and an uplift in tracking – based on our experience with client implementations, we’ve seen up to around a 15% increase in signals, particularly on Apple devices.
A Shift in the Tracking Landscape
Until 2017, digital tracking capabilities were on the rise. Tools like WebTrends (1993), Omniture (1996), Urchin (1998 – later acquired by Google in 2005 and became Google Analytics), Crazy Egg (2006), Piwik (2007), Mixpanel (2011), and Facebook Pixel (2012) enhanced what businesses could measure. However, from 2017 onward, things started to change:
- June 2017: Apple introduces ITP 1.0 🔘
- September 2017: Google introduces Conversion Linker in GTM ⚪
- October 2017: Facebook Pixel allows first-party cookies ⚪
- May 2018: GDPR enforcement begins 🔘
- June 2019: Mozilla Firefox blocks third-party cookies 🔘
- September 2019: Apple releases ITP 2.3, limiting first-party cookies 🔘
- January 2020: Google announces third-party cookie phase-out; CCPA takes effect 🔘
- August 2020: Google announces GTM Server-Side ⚪
- September 2020: Google introduces Consent Mode ⚪
- October 2020: Facebook announces Conversion API ⚪
- April 2021: Apple enforces ATT 🔘
- November 2022: Google updates Consent Mode to V2 ⚪
- January 2023: Chrome begins phasing out third-party cookies 🔘
- March 2024: Google requires Consent Mode V2 ⚪
- July 2025: Chrome cancels third-party cookie phase-out ⚪
These changes significantly impacted the ability of ad platforms to collect data and optimize ads effectively. Changes marked with ⚪ introduced new capabilities or adaptations, while those marked 🔘 imposed limitations. Many of the adaptations were initiated by the ad platforms to maintain tracking capabilities under new constraints.
Different Implementation Approaches
There isn’t a one-size-fits-all solution when it comes to implementing the Conversion API. Several methods are available, each with its own advantages:
Basic Pixel Implementation (Client-to-Server – Not a Conversion API Implementation)
The simplest method involves keeping the familiar Facebook Pixel on a website. Here, data is sent directly from the user’s browser to the ad platform. While easy to set up, this approach still suffers from browser-related restrictions. Even when using first-party cookies, if they are written on the client side via JavaScript, they remain vulnerable to browser limitations and do not offer full tracking coverage.
Client-to-Server-to-Server (C > S > S) via a Proxy
By using tools like Google Tag Manager’s server-side container or other proxies, data is first sent from the browser to your server and then forwarded to the ad platform. This extra step shifts the data transfer into a first-party context, overcoming many browser-based limitations such as ITP 2.3. Since the event is sent both from the client and from the server, an event ID is included with each request to allow the ad platform to deduplicate the event and avoid double-counting.
Pure Server-to-Server (S > S) Implementation
In this setup, conversion data is collected via your backend systems or CRM and sent directly to the ad platform without any client-side involvement. This method is especially useful when you already capture lead data on your website forms and want to ensure that no signal is lost due to browser restrictions. It offers the most control and often the best data accuracy, though it may require additional technical effort.
In addition, this approach can be extended to send downstream funnel events. For example, if a user submits a lead for a demo, a follow-up event can be sent indicating that the demo was positive and the user showed further interest. This type of event is not feasible to track from the browser and is particularly valuable for B2B businesses that want to optimize their marketing efforts toward high-quality leads rather than just lead submissions.
Comparison of Implementation Methods
| C > S (Pixel) | C > S > S (CAPI) | S > S (CAPI) | |
| Context | 3rd Party | 1st Party | – |
| Cookie Mechanisms | Client Side | Server Side | – |
| Events | Limited to browser user interactions | Post-Entry | |
| Visible to user | Yes | Yes | No |
| ITP 2.3 affect | Full | Depends | None |
| Tracking Blockers | Full | Depends | None |
| Tracking Coverage | Baseline | 15% Uplift * | Full coverage |
* It’s important to note that the 15% increase in signals for C – S – S is primarily observed on Apple devices, based on results we’ve seen across client implementations.
Best Practices and Considerations
While implementing the Conversion API, consider the end goal: relevant data is critical for optimizing ad campaigns. For example, platforms like Facebook expect conversion events to be sent almost immediately to adjust their targeting algorithms. However, when building audiences or performing retrospective analysis, batch processing might also work well. The key is to balance both methods according to your campaign objectives.
Moreover, while Facebook’s Conversion API is the most well-known, it’s important to remember that many major ad platforms – including Google, TikTok, LinkedIn, and others – now offer similar server-to-server solutions. This means that by designing a robust and flexible implementation, you can streamline data collection across multiple channels with a single infrastructure.
Conclusion
The Conversion API is more than just a workaround for browser restrictions – it’s a way to future-proof your digital measurement strategy. By understanding its benefits and exploring different implementation approaches, marketers can ensure they’re collecting the best possible data. Whether you choose a hybrid approach with client-to-server-to-server integration or a pure server-side model, the goal remains the same: deliver accurate, real-time insights to drive smarter advertising.