What is the Meta Ads Conversions API
Meta's Conversions API is a "programming interface" designed to receive conversion event data. This data is received through applications with native integrations or servers configured for this purpose. The API was created as a way to establish direct communication between applications (such as CRM, e-commerce, websites) and the Meta Ads platform.
The API gained relevance after the implementation of the iOS14 update, which brought restrictions on the sending of event data through the browser itself on iPhone devices. Using the API to send the same events simultaneously, it is possible to create redundancy and mitigate data loss in this scenario.
This is not the only use case where the API can bring benefits for data collection and measurement of the purchase journey. It is also possible to use the API to report events that occurred in message conversations (WhatsApp, Messenger), in offline contexts, in applications, among others. However, this article focuses on the dynamics of conversion tracking for events that occurred on the website.
Learn more about the Meta Ads Conversions API in the official documentation.
How the Conversions API works
The API acts as the central point for receiving any event, from anywhere it may have occurred. This means that the event may have occurred on your own website, a payment gateway, a third-party application, etc.
The main difference, compared to the Meta Pixel, is that the use of the API promotes centralization in event firing. While the Pixel fires events through each client's browser, an API implementation will centralize this communication in some services, or on a single server.
It is not uncommon for a single digital structure to work with several different service providers such as Hotmart, Typeform, Wordpress, among others. Each of these services was built differently, with different technologies and languages, but they communicate with Meta in a standardized way, through the API. The mechanism that each platform develops to communicate with the API is called "Integration".
Learn more about implementing the Conversions API in the developer documentation.
Integrations
The way each of these services builds this Integration may differ. For example, Hotmart chose to provide only a subset of user data, associated with events that occurred at Checkout. Being a payment gateway, this may be a business rule that makes sense. In other services, such as Wordpress, it is possible to have more control over how and which data will be sent.
Whatever the services and platforms that make up the purchase journey, it is always more interesting to seek greater control and autonomy over the events triggered. This comes with two clear trade-offs: Complexity and Cost. Although limited, third-party "ready" integrations are simple to configure and often do not generate additional costs.
However, establishing greater control over the data of the events triggered to the API allows:
Greater coverage in conversion tracking;
Greater attribution of events to clicks.
How these trade-offs can be compensated by these benefits will depend on the volume of data that the operation generates and the technical capacity of the team.
Server-Side Tag Manager
As a way to mitigate the complexity, maintenance, management, and training of the team about Integrations, I recommend using Google Tag Manager Server-Side. Using a server container to centralize the event firing logic, both via Browser and via server, brings some benefits:
Allows multiple teams to work on the same project, with a common environment and interface;
Simplifies the documentation of logic, facilitating team training and maintenance of the Analytics structure;
Preserves the flexibility needed for operations at any level of complexity.
With this flexibility, it is still possible to make choices about the infrastructure that will provide the Tag Manager. That is, running through Google's cloud computing services, through third-party implementations (such as Stape.io) or choosing to manage an instance on your own server (self-hosted). The choice of these options generates more developments regarding costs and complexity (which are beyond the scope of this article).
How to use the Conversions API
We have previously established that communication with the API can originate from multiple sources and that the best way to manage this ecosystem is through Tag Manager. Regardless of the implementation details of the infrastructure, there are good practices and indicators that must be observed: Indicators of timeliness, quality, and effectiveness of event data in matching and attribution.
Next, let's understand how several of these concepts work in the Conversions API.
Deduplication
Meta's recommendation is the simultaneous use of the API with events fired via Browser (Pixel). This generates duplication for the events received from both sources. Because of this, one of the most essential best practices in using the API is the inclusion of an Event Identifier.
This identifier can be a number or code and must be sent along with the event fired by both API and Pixel (Browser). This identifier must be identical in both firings, allowing Meta to understand that it is a single event fired twice.
Using Tag Manager, it is necessary to configure a variable for this purpose, from a "community template". Configuring this variable in the WEB container, just transmit this identifier to the SERVER container. Including this identifier in the events fired by both containers, deduplication will be done by Meta automatically.
Learn more about deduplication in the official documentation.
Event Quality
Not always an event sent to the Conversions API can be matched to a user and attributed to a click on Meta. This can happen for several reasons, among them, the low quality and quantity of data associated with the event. In terms of advanced matching, user data needs to "match" the data registered on Meta. If the data sent is incorrectly formatted, or different from the data the user provided to Meta, the match will not occur.
Priority
Not all types of data that can be sent along with an event have the same relevance and effectiveness in matching. Sending only address data, for example, will not benefit matching, as there may be hundreds or thousands of people with the informed data. Therefore, the more unique the types of data, the better the chances of a successful match.
Meta establishes priority levels for user data associated with events. The highest priority is those that have the greatest capacity to identify users. Email, phone number, and IP address are the highest priority data.
Quality
From the data provided along with the event, Meta defines quality indicators for each type of event received. These indicators are presented in the form of a Score from 0 to 10 and a Classification, which ranges from: Poor, OK, Good, or Great.
Learn more about event quality in the official documentation.
Score
The numerical indicator is calculated based on the quality of the data sent and the percentage of events that indeed matched a Meta account. In other words, to obtain a high score, it is not enough that the data is sent. It is also necessary that this data is effective in matching the user data registered by Meta.
Classification
From this score, Meta defines a quality classification for the type of event. This classification is determined in relation to the score of other advertisers in the same region. In other words, if a large part of advertisers in the region does not do matching work, the classification will be higher automatically.
Learn more about Classification and Score in the official documentation.
Coverage Details
In the event quality panel, it is also possible to monitor the coverage details for each type of data received. This detail is the percentage of events that are being received with each data.
It is important to keep in mind that each type of event can represent a stage or touchpoint during the purchase journey. Earlier stages in this journey may precede any type of interaction with forms, making data collection unfeasible. Therefore, it is natural that some types of events have lower coverage and scores than events like purchase.
We can take as an example a first Page View on an online store. In this first contact, the visitor did not interact with any form, so data like name and email are not available for sending. In a subsequent interaction, the user subscribes to the Newsletter, providing name and email. From now on, it is possible to send these two data for matching, along with the events. In a third interaction, the user makes a purchase, also providing their address data for delivery. That is, only after the purchase, we have all possible data for the journey of this store. Thus, Page View, Registration, and Purchase events will have different scores, classifications, and coverage.
Data Timeliness
The sending/receiving of events through the Pixel (browser) occurs immediately, as it depends solely on the functioning of the user's browser. On the other hand, receiving events through the Conversions API may vary depending on the implementation of the integration. Ideally, as recommended by Meta, the event should be sent in real-time.
It is important to remember, however, that different services and platforms can implement their integrations in various ways. The ability of the integration to send events as quickly as possible directly affects the level of data timeliness.
This timeliness level can be monitored through the events manager and should be as close as possible to "Real-time". The implication of a longer timeliness level is the lower attribution of events to clicks.
Learn more about timeliness and coverage in the official documentation.
Additional Reported Conversions
As we saw in the article [[Attribution and Matching in Meta Ads]], the firing of events from the Pixel (browser) may not occur. Configuring the Conversions API to generate redundancy with Pixel events can mitigate these scenarios. Conversions recorded from events received by the API, and which do not have an identical event received through the Pixel, are called Additional Conversions.
This metric serves to monitor the impact that the use of the Conversions API is having on the attribution of events to clicks. In other words, accounts that work with audiences using more iPhone devices can expect a higher percentage.
Learn more about additional conversions in the official documentation.
Conclusion
As we saw in the previous paragraphs, the use of the Conversions API can involve different levels of complexity and cost. The choice of services and integrations also affects the effectiveness of the events sent in generating Additional Conversions. Other factors, such as audience behavior or the stage of the configured events, add even more complexity.
Therefore, it is difficult to estimate the impact that implementing this communication with the API can have on performance. However, the market trend, reflected in Meta's own recommendations, is to increasingly reinforce the use of the API. This can expand coverage in collecting user behavior data by creating redundancy in event sending. It also aims to seek ever higher quality for these events by associating data with greater quality and quantity.
Kommentarer