Why your channel report lies

The channel report looks like the simplest table in analytics. Ten rows, one number each, the total matching your overall traffic. It looks like something the tool simply knows. It does not know. Every one of those rows is a conclusion drawn from three unreliable premises, and the order in which the tool checks them decides the answer more than the data does.

What follows are three cases from production. Not from documentation, not from a textbook example: from a panel we built ourselves, where we found these defects by looking at our own traffic. Each of them comes from the same mistake, seen from a different angle.

What the browser actually tells you

When somebody lands on your site, the browser brings at most three things from which origin can be inferred.

1. The referrer (the Referer header): the address of the page the click came from. The browser supplies it; nobody types it in.
2. A click parameter in the URL: gclid from Google Ads, fbclid from Meta, msclkid from Microsoft, a bespoke parameter from every affiliate network. The network appends it during the redirect.
3. Manual tags, the UTM parameters: utm_source, utm_medium, utm_campaign. A human types these while building a link.

Three sources, three levels of trustworthiness, and three different ways of disappearing or lying. Channel grouping rules are nothing more than a fixed order for checking those three things. Change the order and the same traffic lands in a different row.

Case one: the affiliate channel that did not exist

The report showed twelve visits from one affiliate network's domain and two from its publisher panel, both under Referral. There was no Affiliate row in the table at all. Not because there was no affiliate traffic, but because nobody recognised it.

The publisher had placed an ordinary link to the network domain, the network redirected to the shop, and nothing was appended along the way: no parameter, no UTM. From the landing site's point of view this is a visit with a referrer on the network's own domain and nothing else. A rule looking for utm_medium=affiliate had nothing to find.

This is not a quirk of our tool. The default channel group in Google Analytics 4 defines Affiliates with a single rule: Medium = affiliate. Exact match, one field, no fallback. If the publisher wrote affiliate-pl, afiliacja, or nothing at all, affiliate traffic will not reach the affiliate channel. It lands in referrals and blends in with visits from blogs and forums.

The fix is a fourth way of recognising the channel: a list of the domains networks route clicks through. Every network has its own, usually short and unchanged for years, and publishes it in its documentation for publishers. A referrer from one of those is sufficient evidence on its own, with no parameter needed. After adding that list to our panel, the Affiliate channel stopped being empty and Referral dropped from nine visits to two.

Case two: paid search nobody bought

A second view, same panel: the Paid Search channel, containing two visits carrying an affiliate network's name and two from fb. Nobody had bought search advertising from an affiliate network or from Facebook. Both numbers were wrong and both had the same cause.

The affiliate publisher had tagged the link utm_medium=cpc, because from where they sit that is paid traffic. The rule checking medium sat above the rule checking source, so medium won and the traffic fell into search. Same story with the Facebook ad: utm_source=fb, utm_medium=cpc. Medium says "paid", so the tool still has to guess where, and if it only inspects the referrer rather than the UTM source, the abbreviation fb means nothing to it and search is the default guess.

It is worth seeing how GA4 handles the same problem. Its Paid Search rule reads: source matches a list of search sites **and** medium matches `^(.*cp.*|ppc|retargeting|paid.*)$`. A conjunction, not medium alone. The matching Paid Social rule requires a source from a list of social sites. That is the right shape, and it is exactly what we were missing: medium alone can never name a channel, because it describes how the traffic is billed, not where it came from.

There is a second half that a list of search domains does not solve. People do not type domain names into utm_source. They type fb, ig, yt, li, tt. A list that knows facebook.com but not fb will misfile half of the real campaigns.

Case three: ChatGPT filed as direct traffic

The third defect was the most interesting, because it concerns a channel that did not exist five years ago. The report showed a Direct row and, expanding it, ChatGPT sat there alongside the genuinely sourceless visits. The AI Tools channel existed in the panel and was empty.

The reason is that ChatGPT sends visitors without a referrer but appends utm_source=chatgpt.com to the URL. Our channel was read from the referrer alone. No referrer, therefore "direct", and "direct" is supposed to mean somebody typed the address from memory or clicked a bookmark. This is not a naming quibble. Direct is the one channel people describe as "nothing to be done here", so putting anything else in it ends the analysis before it starts.

Why the referrer keeps getting weaker

What binds all three cases is that the referrer let us down. That is not bad luck; it is the direction browsers have been moving for years.

Since version 85, shipped in August 2020, Chrome defaults to the `strict-origin-when-cross-origin` referrer policy. Previously a cross-origin navigation sent the full URL with path and query; now it sends the origin only. https://example.com/article/best-tools?ref=newsletter becomes https://example.com/. Safari went further: in March 2020 it blocked all third-party cookies and downgraded cross-site `document.referrer` to its origin.

The practical consequence: a sources report that once named the specific article sending you traffic now names the domain. And that is the mild case. Mobile apps, messengers and AI assistants frequently send no referrer at all, so a visit from a WhatsApp conversation and a visit from a typed address look identical.

An order that works

The conclusion from all three cases is the same: channel grouping is not a set of rules, it is their order. The rules themselves are similar in every tool. The difference is which one runs first, because the first match wins and no later rule gets a vote.

The principle we settled on: evidence of origin beats a manual label. A click parameter is appended by the network and never seen by a human. A redirect domain is chosen by the network. A UTM tag is typed by a person into a text field, in a hurry, according to their own habit. The checking order should run from the things nobody transcribed by hand toward the things somebody typed.

After reordering, on our own production data: Affiliate went from zero to 714 visits across five networks, Paid Search fell from 788 to 713, Paid Social rose from 229 to 304. Facebook stopped being two rows of 380 and 164 visits and became one row of 544.

Classify on read, not on write

There is one more decision, technical but with large consequences for how much you can trust the report. The channel can be computed at two moments: when the event is stored, or when the report is read.

If the channel is written alongside the event, every correction works forward only. Adding Perplexity to the AI list fixes tomorrow's traffic and leaves yesterday's alone. The report splits into "before the fix" and "after the fix", and year-on-year comparison stops meaning anything. If the channel is computed on read from the raw columns, the same correction repairs the whole history.

The cost is real: the query does more work every time a report opens. But it is the right cost to pay, because the list of AI tools, affiliate networks and the abbreviations people type into UTM fields changes several times a year and will never be complete.

What to do about it

• Agree one UTM vocabulary and hold to it. Not because the tool demands it, but because newsletter, Newsletter and mailing are three channels in the report and none of them carries the real number.
• Do not set `utm_medium=cpc` on affiliate links. That field describes billing, not place, and in every tool it will push the traffic into paid search.
• Ask your affiliate networks for their redirect domains and check whether your tool knows them. It is the only signal that survives missing parameters and missing UTMs.
• Test channels with conflicting examples, not agreeing ones. Consistent data is classified correctly even by a wrong ordering. Only a URL carrying two contradictory signals at once reveals which rule sits on top.
• Treat rising direct traffic as a symptom, not a result. Growing direct almost always means some real source stopped being recognised.

A channel report will never be accurate to the visit, because the material it is built from is incomplete by design and getting more so. It can, however, be honest: putting traffic where the strongest available evidence points, and refusing to fake knowledge it does not have. The distance between those two reports is a handful of rules in the right order.