# Happy Healthy You: why GA4 revenue is wrong, diagnosed

**3 September 2026.** Andy flagged that GA4 revenue is inaccurate and the business runs on
Shopify instead. Both are true. Here is exactly why, measured from their own GA4 property
(`properties/302925420`) and Shopify admin over the identical window, 1 Sep 2025 to 31 Aug 2026.

## The size of the problem

| | GA4 reports | Shopify records | GA4 inflation |
|---|---:|---:|---:|
| Revenue | A$12,698,986 | A$9,525,231 | **+33%** |
| Transactions | 99,503 | 76,726 | **+30%** |
| Sessions | 2,298,515 | 1,794,409 | +28% |

## Root cause: a second purchase tag on the order confirmation page

Every order is being recorded up to **three times**:

1. **Shopify's native Google & YouTube channel** fires the legitimate purchase, with the order
   name as the transaction ID (format `#768150`).
2. **A second, hand-installed tag** fires the same purchase again with Shopify's internal
   numeric order ID (format `6075072741494`) into the **main stream**.
3. The same rogue tag also fires into the **Assessment portal's data stream**
   (`11181411013`), which recorded **8,530 purchases worth A$1,100,004**, despite the portal
   hostname itself recording zero transactions.

The evidence, all recomputed from the API:

- **8,560 transaction IDs fired more than once** (+8,577 extra transactions, ~A$1.11M of
  duplicated revenue). **8,521 of the portal stream's 8,523 purchase IDs also exist in the main
  stream**, so the visible duplicates are the portal tag double-firing checkout.
- The main stream's unique IDs split into two format populations: `#`-prefixed order names
  (the native tag) and bare 10-plus-digit internal IDs (the rogue tag). Same orders, two ID
  formats, so GA4 cannot even see most of the duplication: it thinks they are different orders.
- The arithmetic closes: ~22,800 phantom transactions from the rogue tag's two destinations
  equals the entire 99,503-versus-76,726 gap. There is no second mystery.
- The portal stream also logged **1,008,912 sessions** against only ~206,000 real
  portal-hostname sessions, which is most of GA4's 28% session inflation too.

## Where the rogue tag will be hiding (one of these)

- Shopify **Settings → Customer events**: a custom pixel carrying a `gtag`/GTM purchase event
- The **order status page additional scripts** (legacy field, Shopify Plus stores often still
  carry one), or `checkout.liquid` remnants
- A **GTM container** loaded in the theme with two GA4 configuration tags (one per
  measurement ID)

## The fix, in order

1. **Remove the rogue purchase event** wherever it is found above. Shopify's Google & YouTube
   channel remains the single source of ecommerce events. Result: ~A$2.1M a year of phantom
   revenue disappears and GA4 lands within normal tolerance of Shopify.
2. **Scope the portal stream's tag to the portal.** The `G-` tag for stream `11181411013`
   belongs only on portal.happyhealthyyou.com.au, never in the storefront theme.
3. **Fix the Klaviyo UTMs** (separate issue, five minutes, big payoff): Klaviyo is sending
   `utm_medium=campaign` and `utm_medium=flow`, which GA4's channel rules do not recognise, so
   **A$2.03M of email revenue lands in "Unassigned"** (Klaviyo/campaign A$1.45M +
   Klaviyo/flow A$0.58M of the A$2.37M bucket). In Klaviyo's UTM settings, set
   `utm_medium=email` and GA4 will classify it as Email from that day on.
4. After 1 to 3, re-baseline: GA4 becomes usable for channel decisions, and our monthly
   reporting will not be arguing with Shopify.

## Why this matters beyond hygiene

This is the Measurement pillar of the scorecard (currently 5/25) turning into points, and it
is the exact reason the strategy report's money model was anchored to Shopify truth rather
than GA4. It is also a strong trust move on the call: Andy suspected the data was wrong, and
we can tell him precisely why, to the order-ID format.

*(Diagnosis scripts: `diagnose_ga4.py`, results `ga4_diagnosis.json`.)*