Your conversion rate is lower this week. A campaign changed, mobile traffic grew and a theme release went out. The chart tells you something moved. It does not tell you which change to make next.
A useful investigation narrows that broad question to one journey: what happened when a shopper tried to add, update or buy a product? Here is how we approach it in Dozenfold.
Start with one broken interaction
Consider this fictional storefront example. A shopper opens a product, adds a variant to their cart and changes a delivery option. The cart update fails. They never reach checkout in the observed journey.
| Captured step | Time | What it establishes |
|---|---|---|
| Product viewed | 12:41:58 | The journey includes a product page. |
| Variant added to cart | 12:42:11 | The shopper reached the cart stage. |
| Delivery option changed | 12:42:46 | An interaction occurred before the failure. |
| Cart update failed | 12:42:47 | A specific storefront operation failed. |
That sequence gives a developer a starting point. It does not establish the shopper’s intent, reveal their screen or prove they would have purchased. The next step is to inspect the failed request and its technical context.
The boundary also matters: a storefront theme monitor can observe the theme’s JavaScript and requests. Shopify Pixel funnel events can add checkout progression. That combination does not mean a theme script can inspect every interaction inside Shopify’s hosted checkout.
Separate a repeated error from repeated shoppers
One session can trigger the same failure several times. Look at affected sessions as well as occurrences before deciding that an issue is widespread.
Check browser, device and page patterns next. If most affected sessions use Mobile Safari, reproduce there first. But compare that concentration with the store’s traffic mix before concluding that Safari is the cause. If nearly all visitors are mobile, a mobile-heavy error group may be unsurprising.
In Dozenfold, the issue, its affected journeys and page context stay connected so this investigation can continue past the headline count.
Put a revenue estimate on a comparable foundation
Compare sessions that reached the same stage in a similar context. Give both groups the same time to purchase. Use order values that belong to the comparison.
Dozenfold compares sessions that hit the issue with clean sessions at the same journey stage, device and environment, and counts purchases in the same 30-minute window for both. A verified SDK–Pixel link, known sampling and complete clean order values are part of the calculation. This separates the issue’s association with purchase completion from a simple traffic-count multiplication.
The pooled gap comes with a 95% interval. When the whole interval is above zero, the loss is measured; when it is positive but uncertain, it is directional. When the inputs are missing, the issue and its affected sessions still deserve inspection. See the revenue methodology for the current readiness rules.
Give the developer something they can use
Bring the error fingerprint, affected environment, release, failing request and captured steps. Add an original source frame when a usable source map is available. Keep guesses about the cause separate from observed facts.
You can download our fictional developer brief to see that handoff, or explore the investigation workflow.
After the change ships, watch the same issue for recurrence and check whether comparable traffic has returned. A quiet hour on an empty store says much less than a quiet period with active affected journeys. The useful outcome is a fix you can keep evaluating, with evidence your merchant and developer can both understand.