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.
Order, overlap, and gaps
Channel rules are evaluated in order, and the first match wins. If two rules can both match a session, the one placed earlier classifies it — so a broad rule near the top can swallow traffic a more specific rule was meant to catch. Conversely, if no rule matches, the session falls into 'Unassigned', a sign your rules have a gap.
The most common defect is a rule set that is neither exhaustive nor mutually exclusive: some traffic is double-eligible and some is uncovered.
- First-match-wins: rule order changes classification
- Unmatched sessions fall to 'Unassigned'
- Broad rules placed early swallow specific traffic
Retroactivity and validation
Whether a custom grouping applies to historical data or only going forward depends on the platform and the grouping type; some custom groupings reclassify history while others do not, creating a seam. Confirm before relying on a long-run trend.
Validate by checking the size of 'Unassigned', spot-checking sessions in each channel against their raw source/medium, and ordering specific rules above general ones. Re-audit whenever you add a marketing source.
How it appears in analytics and logs
A large 'Unassigned' channel or traffic in an unexpected channel usually means custom rules have a gap or an ordering conflict.
Diagnostic use case
Build and audit a custom channel grouping that has no gaps or overlaps, so every session lands in the intended channel rather than Unassigned.
What WebmasterID can help detect
WebmasterID retains raw source and medium per session, so you can validate a custom grouping against the underlying values it classifies.
Common mistakes
- Placing a broad rule above a specific one and mis-bucketing traffic.
- Leaving gaps so sessions fall into Unassigned.
- Assuming a custom grouping reclassifies all history.
Privacy and accuracy notes
Channel rules operate on source, medium, and campaign metadata, not on visitor identity. They carry no privacy implication.
Related pages
- 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.
- (not set) and Unassigned values
GA4 shows `(not set)` when no value was collected for a dimension at the time data was recorded, and `Unassigned` when traffic could not be matched to any defined channel group. These are not errors so much as honest placeholders — but each has distinct, documented causes worth diagnosing rather than ignoring. This page separates the placeholders and what produces them.
- 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.
- Attribution analytics
Validate groupings against raw source and medium.
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.