Reported purchases exceed the order count, which suggests the same conversion is sent more than once. In this case, the immediate task is to identify duplicate pixel events and likely sources. The workflow should produce a tracking diagnosis and a repeatable test plan, separating genuine repeat purchases from duplicates in the merchant's event logs.
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 identify duplicate pixel events and likely sources.
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: [event logs with each event's identifier, order reference, timestamp and sending implementation, the list of installed pixels and tags, the order export for the same window, and any deduplication key already in use]. Group events by order reference and deduplication key, calling a repeat purchase genuine only where the order export shows a matching second order and a duplicate where one order reference is sent more than once, then attribute each duplicate to an implementation by comparing the sources and the install locations.
Return a tracking diagnosis and repeatable test plan with each suspected duplicate verified against the records 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.
Collect the event logs with each event's identifier, the order reference it carries, its timestamp at the precision the log records, and the implementation that sent it, together with the list of installed pixels and tags, the order export for the same window, and any deduplication key already in use.
Group events by order reference and deduplication key, calling a repeat purchase genuine only where the order export shows a matching second order and a duplicate where one order reference is sent more than once, then attribute each duplicate to an implementation by comparing the sources and the install locations.
Deliver a tracking diagnosis and a repeatable test plan listing each duplicate group with its order reference, the implementations involved and the likely source among a second installation, a reload or back navigation, and a retried request, then reconcile the deduplicated event count with the order export and state which reports must be restated.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
A duplicate shows one order reference sent more than once with identifiers or timestamps that differ only slightly, while a genuine repeat purchase shows two separate orders in the export. The order export is the deciding record; without it the two look identical in the event log, which is why the count is never adjusted before that check.
Each event carries the source that sent it, whether a theme pixel, an app integration or a server-side sender, and that is compared with the installed list. Where two senders report the same order, the one installed later or the one duplicating the other's trigger is named as the likely source and confirmed by disabling it for one test run.
Every report built on the events that were deduplicated, including campaign conversion counts, channel rates and cost per acquisition, is restated with the deduplicated count and the window affected. Reports that never used those events are left alone; the restatement is recorded with the rule applied so the change can be traced.
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.