100–200 Click Test to Spot VPN Traffic in Solo Ads, Security Backed

You can't trust raw click counts. The only way to know if solo-ad traffic is real is to run a tracked 100-200 click test and check the results for anonymizer flags and timing anomalies. Two things to watch for right away: IP traits that mark a click as coming through a VPN, proxy, or hosting network, and response timing that doesn't match normal human browsing. The step-by-step checklist below shows you exactly how to run that test.

---

TL;DR:

• Running a controlled test of 100 to 200 clicks allows you to compare vendor-reported numbers with your logs and identify suspicious automation or bot behavior.
• Indicators of VPN or proxy traffic include anonymizer flags, hosting provider IPs, extremely uniform click timing, and IP address inconsistencies across regions or within minutes.
• Network testing methods like round-trip time comparisons can reveal masked clicks, with VPN connections typically exceeding a 50ms latency difference from direct connections.
• Log fields such as timestamps, IPs, user agents, and request timings are essential; initial seed tests verify setup, with full tests providing more reliable data.
• Always request raw click logs and conduct your own tests before scaling campaigns, regardless of a vendor’s reputation, to prevent wasting money on fake or low-quality traffic.

---

Table of Contents

• How do you verify solo ad traffic before you buy more?
• What signals in your logs point to VPN or proxy traffic?
• What network tests reveal masked or proxied clicks?
• What exactly should you log, and in what order should you test?
• What should you ask a vendor before paying for traffic?
• How do you turn test results into a buy or walk-away decision?
• Who built this verification method and why it matters
• Why most solo-ad buyers test too late or not at all
• Where to get the checklist and tracking templates
• FAQ
• Sources

How do you verify solo ad traffic before you buy more?

Verification starts before you spend a dollar on a full campaign. You need a controlled test that produces data you control, not just numbers a vendor reports back to you.

1. Build unique HTTPS tracking links for each vendor and route them to a server-side landing page that logs every request.
2. Run a batch of 100 to 200 clicks and capture IP address, user agent, ASN, and timestamp for each one.
3. Compare the vendor's reported click count against your own server logs and your email service provider's data.
4. Scan the batch for obvious automation, such as identical user agents repeated dozens of times or clicks arriving in bursts of less than a second apart.

Our guide to tracking solo ad traffic walks through the setup in more detail, and the full rationale for the test size is covered in our 100 to 200 click verification procedure.

While you're reviewing logs, keep an eye out for:

• Clicks with no corresponding page-load time, which suggests a bot fired the request without rendering anything.
• A handful of IPs responsible for a disproportionate share of clicks.
• Click timestamps that line up in suspiciously even intervals.

Pro Tip: Run your first test batch small and cheap. If the vendor balks at a paid test of 100 to 200 clicks, that reluctance tells you more than the test itself would.

What signals in your logs point to VPN or proxy traffic?

Once you have logs, the real work is reading them correctly. A few signals carry more weight than others; for example, tools like Gleanit offer ad-monitoring and campaign monitoring capabilities that complement verification workflows.

• Anonymizer flags: Services like MaxMind's minFraud can identify anonymizers including VPNs, hosting providers, public proxies, and Tor exit nodes, and return a confidence score you can use to triage risk.
• ASN and hosting indicators: An IP registered to a data center or hosting provider almost never represents a real reader opening an email on a home network.
• Behavioral oddities: Sessions that last zero seconds, identical click sequences repeated across supposedly different visitors, or browsing speeds no human could physically achieve.
• IP churn and geo mismatch: The same click token resolving to IPs in different countries within minutes, or a location that contradicts the list's stated geography.

A single anonymizer flag doesn't prove fraud, but a cluster of these signals on the same batch of clicks is a strong reason to question the traffic source.

What network tests reveal masked or proxied clicks?

Beyond log review, you can run network-level checks that are harder for a reseller to fake. The most useful one is a round-trip-time comparison.

Researchers behind the CalcuLatency method found that comparing application-layer latency against network-layer latency produces a reliable split: in their testing, most direct connections showed a difference under 50 milliseconds, while a large majority of VPN connections exceeded that threshold. That 50ms gap is a usable heuristic, not a certainty.

In practice, you can gather these signals with:

• WebSocket or TCP timing captured at your landing page.
• Server-side timestamps logged at the moment a request hits your infrastructure.
• ICMP pings to addresses near the visitor's reported IP, where your hosting setup allows it.

Pro Tip: Treat RTT anomalies as one input among several. A visitor on a close-by VPN exit, a mobile carrier network, or a corporate connection can show similar timing without being fraudulent traffic.

What exactly should you log, and in what order should you test?

Precision here is what turns a hunch into evidence you can bring back to a vendor. Log these fields on every click:

• Timestamp down to the millisecond
• Client IP address and resolved ASN
• Full user agent string
• Landing-page server timing
• Redirect chain from click to landing page
• The unique click token tied to that vendor's campaign

Run the test in two stages:

1. Seed batch: Send 20 to 50 clicks first to confirm your tracking setup works and your logs populate correctly.
2. Verification batch: Scale to the full 100 to 200 click test, then reconcile the vendor's reported numbers against your own server logs.

Expect some noise from mailbox security scanners opening links automatically. M3AAWG's research on nonhuman interactions documents that these scans generate real clicks that distort engagement data and can't be fully filtered out, so separate rapid, repeated hits from a single corporate IP from the pattern of clicks spread across your list. Our click log guide covers field-by-field reconciliation if you want a deeper walkthrough.

