The deliverable
A real Revenue Guard report
This is a complete report rendered from an actual scanner run against a reference storefront — the same structure a client account produces. Client identifiers are replaced with demo names; every finding, evidence value and recommended fix below is the run’s own output, not 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 |
No monetary figure appears anywhere in a Safeliant report. A scan observes a storefront from the outside and has no access to order values, margins or traffic, so any euro amount it produced would be modelled rather than measured. Findings state measurement and revenue risk, and stop there.
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.
Journey coverage is validated end to end on Shopify. On WooCommerce the journey is attempted and often works, but full checkout-entry coverage is not yet guaranteed — a store that blocks the scanner is reported as unassessed, never as working and never as broken.
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
Every finding, with the evidence behind it
This is the whole finding as a client would receive it: the rule that produced it, what was tested, what was observed, what was expected, the captured artefacts, the risk it carries and the fix to apply.
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. Full journey coverage across a portfolio is quoted on how many client accounts you monitor.