Meta CAPI
Check received data

Check Received Data

Once your Meta CAPI tag is configured, it's crucial to ensure that:

  • Your server container is correctly transmitting events to META, both from the pixel and from CAPI.
  • The volume of events received by Facebook is consistent and that deduplication is effective (the same event received from both the pixel and CAPI should only be kept once).
  • The quality of the data received is high, ensuring Facebook can match your most important events to a META user. To enable Facebook to match these events to its users, make sure you are sending user data with your events.

Verifying Event Transmission

GTM Server-Side Preview

The first step is to ensure that the Meta CAPI tag is correctly triggered for the events specified in the trigger.

In the server container preview, make sure that your Meta CAPI tag is triggered for a specific event (e.g., in our case, we check the trigger on the view_item event). Confirm that it appears in the Tags fired section and that the tag status is Succeeded.

Verifying Meta CAPI tag trigger on server-side

In the preview, click on the Meta CAPI tag to verify that requests have been sent to Meta via the conversion API and the pixel.

Note that a pixel request will only appear here if the Send pixel request option was checked during the tag configuration

Verifying data sent via Meta CAPI and Facebook pixel on server-side

Verifying Event Volume Received

Meta Side: Volume of Events Received

Access your Facebook Events Manager (opens in a new tab) Then click on the Overview tab. The events received by Meta appear here for the Pixel+CAPI data sources.

Verifying data sent via Meta CAPI and Facebook pixel on server-side

Meta Side: Pixel Volume, CAPI Volume, and Deduplication

Since you have implemented double tracking of your events via the pixel and Meta CAPI, you now need to ensure that the events:

  • Come from both data sources, from the pixel AND from Meta CAPI.
  • Are correctly deduplicated. You need to ensure that Facebook can recognize the same event received by the pixel and by CAPI, and that only one of these events is retained. This process is known as deduplication.

Click on a specific event from the Overview tab. In our example, we will verify that our implementation is functional for the Purchase event.

Verifying data sent via Meta CAPI and Facebook pixel on server-side

Here, we see that both data sources are active, and Meta is correctly receiving Purchase events from both the pixel (183 events from the Browser) and Meta CAPI (230 events from the Server).

The number of events received from the Pixel (browser) should remain relatively stable: adding the Meta CAPI tracking source should not affect the volume of data received via the browser. Therefore, you should observe a similar number of events for this pixel data source.

However, the number of events received from the server (Meta CAPI) should be higher than the number of pixel events. If you see 5-20% more events for CAPI, your setup is correct. If the volume of data received via the server is higher, your setup needs to be checked.

⚠️

If you notice a higher volume of events coming from the Pixel than from CAPI, this means there is another Pixel implementation on the site, and you are receiving duplicated Pixel events. You should verify where this second Pixel is coming from. You may have forgotten to disable it in your GTM WEB container, or it may still exist via a hardcoded implementation on the site (check with your developers).

Next, ensure that these events sent to Facebook are properly deduplicated by clicking on the View Details button and then clicking on the Event Deduplication tab.

Verifying event deduplication in Facebook Ads Manager

Here, we see that deduplication is effective, with no issues detected. Event IDs are 100% sent from both the Pixel and the Conversion API, allowing for perfect deduplication.

The Overlap information tells us the percentage of events containing a deduplication key and received from both the API and the pixel. In our example, this means that:

  • 76,56% of the received events were sent by both data sources, with the same Event ID. All of these events are deduplicated.
  • 79,07% of the received events were sent by both data sources, with the same FBP (Facebook Browser ID, automatically sent when present). All of these events are deduplicated.

Addingwell Side via Tag Health: Successful Requests

Click on the Tag Health tab in your Addingwell Container. Start by checking the number of requests made for Meta Conversions API over a given period, as well as the success rate of these requests. Click on Meta Conversion API for more details.

Verifying Meta Conversion API requests in Addingwell Container

