Facebook Pixel: Privacy
Facebook Pixel plugin for Sylius: which data the browser pixel and the Conversions API send to Meta, what is hashed, how consent applies and what is stored locally.
Facebook Pixel: Privacy
Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net
The plugin transmits visitor and order data to Meta. You must disclose this in your shop's privacy policy and cookie banner and make sure valid consent is obtained. This page describes what the plugin does technically; it is not legal advice.
Browser pixel
The plugin loads the Meta Pixel script from https://connect.facebook.net/en_US/fbevents.js and initializes it with the channel's Pixel ID. From that moment on, the visitor's browser communicates with Meta. Meta's pixel script uses the cookies _fbp and _fbc among other things for this.
The plugin passes these event data to the pixel (see Storefront Integration): variant codes, product or category name, category path, value, currency, item count and, for InitiateCheckout and Purchase, the order number. The plugin does not hand an email address or phone number to the browser pixel.
The script is only executed once consent is given when Release the tracking scripts through Klaro consent is effective (box ticked and mmd/sylius-klaro-consent-plugin installed). Without Klaro you must make sure yourself that it is blocked until consent is given.
Conversions API (server-side)
When the Conversions API is active, your server sends one call per selected event to https://graph.facebook.com (endpoint /{pixel ID}/events). The call contains:
| Field | Content |
|---|---|
event_name, event_id, event_time |
Event name, shared event ID and time. |
event_source_url |
Scheme, host and path of the requested page. The query string is deliberately dropped so that, for example, tokens or tracking parameters do not go to Meta. |
action_source |
Always website. |
user_data.client_ip_address |
The visitor's IP address in plaintext. |
user_data.client_user_agent |
The visitor's user agent in plaintext (truncated to 512 characters). |
user_data.em |
Email address, lowercased and trimmed, SHA-256-hashed. |
user_data.ph |
Phone number, reduced to digits, SHA-256-hashed. |
user_data.fbc, user_data.fbp |
The visitor's Meta cookies _fbc and _fbp, if present and in the expected format. |
custom_data |
The event data as in the browser pixel. |
The plugin sends IP address and user agent in plaintext because Meta requires it; only email and phone number are hashed. The hashing is unsalted SHA-256, as Meta specifies for em and ph.
Where email and phone number come from
PageView,ViewContent,ViewCategoryandAddToCart: the email address of the logged-in customer. Guests and visitors who are not logged in supply no email. No phone number is passed here.InitiateCheckoutandPurchase: the email address of the order's customer and the phone number of the billing address, also for guests.
Consent
The server-side events have their own consent check (Require verified consent for server-side events, on by default). The built-in Klaro provider reads the visitor's Klaro cookie and checks for facebook_pixel: true. Without evidence nothing is sent. If you switch the requirement off, the plugin sends without any check; the responsibility is then yours. See Configuration and Extending.
What is stored locally
- Settings: The table
mmd_sylius_facebook_pixel_channel_configurationonly holds the channel settings, no visitor data. The access token is stored encrypted and is never output again, neither in the admin nor through the Shop API. - Message queue: The CAPI calls run through Symfony Messenger. Until processed, the message contains IP address, user agent, the
_fbc/_fbpcookie values, the hashed email and phone number, source URL and event data. It does not contain a plaintext email or phone number. With a Doctrine transport, this data sits in the Messenger table until it is processed. - Session: For
AddToCartthe plugin briefly queues event ID and product data in the session until the next page emits them. - Logs: Failed CAPI calls are logged with HTTP status, event name and event ID, not with the payload.
- Cookies: The plugin sets no cookies itself.