Channel grouping rule changes
Default channel groupings are sets of rules that map sources and mediums to channels like Organic, Paid, and Referral. When a platform revises those rules — adding a channel, retiring one, or changing how a source is classified — traffic moves between channels and historical trends appear to jump. This page explains how channel-rule changes reshape reports and how to read a channel trend across a definition change.
Channels are rules, not raw data
A channel grouping is a rule set applied to the underlying source, medium, and campaign of each session. 'Organic Social', 'Paid Search', 'Referral' and the rest are defined by patterns, and platforms update those patterns over time — for example splitting social into organic and paid, or reclassifying a category like Shopping.
When the definition changes, the same raw traffic maps to different channels, so a channel line can jump on the date the new rules took effect.
- Channels map raw source/medium via documented rules
- Platforms revise the default rule set over time
- Same raw traffic can land in a different channel after a change
Reading trends across a change
Whether a change applies retroactively or only going forward determines what your trend looks like: a forward-only change creates a visible seam, while a retroactive redefinition reshapes history without a seam but still moves volume between channels. Always check the platform's change log when a channel jumps on a specific date.
For stable long-run analysis, anchor on raw source/medium or a custom grouping you control rather than a default that can shift underneath you.
How it appears in analytics and logs
A channel that suddenly gains or loses volume on a specific date, with the offset appearing in another channel, usually reflects a channel-definition change.
Diagnostic use case
Recognise a step change in a channel report as a rule update, and interpret channel trends correctly across a default-grouping revision.
What WebmasterID can help detect
WebmasterID records the raw source and referrer of each session, so you can reclassify consistently rather than being subject to a shifting default grouping.
Common mistakes
- Reading a channel-definition change as a real traffic shift.
- Comparing channel volume across a default-grouping revision.
- Ignoring the platform change log when a channel jumps.
Privacy and accuracy notes
Channel grouping classifies source/medium metadata, not individuals. Rule changes carry no privacy implication.
Related pages
- Custom channel grouping pitfalls
Building a custom channel grouping gives you control, but it also introduces failure modes: rules that overlap so order decides classification, sessions that match nothing and fall to 'Unassigned', and changes that may not apply to history. This page covers the pitfalls of custom channel groupings and how to build one that classifies traffic cleanly and consistently.
- Social vs referral misclassification
Traffic from social platforms should appear in a social channel, but it often lands in Referral instead. The cause is classification: analytics recognises social by matching the referrer against a known list, and app clients, short-link domains, and new platforms may not match. The result understates social and inflates referral. This page explains the misclassification and how to correct channel attribution.
- Direct traffic as a catch-all bucket
Direct traffic is often misread as 'people who typed the URL'. In practice it is a catch-all for any session with no usable referrer or campaign: untagged links, stripped referrers, app and messaging clicks, and redirects that lose data. When other attribution fails, direct swells. This page explains what really lands in the direct bucket and how to shrink it.
- Attribution analytics
Anchor on raw source/medium across grouping changes.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.