The deliverable
Sample revenue journey report
This example uses an actual scanner run against a reference storefront. The portfolio counts are from that run; three priority findings are shown in full. Client identifiers are replaced with demo names, and the finding details and evidence values come from the run rather than copy written for this page.
Portfolio summary
One run across every client account in the portfolio, ranked by what needs attention first. A store that refused the scanner appears as unassessed rather than as clean.
- Client accounts assessed
- 2of 2
- Findings, all clients
- 15
- Client-reportable
- 12
- Priority to act on
- 3
Severity of the 12 client-reportable findings
- critical
- 0
- high
- 3
- medium
- 8
- low
- 1
The remaining 3 are diagnostic: real observations the scanner will not assert in a client-facing report. Severity never overrides that — a diagnostic finding stays diagnostic even when it is HIGH, because a finding we cannot fully stand behind does more damage in front of a client than it does good.
Portfolio — 2 client accounts, 15 findings
- demo-store-a.exampleOPEN
Checkout · 14 findings
- demo-store-b.exampleOPEN
Checkout · 1 finding
| Client | Journey | Findings | State |
|---|---|---|---|
| demo-store-a.example | Checkout | 14 | OPEN |
| demo-store-b.example | Checkout | 1 | OPEN |
This example contains no monetary estimate. An outside scan lacks order values, margins and traffic. A financial range would require enough client-provided inputs and would be labelled as an estimate.
The journey that was walked
One persistent browser session, in run order. Every finding below is anchored to the step it was observed on, which is what lets a developer reproduce it.
This Shopify example comes from a reference storefront. Each merchant setup must be assessed separately. On WooCommerce, full checkout-entry coverage is not yet guaranteed; a blocked step is reported as unassessed.
Revenue journey — demo-store-a.example
- Homestorefront loadedPASS
- Productproduct page discoveredPASS
- Add to cartverified by cart statePASS
- Cartproduct presentPASS
- Checkout entryreachedPASS
- Completed purchaseno order is ever placedNOT TESTED
14
findings on this client
3
priority to act on
0
critical
Findings
Selected priority findings, with their evidence
Each example below shows the finding detail from the run: its rule, what was tested, observed and expected, supporting evidence, risk and recommended action. The run contains additional findings that are summarized above.
Finding 1 of 3 — demo-store-a.example
Ecommerce events missing value or currency
events_missing_value_or_currency
- Tested
- Walked the storefront in one persistent browser session: homepage → product page → add to cart → cart → checkout entry, accepting the consent banner first, recording every analytics beacon, dataLayer push, console error and network failure per step. The journey stops at checkout entry and never submits an order.
- Observed
- 1 of 2 ecommerce event(s) recorded during the journey were sent without a value and/or a currency parameter.
- Expected
- Every revenue-bearing ecommerce event should carry both value and currency.
Evidence
analytics_event · view_item params as sent
{"tid":"G-AAAA111111","en":"view_item","item_name":"Akku-Bohrhammer 18V"}
Risk
1 of 2 ecommerce event(s) were sent without a value and/or currency. Value-based bidding and ROAS reporting silently treat these as zero.
Recommended fix
Populate value and currency on every ecommerce event. Verify the value is numeric and not a formatted string.
Finding 2 of 3 — demo-store-a.example
No begin_checkout event at checkout entry
missing_begin_checkout_event
- Tested
- Walked the storefront in one persistent browser session through to checkout entry, recording every analytics beacon and dataLayer push per step.
- Observed
- Checkout entry loaded successfully, and across that step no GA4 begin_checkout beacon and no begin_checkout dataLayer push were observed. Events seen on this step: [].
- Expected
- A GA4 begin_checkout event should fire when checkout is entered.
Evidence
url · checkout step
https://demo-store-a.example/checkout
analytics_event · events seen on this step
[]
Risk
Checkout was entered without a begin_checkout event. This is the single most useful drop-off marker in the funnel, and on many platforms it is also the last event before a hosted checkout where tracking is hardest.
Recommended fix
Push begin_checkout with items[], value and currency on checkout entry. On hosted checkouts, use the platform’s checkout scripts or server-side tagging.
Finding 3 of 3 — demo-store-a.example
Tracking fired before any consent interaction
tags_fire_before_consent
- Tested
- Loaded the storefront with a clean profile and recorded all outbound tracking beacons BEFORE any interaction with the consent banner.
- Observed
- A consent banner was visible on load, and 2 tracking beacon(s) were sent before any consent interaction.
- Expected
- No non-essential tracking beacon should be sent before the visitor interacts with the consent banner.
Evidence
network_request · fired pre-consent
https://www.facebook.com/tr?id=&ev=PageView&noscript=1
network_request · fired pre-consent
https://analytics.tiktok.com/i18n/pixel/events.js
Risk
A consent banner was visible on load, and 2 tracking beacon(s) fired anyway before any consent was given. Either the consent manager is not blocking, or these tags sit outside its control.
Recommended fix
Move the offending tags under consent-manager control (a GTM consent-initialisation trigger or category blocking) and re-test with a fresh session.
A live report also carries per-step screenshots captured during the run. They are omitted here because this run’s captures are of a local reference storefront — a stand-in image in their place would be the kind of decorative mock-up this page exists to replace.
Run this against one of your clients.
The free check runs on one public page and needs no account, no card and no meeting. For an agreed Shopify product journey, scope and price are confirmed before work begins.