cc @next-devin
Spark fixed its missing event trackers at the start of September, but a live store built from Spark before that fix is still running without them, and its analytics have been silently empty ever since. Nothing tells a derived theme that the base layout gained a required block, so the store only found out when the merchant tried to launch ads and noticed there was no conversion data to bid on. Fixing that one store is small and sits on the store's side, not in this repo. What this is asking you to decide is whether Spark should carry something that lets a derived theme discover it is missing a required block, because today the only way to find out is for a merchant to lose weeks of tracking.
···
What happened
{% pixels %} was restored to the base layout in #55 and shipped in 1.3.0 on 2026-09-03. That fix is correct and main is fine.
A production store theme derived from Spark between the drop and the fix never picked it up, and was still serving no tracker frames on 2026-09-09, six days after 1.3.0.
|
|
| Dropped |
beb033f 2026-03-20, "remove jQuery and Bootstrap" (removed {% core_js %}) |
| Restored |
7d6cf2c 2026-09-03, #55, released 1.3.0 |
| Store theme derived |
after 2026-05-21 (it carries spark-events.js, added in #9) and before 1.3.0 |
| Symptom found |
2026-09-09 |
Evidence
On a product page of the affected store:
document.getElementsByName('customer_event_iframe').length // 0
typeof window.customerEventManager // 'undefined'
pixels.min.js in document.scripts // false
(window.dataLayer||[]).map(e => e.event) // gtm.js, gtm.dom, gtm.load
Both of the store's active trackers were registered, enabled and served the whole time. Fetching either tracker's own URL on the storefront returns 200 with its settings embedded, and an addCartLines mutation against /api/graphql/ returns a fully-formed product_added_to_cart payload on the Analytic-Events response header. The server never stopped emitting. Nothing on the page was listening.
The merchant read the app source themselves, correctly concluded the tracker was registered but never instantiated, and could not get further because {% pixels %} is not documented anywhere public. A paid-media launch that depended on the tracking was held up by it.
Checkout was unaffected throughout, exactly as #55 predicted: /checkout/ renders {% pixels %} from the platform's own layout, and begin_checkout was observed reaching the container with currency, value and items. That is what made this invisible for months. Storefront pages were dark, the funnel end of the data looked alive.
The gap
This repo's fix does not reach a store that already forked. There is no version signal in a derived theme, no upgrade note that says "1.3.0 adds a required base-layout block", and no check a theme author can run that would fail on its absence.
The blast radius is unknown and probably not one. Any store theme derived from Spark between 2026-03-20 and 2026-09-03 is a candidate, and the failure is silent on every one of them: the storefront renders correctly, apps stay installed and enabled in the dashboard, and only the events go missing. That includes every app that registers a storefront_event_tracker, so a store can be dark for Google Analytics 4, Google Tag Manager, Klaviyo and Taboola at once. On this store the tag manager and Klaviyo trackers were both inert.
What would have caught it
Open question, and the reason this is addressed to you rather than proposed as a change:
Out of scope
Two traps for whoever verifies a fix on a derived theme
- Verify on the published storefront.
customer_event_iframes.py returns empty lists when request.is_setting_preview, so the Theme Editor preview shows the fault whether or not it is there.
- A custom GraphQL cart is never the cause of a missing
add_to_cart. The events are generated server side on the mutation and delivered on a response header, so any cart going through /api/graphql/ drives them once the block renders.
cc @next-devin
Spark fixed its missing event trackers at the start of September, but a live store built from Spark before that fix is still running without them, and its analytics have been silently empty ever since. Nothing tells a derived theme that the base layout gained a required block, so the store only found out when the merchant tried to launch ads and noticed there was no conversion data to bid on. Fixing that one store is small and sits on the store's side, not in this repo. What this is asking you to decide is whether Spark should carry something that lets a derived theme discover it is missing a required block, because today the only way to find out is for a merchant to lose weeks of tracking.
···
What happened
{% pixels %}was restored to the base layout in #55 and shipped in 1.3.0 on 2026-09-03. That fix is correct andmainis fine.A production store theme derived from Spark between the drop and the fix never picked it up, and was still serving no tracker frames on 2026-09-09, six days after 1.3.0.
beb033f2026-03-20, "remove jQuery and Bootstrap" (removed{% core_js %})7d6cf2c2026-09-03, #55, released 1.3.0spark-events.js, added in #9) and before 1.3.0Evidence
On a product page of the affected store:
Both of the store's active trackers were registered, enabled and served the whole time. Fetching either tracker's own URL on the storefront returns 200 with its settings embedded, and an
addCartLinesmutation against/api/graphql/returns a fully-formedproduct_added_to_cartpayload on theAnalytic-Eventsresponse header. The server never stopped emitting. Nothing on the page was listening.The merchant read the app source themselves, correctly concluded the tracker was registered but never instantiated, and could not get further because
{% pixels %}is not documented anywhere public. A paid-media launch that depended on the tracking was held up by it.Checkout was unaffected throughout, exactly as #55 predicted:
/checkout/renders{% pixels %}from the platform's own layout, andbegin_checkoutwas observed reaching the container with currency, value and items. That is what made this invisible for months. Storefront pages were dark, the funnel end of the data looked alive.The gap
This repo's fix does not reach a store that already forked. There is no version signal in a derived theme, no upgrade note that says "1.3.0 adds a required base-layout block", and no check a theme author can run that would fail on its absence.
The blast radius is unknown and probably not one. Any store theme derived from Spark between 2026-03-20 and 2026-09-03 is a candidate, and the failure is silent on every one of them: the storefront renders correctly, apps stay installed and enabled in the dashboard, and only the events go missing. That includes every app that registers a
storefront_event_tracker, so a store can be dark for Google Analytics 4, Google Tag Manager, Klaviyo and Taboola at once. On this store the tag manager and Klaviyo trackers were both inert.What would have caught it
Open question, and the reason this is addressed to you rather than proposed as a change:
Out of scope
{% pixels %}behaves correctly.{% core_js %}as a jQuery-era cart and CSRF bundle without saying it renders the tracker layer, and does not document{% pixels %}at all. That is adeveloper-docsissue and Render {% pixels %} in the base layout, recover from a consumed cart id; release 1.3.0 #55 flagged the same thing.Two traps for whoever verifies a fix on a derived theme
customer_event_iframes.pyreturns empty lists whenrequest.is_setting_preview, so the Theme Editor preview shows the fault whether or not it is there.add_to_cart. The events are generated server side on the mutation and delivered on a response header, so any cart going through/api/graphql/drives them once the block renders.