Skip to Content
Meta CAPICheck 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 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.

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.

Check Meta Conversion API requests in the Addingwell container via Events Monitoring

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.

View logs for Meta Conversion API requests via the Addingwell container

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.

Checking logs for failed Meta Conversion API requests via the Addingwell container

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:

  1. Better attribute conversions, by identifying conversions that otherwise would not have been linked to your Facebook/Instagram campaigns.
  2. 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.

Check parameters attached to a server-side purchase 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.

Check user data attached to a Meta event in server-side setup

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

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?