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.
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 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.
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.
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.
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.
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.
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
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.
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:
- Better attribute received conversions, identifying conversions that otherwise would not have been attributed to Facebook/Instagram campaigns.
- 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.
On this screen, you can see the percentage presence of email user data in your server-side events.
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
Here is the interpretation of the previous screenshot for each parameter:
Parameter Name | Interpretation |
---|---|
1. Email Address | The 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 Address | The IP address is a technical data point present in HTTP requests. |
3. User Agent | Automatically sent. |
4. Phone Number | Transferred 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. Gender | Gender 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 Code | Transferred in user_data when a user is logged in. Everything is normal. |
8. Date of Birth | Transferred in user_data when a user is logged in. Everything is normal. |
9. Country | Transferred in user_data when a user is logged in. Everything is normal. |
10. First Name | Transferred in user_data when a user is logged in. Everything is normal. |
11. Last Name | Transferred in user_data when a user is logged in. Everything is normal. |
12. City | Transferred 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.