What should you ask a vendor before paying for traffic?

A 21-question vendor vetting framework exists because most fraud gets caught in the paperwork, not the click data. A few questions do most of the work:

• Will you provide raw click logs, not just a summary screenshot?
• Can you produce signed or timestamped results from a recent, independent test?
• Will you accept a small paid test batch before a full campaign?
• What's your refund or make-good policy if verification shows masked traffic?

Treat a refusal to answer any of these as a red flag on its own. Generic screenshots, resistance to a paid test, or traffic that skews heavily toward hosting and proxy ASNs are reasons to walk away before you commit a full budget. The complete framework, with all 21 questions, is laid out in our guide to spotting fake conversions.

How do you turn test results into a buy or walk-away decision?

Data only helps if you act on it consistently. A few rules make that easier:

• Accept the traffic when anonymizer flags stay low, RTT deltas mostly fall under the 50ms threshold, and click behavior looks human (varied timing, real session length).
• Push for a re-send or partial refund when you see a moderate mix of flagged IPs alongside otherwise normal behavior, since this often points to a portion of resold or low-quality inventory rather than outright fraud.
• Reject the vendor when anonymizer flags, data-center ASNs, and impossible click timing show up together across most of the batch.

Watch for false positives: a reader on a corporate VPN or a mailbox security scanner can trigger some of the same flags as fraud. Confirm with a second signal, like a cluster of claims from vendors you already know, before writing off a batch.

Pro Tip: When results are mixed, ask for a smaller re-send before deciding. A vendor confident in their list will usually agree.

Who built this verification method and why it matters

This framework comes from Philip Coble, who has worked as a solo ads vendor for 11 years and built SoloAdsGuide.com to help buyers avoid the scams common in this industry. The test protocol and vetting questions in this guide combine buyer-first experience with published security research, including work from Cloudflare's bot detection team on residential proxy abuse. None of the steps here require enterprise fraud-detection software. They're built to run with a tracking link, a spreadsheet, and a free IP lookup tool.

Why most solo-ad buyers test too late or not at all

Most advice on buying solo ad traffic focuses on finding a "trusted" vendor, as if trust were something you could identify from a sales page or a testimonial. That's backward. A vendor's reputation tells you how they treated other buyers in the past, not whether the batch they send you next week is clean.

The overrated piece of conventional advice is relying on vendor-provided proof alone, screenshots of past campaigns, claims of "premium" traffic, or testimonials with no raw data behind them. None of that is verifiable after the fact. What matters is running your own test, on your own tracking, before you scale spend.

The habit we'd most like to see change is treating verification as optional for "established" vendors and mandatory only for new ones. Traffic quality can shift between batches, even from someone who delivered well before. Run the 100-200 click test every time you buy, not just the first time.

— Philip Coble

Where to get the checklist and tracking templates

We built SoloAdsGuide.com around exactly this problem: buyers spending money on traffic they can't verify. Our site includes the full 21-question vendor vetting checklist, step-by-step tracking guides, and sample test scripts you can adapt for your own landing pages.

Before you commit real budget to a vendor, run the 100-200 click test described above and work through the checklist against their answers. On our landing page you'll find:

• The complete 21-question vendor vetting framework
• A tracking setup guide with sample log fields
• Sample test scripts for running a seed and verification batch

Start at Soloadsguide to pull the checklist before you send your next payment.

FAQ

How accurate is the 50ms RTT threshold for spotting VPNs?

It's a heuristic, not a guarantee. CalcuLatency research found most direct connections fall under a 50ms gap between application and network latency, while a large share of VPN connections exceed it, but close-by VPN exits and some mobile networks can still produce false readings.

Why run 100 to 200 clicks instead of a smaller sample?

A smaller batch can look clean purely by chance, especially if a vendor is mixing in a small amount of bad traffic. A 100 to 200 click batch gives you enough volume to spot patterns like repeated IPs, identical user agents, or timing clusters that a very small test would miss.

Can ESP click numbers be trusted on their own?

Not fully. M3AAWG documents that mailbox security scanners generate real clicks that inflate engagement numbers, so your email service provider's reported clicks should be one input alongside your own server logs, not the only proof of real traffic.

What's the fastest thing to check before buying from a new vendor?

Ask for raw click logs from a recent campaign and run a small paid test batch with your own tracking links before committing to full volume. If the vendor refuses either request, treat that as your answer.

Do cheap analytics filters actually help?

Yes, as a baseline layer. GA4 guidance recommends hostname filters and internal traffic exclusions as permanent, low-cost steps that catch some obvious bad traffic, though they won't replace a full verification test.

Sources

• Using machine learning to detect bot attacks that leverage residential proxies | Cloudflare Blog
• CalcuLatency: Detecting remote proxies via layered RTT differences (USENIX paper)
• Exploring the impact of nonhuman interactions on email send metrics (M3AAWG)
• How minFraud identifies anonymizers (MaxMind support)

Recommended

• Marketers: Verify Solo Ad Traffic With a 100 to 200 Click Test
• Stopping Fake Clicks: A Guide to IP Filtering for Solo Ads
• Solo Ad Click Logs: A Buyer's Guide to Verifying Traffic
• How to Track Solo Ad Traffic (Catch Low-Quality Clicks)