Events that used to appear in the reports have stopped arriving, while the storefront itself has shown no errors. In this case, the immediate task is to investigate missing ecommerce tracking events. The workflow should produce a tracking diagnosis and a repeatable test plan, judging each gap against the consent conditions and logs the merchant can supply.
First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.
Act as a Shopify operations specialist.
Help me investigate missing ecommerce tracking events.
My store context is [describe the business, products and target audience].
My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [the events expected with the page or action that triggers each one, the received logs with timestamps and identifiers, the order records for the same window, the consent and browser conditions reported with the gap, and the dated history of theme and app changes]. Classify each gap by comparing the expected sequence with the received one, then test it under more than one condition to decide whether consent, a browser extension, the checkout step or a template change removed the event, marking a gap as unexplained only after those conditions have been ruled out.
Return a tracking diagnosis and a repeatable test plan, re-running the journey to check the result for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
List the events that should fire with the page or action that triggers each one, then collect the logs showing what arrived with timestamps and identifiers, the order records for the same window, the consent and browser conditions reported when the gap was seen, and the dated history of theme and app changes to the storefront.
Classify each gap by comparing the expected sequence with the received one, then test it under more than one condition to decide whether consent, a browser extension, the checkout step or a template change removed the event, marking a gap as unexplained only after those conditions have been ruled out.
Deliver a tracking diagnosis and a repeatable test plan naming each gap, its classification, the condition that reproduces it and the check that confirms the fix, then re-run the documented journey and reconcile the events now received with the order records for the window.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
The gap is placed in the journey first, then tested against one condition at a time: consent granted, default browser settings, and the same step reached from another entry point. Whichever condition restores the event identifies the cause; if none does, the fault is in the implementation itself and the template or script for that step is inspected next.
A retest covers consent granted and consent declined, a browser without extensions and one carrying the extensions the merchant's shoppers use, and both the standard and the express checkout paths where they exist. A single condition proves only that the event fires there; the conditions used are recorded so the result can be reproduced later.
A gap is closed when the event reappears in the logs with the identifier, value and currency matching a test order, and stays present across repeated runs under the documented conditions. One successful run is noted but not treated as proof, because an event can fire once and then stop; the merchant's logs for a later window confirm it held.
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.