Background
In the recent years ad platforms such as Facebook Ads (Meta) and Google Ads began to introduce and promote use of the conversion APIs, allowing advertisers to send more details about their conversions. This article describes how conversion APIs work, why their use is essential and how different implementations can affect their performance. It describes common pitfalls why conversion APIs may not have delivered the desired result and documents approaches to fixing this.
Facebook's study has shown that correct use of Conversions API results in increase of CPA by 13% and lead to sale conversion rate by 20% on average; the average is misleading as the figure is funnel dependent. Some funnels may already track all conversions correctly without Conversions API. Others may gain up to a 7x RoAS (return on ad spend) increase and doubling number of tracked conversions in other funnels in our experience.
A common belief assumes that conversions reported in the ad platforms' are not supposed to reflect real-life sales. This assumption is the most compelling reason to understand why use of conversion APIs is essential for modern marketers. Digging deeper into the implementation details is usually required. It's not just the integrity of reports of the affected ad platforms - the data visible in the reports are used by ad platforms to target advertisements to their users. When an ad platform doesn't understand which ones convert, it is unable to offer cost-effective solution as it's targeting AI cannot work without reliable data, facing the problem known in computer science as "garbage in- garbage out".
This became especially important in 2021, after further rollout of Facebook audience expansion and Google Ads Performance Max campaigns. While there are indeed limitations on what conversions can be tracked and reported, most advertisers can get a much better value from online ads by making sure that conversion APIs are used correctly to convey details of their converting audience to ad platforms' AI.
The reasons behind conversion APIs appearance
Traditionally, tracking pixels and tags were used to track conversions. They relied on using cookies to trace any eventual purchase back to the original ad source. While they never supported tracking of 'offline' conversions (which, in addition to CRM sales and in-store purchases, include other conversion events that happen outside of browser such as Stripe subscriptions after end of trial), they did track online sales well. This changed after browser vendors started to introduce limitations of how tracking cookies can be used, eliminated use of third-party cookies that allowed ad platforms to monitor behavior of their users on other websites, and forbidding use of the ad click identifiers by Apple out of privacy concerns became the last straw, destroying ability to rely on browser tracking for most advertisers.
Conversion APIs were rolled out by Facebook, Google and TikTok to overcome limitations of online browser tracking. They work by supplementing tracking done by pixels and tags with server-side data integrations. However, some common integration implementations that rely on sending data to secondary tracking pixel or sending conversions from an e-commerce or integration platform like Zapier often don't work as intended. We'll need to look into intricacies of how the conversion API data are used on the ad platforms' end to understand why and how conversion APIs can be used to solve this.
How pixels, tags and conversion APIs work together
To attribute conversions to corresponding ad campaign, ad group and creative, ad platforms aim to collect various information about conversion and use the best available data for attributing conversions on their end. When no precise data are available, ad platforms will use so-called modelled conversions to make an imprecise guess of what ad click the conversion should be attributed to and having more data in this scenario is of a paramount importance.
When a user clicks on an ad, ad platform will include a tracking identifier in the URL. Ideally this is a unique identifier, in which case the process is relatively simple: when a visitor comes to a website, tracking pixel sets up a cookie in the user's browser, associating it with a click identifier (which is known from the URL). This identifier is then can be used to reliably attribute a purchase done in the same browser; alternatively, if it is recorded by advertiser's and sent to the API later when a purchase occurs, the purchase will also be attributed.
This is not available for bulk of the IOS traffic (which includes any ads in YouTube, Google app searches and many others) however, where ad platforms are forbidden from tracking their users end-to-end and other approaches need to be taken.
One approach allowed by Apple is non-unique identifiers that don't allow to identify a specific users but can be used by ad platform to measure performance of an ad group while being fully privacy conscious. Google uses identifiers called wbraid and gbraid for this purpose; Facebook doesn't use such identifiers in the URL explicitly, its Pixel records details about browser, setting a first-party cookie to the browser and recording details such as type of browser being used, IP address, time of the first access of a website and so on.
These details allow to use modelled conversions reliably and are fully dependent on advertisers being able to provide relevant non personally identifying conversion identifiers and browser details in the conversion events sent to ad platforms' APIs. These data should be supplemented with first-party customer data such as emails and phones when available, as well as browser details when supported by an ad platform, ensuring that most data available for the ad platform to use.
Common use cases
Offline conversion tracking and building a 360-degree customer view
Tracking offline conversions is the most essential use case for supplementing online tracking with a server-to-server integration. While many advertisers solely rely on tracking of conversions that happen online, such as sign ups, lead form completions and check outs, offline conversion data such as completed payments and subscriptions provides much better insights into understanding performance of ads precisely.
When the volume is sufficient (50+ conversions per week are usually recommended), it can be used as an optimization goal directly; when there are fewer conversions, they can be used to populate audiences used for lookalike advertising, and the customer journeys can be analyzed individually to profile paying customers and understand how they interact with the website.
IOS14.5+ conversion tracking
After Apple introduced ad tracking restrictions in IOS 14.5+, ad platforms were forced to remove unique click identifiers such as gclid and fbclid and instead either rely on non-unique anonymized identifiers (Google Ads) or browser and device tracking (Facebook).
Facebook uses Facebook Pixel to identify first interaction with the website and assign unique identifier to the browser, which is stored in a first-party cookie. Facebook associates this cookie with user's IP address, time of advertiser's website access, browser details and similar parameters. This allows Facebook to guess which of the browser identifiers, belonging to the paying (converting)customers, are likely to be associated with which ad clicks and views.
Google Ads uses non-unique click identifiers that can be shared between several users and identify a group of clicks rather than a person. The allow to model conversions without impacting users' privacy, but their use require server-side support -which integrations that rely solely on gclids don't offer.
Facebook, Google Ads and TikTok also provide a way to send customer details such as email and phone in a conversion, which, depending on the ad platform, are used to either supplement click and browser identifiers or as a fallback method when identifiers aren't available. They can't be used to replace click identifiers entirely as customers may use emails and phones not known to the ad platform.
The ad platform perspective. Why both pixels and conversions API must be used and why deduplication doesn't work as expected
Ad platforms deal with immense amount of data and their infrastructure is built to record a lot of customer details to attribute conversions to users and understand how to target your ads better.
They operate by collecting various conversion events incrementally. For example, when a tracking pixel or tag is triggered, it will record a page view associated with ad click (if an identifier is available) and will record browser details, setting a first-party tracking cookie, and a purchase similarly may be tracked by recording a thank you page view.
While many advertisers have tried sending data to conversions API, many were disappointed with the results. In many cases this is caused by ad platforms' infrastructure limitations.
As ad platforms are built to process large number of conversions, the algorithms that ingest events are optimized to work as fast as possible and process events independently. What this means is when an ad platform processes conversion, its processed independently of data sent in other conversions.
Common issues with implementations
Because of this, when a same conversion is tracked via both pixel and conversions API and a deduplication identifier is sent to prevent duplication, it will only process one of the events, regardless of whether the conversion was attributed correctly.
Only a small subset of data will be available for attribution resulting in 30-70% conversions missing from the reports when deduplication is used without a customer data platform that collects all customer details (available click ids, both unique and non-unique IOS-friendly types, browser details and customer information such as email) and sends it in a single conversion event to the API, This is also a common problem when using integration platforms such as Zapier or Integromat.
Achieving deduplication by using one pixel on the website and another pixel (or another conversion action in Google Ads) for server-to-server tracking is another common mistake. Because ad platforms nowadays may rely on browser session to see end-to-end attribution of a conversion without a unique click identifier, using separate pixels in browser and for the back-end tracking hampers efforts of understanding entire customer path by the ad platform.
How attribution algorithms work
Ad platforms offer tracking pixels such as Facebook Pixel and Google Tag. These pixels track events that happen on the pages and send these events to the ad platform. They associate page click identifier (when available) and browser details, setting a first-party cookie to track visitor throughout the path of the website.
For many funnels this tracking method alone works well: ad platform attributes most of the conversions via its own first-party tracking cookie, the purchase happens while it's available, the thank you page is always displayed, all traffic comes from desktop browsers with click identifiers (no YouTube or Instagram clicks for example). It works extremely well in right circumstances and in case if your reports show most conversions, you may not need to worry about conversions APIs.
For most advertisers, however, data tracked by pixels are insufficient to attribute conversions to the source. Or the conversions that define RoAS happen offline. Tracking pixels would either not be able to see these conversions entirely, or correctly recognize 30-70% of them, damaging ad optimization and resulting in inadequate conversion reports.
To solve this problem, ad platforms implement conversion APIs that enable advertisers to send additional customer data for conversions that happen offline or don't have identifiers to improve chances of ad platform understanding which of its users and clicks has converted.
Ad platforms receive API events to link conversions with browsers or profile personal data and, indirectly, ad clicks, to model conversions that can't be tracked otherwise. This requires use of both browser pixel and API to process page view and conversion event; however, sending the same event from two and use of deduplication may result in loss of the tracking data as ad platforms discard duplicate events instead of merging them.
Even in case of offline conversions its best that both pixel and conversion APIs are used, but only conversion API actually sends conversions. This is beneficial for the following reasons:
- Using pixel allows ad platform to assign browser identifier and set a first-party cookie, which can then be used to attribute the click to a specific browser when a specific click id is not used. This is substantially beneficial to only sending click id or an email to the API as it prevents loss of data when these precise identifiers cannot be used to attribute conversion.
- When a deduplication is used, ad platforms don't look data sent in the previous events with the same order id. They usually only rely on the API data instead. Advertisers must include all relevant information (click id when available, browser id, personal details etc) in a single conversion event. When two conversion events are sent, one from a browser pixel, and other to the API, only one of them will actually be processed.
- Accordingly, all conversions should be sent to the same pixel that is used on the website. When two separate pixels are used, ad platform won't be able to link server-side events with the pixel browser identifiers, resulting in loss of data. Events sent to a pixel that is not used in the ad and in the website will be effectively discarded with regard to optimizing the active campaigns (although they could be used to build lookalike audiences, for example). It is also beneficial to use standard events instead of custom ones, as they allow ad platforms to understand nature of the conversion better and process it in its algorithms correctly.
Implementation checklist
When integrating with conversions API, verify that the integration supports following cases as most sales funnels will encounter all of them, albeit in a varying proportion:
- Sending unique click identifier to ad platforms when it's available
- Sending conversion attributed to the exact client id that was used in the first user's session to Google Analytics
- Sending non-unique click identifiers (wbraid, gbraid for Google Ads, fbp for Facebook) when they're available
- Sending additional browser details to ad platforms that support it (Facebook, Google Ads)
- Sending first-party customer data such as emails or phones to supplement online identifiers or when there's no way to attribute conversion to specific identifiers
Different approaches to implementation
When we built Able CDP we've aimed to solve needs of marketers and developers, streamlining implementation of data integrations.
Integration platforms such as Zapier
Integration platforms offer an easy way to send customer personal data. They are a good solution for sending data to offline conversions sets when the CRM data are used and leads cannot be tracked on the website. Using integration platform to send click and browser identifiers is not always supported and needs to rely on in-house database and tracking. Able resolves integration services' limitations by attributing each conversion to the website visitor, providing most thorough conversion data to the conversions APIs.
Third-party reporting tools
Third party reporting tools are often an easier method on obtaining RoAS data compared to setting up conversion APIs, Google Analytics or custom in-house reporting. The major downside is that while they provide a good picture of marketing efficiency to the advertiser, they don't provide it to the ad platform. Able makes sure that ad platforms have best possible data about the conversions. Meaning your ads are now better targeted than competitors' and you're no longer spending more money on ads unnecessarily.
In-house development
Integrations with Conversion APIs can be built in house, or a general-purpose customer data platform can be used instead. Generally, such approach takes larger developers 'effort and, in case of in-house integration, requires continuous monitoring, API upgrades and bugfixes. Adding new integrations requires additional development work. Use of a marketing integration focused ad platform such as Able eliminates these issues, allowing a simple way to set up marketing integrations.