Seatext library / BotRefund evidence
Should You Block Bots at the Campaign Level or Account Level? A Decision Framework
Start with account-level IP exclusions for known bad actors like data centers and VPNs, then refine to campaign-level blocks for geo-specific or keyword-specific fraud patterns. This layered approach balances broad protection with precise reach...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Most advertisers face bot traffic that wastes budget and corrupts conversion data. The question isn't whether to block bots, but where to apply the exclusions: at the account level or the campaign level. This two-tier strategy keeps your protection broad where the threat is universal and surgical where the threat is contextual.
| Criterion | Account‑Level Block | Campaign‑Level Block |
|---|---|---|
| Coverage | All campaigns automatically protected | Only selected campaigns protected |
| False Positive Risk | Higher – may block legitimate traffic in unrelated campaigns | Lower – scoped to where fraud occurs |
| Maintenance Effort | Low – single list to manage | Higher – replicate or customize per campaign |
| Fraud Pattern Fit | Universal infrastructure threats (data centers, VPNs, Tor) | Contextual threats (geo‑specific, keyword‑specific, placement‑specific) |
| Testing Flexibility | Low – changes affect every campaign | High – A/B test in one campaign first |
| Takeaway: Start with account‑level blocks for known‑bad infrastructure, then add campaign‑level blocks as needed. | ||
Why the Granularity Decision Matters
IP exclusions are the primary lever platforms give you to stop invalid traffic. Google Ads and Meta both let you exclude IP addresses or ranges at the account level and, in Google's case, at the campaign level. Meta handles exclusions differently—largely through placement controls and audience settings—but the principle holds: broader blocks catch more bad traffic but risk false positives; narrower blocks preserve reach but require more maintenance.
If you block a university network at the account level because one campaign saw bot traffic from a campus VPN, you also block legitimate students from seeing your other campaigns. If you only block at the campaign level, you must repeat the same exclusions across dozens of campaigns, increasing the chance of gaps. The right granularity reduces both wasted spend and operational overhead.
How IP Exclusions Work at Each Level
Account-Level Exclusions
Account-level exclusions apply to every campaign in the account. In Google Ads, you add IP addresses or CIDR ranges in the account settings; they propagate to all search, display, shopping, and video campaigns. Meta does not offer a direct account-level IP exclusion list, but you can achieve similar coverage by applying block lists to all ad sets or using partner integration tools.
Use account-level blocks for threats that are universally invalid: known data center ranges (AWS, Google Cloud, Azure), commercial VPN exit nodes, Tor exit nodes, and IP ranges flagged by threat intelligence feeds. These sources rarely produce legitimate conversions for any campaign.
Campaign-Level Exclusions
Campaign-level exclusions apply only to the selected campaign. In Google Ads, you can add IP exclusions per campaign. This lets you tailor blocks to the specific fraud patterns each campaign attracts. A campaign targeting North America might see bot traffic from a specific hosting provider in Virginia, while a campaign targeting Europe sees fraud from a different provider in Frankfurt. Blocking both at the account level would be overbroad; blocking each at its respective campaign level is precise.
Meta's campaign structure uses ad sets for targeting granularity. You exclude placements, audiences, or use third‑party tools that feed block lists per ad set. The principle is the same: match the exclusion scope to the fraud pattern's scope.
Account-Level Blocking: When It's the Right Choice
Choose account-level blocking when:
- The IP range is a known bad actor across the entire internet, not just your campaigns.
- You manage many campaigns and want a single source of truth for universal blocks.
- The threat is infrastructure‑based (data centers, VPNs, proxies) rather than campaign‑specific.
- You lack the operational capacity to maintain per‑campaign lists.
BotRefund's detection engine identifies "superhuman input speed (<1ms)" and "robotic linear mouse movements" as bot signals that are consistent across campaigns. When these signals correlate with specific IP ranges, those ranges are candidates for account-level exclusion.
Campaign-Level Blocking: When It's the Right Choice
Choose campaign-level blocking when:
- Fraud patterns differ by geography, keyword theme, or placement.
- A legitimate IP range produces fraud in one context but not another (e.g., a corporate network used by both employees and a botnet).
- You need to preserve reach for high‑value campaigns while aggressively blocking in test or low‑margin campaigns.
- You want to test the impact of a block before rolling it out account‑wide.
For example, a campaign targeting "enterprise software demo" keywords might attract sophisticated bots from a specific hosting provider that mimics human behavior. A brand awareness campaign on the same account might not see that traffic. Blocking the provider only in the demo campaign protects the high‑value funnel without reducing brand reach.
Decision Framework: A Tradeoff Table
| Criterion | Account-Level Block | Campaign-Level Block |
|---|---|---|
| Coverage | All campaigns automatically protected | Only selected campaigns protected |
| False Positive Risk | Higher — blocks legitimate traffic in unaffected campaigns | Lower — scoped to where fraud occurs |
| Maintenance Effort | Low — one list to manage | Higher — replicate or customize per campaign |
| Fraud Pattern Fit | Universal infrastructure threats (data centers, VPNs, Tor) | Contextual threats (geo‑specific, keyword‑specific, placement‑specific) |
| Testing Flexibility | Low — changes affect everything | High — A/B test blocks in one campaign first |
| Platform Support | Google Ads: yes. Meta: via partner tools or bulk ad set application | Google Ads: yes. Meta: per ad set or via tools |
Takeaway: Start with account-level blocks for known‑bad infrastructure. Add campaign-level blocks when fraud patterns diverge by campaign context.
Step-by-Step Decision Process
- Audit your invalid traffic sources. Pull IP addresses from Google Ads invalid click reports, Meta traffic quality reports, and your analytics. Tag each IP with the campaign(s) it affected.
- Classify each IP range. Is it a known data center, VPN, proxy, Tor exit node, or residential ISP? Use threat intelligence feeds (AbuseIPDB, IPQualityScore, or BotRefund's own signals) to categorize.
- Apply the rule: If the range is infrastructure‑based and appears across multiple campaigns → account‑level block. If it appears only in specific campaigns or correlates with specific keywords/placements/geos → campaign‑level block.
- Implement in phases. Add account‑level blocks first. Monitor for 7–14 days. Then add campaign‑level blocks for residual fraud.
- Review monthly. Fraud patterns shift. New data centers spin up; VPN providers change IP ranges. Schedule a monthly review of exclusion lists and invalid traffic reports.
Practical Scenarios
Scenario 1: E‑commerce Brand with 50 Campaigns
An online retailer runs search, shopping, and Performance Max campaigns across 10 countries. Invalid click reports show 60% of bot traffic originates from three cloud provider ranges (AWS, DigitalOcean, Hetzner). These ranges appear in every country and every campaign type. Action: Add all three ranges to the account‑level exclusion list. Result: Universal protection with one update.
Scenario 2: B2B SaaS with High‑Value Demo Campaign
A B2B company runs a generic brand campaign and a high‑intent "request demo" campaign. The demo campaign sees sophisticated bots from a specific VPN range that completes forms with realistic timing. The brand campaign sees no such traffic. Action: Block the VPN range at the campaign level for the demo campaign only. Result: The high‑value funnel is protected; brand reach is untouched.
Scenario 3: Agency Managing 20 Client Accounts
An agency manages Google Ads accounts for 20 clients. They maintain a shared master list of known‑bad IP ranges (data centers, VPNs, Tor). Action: Apply the master list at the account level for each client. For client‑specific fraud (e.g., a competitor clicking one client's ads), add campaign‑level blocks only in that client's account. Result: Operational efficiency with client‑specific precision.
Limitations and When This Advice Doesn't Apply
- Meta's platform constraints: Meta does not support direct IP exclusions. You must use placement exclusions, audience exclusions, or third‑party tools that integrate via the Conversions API. The campaign‑vs‑account logic still applies, but the implementation differs.
- Dynamic IP environments: Residential proxy networks rotate IPs rapidly. Static IP lists (at any level) lose effectiveness quickly. Behavioral detection (mouse movement, scroll patterns, click timing) becomes more reliable than IP blocking alone.
- Shared corporate networks: Blocking a corporate IP at the account level may block legitimate employees researching your product. Campaign‑level blocks mitigate this but require knowing which campaigns those employees interact with.
- Small accounts with few campaigns: If you run 2–3 campaigns, the maintenance difference between account and campaign level is negligible. Simplicity may favor account‑level for everything.
Key Facts from BotRefund's Detection Data
| Metric | Value | Source |
|---|---|---|
| Bot click budget theft | Up to 20% of Google and Meta ad budget | S2 |
| Detection accuracy | 99% via corroborated signals | S3, S5 |
| Independent checks per visit | 106 | S3, S5 |
| Average ad spend recovered (case studies) | $15,400 – $1,200,000 | S1 |
| Bot click rate (FinTrust case study) | 14% | S6 |
| Conversion rate increase after protection (FinTrust) | +18% | S6 |
Terminology Quick Reference
- CIDR notation: A compact way to write IP ranges (e.g., 192.0.2.0/24 covers 256 addresses).
- Data center IP: An IP assigned to a cloud provider (AWS, GCP, Azure) or hosting company, rarely used by residential consumers.
- VPN exit node: The public IP a VPN user appears to come from; shared by many users.
- Residential proxy: A proxy that routes traffic through a real consumer's home IP, making it look like legitimate residential traffic.
- Invalid click report: Google Ads report showing clicks Google has automatically filtered as invalid.
- Traffic quality report: Meta's equivalent, showing estimated invalid traffic by placement and audience.
FAQ
Can I use both account-level and campaign-level blocks simultaneously?
Yes. Google Ads applies both. An IP blocked at the account level is blocked everywhere; a campaign-level block adds additional exclusions for that campaign only. There's no conflict.
How often should I update my exclusion lists?
Monthly at minimum. Weekly if you spend over $50K/month or operate in high‑fraud verticals (lead gen, finance, gaming). BotRefund's continuous monitoring automates this by feeding fresh signals into your exclusion workflow.
Does blocking IPs at the account level hurt my Quality Score?
No. Excluded IPs simply don't see your ads. They don't generate impressions, clicks, or negative signals. However, over‑blocking legitimate traffic reduces total conversion volume, which can indirectly affect algorithm learning.
What about IPv6 addresses?
Google Ads supports IPv6 exclusions in CIDR format. Most data center and VPN ranges have both IPv4 and IPv6 blocks. Include both when available.
Should I block entire countries at the account level?
Only if you don't serve those countries at all. Country‑level blocking is a targeting decision, not a bot decision. Use location targeting settings instead of IP exclusions for geographic restrictions.
How do I know if a campaign-level block is working?
Compare invalid click rates, conversion rates, and cost per conversion before and after the block (7–14 day windows). Look for reduced invalid clicks without a proportional drop in legitimate conversions.
Can BotRefund automate this decision for me?
BotRefund detects bots at the browser and behavior level (106 independent checks including "ghost click detection," "honeypot trap interactions," and "absence of humanlike mouse tremor") and provides forensic evidence for refund claims. It identifies which IPs correlate with bot signals, helping you build evidence‑based exclusion lists at the right granularity.
Learn more — Continue to the relevant page on the client website
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.