> ## Documentation Index > Fetch the complete documentation index at: https://docs.wisepim.com/llms.txt > Use this file to discover all available pages before exploring further. # Tracking Health > Check how much of your order revenue GA4 records, work through 11 tracking checks with fixes per platform, and link GA4 products to your catalog. Tracking Health compares what Google Analytics 4 recorded with the orders your store actually took. The headline reads **GA4 tracks `{percent}` of your order revenue**, and a **Tracking score** out of 100 sums up the checks below it. Every GA4 number elsewhere in Analytics, from channel reports to the product funnel, is only as good as this score. **What this page enables:** you find out whether a drop in GA4 revenue is a real sales drop or a broken purchase tag, you hand your developer a copy-ready spec instead of a vague complaint, and you keep payment providers from stealing credit from the channels that brought the shopper. **Where to find it:** **Analytics > Data & setup > Tracking Health**. The page needs a connected GA4 property; without one it shows **Connect Google Analytics 4 first**. Right after connecting it shows **Waiting for the first GA4 sync** until the first import lands, usually within a few hours. > [!NOTE] > > Other GA4 pages carry a trust chip that reads **GA4 tracks `{percent}`** or **Tracking score `{score}`**. Before it has run it says **Tracking not checked yet**. Click the chip to land here. ## Pick a period The **Period** tabs switch between the last **28**, **56** and **90** days. The provenance line under the headline tells you exactly what was compared: **Source: Google Analytics 4 (`{property}`) and your store orders**, **Compared `{start}` to `{end}`**, and **Days follow the GA4 property time zone (`{tz}`)**. If WISEPIM could not read the property time zone, days fall back to UTC and can be off by one at the edges. ## How the headline is measured Open **How we measure** under the headline to see the rules behind the percentage. * **Paid orders only.** Only orders your platform reports as completed or processing count. Pending orders are often unpaid and never reached the thank-you page, and refunded or cancelled orders are not sales. The UI puts it as: pending and refunded orders don't count. * **Net or gross basis.** Many shops send GA4 revenue without VAT and shipping. When at least 90% of the orders in the window carry a tax amount, WISEPIM compares GA4 with your order value excluding VAT and shipping, and the headline reads **GA4 tracks `{percent}` of your order revenue (excl. VAT and shipping)**. When your platform only reports totals, the comparison is gross and the headline says **(incl. VAT and shipping)**. On a gross basis the share reads lower than your real tracking, and the page says so. * **A minimum of 20 orders.** With fewer store orders in the window the page says **Not enough store orders yet to compare GA4 with your store** and leaves the headline blank. It never shows 0%. * **Same currency only.** When GA4 reports in one currency and your store sells in another, money is not compared. The page says so and compares the share of orders instead. * **Over-reporting is flagged too.** **GA4 reports `{amount}` more than your store took. That usually means a purchase tag fires twice.** The **Tracking score** weighs the checks below. Checks without enough data do not count toward it, and the score reads **Not enough data yet** until enough checks have run. ## The Checks tab The page opens on **Checks**. Each check has a status: **Passing**, **Needs attention**, **Broken** or **Not enough data**. Failing checks are listed first under **`{count}` checks need attention**, then **Passing (`{count}`)** and **Waiting for data (`{count}`)**. | Check | What it compares | | - | - | | **Revenue reaches GA4** | GA4 purchase revenue against your store orders, on the basis above. | | **Every order sends one purchase** | GA4 purchase events against your order count. More events than orders means some purchases are sent twice. | | **Purchases still arrive** | The date of the last GA4 purchase against the days your store kept selling after it. | | **GA4 products match your catalog** | The share of GA4 product views on products WISEPIM can link to your catalog. | | **The shopping funnel is complete** | Whether `view_item`, `add_to_cart`, `begin_checkout` and `purchase` all arrive, and whether each step is smaller than the one before. | | **Traffic has a source** | The share of sessions with no source. | | **Payment providers aren't credited as traffic** | Sessions and revenue GA4 credits to iDEAL, PayPal, Klarna and similar domains. | | **GA4 keeps data long enough** | The property's event data retention setting. | | **Purchase is a key event** | Whether `purchase` is a key event, and whether page-level events are wrongly marked as key events too. | | **GA4 uses your store currency** | The property currency against the currency your store sells in. | | **Refunds reach GA4** | GA4 refund events against the refunds your store processed. | Every check card follows the same structure: **1. Why it matters** One or two lines on what the problem does to your reports. For example, the revenue check warns that missing revenue makes every channel look worse than it is. **2. Evidence** The numbers behind the status, such as **GA4 recorded `{ga4}` against `{store}` in store orders (`{percent}`)** or **The last GA4 purchase was on `{date}`, but your store took `{orders}` orders on `{days}` days since then**. **3. How to fix** Expands to **Steps for `{platform}`**, written for your connected platform: Shopify, WooCommerce, Magento, Shopware, Lightspeed, CCV Shop, or generic steps for any shop. Checks that need code changes also show **Spec for your developer** with a **Copy** button, so you can paste the exact event and parameter requirements into a ticket. > [!NOTE] > > The configuration checks (retention, key events, currency) read the property settings from Google. When Google does not return them, the page says **Google didn't return the property settings, so the configuration checks are waiting for data.** and those checks sit under **Waiting for data**. ### GA4 vs store revenue per day Below the checks, a chart plots **GA4 revenue** and **Store revenue** for every day in the period. The gap between the lines is labelled **Not tracked by GA4**, and a summary line puts a number on it: **GA4 is missing about `{amount}` across `{days}` days** on a net basis, or **`{amount}` difference across `{days}` days, partly VAT and shipping** on a gross basis. Use it to date a problem: a gap that opens on one day usually matches a theme, plugin or checkout change. When the currency of the period is unknown or mixed, GA4 amounts are hidden and only counts are shown. ### Domains to add to GA4's unwanted referrals When the payment-provider check finds sessions credited to a payment domain, the card lists every domain under **Domains to add to GA4's unwanted referrals** with a **Copy list** button. In GA4, open **Admin**, your web data stream, **Configure tag settings**, then **List unwanted referrals**, and add each domain with the match type *Referral domain contains*. GA4 accepts up to 50 domains per web stream, and the change only affects new sessions. ## The Item Matching tab Switch to **Item Matching** to see how well GA4's product data lines up with your catalog. This matching powers the product funnel, the [Fix these first worklist](https://docs.wisepim.com/en/analytics/product-performance.md) and Content Impact. Three metrics sit at the top: **Product views matched**, **Revenue matched** and **GA4 product IDs matched**, each shown as a share of the total, for example **`{matched}` of `{total}` product views**. WISEPIM matches GA4 products to your catalog by SKU, variant SKU, GTIN or shop product ID. The table of **GA4 products** lists each GA4 `item_id` with its **Match** state (**Matched**, **Not matched** or **More than one match**), the method used (**Linked by hand**, **By SKU**, **By variant SKU**, **By GTIN**, **By shop variant ID**, **By shop product ID**), its **Product views**, **Units sold** and **Product revenue**. Unmatched rows carry a reason, such as **No SKU, GTIN or shop ID matches** or **Matches more than one product**. **1. Link a product** Click **Link product** on an unmatched row, search by SKU or product name, pick the catalog product and click **Save link**. Links apply to WISEPIM's reports only; GA4 stays as it is. **2. Change or remove a link** On a matched row, **Change match** picks a different product. **Remove link** drops a manual link, and automatic matching by SKU, GTIN or shop ID applies again. > [!NOTE] > > Only members who manage analytics and integrations can change matches. Everyone else sees the table read-only. If GA4 reported more than one currency in the period, revenue is hidden until the next GA4 sync. ## Act on what you find > **The headline is well under 100% and the daily chart shows a steady gap** > > A constant gap on a net basis points at orders that never send a purchase: a cookie banner without Consent Mode, a payment method whose return page skips the thank-you page, or a second tracking tool that overwrites the first. Open **Revenue reaches GA4**, follow **Steps for `{platform}`**, then place a test order and watch GA4 DebugView for one purchase. **Outcome:** the channel reports in Analytics stop under-crediting the sources that actually sell. > **GA4 reports more than your store took** > > Two senders are firing purchase, or the confirmation page re-sends it on reload. **Every order sends one purchase** names the ratio. Keep one sender (on Shopify, the Google & YouTube app) and remove the other. **Outcome:** conversion rate and average order value in GA4 stop being inflated. > **Purchases stopped arriving on a specific date** > > **Purchases still arrive** gives you the date of the last GA4 purchase. Think back to what changed that day: a theme update, a new checkout, a consent change. On Shopify, scripts on the old thank-you page stop working after a move to the new checkout and must become a customer events pixel. **Outcome:** the tag is fixed before the gap grows into a month of missing data. > **GA4 products match your catalog is failing** > > Open **Spec for your developer** on the check, copy it, and ask for a stable `item_id` (SKU, GTIN or shop variant ID) in every ecommerce event. Meanwhile, click **Match unmatched products** and link the biggest unmatched IDs by hand on the Item Matching tab. **Outcome:** product reports and the worklist cover the products that matter most while the tag is being fixed. > **Payment providers appear as a traffic source** > > Copy the domain list and add it to GA4's unwanted referrals. Until you do, sales from shoppers who paid through iDEAL or PayPal are credited to the payment provider, and every real channel looks weaker. **Outcome:** channel reports credit the campaigns and search terms that did the work. > **Refunds reach GA4 is failing** > > Most platform integrations send purchases but not refunds. Ask your developer to send refunds through the GA4 Measurement Protocol with the original `transaction_id`. Refunds cannot be added afterwards, so set it up before the next one. **Outcome:** returns-heavy products stop looking better in GA4 than they are. ## Related > **[Google Analytics 4 Integration](https://docs.wisepim.com/en/integrations/google-analytics.md)** > > Connect a GA4 property and learn which events and parameters WISEPIM expects. > **[Conversions](https://docs.wisepim.com/en/analytics/conversions.md)** > > The GA4 event funnel that these checks keep honest. > **[Product Performance](https://docs.wisepim.com/en/analytics/product-performance.md)** > > Product views, add-to-cart rates and the Fix these first worklist built on matched GA4 products. > **[Traffic & Behavior](https://docs.wisepim.com/en/analytics/traffic-behavior.md)** > > Sessions by source, device and country, with the same GA4 trust chip. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.