Search, social and native traffic: how routing signals differ

Why source type matters more than the platform name

Organising routing configuration by platform is the common approach and the one that most often goes wrong. The reason: platform differences concentrate in policy wording and review cadence, whereas what a request actually looks like when it reaches your server is determined by the technical shape of the source. A request from a YouTube card and a request from a Snapchat ad resemble each other, at the HTTP level, far more than either resembles a click on a Google search ad.

A more useful taxonomy has three buckets: search (Google, Microsoft Advertising), social and video (Meta, TikTok, YouTube, Snapchat, Pinterest), and native and display (content recommendation networks, DSP display inventory). Platforms inside one bucket can share signal assumptions; across buckets they cannot. Policy wording differences at the platform level are compared separately in the ad platform landing-page policy comparison.

Search traffic: the richest signals, the most continuous scrutiny

Requests from search almost always originate in a real desktop or mobile browser: a standard user agent, a present and readable referrer, a complete cookie and JavaScript environment, and a TLS fingerprint that sits inside common distributions. Any judgement based on "does this request look like a real browser" therefore reaches its highest confidence on search traffic.

The cost is scrutiny. A search ad destination is simultaneously exposed to three kinds of automated access: the ad system's landing-page fetch, the search engine's organic crawl, and assorted third-party monitors. What all three read has to match what a real user sees — a mismatch is a landing-page policy problem, not a technical one. How search engines frame that judgement is set out in cloaking in an SEO context.

Two practical points. First, the search-source pass rate is normally the highest of the three, because the noise share is low — if your search segment drops noticeably below its own history, suspect over-blocking before suspecting traffic quality. Second, do not handle the search segment by blocking crawlers: that damages organic indexing and ad review at the same time.

Social and video traffic: WebViews, stripped referrers and prefetches

This is the technically messiest bucket and, for most advertisers, the highest-volume one. The typical request comes from an in-app browser (a WebView) rather than the system default browser, which produces three structural differences.

First, the referrer is often stripped entirely or replaced by the platform's own intermediary domain, so "is the referrer trustworthy" — a strong signal on search — carries almost no information here. Second, the user agent contains platform-specific markers and does not follow the standard format; if your rule set treats non-standard user agents as suspicious, the whole social segment gets caught. Third, platforms fetch the destination URL at several points — ad review, card preview generation, link safety scanning — from their own infrastructure, and none of those fetches represents a real user. The WebView and referrer details are covered separately in mobile WebView and referrer behaviour.

The platforms inside this bucket still differ from each other: short-video feed clicks complete almost entirely inside the WebView, while image and discovery placements bounce out to the system browser more often. Platform-specific behaviour and policy wording are covered in the individual articles on TikTok, YouTube, Snapchat, Pinterest and Facebook.

Native and display traffic: an extra hop, the weakest signals

Native ads (content recommendation networks) and programmatic display requests usually pass through one or two intermediary domains before reaching you — the network's own click tracker, sometimes plus a DSP redirect. Each hop erodes the original signal: the referrer becomes the intermediary domain, query parameters get rewritten, and timestamps drift from the real click.

This bucket also carries a structurally higher share of automated traffic: display inventory mixes in a substantial volume of non-human requests, which is an accepted industry baseline rather than one network's failing. Identifying it relies on landing-page behavioural signals rather than request headers, as described in bot traffic detection. Native placement characteristics specifically are covered in native advertising scenarios.

There is also a content-side difference that gets overlooked: intent on native traffic is shaped by an editorial-style recommendation unit, not by a query or a video. The user arrives expecting to keep reading, not to buy immediately. A safe page built like a search-intent page — product claims stacked at the top — produces a poor bounce rate, and that bounce rate feeds back into how the network distributes you.

Side-by-side comparison

Pass rates and monitoring: read them per source

All of the above collapses into one operational conclusion: a single global pass-rate threshold is meaningless. Mixed together, the three sources produce an average dragged down by the weakest — too strict for search (real users caught) and too loose for native (noise let through). Build a baseline per source, set thresholds per source, and judge anomalies against that source's own history rather than an account-wide mean.

What too-strict and too-loose thresholds each leave behind in the data, and how to tell them apart, is worked through in tuning the pass rate; which dashboard metrics matter overall is in reading traffic routing analytics.

Once split by source, three monitoring habits hold across all three buckets:

• Track a 7-day and 28-day pass-rate baseline per source, and alert only on deviation from that source's own line.
• Classify platform-infrastructure fetches (review, preview, safety scans) as their own category rather than folding them into the real-user pass rate.
• Increase monitoring frequency for 48 hours after a creative or placement change — social and video re-checks usually trigger inside that window.

Three recurring cross-source mistakes

First, copying a rule set validated on search onto a newly opened social channel, then explaining the low pass rate as "the new channel underperforms". The real cause is usually a broken referrer assumption.

Second, counting platform review fetches inside the pass-rate denominator. That makes the number wobble inexplicably at every submission and every scale-up, which in turn triggers an unnecessary rule change.

Third, serving one identical safe page to all three sources. The structure can be shared — real content, working navigation, honest claims are identical requirements everywhere — but the framing should not be. Search visitors are looking for an answer, social visitors are continuing an expectation set by a creative, native visitors are reading. How to construct the page itself is covered in safe page versus real page structure.

FAQ