Meta CAPI
Check received data

Check that data is correctly received by Meta

In the GTM Server-Side preview

The first thing to check in the GTM server preview is that the Meta Conversion API tag is correctly triggered by the events configured in the trigger.

By clicking on the tag triggered by the view_item event, it is then possible to check that requests have been sent to Meta via the conversion API and the pixel.

A request to the pixel will be visible here only if the Send pixel request box has been checked in the tag configuration.

Meta Conversion API Requests Sent

In the Meta Business Manager event handler

With test events

In the event manager, inside the pixel, access the Test Events tab to debug events received by Meta.

Before any events appear here, copy and paste the test code (for example, TEST14336) into the Meta Conversion API tag.

Meta Pixel Test Events

It is also possible to see that the event has been correctly deduplicated thanks to the Deduplicated badge present on the event coming from the server.

⚠️

It is not recommended to keep the Test ID in the Meta Conversion API tag in production. You should remember to remove it before publishing my server container.

With the overview

The number of events received

The number of events received from the browser should be equal to the number of events received from the server. It is also possible to observe a greater number of events received by the server, which would indicate that certain browser requests are being blocked (notably by ad-blockers).

⚠️

If more requests come from the browser than from the server, this indicates that another implementation of the pixel exists somewhere on the website. It is then necessary to determine whether this pixel conflicts with the current implementation, or whether it is another markup that does not yet have a Server-Side implementation.

The amount of data received (including user data)

To assess the amount of data received, Meta offers Event Match Quality.

Meta will examine the parameters sent in each event and assign a score out of 10. Overall, the more data sent in an event, the higher the score.

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

The idea here is not to get a score of 10/10 everywhere, but to see for each event if there is data you could transmit in addition to improve match quality.

Let's take the PageView event as an example.

Shared parameters

PageView Shared Parameters

Here's how to interpret the previous screenshot for each parameter:

Parameter nameInterpretation
E-mail addressThe e-mail address is present in 3.47% of PageView events. On the website (here a Podia space), the email address is only accessible when the user is logged in, which seems normal.
IP addressThe IP address is a technical data present in all HTTP requests, which is normal.
User agentSent automatically.
Browser ID (fbp)Sent automatically when the _fbp cookie is present.
External IDThe external ID is retrieved from the user_id sent as soon as a user logs in, in the same way as the email address. The coverage is therefore the same as for the email address, which is normal.
First nameTransferred through user_data when a user is logged in. Everything is normal.
Last NameTransferred through user_data when a user is logged in. All normal.
Click ID (fbc)Sent when the user comes from an ad, i.e. when the _fbc cookie is present. For this reason, coverage is very low.

Other parameters

PageView Not Shared Parameters

Here's the interpretation of each parameter in the previous screenshot:

Parameter nameInterpretation
Date of birthThis information is not requested when creating a user account, so it cannot be sent to Meta on a PageView event.
CityThis information is not requested when creating a user account, so it cannot be sent to Meta on a PageView event.
StateThis information is not requested when a user account is created, so it cannot be sent to Meta on a PageView event.

The purpose of this analysis is to show that Meta's recommendations are not always synonymous with incorrect tracking. However, if certain parameters that are supposed to be sent are not present on the Meta side, the implementation needs to be reviewed.

Congratulations

You've finished configuring Meta CAPI.

If you encounter any problems during these steps, please do not hesitate to contact our support team.