Conversions missing from Facebook (Meta) Ads Manager is a common issue that many Facebook (Meta) advertisers are facing. In this article we highlight two most common yet obscure reasons why transactions may be missing from Facebook and offer ways to solve Facebook tracking and attribution.
Reason 1: Deduplication
Facebook (Meta) often recommends advertisers to send conversion events to Conversions API in addition to sending same events to the Pixel and provide a deduplication parameter to prevent same event tracked twice. While well-intended, this advice is designed for a narrow use case when JavaScript is blocked in the browser, allowing Facebook to attempt to attribute conversion using customer details available on the back-end alone. In practice, it often reduces amount of data available to Facebook to match the conversion to the ad interaction.
The co-existence of browser-based Pixel tracking and server-side Conversions API is sometimes interpreted to imply a possibility of using server-side events to extend attribution data available to Ads Manager. Nothing can be further from the truth. According to Meta, Conversions API uses deduplication to keep only one of the events it receives: "If we know that the events are the same and therefore redundant, we can keep one and discard the rest."
Sending the same conversion conversions to Facebook (Meta) Pixel and then sending additional customer details to Conversions API with deduplication parameters will result in the Conversions API event being dropped by the Conversions API in most cases.
The primary reason for this is that Facebook (Meta) Conversions API deduplication parameter makes Facebook to ignore the event sent to Conversions API altogether when a corresponding Pixel event is available, even if Conversions API event has more customer data.
Meta describes the algorithm that drops subsequent events as follows: "If server and browser events do not differ meaningfully in their content, we generally prefer the event that is received first."
While there's some ambiguity in what "meaningfully" and "content" mean in this context, the remainder of the document describes this unambigously: "If we find the same server key combination (event_id and event_name) and browser key combination (eventID and event) sent to the same Pixel ID within 48 hours, we discard the subsequent events."
This is often the case with built-in Conversions API integrations in web applications, as well as Conversions API integrations offered by companies that don't specialize in attribution.
Able Customer Data Platform solves this limitation by merging in-browser customer identifiers, such as Facebook Browser and Click Ids (fbp/fbclid), with the customer details that are available on the back-end and can be used by Facebook to attribute the conversion such as customer email, name and address. It then sends it to Facebook Conversions API as a single event, combining the details that would normally be sent to Pixel and API separately allowing Facebook to use both for attribution.
Reason 2: Modelled Conversion Settings
When Apple introduced tracking and privacy restrictions, it's primary goal was to stop ad platforms from collecting data about external activities of users. Facebook complied with the restrictions by removing click id parameter from IOS clicks and relying on browser identifiers and non-personally identifying parameters instead. Facebook implemented a method it calls 'modelled transactions', which uses partial details such as depersonalized identifiers and personal details sent via Conversions API to guess, which ad click produced the conversion.
While the method works fairly reliably, Facebook severely restricts what events and what attribution windows can be used to comply with privacy restrictions. Advertisers need to ensure that the attribution settings that are used are compatible with conversion modelling; otherwise Facebook won't be able to attribute IOS transactions correctly.
The latest official announcement at the time of writing this post states: "We are introducing modeled reporting for our 1-day click-through attribution window that accounts for events no longer reported. To adjust for data sharing limitations, we will not use modeling for our 7-day click through and 1-day view through attribution windows. Reporting for these attribution windows will be partial and not include all events."
Using unsupported attribution setting in Facebook will mean that even the conversions that can be attributed from the Conversions API data sent to Facebook won't be shown because of privacy limitations.
Detailed information about recommended conversion window settings is available on Facebook website: