Deutsche Version

Back to overview

Facebook Pixel: Troubleshooting and FAQ

Live Demo: Try this and other plugins live — no installation, no risk: demo.markus-michalski.net

Common problems

The pixel script never shows up in the storefront

• Symptom: no fbq calls in the page source, nothing in the Meta Pixel Helper browser extension.
• Check: Does the channel have a row with Tracking enabled ticked and a valid numeric Pixel ID? Is Release the tracking scripts through Klaro consent effective (ticked and Klaro installed) while no consent has been given in the browser yet? Then the script sits in the source as text/plain and only runs after consent.
• Solution: correct the channel settings under MMKreativ Plugins > Facebook Pixel. With Klaro gating, grant consent for facebook_pixel in the Klaro dialog to test.

A single event is missing

• Symptom: PageView arrives, Purchase or another event does not.
• Check: Is tracking ticked for exactly this event (for example Track Purchase)? Is the hook point overridden by a theme without rendering the hook any more (see Storefront Integration)?
• Solution: tick the checkbox or keep rendering the hook in the theme.

Events show up twice in Meta Events Manager

• Symptom: the same action (for example a Purchase) seems to be counted twice.
• Check: Is this the expected deduplication (the browser and server events are listed separately in the raw list, Meta's reporting merges them by event_id), or are two pixel base codes loaded on the same page (another plugin, a theme override, a tag manager)?
• Solution: for real duplicates, make sure the bootstrap hook renders exactly once per page and no other integration loads fbq() a second time.

CAPI events never reach Meta

• Symptom: browser events appear in Events Manager, server-side ones ("Conversions API") do not.
• Check: Is Conversions API enabled ticked? Is the access token stored (the field is always shown empty; when in doubt, enter it again)? Is the event selected under Events sent via Conversions API (none is selected by default)? Is browser tracking ticked for this event? And, the most common cause: is Require verified consent for server-side events on while no provider can confirm the test visitor's consent (no Klaro installed, no cookie storage, never agreed)?
• Solution: grant the Klaro consent before testing, add a custom provider (see Extending) or, only knowing the consequences, switch the requirement off. Also check that a Messenger worker for the main transport is running (bin/console messenger:consume), because CAPI messages are sent asynchronously. With a Test event code from Events Manager you see the events there under Test Events.

Prices are 0 or look wrong

• Symptom: value is 0, missing, or does not match the storefront.
• Check: Does the variant have a price for this channel? If the channel price is missing, value is omitted for ViewContent. Is Track gross prices set appropriately (on for B2C, off for B2B)?
• Solution: correct the gross/net setting. ViewContent always uses the channel's variant price; AddToCart, InitiateCheckout and Purchase use the line or order totals.

Known limitations

• Switching off Require verified consent for server-side events removes the server-side consent check completely: events then go to Meta without any evidence. Only switch it off if you know why.
• The built-in provider needs mmd/sylius-klaro-consent-plugin with cookie storage and an enabled row for the channel. Without it (not installed, no enabled row, or localStorage, which the server cannot read), CAPI never sends for that channel while the requirement is on and no other provider confirms.
• The CAPI copies are created when the Twig storefront renders and on the add-to-cart action. A headless frontend without Twig rendering does not trigger server-side events.
• Reloading the order confirmation page produces a browser event and a CAPI event again with the same event_id; the stable ID lets Meta merge them.
• Single-event scripts without Klaro gating wait for DOMContentLoaded if the document is still loading. Klaro-gated scripts are not delayed separately.
• The value of ViewContent is the channel's variant price; Track gross prices has no effect there.
• The Klaro catalog entry is created on a best-effort basis: a deviating Klaro schema is logged and skipped instead of failing the save. In that case, create the facebook_pixel service by hand in the Klaro catalog.
• CAPI calls are not retried on failure, only logged.

FAQ

General

Does this plugin need mmd/sylius-klaro-consent-plugin? No. It is detected at runtime and used if present; the plugin also works without it. Without Klaro you must make sure yourself that your consent tool blocks the pixel script, and for CAPI add a custom provider or deliberately switch the requirement off.

Is this the same code as the Shopware plugin? It is the Sylius port of the functionality of mmd/sw67-facebook-pixel, built on Sylius's own architecture (Twig hooks, Doctrine entities, Shop API, Symfony Messenger) rather than a line-by-line translation.

Configuration

Can I track gross prices on one channel and net prices on another? Yes, Track gross prices is a per-channel setting.

Can I enable CAPI for individual events only? Yes. Select only the wanted events under Events sent via Conversions API. An event can only be sent server-side if its browser tracking is ticked as well.

Compatibility

Does it work with a headless frontend? Partly: the Shop API endpoint returns the settings and the frontend fires the pixel itself. Server-side events are only triggered by the Twig storefront.

Does a custom theme break the pixel? Only if it overrides a hook point without rendering the hook any more. See Storefront Integration.