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 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.
On the Addingwell Side via Events Monitoring: Successfully Sent Events
Click on the Events Monitoring tab from your Addingwell container. Select the desired time range, then click on the Meta CAPI tag card.

This screen provides details about the events sent from your server to the Meta Conversion API, along with the success rate for each event (100% success rate in this example).
If your requests don’t show a 100% success rate, you can investigate further by checking the logs for those failed requests. Click on the Logs tab, then open the Meta API logs.

For example, in our account’s error logs, the most frequent error (118 occurrences) is related to a product price that is not a valid number. This value must be corrected in the data sent from the site’s dataLayer. On your end, you can inspect your logs to identify and resolve the specific issues.

Check the Quality of the Data Received
Sending your conversion events to Meta is an important first step. You can further enhance this process by including user data (such as email, phone number, or names) in your events. This user information allows Meta to match the received data to a real user in their database.
This helps Meta to:
- Better attribute conversions, by identifying conversions that otherwise would not have been linked to your Facebook/Instagram campaigns.
- Further optimize your campaign bidding, using higher-quality signals.
To follow our methodology for reliable server-side user data delivery, check out our dedicated documentation.
On the Addingwell Side via Events Monitoring
Click on the Events Monitoring menu from your Addingwell container. This screen displays all user data processed by your GA4 client and made available for your server-side events.
Let’s take the purchase event as an example: by clicking on the event name, you can view which parameters are available for this specific event.

On this screen, you can see the presence rate of user data parameters such as email in your purchase events, and the coverage rate of each parameter.

In our example, user email data is present in 100% of purchase events.
This means the data quality is good, as the events contain the required user data that is available at that point in the customer journey.
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.