This screen provides details on the events sent by your server to Meta Conversion API, as well as the success rate of requests, which is up to 100% in our example.

Success rate in Meta Conversions API requests in Addingwell Container

If your requests are not 100% successful, you can investigate further by retrieving the logs of these failed requests. Click on the Logs tab and then click on the Logs of the Meta API

Detailed logs of Meta Conversions API requests in Addingwell Container

For example, in the error logs of our account, the most frequent error (118 occurrences) is related to a product price that is not a number. It is necessary to modify this value sent by the website from the datalayer to avoid this error. On your side, you can check your logs to identify and correct the errors you have received.

Checking logs on error requests for Meta Conversions API in Addingwell Container

Verifying the Quality of Data Received

Sending your conversion events to the Meta platform is an important first step, but you can improve this process by adding user data (such as email, phone number, or names) to these events. This data allows Meta to match the information sent from your server to an actual user in their database.

This enables Meta to:

  1. Better attribute received conversions, identifying conversions that otherwise would not have been attributed to Facebook/Instagram campaigns.
  2. Further optimize your campaign bids through higher-quality data. To follow our methodology for reliably sending user data in server-side events, refer to our documentation on the subject

Addingwell Side via Data Monitoring

Click on the Data monitoring menu in your Addingwell Container. This screen displays all user data processed by your GA4 client and made available to your server-side events. For example, you can see that email data is present in 23,4% of server-side events. To verify the list of events where user email data is transmitted, click on the search icon for more details.

Verifying the quality of data received - Data monitoring Addingwell

On this screen, you can see the percentage presence of email user data in your server-side events.

Verifying the quality of user data in Addingwell

In our example, user email data is present in 100% of purchase events but only in 38,3% of add_to_cart events. This aligns with our purchase funnel, as the email is not available for all users at the add-to-cart stage.

The data sent here is of high quality because the events contain the desired and available user data.

Meta Side: Verifying Match Quality

Meta provides more details on the quality of the data received in the Match Quality tab. Meta assigns a score out of 10 for each event, indicating whether the user-data parameters are present in the event. The more user-data you send in an event, the higher the Match Quality score.

If you send complete user data for a Purchase event, your score will be high. For a PageView event (which contains little or no user data), your score will be lower.

The goal here is not to achieve a 10/10 score on every event but rather to see if there are additional user data you could send in your parameters to improve match quality for each one.

We will now check if we can improve the Match Quality for a PageView event by reviewing the shared parameters for this event.

Shared parameters

Shared parameters in Meta's event manager

Here is the interpretation of the previous screenshot for each parameter:

Parameter NameInterpretation
1. Email AddressThe email address is present in 29.05% of PageView events. On the site used in our example, the email address is accessible only when the user is logged in and is then transmitted in user_data. Everything seems normal.
2. IP AddressThe IP address is a technical data point present in HTTP requests.
3. User AgentAutomatically sent.
4. Phone NumberTransferred in user_data when a user is logged in. Everything is normal.
5. Browser ID (fbp)Automatically sent when the _fbp cookie is present.
6. GenderGender information is present in 25.28% of PageView events. On the site used in our example, this information is only available when the user is logged in, which seems normal.
7. Postal CodeTransferred in user_data when a user is logged in. Everything is normal.
8. Date of BirthTransferred in user_data when a user is logged in. Everything is normal.
9. CountryTransferred in user_data when a user is logged in. Everything is normal.
10. First NameTransferred in user_datawhen a user is logged in. Everything is normal.
11. Last NameTransferred in user_data when a user is logged in. Everything is normal.
12. CityTransferred in user_data when a user is logged in. Everything is normal.
13. Click ID (fbc)Sent when the user comes from an ad, so when the _fbc cookie is present. This is why the coverage is very low.

Congratulations

You have completed the Meta CAPI setup, and you've verified that your data is being successfully transmitted to Meta and that the data is of high quality.

If you encountered any issues during these steps, feel free to contact our support team.

Did this page help you?