My pixels / analytics events aren’t firing
Section titled “My pixels / analytics events aren’t firing”The analytics module is opt-in and lazy-loaded - it only loads when <storesynk-store> has the track-events attribute. Without it, no pixels.js chunk loads and nothing is tracked. Add track-events to your store tag. If only some providers are missing, check the routing attributes: a track-client allow-list (e.g. track-client="meta,ga") drops every provider not listed (meta, ga, tiktok, pinterest, reddit, klaviyo); with no track-client, all auto-detected client pixels run - except ga when it is listed in track-server (server wins, see the next entry). (The old track-exclude deny-list was removed; if stale markup still carries it, it does nothing - replace it with a track-client allow-list naming the providers you do want.) If everything is silent, confirm the merchant’s onsite pixel scripts are actually present on the page (the module fires to the pixels it detects), and that require-consent (if set) has been satisfied. Enabling can also come from the centralized config block (<script type="application/json" data-storesynk-config>{"pixels":{"enabled":true}}</script> as a direct child of <storesynk-store>) - the store stamps track-events from pixels.enabled, so config-only enablement works. A malformed config block is silently ignored (the store catches the JSON parse error and falls back to attributes/defaults): if config-driven pixels/cart behavior does nothing, validate that the block is well-formed JSON.
My GA client pixel stopped firing after I enabled track-server
Section titled “My GA client pixel stopped firing after I enabled track-server”Expected. GA has no client/server de-duplication, so when ga is listed in track-server the module always drops its client pixel - server wins, GA never runs both ways (Meta does run both, deduped via the shared event id). If you want GA client-side, take ga out of track-server.
Server-side events (relay / Meta CAPI) aren’t arriving
Section titled “Server-side events (relay / Meta CAPI) aren’t arriving”Server-side forwarding is a separate opt-in from the onsite pixels: add track-server="meta,ga" (a comma-separated provider list, not a URL) alongside track-events on <storesynk-store>. Its presence enables the beacon to the default relay endpoint; a self-hosted endpoint goes in relay-endpoint="https://…/collect" - a URL in track-server itself is parsed as a bogus provider name (this moved: older markup used track-server="<url>"). With track-events but no track-server, only the client-side pixels fire - nothing reaches the relay. If track-server is set but events still don’t land server-side, the relay authors the real provider calls from the shop’s stored integrations config, so an empty/misconfigured config there (or a wrong relay-endpoint) is the cause - an app-side issue, not markup. (The beacon also carries the GA session_id - read from the _ga_<container> cookie - plus first-touch utm_*/gclid, so GA4 Measurement Protocol attribution works server-side; if GA4 sessions look wrong, check that the GA cookie exists on the storefront domain.)
<klaviyo-back-in-stock> does nothing / renders nothing
Section titled “<klaviyo-back-in-stock> does nothing / renders nothing”It consumes productContext, so it must sit inside a <storesynk-product> (SSK-102) - it needs the selected variant’s id to subscribe. It also needs a child <input type="email"> (and a <button> or a wrapping <form>) to wire up; with no email input it silently does nothing. On submit it toggles [ss-loading] → then [ss-active] (success) or [ss-empty] (failure), so style those states rather than expecting built-in messaging. Under the hood it scrapes the Klaviyo company id from the merchant’s onsite Klaviyo script - if that script isn’t installed, subscriptions can’t be sent.
Imported from the Storesynk skill v0.1.0 (references/known-issues.md). To change this page, change it there.