Tracking | SEO and attribution
Verified
In short
Section titled “In short”Analytics → Tracking | SEO answers the question Reports cannot: how much you can trust those numbers.
Reports tell you how much was sold. Tracking | SEO tells you how much of it analytics saw and where it came from. Two different questions, so two screens. The period, the shop and the VAT basis are shared — switching between Reports and Tracking | SEO changes nothing.
The screen has four tabs:
| Tab | What it answers |
|---|---|
| Overview | How many orders and how much revenue measurement captured. |
| Channels and attribution | Where the orders came from. |
| SEO | How search engines see you. |
| Orders | The order-by-order breakdown. |
Two truths that must never be mixed
Section titled “Two truths that must never be mixed”This is the most important distinction in the whole Analytics section.
- Commerce truth is what was actually sold. It comes from e-shop orders. Revenue, order counts and every financial figure are calculated from it.
- Analytics truth is what browser measurement captured. It is always smaller — some visitors decline measurement, some block it, and some orders never happen on the web at all.
MitoOps never passes analytics truth off as commerce truth. Revenue in a report is always real revenue, even when analytics knows nothing about part of the orders.
Overview
Section titled “Overview”Order coverage and revenue coverage
Section titled “Order coverage and revenue coverage”Two numbers that say how much of the measurement works:
- Order coverage — of the orders where a browser trace can legitimately be expected, how many analytics actually recorded a transaction for.
- Revenue coverage — how much of those same orders’ revenue it captured.
Both are shown with the exact figures (“82 of 115”, “€8,389 of €10,851”), not just a percentage.
What coverage does not count
Section titled “What coverage does not count”Only orders where a browser trace is legitimately expected go into the denominator. A manually created order was never shown to the customer, so no trace could exist — that is not missing measurement and it does not lower coverage.
Orders younger than 48 hours are excluded too: analytics backfills data, and a fresh order may still arrive.
Shop comparison
Section titled “Shop comparison”Every connected shop gets its own row with coverage and measurement status. The status is in plain words, not technical:
| Status | What it means |
|---|---|
| Good coverage | Measurement captures the large majority of orders. |
| Watch | Coverage dropped, but there is no reason to act yet. |
| Insufficient measurement | A substantial part is missing. Channel figures for this shop are incomplete. |
| No data | Nothing to calculate from for this period. |
The thresholds are shared across the application, not set per table.
Trend over time
Section titled “Trend over time”A chart of order and revenue coverage by day. A missing historical snapshot is not drawn as zero — a day without a snapshot simply is not in the chart. Zero would claim that measurement captured nothing that day, which is a different statement from “we were not measuring yet”.
When the data was last pulled
Section titled “When the data was last pulled”Above the figures is a Last sync line with a time for shop orders, GA4 and GSC. It serves one purpose: telling “measurement did not capture the order” apart from “analytics has not been pulled yet”. The first is a finding, the second only a delay — and without this line the second is easily read as the first, sending you to look for a fault that is not there. A source that has never been pulled is labelled as such.
Warning about a sharp drop in coverage
Section titled “Warning about a sharp drop in coverage”When coverage for the latest period drops sharply against the usual level, a warning appears above the figures with both values. This is not an application fault: the figures below it are correct and come from shop orders. Fewer of them were captured by measurement, so the channel breakdown is less complete for this period. Usual causes are a measurement outage, a change in cookie consent, or an interrupted import.
The comparison uses the median of previous periods, not the average — a single bad week would drag the average down far enough that the next outage would no longer trigger the warning. Periods with few orders are left out of the comparison: the last day is usually incomplete, and a single uncaptured order out of one would otherwise report an outage every day.
Channels and attribution
Section titled “Channels and attribution”Four layers
Section titled “Four layers”Every order belongs to exactly one layer. Their sum is always the entire commerce result.
| Layer | When an order belongs there |
|---|---|
| Captured in analytics | Analytics knows the transaction. The channel comes from it. |
| Attributed by MitoOps | Analytics has no transaction, but there is unambiguous evidence — a partner coupon or a campaign code registered in the code registry. |
| Needs review | A signal exists, but it is not unambiguous. |
| Unattributed | We have no evidence about the order’s origin. |
Why nothing is estimated
Section titled “Why nothing is estimated”Missing orders are never distributed across existing channels proportionally. It would look more precise and it would be made up: if a measurement outage hit exactly one channel — which happens routinely after a change to the website — proportional distribution would smear it across all of them and hide precisely what should be visible.
An unattributed order is the correct result, not an error. The point of Tracking is not to claim we know everything, but to separate exactly what we know from what we do not.
When MitoOps attributes an order itself
Section titled “When MitoOps attributes an order itself”Only when it has unambiguous structured evidence and analytics has no transaction. The order of precedence is fixed:
- Analytics knows the transaction → the channel is its own. Even when it cannot name the channel — that is Captured, channel unknown. A coupon on such an order does not override it; otherwise the same order would count twice under two different origins.
- Analytics has no transaction and the order carries a partner coupon → Affiliate · partner name · code.
- Analytics has no transaction and the order carries a campaign code → Campaign · name · code.
- The code is unknown, or the order carries two different codes → Needs review.
- No evidence → Unattributed.
A discount code does not automatically mean affiliate. What is recorded about the code decides, not what its name looks like.
Internal notes are never parsed
Section titled “Internal notes are never parsed”An order note is free text written by a person. MitoOps never derives attribution from it — matching a name with a regular expression is guessing with a straight face. A note may help an administrator decide manually; it never enters a report as an attribution source.
Discount codes
Section titled “Discount codes”The Discount codes table lists every code that appeared on orders in the period — classified and unclassified alike. Tabs above the table switch between All, Unassigned and Assigned, and the search box finds a code by its name or by its classification. A code you classify therefore does not disappear from the screen and can be traced back at any time.
You can choose:
- Affiliate — a partner’s code,
- Campaign — a marketing promotion,
- Internal — your own operational code, not a marketing channel,
- Ignore — a deliberate decision not to attribute it.
Until a decision is made, orders with such a code get their own row Discount code · … flagged Unclassified — the revenue and counts are real, only the classification is missing. The system may suggest a classification, but a suggestion never becomes a rule on its own.
Two columns that must not be confused
Section titled “Two columns that must not be confused”Each code carries two different numbers:
| Column | What it means |
|---|---|
| Orders with the code | How many orders carried that code. |
| Attributed | How many of them MitoOps actually assigned by it. |
They differ because analytics takes precedence. An order analytics saw is attributed by analytics based on the visit source — even if a coupon was on it. Otherwise the same order would be counted twice.
A real example: the code GROUNDING20 was on 5 orders of one shop, but only 1 was attributed by it — analytics already knew the other 4.
When one order carries several codes, only the code that won the attribution counts it. Otherwise both would claim to have brought it.
Your own attribution category
Section titled “Your own attribution category”The five classes above are a structure, not a list of how you tell your own sources apart. If you run a newsletter, a popup and remarketing, all three end up under one name.
The dialog opens immediately when you pick the option — nothing has to be confirmed separately. If you close it without creating anything, the selector returns to its previous classification.
The classification picker therefore offers + Custom category…. It opens a small dialog with a name and an optional colour; once saved, the category appears in the picker for every discount code, and the code you created it from is classified into it right away. In the report it gets the row category name · code.
A category applies to the whole account and the classification is retroactive: a report for an older month renders with the same breakdown, because the classification lives in the code registry, not in the orders. Renaming a category therefore also changes older reports — the name is never copied anywhere.
You can rename it where you pick it: the classification dropdown has a Manage custom categories option (shown only when you have at least one). It opens a window with the list; each row has Edit, which swaps the name for an input. The new name applies retroactively to the whole period — orders and revenue stay unchanged, and the raw analytics data (source, medium, referrer) is not touched at all. Two identical names are rejected: the report would show two rows nobody could tell apart.
A category you stop using can be archived (it disappears from the picker). It cannot be deleted while a code is classified into it — otherwise an old report could no longer say what the order was classified as.
Coupons issued to partners through the Affiliate module never appear here — they are classified by the fact that they exist.
Visits are never invented
Section titled “Visits are never invented”For a channel that came from an internal attribution signal, analytics recorded no visit. The Visits column therefore shows a dash, not a zero. Zero would claim nobody came.
AI and language models
Section titled “AI and language models”Traffic from AI search tools (ChatGPT, Claude, Perplexity, Gemini, Copilot, Grok) has its own rows and a shared subtotal row. The subtotal is not counted into the totals a second time — it summarises the rows above it, it is not another channel.
Search Console data: clicks, impressions, CTR and average position — overall, per shop, and broken down by query, page, country or device.
Until 22 Aug 2026 this lived in the Reports Overview. It moved here because it is measurement, not a financial result.
Orders
Section titled “Orders”The order-by-order breakdown: order number, shop, date, amount, status, and whether analytics captured it.
No customer data. The table holds no name, e-mail, phone or address — attribution does not need them and the reporting tables do not store them.
The statuses are unchanged: Captured, Sent by server, Missing in analytics, Tracking not expected, Waiting for data, Unknown status. When judging coverage, look at Missing in analytics — the others lower it legitimately.
The Attribution column
Section titled “The Attribution column”Every order shows where the report placed it: an analytics channel (Organic, Direct, Paid Google…), an internal signal (Affiliate · name · code, Campaign · name · code, custom category name · code), Discount code · … for an unclassified code, Needs review for a conflict, or Unattributed.
Below the value sits a source badge: GA4 when analytics decided the classification, the application name when an internal signal did, or no source when there is none. The column used to be called MitoOps assignment even though analytics channels appeared in it — the name claimed something the content did not support.
Searching the list
Section titled “Searching the list”The box above the table searches by order number, discount code and attribution name (channels included). Type GROUNDING20, Newsletter or Direct and the list narrows to the matching orders in the selected period.
It does not search by customer name, e-mail, phone or address, and the screen does not display them — finding a specific person belongs in Orders, not in measurement.
It is a derived value. The order in the e-shop is not modified and nothing is written back to analytics — it is derived by the same logic that produces the totals in the report, so the list and the totals can never say two different things.
An affiliate partner’s name is personal data. Someone with Tracking access but no Affiliate permission sees the classification without the name; the code stays, so the order can still be traced. Warehouse and support roles cannot reach the list at all.
Who gets access
Section titled “Who gets access”Tracking | SEO is tied to the Tracking and attribution permission, which is separate from the Reports permission and from Company costs.
That makes it possible to build a role that sees channels, attribution and SEO but not gross profit, purchase prices or company costs. Configure it in Settings → Users.
Common problems
Section titled “Common problems”- Coverage is low. Check how much of it is Missing in analytics. Manual and fresh orders lower coverage legitimately.
- Many orders are Unattributed. It means we have no evidence about their origin. Better measurement coverage or classifying the discount codes you use will help.
- A partner reports more orders than the report shows. The affiliate statement and the channel report answer different questions. When analytics knows the transaction, the channel is its own — the partner may still be entitled to commission, but no second sale appears in the report.
- A channel has no visits. Channels derived from an internal attribution signal have no recorded visit. The dash is the correct answer.
- The trend chart is empty. There are no historical snapshots for the period yet. They are created daily.