Not all TwinRed traffic is equal. ValidVisit scores every visit 0–100 and pins it to the exact placement that sent it — so you can tell real humans from bots and invalid clicks, worst placements first.
site / traffic source in TwinRedThe buyer opens Site Targeting, reviews the list of all eligible sites/traffic sources (TwinRed is transparent, all sources visible), and toggles each bad site to Block (or blocks all and allows only a whitelist) at campaign, placement, or account level.
ValidVisit reports the device, OS, browser — down to the version — plus the language and ISP behind every flagged visit, and TwinRed supports OS, browser, language, device type and connection type targeting. The segments we flag are segments you can exclude.
TwinRed sells display, pop and push inventory across a supply chain it exposes unusually openly: every eligible site and traffic source is visible in the advertiser portal, and each click carries a {sspId} for the supply partner behind it, a {sourceSite} for the specific placement, and a {transactionId} that identifies the click itself. That transparency is a real advantage, because it means a quality problem can be named precisely rather than guessed at — but it only pays off if you can tell which of those visible sources are actually sending people. Pop and push formats generate clicks with no deliberate intent behind them by design, which makes the usual engagement heuristics close to useless: a short session on a pop placement is normal, not suspicious. ValidVisit scores each visit against 100+ independent data points covering the network the click arrived from, the device behind it, and how the session behaves on the page, resolving to one 0–100 quality score per visit. That per-visit score is what lets you separate a low-intent-but-real pop visitor from an automated one — a distinction that decides whether a {sourceSite} belongs on a blocklist or simply deserves a lower bid.
The invalid-traffic patterns on TwinRed follow the formats it sells. On pop and push inventory the leading issue is automation dressed as a real browser: click volume generated by tooling and stripped-down browser builds whose connection characteristics, device profile and on-page activity fail to agree with the operating system and browser the session claims. Pop traffic already arrives through an extra hop before landing on your page, and the longer that path, the more places an inconsistency has to show itself — which is precisely why signals drawn from the network side and the on-page side together read this traffic far more reliably than either does alone.
On display inventory the more common pattern is supply-side inflation: a partner acquires visitors cheaply, builds impression volume on its own pages, and a share of the resulting clicks come from sessions with no interest in the offer. Because those sessions run in a genuine browser on a genuine URL, address-based filtering alone tends to miss them. ValidVisit reads the network origin of each click as part of its score, and that is where this pattern shows: partners running it commonly route through residential proxy pools to disguise a datacenter origin, and the routing marks the wider signal set before any one filter reacts.
A third pattern worth naming is uneven quality inside a single {sspId}. Because TwinRed exposes both the supply partner and the individual placement, you frequently find a partner whose aggregate numbers look acceptable while one or two {sourceSite} values inside it carry nearly all the invalid volume. Scoring at the placement level rather than the partner level is what keeps you from blocking an entire supply source over a problem confined to a couple of its zones.
{sourceSite} within one {sspId}Group your ValidVisit report by {sspId}, then break each partner down by {sourceSite}. A supply partner whose overall score looks tolerable but whose volume is concentrated in a handful of very weak placements is the single most common shape here — and it is the one that argues for zone-level blocking in Placement settings rather than dropping the partner entirely.
Do not compare pop or push placements against display baselines. Interruptive formats produce shallow sessions from real people as a matter of course, so a low engagement figure is not evidence of automation on its own. Read the quality score, which already accounts for the network and device signals, rather than session depth in isolation.
For each weak {sourceSite}, check whether the poor scores trace mainly to where the clicks came from. A placement whose invalid share sits almost entirely in its traffic origin is showing a structural sourcing problem and belongs on the block list. One whose weakness appears mostly in on-page behaviour may be a smaller automated operation that a lower bid can absorb.
TwinRed reports the OS and browser family behind each click. A {sourceSite} whose declared device mix disagrees with how those visits actually behave on the page — a stated mobile population that never touches the screen, for instance — is a readable signal rather than an inference, and it is one of the faster ways to spot a zone worth blocking.
TwinRed itself isn’t the problem — bots and invalid traffic concentrate in a handful of its sub-sources: the publisher, site or zone, and the placement or widget within it. So we roll the score up by those TwinRed tokens, not by creative (which says nothing about whether a click was human).
Bought as one TwinRed line, a buy reads as a single number. Scored per sub-source, a spread like this illustration runs from 85 down to 29 — the worst is nearly all bots. That’s the leak a blended average hides.
Illustrative: TwinRed traffic scored 0–100 per sub-source, worst first — down to the placement you buy.
Bot / invalid-traffic score broken down by:
{sspId}Bot / invalid-traffic score broken down by:
{sourceSite}Per-click id: TwinRed passes a unique click id, so we also run velocity, deduplication and repeat-source checks on every visit.
Compare bot & invalid-traffic breakdown across every ad network →See your own TwinRed sub-sources scored this way.
Each TwinRed macro maps to a normalized parameter, so every scored click is pinned to the right campaign, creative and publisher.
https://yoursite.com/landing?utm_source=twinred&utm_medium=banner&vv_click_id={transactionId}&vv_campaign_id={campaignId}&vv_campaign_name={campaignName}&vv_publisher_id={sspId}&vv_placement_id={sourceSite}&vv_ad_id={adId}| Token | TwinRed macro | Maps to | Identifies |
|---|---|---|---|
| Transaction ID | {transactionId} | click_id | click |
| Campaign ID | {campaignId} | campaign_id | campaign |
| Campaign Name | {campaignName} | campaign_name | campaign |
| SSP ID | {sspId} | publisher_id | publisher |
| Source Site | {sourceSite} | placement_id | placement |
| Ad ID | {adId} | ad_id | ad |
{transactionId}{campaignId}{campaignName}{sspId}{sourceSite}{adId}Every visit is weighed against more than a hundred independent data points and reduced to a single, sortable 0–100 quality score.
Each data point is combined rather than checked in isolation, so a genuine human almost never trips enough of them to be flagged — and bots that beat one rarely beat the rest.
The detection model is ours and stays that way. What you get is a clear verdict on every visit — not a single brittle rule you can game, and not an unexplained number you can’t act on.
Every verdict maps to the campaign, publisher and placement that sent the click — so you know exactly which source to cut.
Scoring and attribution are the means — the point is cutting the TwinRed traffic that wastes your spend. Here’s how ValidVisit gets you a list you can act on.
You buy TwinRed clicks; what arrives are visits. ValidVisit scores each one 0–100 so real humans stand out from bots and invalid traffic — one script, no funnel hop, no fingerprinting.
Every scored visit is tied to the exact TwinRed site / traffic source and zone via the network’s own tokens — so the bad traffic has an address, not just a headline percentage.
You get the worst offenders as a ready-to-use list plus postbacks to your tracker — so you can exclude them in TwinRed and put your next dollar behind the traffic that converts.
It is manual. ValidVisit scores every visit and surfaces the {sspId} and {sourceSite} values carrying weak quality scores. You then set the blocks yourself in the advertiser portal, which offers three levels: per-campaign under Campaign Site Targeting, per-placement through the zone selection in Placement settings, and account-wide under Advertiser Site Targeting. There is no automated push from ValidVisit into TwinRed. The workflow is: score in ValidVisit, identify the problem placement, block it at whichever level fits — and because TwinRed shows every eligible source, you can equally run a whitelist rather than a blocklist.
By not treating engagement depth as the test. An interruptive format produces short, shallow sessions from genuine people, and a scoring model that keyed on dwell time or scroll would condemn the whole channel. ValidVisit weighs the network the click came from and the consistency of the device behind it alongside on-page behaviour, so a real person arriving through a pop scores differently from an automated session arriving the same way. That is the distinction that makes a per-placement decision possible at all on this inventory.
The pairing of {sspId} and {sourceSite} carries the most weight: the first names the supply partner, the second the individual placement, and it is almost always the placement that isolates a problem worth acting on. Those are also the exact dimensions the portal’s site targeting operates on, so the scores line up with the controls without a translation step. The {transactionId} gives per-click identity and ties a scored visit back to the TwinRed click record, which is what a server-to-server conversion postback rides on. Adding {campaignId} and {adId} tells you whether a weak pattern is placement-wide or specific to one creative being served there.
See which publishers and placements send real buyers vs bots — every visit scored 0–100, worst first.
Free trial at launch · just your email
One script · no cookies · no fingerprinting · raw IP never stored