Facebook Pixel: Conversions API
Server-side events through the Meta Conversions API in the Facebook Pixel plugin for Shopware 6.7: prerequisites, setup, which conditions an event must meet, deduplication, message queue and failure behaviour.
Facebook Pixel: Conversions API
Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net
The Meta Conversions API (CAPI) sends events directly from the server to Meta, in addition to the browser pixel. These events are independent of the browser, so ad blockers and browser restrictions do not affect them. Meta calls the combination of both a redundant setup.
Privacy: The Conversions API also transmits the visitor's IP address and user agent server-side, and they are not hashed. Only email and phone number are hashed. Details: Privacy.
Setup
- In Meta Events Manager, generate an access token under Settings > Conversions API
- In the plugin configuration, switch on Enable Conversions API and enter the Access Token
- Under Server-Side Events, choose the events you want (Meta recommends at least PageView and Purchase)
- Optionally enter a Test Event Code and check the credentials with Test connection
- Make sure the message consumer is running (see Installation)
- Clear the Test Event Code again for production
When is an event sent server-side?
An event is only sent when all of the following conditions are met:
| No. | Condition |
|---|---|
| 1 | Enable Tracking is on and the Pixel ID consists of digits only |
| 2 | Enable Conversions API is on and an access token is entered |
| 3 | The event is listed in Server-Side Events |
| 4 | Consent exists: with Klaro active, the klaro cookie contains the service with true, otherwise, with Require Cookie Consent, a recognised consent cookie (see Consent and cookies) |
| 5 | The request is a web request with a request context |
The switches of the tracking options also apply: if Track Orders is off, for example, no Purchase event is created at all, neither in the browser nor on the server.
Flow
- The page's subscriber creates the event and hands it to the browser code. At the same time it announces it internally as "event dispatched".
- The listener checks the conditions above and hashes email and phone number.
- It puts a message into the message queue. The page is not slowed down by this.
- The consumer processes the message and sends it over HTTPS to Meta's Graph API (
graph.facebook.com, versionv21.0, endpoint/{pixel-id}/events). The timeout is 5 seconds.
A failed delivery is not retried. If the request fails, the plugin writes a warning to the log (channel mmd_facebook_pixel) and the event is lost.
Deduplication
Browser and server use the same ID per event: eventID in the browser, event_id on the server. Meta thereby recognises that both describe the same occurrence and counts it once. Duplicate entries in Events Manager are therefore expected in the redundant setup, as long as they are deduplicated.
What is sent?
| Field | Content |
|---|---|
event_name |
Name of the event (for example Purchase) |
event_id |
Event ID, identical to the eventID in the browser |
event_time |
Time at which the message was created (Unix time) |
event_source_url |
Full URL of the requested page |
action_source |
always website |
custom_data |
The same event data as in the browser, see Events and data. The field is omitted when an event has no data, that is for PageView. |
user_data |
See Privacy |
If a Test Event Code is entered, it is sent along as test_event_code.