Ad blockers and privacy extensions (uBlock Origin, Privacy Badger, Ghostery) often strip query parameters they recognize as tracking IDs. Some corporate networks and VPNs do the same at the firewall level.

In-App Browsers and Redirect Chains

Clicks from Facebook and Instagram often open in Meta's in-app browser (FBIA / IBIA). These browsers sometimes fail to pass the fbc parameter to your final URL, especially when your landing page redirects (HTTP 301/302), uses a consent management platform that reloads the page, or loads via a CDN that rewrites URLs. A slow redirect — over 2–3 seconds — increases the chance the parameter is lost before analytics initializes.

App browsers also isolate cookies from the system browser. A user who clicks an ad in Instagram, then later opens your site in Safari, starts a new session with no click ID.

Consent Banners and Cookie Blocking

If your cookie banner blocks the Meta pixel until consent is given, the pixel fires after the page load — by which time the fbc parameter may already be gone from the URL (single-page apps often drop it on route change). Server-side tagging (GTM server-side, CAPI) can capture the ID on the first request, but only if your server reads the query string before any redirect or rewrite.

Bot and Invalid Traffic Without Attribution

Not all unattributed sessions are privacy-related. Bot traffic — scrapers, click farms, Audience Network publisher scripts — often hits your landing page without a valid fbc because the click never originated from a real Meta ad auction. These sessions show up as direct or referral traffic with no campaign data. S1 notes that "a click-to-session gap can have ordinary explanations such as app browsers, tracking consent, slow loads, or analytics configuration" but also that bot traffic leaves "repeatable technical and behavioral patterns: unusually fast form completion, identical field structures, sudden placement-level spikes, or conversion events with no meaningful page engagement."

S3 explains that Meta Audience Network placements "have historically shown high click-through rates (CTRs) and near-instant bounce rates" from publisher bots clicking ads to generate revenue. These clicks are billed but carry no real attribution.

Investigation Workflow: Find the Leak

1. Compare click vs. session counts in Meta Ads Manager vs. GA4/analytics. A consistent 10–30% gap is normal (privacy, app browsers). A sudden spike or >50% gap signals a technical break.
2. Check URL parameters on landing page loads. Use browser dev tools or server logs: does ?fbc=... appear on the first request? Is it still there after redirects?
3. Audit the fbp cookie. In dev tools → Application → Cookies, verify _fbp sets on landing. If not, your consent banner or CSP may block it.
4. Segment by device, browser, placement. S6 recommends looking for clusters: "Quality normally changes by placement, audience, creative, device, geography, landing page, and time." A drop only on iOS Safari or only on Audience Network points to the cause.
5. Review CAPI event match quality. In Events Manager, check the Event Match Quality score for fbc and fbp. Low scores mean the server isn't receiving the IDs.
6. Preserve evidence before changing anything. S1 and S6 both stress: "Preserve the click identifier, campaign context, timestamp, URL parameters, CRM record, and any verification result before you change campaign settings."

Fixes That Restore Attribution

• Enable CAPI with deduplication. Send fbc and fbp from your server on the first page view. Deduplicate with browser pixel events using event_id.
• Capture fbc on the server immediately. Read the query string in your edge/CDN/worker before any redirect. Store it in a first-party cookie or session, then pass it to CAPI.
• Use utm_source=facebook + utm_medium=cpc as a fallback. UTM parameters survive more often than fbc and let you attribute in GA4 even when Meta's IDs are lost.
• Minimize redirect chains. Point ads directly to the final landing page URL. Avoid tracking domains, link shorteners, or multi-step consent flows that reload the page.
• Test in-app browser behavior. Open your ad in the Facebook/Instagram app, click through, and verify the URL and cookies. Use fbclid (legacy) and fbc as dual signals.
• Audit Audience Network placement performance. If a placement shows high clicks, near-zero session duration, and no fbc, exclude it or apply a block list.

Key Facts

Limitations and When This Advice Doesn't Apply

This analysis covers web attribution. App installs and in-app events use different attribution (SKAdNetwork, ATT, MMPs like AppsFlyer/Adjust). If your conversion happens entirely in a mobile app, web click IDs don't apply.

Cross-device journeys (click on mobile, convert on desktop) will always show attribution gaps unless the user is logged into Meta on both devices and you use CAPI with user identifiers (email/phone hash).

Meta's own attribution reporting (Ads Manager) uses modeled conversions when data is missing. Your analytics (GA4, Mixpanel, etc.) does not. The two will never match perfectly.

FAQ

Why does Meta Ads Manager show more clicks than my analytics shows sessions?

Normal gaps of 10–30% come from privacy settings, app browsers, users closing the tab before load, and ad blockers. Larger gaps indicate broken tracking (missing fbc, redirect drops, consent banner blocking).

Can I recover attribution for sessions that already happened?

No. Historical sessions without click IDs cannot be retroactively attributed. You can only fix forward tracking. For billed clicks that were invalid, S5 and S7 note Meta has a refund process — but you need behavioral evidence (client-side logs showing automation) to succeed.

Does CAPI fix attribution automatically?

Only if your server captures the fbc or fbp on the first request. CAPI doesn't invent missing IDs; it just gives you a second path to send them.

Should I turn off Audience Network to fix attribution?

It often improves lead quality (S3), but you lose reach. Audit placement-level quality first (S6). If Audience Network delivers real conversions at acceptable cost, keep it and fix tracking instead.

What's the difference between fbc and fbp?

fbc is the click ID passed in the URL (lasts 28 days). fbp is a first-party cookie set by the Meta pixel (lasts 90 days, but ITP shortens it). You need at least one for attribution.

How do I know if unattributed sessions are bots?

Look for: near-zero time on page, no scroll events, superhuman click speeds (<1ms), linear/grid mouse paths, identical form submissions, bursts from same IP or ASN. S4 lists these as detection signals BotRefund uses.

Will UTM parameters alone solve this?

UTMs survive more reliably than fbc and work in GA4, but Meta's own reporting and CAPI matching still need fbc/fbp. Use both.

Device-level aggression means blocking an entire device group—such as a specific OS version, browser, or device model—based on a small number of suspicious events. The best approach is to hold off on blocking until you have enough data. A good rule of thumb: if the group has fewer than 50 clicks, flag it as suspect but do not block it. Instead, monitor it for at least a week. If the suspicious pattern continues, then consider manual blocking.

Readiness Checklist: Steps to Take Before Blocking

• Check the sample size: Count clicks or conversions for the device group. Below 50 clicks? Move to monitoring.
• Review the time window: Look at the last 7 days. A short spike is not a trend.
• Compare with baseline: Compare the device group's click-through rate, conversion rate, or error rate to your account average. A small deviation may be noise.
• Investigate the source: Use platform reports (e.g., Meta Ads Manager) to see if the traffic is concentrated in one placement, like Audience Network, which often has higher bot activity (S4).
• Preserve attribution: Before making any changes, export click IDs, timestamps, and campaign context. This evidence is needed if you later request a refund (S5).
• Set up a manual review process: Create a rule that moves low-sample device groups to a “recommended” or “suspect” status instead of automatically blocking them.

Worked Example: Applying the Block-vs-Monitor Rule

Imagine you run a lead-generation campaign on Meta. You notice that the device group "Android 13 / Chrome 119" has 32 clicks over the past 7 days. The click-through rate is 4.2%, double your account average of 2.1%. However, zero leads came from those clicks. The traffic comes entirely from Audience Network placements.

Step 1: Sample size is 32 clicks, which is below the 50-click threshold. You mark the group as "suspect" in your tracking sheet.

Step 2: You check the 7-day window. The clicks are spread across 5 days, not a single spike.

Step 3: You compare baseline metrics. The bounce rate for this group is 95% versus 60% account average. Time on page is under 2 seconds.

Step 4: You see the placement concentration. All clicks are from Audience Network. According to BotRefund (S4), Audience Network often has higher bot activity.

Step 5: You export click IDs (GCLIDs/FBCLIDs) and timestamps for the 32 clicks. You save them in a CSV for potential refund claims.

Step 6: You set a calendar reminder to review this group in one week. If the pattern holds (e.g., another 30+ clicks with zero leads and high bounce), you will manually block the device group at the placement level first.

Step-by-Step Guide: Building a 7-Day Device-Group Report in Meta Ads Manager and Google Ads

Meta Ads Manager

1. Open Ads Manager and go to the "Reports" tab.
2. Click "Create Report" and choose "Custom Report".
3. Set the date range to "Last 7 days".
4. In "Breakdown", select "Device" then "Operating System" or "Device Model" as needed.
5. Add metrics: Clicks, Impressions, CTR, Cost per Click, Landing Page Views, Leads (or Conversions).
6. Apply a filter: "Clicks" less than 50.
7. Save the report with a name like "Low-Sample Device Groups - 7 Day".
8. Schedule weekly email delivery to yourself or your team.

Google Ads

1. In Google Ads, navigate to "Reports" > "Predefined reports" > "Basic" > "Device".
2. Set the date range to "Last 7 days".
3. Add segments: "Device model" or "Operating system version".
4. Include columns: Clicks, Impr., CTR, Avg. CPC, Conversions, Cost/conv.
5. Download the report as CSV.
6. In Excel or Google Sheets, filter the "Clicks" column to show only rows with fewer than 50 clicks.
7. Add a column for "Status" with values "Monitor" or "Block".
8. Save the file in a shared folder for weekly review.

Signs to Wait: When a Low-Sample Device Group Is Not a Threat

Not every suspicious-looking device group is fraudulent. Delay blocking if:

• The group has fewer than 50 clicks and the pattern is not repeating.
• Traffic comes from a newly released device or OS version that naturally has low volume.
• The spike happened during a promotional campaign or seasonal event—legitimate users may behave differently.
• Your conversion tracking setup has a known issue, such as missing consent or slow page load, that could cause data gaps.
• The suspicious activity is isolated to a single day and does not persist.

Exception: When Immediate Blocking Is Justified

In rare cases, you can block a device group with low sample size. Do this only if:

• The group shows clear evidence of coordinated fraud, such as identical form submissions from multiple devices at the same second.
• The device group is a known source of invalid traffic from past audits (e.g., a specific IP range or data center).
• You are losing a significant amount of budget (e.g., over $1,000 per day) from that single group, and the pattern is unmistakable.

Even then, prefer to block at the placement level first rather than the entire device group.

Decision Table for Edge Cases

How to Set Up a Monitoring Workflow

Use a simple two-step process:

1. Create a saved report in your ad platform that shows device group performance over the last 7 days. Filter for groups with fewer than 50 clicks.
2. Review the report weekly. If a group shows consistent poor quality (e.g., high bounce rate, no conversions, fast form fills) for two consecutive weeks, escalate to manual blocking.

For more advanced detection, tools like BotRefund can automatically flag device groups with abnormal behavior patterns, even when sample sizes are low. Their client-side audit captures behavioral signals like mouse movement, session duration, and form interaction speed—giving you evidence to decide whether to block or wait (S2).

Key Facts: Device Group Aggression and Invalid Traffic

Limitations of This Approach

This approach works best for accounts with moderate to high traffic. If your entire account receives fewer than 100 clicks per week, even 50 clicks may be a large portion of your data. In that case, monitor for 2-3 weeks before making a decision. Also, this advice applies to device groups, not to individual IP addresses or user agents. For very low-traffic accounts, consider using a third-party detection tool that can pool data across accounts or use behavioral signals that do not require large sample sizes.

Terminology

• Device group: A set of devices sharing the same operating system, browser, or model (e.g., iOS 15.4, Chrome 120, Samsung Galaxy S22).
• Sample size: The number of clicks or conversions recorded for a device group in a given period.
• Device-level aggression: The practice of blocking an entire device group based on limited data.
• Invalid traffic: Clicks or impressions that are not the result of genuine user interest, including bots and accidental clicks.

Frequently Asked Questions

Why is 50 clicks the recommended minimum?

Below 50 clicks, the data is too noisy to distinguish between a real threat and random variation. Statistically, you need at least 30-50 events to have any confidence in a rate or pattern.

What if the device group has very high click-through rate but no conversions?

That is a red flag, but still wait for 50 clicks and a week of data. It could be a technical issue with your landing page or tracking.

Can I use a tool to automate this monitoring?

Yes. BotRefund offers a free audit that automatically detects suspicious device groups and provides video evidence of bot behavior. This can speed up your decision process.

How do I know if my ad platform already blocks low-sample device groups?

Platforms like Meta and Google have automated systems that may block device groups with very few events. But they are not perfect. Manual oversight is still needed.

What if I block a device group by mistake?

It can cut off legitimate users and distort your campaign optimization. That is why the wait-and-monitor approach is safer. If you accidentally block, you can restore the group in your ad platform's invalid traffic list.

Does this approach work for both Google and Meta campaigns?

Yes. The same logic applies to any ad platform that reports device-level data. The sample size threshold may vary, but the principle of avoiding premature blocking holds.

How much does it cost to use a tool like BotRefund?

BotRefund offers a free bot audit with no credit card required. Pricing is based on ad spend range. Check their website for details.

Further Reading

These sources from the provided pack cover invalid traffic, bot detection, and refund workflows:

• Meta Ads Invalid Traffic: What Advertisers Can Measure and Block (S1)
• Facebook Ad Bot Detection: How to Identify Fake Traffic and Reclaim Social Ad Spend (S3)
• Facebook Ads Getting Bot Traffic? How to Secure Your Meta Campaigns (S4)
• Google Ads Invalid Activity Credit: How It Works and How to Get Your Money Back (S5)
• How to Audit Meta Lead Quality in Your CRM (S6)
• Click Fraud Impact on ROAS: How Invalid Traffic Destroys Your Return on Ad Spend (S7)

Why Questionable Sessions Matter for Meta Campaigns

Meta campaigns reach people across Facebook, Instagram, and the Audience Network at high volume. That reach is valuable, but it also opens the door to accidental interactions, low-intent traffic, automated browsing, and deliberately fraudulent submissions. A fake lead may be intended to earn an affiliate payout, inflate a publisher's performance, scrape an offer, or simply exhaust a sales team's time. Treating every unresponsive contact as fraud can make a team exclude a valuable audience, so evidence-based separation is essential.

When invalid traffic triggers conversion events, it poisons the Meta Pixel. The platform's machine learning then optimizes targeting for bots rather than real buyers, raising customer acquisition costs and lowering ROAS. The financial impact compounds: you pay for the click, you pay for the corrupted optimization, and your sales team wastes hours on contacts that never existed.

Core Signals That Indicate Invalid Traffic

The source material identifies five signal categories worth investigating. Each leaves a repeatable pattern that differs from normal human variation.

• Contactability: disconnected numbers, invalid email domains, repeated addresses, or an unusual concentration of one country code.
• Timing: several leads arriving in short bursts, forms submitted immediately after landing, or conversions concentrated at unusual hours.
• Session behavior: no scrolling, no field corrections, uniform click paths, and no meaningful time on the offer page.
• Campaign patterns: a sharp lead-quality difference by placement, creative, audience expansion, device, or landing page.
• CRM outcome: a high reported lead count paired with no calls connected, demos booked, qualified opportunities, or repeat engagement.

Client-side behavioral signals add another layer of proof. These include ghost clicks that happen without the natural sequence of human intent, honeypot trap interactions where bots respond to hidden page elements, robotic linear mouse movements, absence of humanlike mouse tremor, superhuman input speed under one millisecond, grid-aligned movement patterns, absence of clicks or scrolling, and unnatural session durations that are too short, too long, or too uniform to be human.

Step-by-Step Investigation Workflow

1. Preserve attribution before changing the campaign. Keep campaign, ad set, creative, placement, and click identifiers intact so you can trace any refund claim back to the exact source.
2. Export Meta Ads Manager data. Pull placement-level, creative-level, and audience-level reports with click IDs (FBCLIDs) attached. Note any sudden spikes in click-through rate or conversion rate paired with near-instant bounce rates.
3. Cross-reference with website analytics. In Google Analytics or your preferred tool, segment sessions by the same FBCLIDs. Check for zero scroll depth, zero field interactions, session durations under three seconds, and identical navigation paths across multiple sessions.
4. Layer CRM outcomes. Match each lead record to its originating click ID. Flag records with disconnected phones, invalid emails, duplicate addresses, or zero downstream activity (no calls, no demos, no repeat visits).
5. Run a client-side behavioral audit. Deploy a script that captures mouse movement, scroll behavior, form interaction timing, and honeypot triggers. This produces the forensic evidence — video replays, click-path logs, and behavioral scores — that ad platforms require for manual refund disputes.
6. Quantify the waste. Calculate the share of spend tied to flagged click IDs. This becomes the basis for your refund request.
7. Submit a structured dispute. Package the behavioral evidence, click IDs, and CRM outcome mismatch into the format Meta's billing team expects. Include placement-level breakdowns so the reviewer can see the pattern without guessing.

Server-Side vs Client-Side Detection Methods

Server-side audits examine server log files: IP addresses, request headers, and user-agent strings. They catch basic scraper bots but struggle with advanced botnets that rotate residential IPs and mimic legitimate headers. Client-side audits analyze the visitor's browser behavior in real time — mouse movement, scroll depth, form interaction timing, and responses to hidden traps. This catches sophisticated bots that look clean on the server side but behave mechanically in the browser. For refund claims, client-side evidence is what ad platforms accept as proof of invalid activity.

Common Sources of Bot Traffic on Meta

• Meta Audience Network: Meta defaults campaigns into this network of third-party mobile apps and websites. Many publishers use automated bots to click ads and generate artificial revenue. Audience Network clicks historically show high CTRs and near-instant bounce rates.
• Profile scrapers and directory bots: Thousands of bots crawl Facebook and Instagram to scrape profile directories, group posts, and page data. They follow and click outbound links on posts and ads to discover content.
• Click farms: Locations where low-cost labor or automated script emulators click ads from rows of real smartphones. Because they use actual mobile hardware, they bypass standard IP-range filters.
• Residential proxy botnets: Malware on household computers and phones redirects clicks through normal consumer IP addresses, hiding bot activity within legitimate regional traffic.

Building Evidence for Refund Claims

Meta provides a manual billing dispute system for advertisers billed for invalid or fraudulent clicks. The process is not automatic. Success depends on submitting client-side behavioral evidence — video proof of each bot session, captured click IDs (FBCLIDs), and a clear mapping between the flagged sessions and the spend you want refunded. The source material notes an 83% approval rate across client refund claims submitted to ad platforms when this evidence is properly compiled. Refunds can be recovered for Google Ads spend dating back to 2017; Meta's lookback window varies but typically covers recent billing cycles.

Limitations and When This Advice Does Not Apply

• This guide focuses on detection and evidence collection, not on automated blocking. Meta does not allow third-party scripts to block clicks before they are billed.
• Low-volume campaigns (under a few thousand clicks per month) may not produce statistically clear patterns; the signal-to-noise ratio improves with volume.
• Brand-awareness campaigns optimizing for reach or video views have different quality signals than lead-generation or conversion campaigns.
• If your CRM cannot match leads to click IDs, the CRM-outcome signal cannot be used. Implement FBCLID capture on your forms first.
• Some invalid traffic — accidental mobile taps, for example — is filtered automatically by Meta and never reaches your billing. The workflow above targets the portion that escapes automatic filters.

Key Facts

FAQ

How quickly can I see results after starting an audit?

Behavioral data begins collecting as soon as the client-side script is live. Meaningful patterns usually emerge within 7–14 days for campaigns spending at least $10,000 per month. Lower-volume campaigns need longer to reach statistical clarity.

Do I need to pause my campaigns while investigating?

No. The first step is explicitly to preserve attribution without changing the campaign. Pausing resets learning phases and destroys the very click IDs you need for evidence.

Can I get refunds for traffic from the Audience Network specifically?

Yes. If your evidence shows a placement-level pattern — high CTR, instant bounce, zero CRM outcome — tied to Audience Network click IDs, you can request a refund for that placement's spend. Many advertisers simply exclude the Audience Network after confirming the pattern.

What if my CRM doesn't capture FBCLIDs?

Add a hidden field to your lead forms that writes the FBCLID query parameter into your CRM. Without this link, you cannot tie a specific lead record to a specific billed click, which weakens any refund claim.

Does this process work for Instagram-only campaigns?

Yes. Instagram placements use the same click-ID system (FBCLIDs) and the same Pixel. The detection signals — session behavior, timing, CRM outcome — apply identically.

How much of my budget is typically wasted on bots?

Industry studies estimate 10–30% of programmatic ad spend goes to invalid traffic. For Meta specifically, competitive B2B campaigns often see higher rates because lead-gen forms are attractive targets for affiliate fraud and click farms.

What happens after I submit a refund request?

Meta's billing team reviews the evidence. If approved, a credit appears in your Ads Manager billing section. The credit applies to future spend; it is not a cash payout. The review timeline varies from a few days to several weeks depending on claim complexity.

Create a new Node project, install Playwright, and run the script below. It opens the target URL in Chromium, waits for network idle, then logs the page title, URL after navigation, and whether a CAPTCHA element appears.

const { chromium } = require('playwright');

async function testBlock(url) {
  const browser = await chromium.launch({ headless: true });
  const context = await browser.newContext();
  const page = await context.newPage();
  
  const response = await page.goto(url, { waitUntil: 'networkidle', timeout: 30000 });
  
  console.log('Status:', response?.status());
  console.log('Final URL:', page.url());
  console.log('Title:', await page.title());
  
  // Common CAPTCHA selectors
  const captcha = await page.$('iframe[src*="captcha"], [id*="captcha"], [class*="captcha"], [data-testid*="captcha"]');
  console.log('CAPTCHA detected:', !!captcha);
  
  // Check for challenge pages
  const bodyText = await page.textContent('body');
  const challengeKeywords = ['challenge', 'blocked', 'access denied', 'rate limit', 'please verify'];
  const hasChallenge = challengeKeywords.some(k => bodyText.toLowerCase().includes(k));
  console.log('Challenge page detected:', hasChallenge);
  
  await browser.close();
}

testBlock('https://example.com').catch(console.error);

If the status is 200 but the title shows a challenge page, a CAPTCHA element exists, or the final URL redirects to a verification endpoint, the site is likely blocking or challenging Playwright.

Why sites block Playwright

Anti‑bot services look for automation fingerprints. BotRefund's detection suite includes a Playwright Init Scripts check that flags mismatches between patched browser APIs and the underlying browser implementation. As BotRefund explains, "Automation tools often patch or hide browser APIs, but those changes can break when the browser is checked from another angle." This signal is one of 106 independent checks used to build a reliable picture of whether a visit is human or automated.

Step‑by‑step testing procedure

1. Baseline with a real browser. Open the target URL in a regular Chrome profile. Note the title, visible content, and network requests in DevTools.
2. Run headless Playwright. Use the script above. Compare status code, final URL, title, and body text against the baseline.
3. Run headed Playwright. Launch with headless: false. Some blockers only trigger in headless mode.
4. Add a realistic context. Set a common user‑agent, viewport, locale, and timezone. Disable navigator.webdriver via context.addInitScript().
5. Capture network logs. Listen for page.on('response') and log responses with status 403, 429, 503, or redirects to known challenge domains.
6. Screenshot diff. Take full‑page screenshots in both real and automated sessions. Visual differences often reveal hidden overlays or missing dynamic content.

Interpreting the script output

The console prints four key values. Understanding each helps you decide whether Playwright was blocked.

• Status: A 200 status means the server delivered a page. A 403, 429, or 503 usually indicates a block at the HTTP layer.
• Final URL: If the URL changes to something like /challenge or /verify, the site redirected you to a verification flow.
• Title: Compare the title with the baseline. A generic title such as "Just a moment..." or "Access denied" signals a challenge page.
• CAPTCHA detected: true means an iframe or element matching common CAPTCHA selectors was found. This is a strong indicator of a bot block.
• Challenge page detected: The script scans the body text for keywords. true suggests a JavaScript or server‑side challenge even if no visible CAPTCHA appears.

When two or more of these signals differ from the baseline, you can confidently label the site as blocking Playwright.

Checklist: CAPTCHA vs. JavaScript challenge vs. IP‑based block

Use this quick list to classify the type of block you encounter.

1. CAPTCHA present
   • Visible iframe from hCaptcha, reCAPTCHA, Turnstile, or a custom provider.
   • Requires mouse click, checkbox, or image selection.
   • Script will return CAPTCHA detected: true.
2. JavaScript challenge
   • Page loads a blank or minimal DOM, then replaces it after a short delay.
   • Network shows a request to /cdn-cgi/challenge-platform or similar.
   • No visible CAPTCHA, but Challenge page detected: true and the title often reads "Checking your browser...".
3. IP‑based block
   • Immediate 403/429 response without any DOM changes.
   • Same response occurs in a regular Chrome session when using the same IP.
   • Switching to a residential proxy makes the page load normally, confirming an IP reputation issue.

Troubleshooting table for common Playwright detection signals

Common blocking signals to watch

• HTTP 403, 429, or 503 on the initial navigation or critical XHR/fetch calls
• Redirect to a challenge subdomain (e.g., challenge.example.com, cdn-cgi/challenge-platform)
• CAPTCHA iframes from providers like hCaptcha, reCAPTCHA, Turnstile, or custom challenges
• JavaScript challenges that require solving before the real content loads
• Empty or skeleton DOM where the real browser shows full content
• Missing cookies or localStorage values that the real browser sets

Advanced detection checks

Beyond the basic script, you can probe the specific fingerprints that anti‑bot systems evaluate:

• navigator.webdriver — should be undefined in a real browser; Playwright sets it to true unless masked.
• Chrome runtime — window.chrome.runtime exists in real Chrome; often missing or incomplete in automation.
• Permissions API — query navigator.permissions.query({name:'notifications'}); automation often returns a different state.
• WebGL fingerprint — getParameter(UNMASKED_VENDOR_WEBGL) and UNMASKED_RENDERER_WEBGL should match a real GPU.
• Canvas fingerprint — draw a known image and hash the output; headless browsers often produce different noise patterns.

BotRefund's approach cross‑checks these signals: "A single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. BotRefund keeps this signal as evidence—not a verdict—and cross‑checks it against independent browser, network, device, and behavior data."

What to do if blocking is confirmed

1. Use Playwright Stealth plugins. Community projects like playwright-stealth patch common fingerprints.
2. Rotate residential proxies. Data‑center IPs are heavily flagged; residential or mobile IPs reduce reputation‑based blocks.
3. Mimic human behavior. Add random delays, mouse movements, scroll patterns, and realistic click coordinates.
4. Persist browser state. Reuse a user-data-dir with cookies and localStorage from a prior manual login.
5. Consider a dedicated anti‑detect browser. Tools like Browserless, ScrapingBee, or Bright Data handle fingerprinting at scale.

Key facts

Limitations of this testing approach

• Some advanced blockers only activate after behavioral analysis (mouse heatmaps, scroll depth, dwell time). A single page load may not trigger them.
• Results can vary by IP reputation, time of day, and geographic location.
• Sites using client‑side fingerprinting (e.g., FingerprintJS, Castle) may require full session replay to evaluate.
• This guide covers detection, not bypass. Bypassing may violate terms of service or laws; consult legal counsel.

Frequently asked questions

How do I know if a block is Playwright‑specific vs. IP‑based?

Run the same script from a residential IP and a data‑center IP. If only the data‑center IP gets blocked, it's IP reputation. If both get blocked with identical fingerprints, it's browser automation detection.

Can I test blocking without writing code?

Yes. Use npx playwright open to launch a headed browser with the Playwright devtools recorder, then navigate manually and observe console errors or network failures.

Does headless mode always trigger blocks?

Not always. Some sites only challenge headless; others challenge any automation fingerprint regardless of headless state. Test both modes.

What's the difference between a CAPTCHA and a JavaScript challenge?

A CAPTCHA requires human interaction (image selection, checkbox). A JavaScript challenge runs silently in the background (proof‑of‑work, token generation) and redirects once solved.

How often should I re‑test a target site?

Anti‑bot vendors update fingerprints weekly. Re‑test after any Playwright version upgrade, when scrapers start failing, or on a monthly schedule for critical targets.

Can BotRefund help me understand why my Playwright traffic is blocked?

BotRefund's client‑side pixel captures 110+ behavioral, browser, hardware, and network signals per session. Their reports show exactly which signals triggered a bot classification, including the Playwright Init Scripts check, so you can see the specific evidence used.

Is it legal to test if a site blocks Playwright?

Testing your own access is generally acceptable. Scraping or bypassing blocks on third‑party sites may violate Terms of Service, CFAA, or GDPR. Always review the site's robots.txt, ToS, and applicable law before proceeding.

Why Invalid Traffic Skews Your Contact Rate Baseline

Your contact rate baseline measures the percentage of reported leads that turn into reachable, qualified conversations. When invalid traffic — bots, scrapers, click farms, and accidental clicks — gets counted as leads, the numerator inflates while the denominator (real human contacts) stays flat. The result: a baseline that overstates performance and misguides budget decisions.

Meta Ads Manager may show a steady cost per lead while your sales team receives disconnected numbers, copied messages, or enquiries that never progress. This gap between platform-reported leads and CRM outcomes is the first signal that invalid traffic is poisoning your data.

Signals That Indicate Invalid Traffic

Not every bad lead is a bot, and treating every unresponsive contact as fraud can make you exclude a valuable audience. Start with a structured audit that compares ad-platform data, website sessions, and CRM outcomes. The following signals, drawn from real investigation workflows, help separate normal lead-quality variation from automated and invalid activity:

• Contactability: Disconnected numbers, invalid email domains, repeated addresses, or an unusual concentration of one country code.
• Timing: Several leads arriving in short bursts, forms submitted immediately after landing, or conversions concentrated at unusual hours.
• Session behavior: No scrolling, no field corrections, uniform click paths, and no meaningful time on the offer page.
• Campaign patterns: A sharp lead-quality difference by placement, creative, audience expansion, device, or landing page.
• CRM outcome: A high reported lead count paired with no calls connected, demos booked, qualified opportunities, or repeat engagement.

These patterns repeat because automated traffic lacks the micro-variations of human behavior — tremor in mouse movement, hesitation before clicking, natural scroll depth, and variable form-completion speed.

Step-by-Step Investigation Workflow

A practical investigation preserves attribution before you change anything. Follow this sequence:

1. Preserve attribution before changing the campaign. Keep campaign, ad set, creative, placement, and click identifiers intact so you can trace each lead back to its source.
2. Export raw lead data from Meta Ads Manager. Include click IDs, timestamps, placement, creative, and audience segment for every conversion event.
3. Pull corresponding website sessions. Use your analytics platform or a client-side detection tool to capture session recordings, scroll depth, mouse paths, form-interaction timestamps, and behavioral fingerprints for each click ID.
4. Match leads to CRM outcomes. Tag each lead as connected, qualified, disqualified, or unreachable. Note the time from lead creation to first contact attempt and final disposition.
5. Score each lead against the five signal categories. Flag leads that show two or more invalid-traffic indicators (e.g., instant form submit + no scroll + disconnected phone).
6. Recalculate your contact rate using only clean leads. Divide qualified conversations by validated human leads. This is your true baseline.
7. Segment the clean baseline by placement, creative, and audience. Identify which segments drive real conversations versus which attract invalid traffic.
8. Document findings and set a re-audit cadence. Invalid traffic patterns shift; schedule monthly audits for high-spend campaigns and quarterly for lower spend.

Client-Side vs Server-Side Detection: What Catches What

Server-side audits examine server log files — IP addresses, request headers, user-agent strings. They catch basic scraper bots and known data-center ranges but struggle with advanced botnets that rotate residential proxies and mimic legitimate browser fingerprints.

Client-side audits run in the visitor's browser. They analyze mouse movement, scroll behavior, click timing, form-interaction patterns, and device sensors. This catches sophisticated automation that passes server-side checks: bots with realistic IPs but robotic linear mouse movements, superhuman input speed (under 1ms), grid-aligned movement patterns, absence of humanlike mouse tremor, and sessions with no clicks or scrolling.

For a clean contact rate baseline, you need both layers. Server-side filters remove known bad actors; client-side verification proves which remaining clicks are human.

Common Sources of Invalid Traffic on Meta Campaigns

Meta campaigns reach people across Facebook, Instagram, and eligible partner inventory at high volume. That reach brings invalid traffic through several channels:

• Meta Audience Network: Meta defaults to opting you into the Audience Network, which displays ads on thousands of third-party mobile apps and websites. Many publishers on this network use automated bots to click ads to generate artificial revenue. Clicks from Audience Network historically show high click-through rates and near-instant bounce rates.
• Profile scrapers and directory bots: Thousands of bots crawl Facebook and Instagram to scrape profile directories, group posts, and page data. When these bots follow outbound links on posts and ads, they register as clicks.
• Competitor click fraud: Competitors or hired click farms deliberately exhaust your budget by clicking ads repeatedly.
• Accidental mobile taps: Unintentional taps on mobile ad placements, especially in-feed and stories formats.
• Affiliate and lead-gen fraud: Fake submissions intended to earn affiliate payouts or inflate publisher performance metrics.

Each source leaves distinct behavioral fingerprints. Audience Network traffic often shows zero scroll depth and sub-second form completion. Scraper traffic may show normal navigation but no form interaction. Click farms may mimic human timing but repeat identical field structures across submissions.

Building a Clean Baseline: Practical Steps You Can Implement Today

You don't need enterprise tooling to start. Begin with these accessible steps:

1. Add a honeypot field to your lead forms. A hidden field that humans never see but bots fill out. Submissions with the honeypot populated are automatically flagged.
2. Enable Google reCAPTCHA v3 or hCaptcha on forms. These return a risk score; set a threshold that routes low-score submissions to a review queue instead of your CRM.
3. Track scroll depth and time-on-page via Google Tag Manager. Create a custom event that fires when a user scrolls past 25%, 50%, 75% of the page and spends more than 10 seconds. Leads without these events are suspect.
4. Capture click IDs (fbclid, gclid) in hidden form fields. This lets you join CRM records back to ad-platform data for the audit workflow above.
5. Set up a weekly data-quality review. Pull the last 7 days of leads, check contactability rates by source, and flag any placement or creative with a contact rate below 20% (adjust threshold to your historical norm).
6. Exclude Audience Network from lead-generation campaigns. In Meta Ads Manager, edit placements and uncheck Audience Network. Test the impact on lead volume and contact rate for 14 days before deciding.
7. Implement IP exclusion lists for known data-center ranges. Use a regularly updated feed (e.g., from your hosting provider or a threat-intel service) to block server-farm traffic at the firewall or CDN level.

These steps reduce invalid traffic entering your funnel. For ongoing protection and refund recovery, a dedicated client-side detection platform automates the behavioral analysis and generates the evidence files ad platforms require for refund claims.

Limitations and When This Advice Doesn't Apply

• Low-volume campaigns: If you generate fewer than 50 leads per month, statistical noise dominates. Focus on lead quality reviews rather than baseline precision.
• Brand-awareness objectives: Campaigns optimized for reach or video views don't produce leads; contact rate is the wrong metric.
• Offline conversion imports: If you import offline conversions (e.g., in-store purchases) without click IDs, you cannot trace invalid traffic to specific ad interactions.
• Single-channel attribution: This workflow assumes Meta is a primary lead source. Multi-touch journeys require a customer data platform to weight each touchpoint.
• Regulatory constraints: Some jurisdictions restrict behavioral tracking (e.g., GDPR consent requirements for mouse-movement recording). Verify compliance before deploying client-side scripts.

Key Facts

Frequently Asked Questions

How often should I re-audit my contact rate baseline?

Monthly for campaigns spending over $10,000/month; quarterly for lower spend. Re-audit immediately after major campaign changes (new creative, audience expansion, placement additions) or when you notice a sudden drop in contactability.

What's the difference between invalid traffic and low-quality leads?

Invalid traffic is non-human (bots, scripts, accidental clicks). Low-quality leads are real people who aren't ready to buy, gave fake details, or misunderstood the offer. Invalid traffic requires technical filtering; low-quality leads require better targeting, creative, or qualification.

Can I get refunds from Meta for invalid clicks?

Yes. Meta's Advertising Policies state advertisers should not be charged for clicks or impressions Meta determines are invalid — including automated bots, accidental clicks, and other non-genuine interactions. However, Meta's automated detection catches only a fraction. You need behavioral evidence (client-side logs showing automation) to file a successful claim.

Does excluding Audience Network hurt my reach?

It reduces impression volume, but for lead-generation campaigns, the trade-off is usually positive. Audience Network clicks historically show high CTR and near-instant bounce. Test with a 14-day A/B: one campaign with Audience Network, one without. Compare contact rate and cost per qualified conversation.

What if my CRM doesn't capture click IDs?

Add hidden fields to your forms for fbclid, gclid, and any other click identifiers. If your form builder doesn't support this, use a lightweight JavaScript snippet that reads URL parameters and populates hidden inputs on load. Without click IDs, you cannot join CRM outcomes to ad-platform data for the audit.

How much budget does invalid traffic typically waste?

Industry studies estimate 10–30% of programmatic ad spend goes to invalid traffic. For Google Search, invalid click rates range from 4% (well-protected accounts) to over 35% (high-CPC competitive keywords). On Meta, Audience Network and scraper traffic can push invalid rates higher in lead-gen campaigns. A $50,000/month budget could lose $5,000–$15,000 monthly.

Do I need a dedicated bot-detection tool, or can I build this myself?

You can build the basics: honeypots, CAPTCHA, scroll-depth tracking, IP exclusions. But sophisticated bots bypass these. A dedicated platform provides continuous behavioral fingerprinting (mouse tremor, input speed, path analysis), video session replay for evidence, and automated refund-report generation formatted for Meta and Google dispute processes. The ROI comes from recovered spend and cleaner optimization signals.

What Meta Considers Invalid Traffic

Meta defines invalid activity broadly, covering clicks from automated bots, accidental clicks, and other non-genuine interactions. However, the platform distinguishes between traffic it can verify server-side and traffic that requires advertiser-provided evidence. Server-side detection looks for rapid clicking from the same IP, duplicate click signatures, known data-center ranges, and abnormal patterns at the network level. These signals catch basic fraud but miss sophisticated operations that use residential proxy botnets — malware on household devices that routes clicks through legitimate consumer IPs — or click farms with rows of real smartphones.

According to Meta's policy, advertisers should not be charged for clicks or impressions the platform determines are invalid. The catch is that determination relies heavily on what Meta can see from its side. When bots mimic human behavior closely enough — scrolling, dwelling, even filling forms — server-side signals often appear normal. That gap is where refund claims live or die.

The Evidence Gap: Why Suspicious Isn't Enough

Most denied claims share a common flaw: they present suspicion instead of proof. A high bounce rate, low conversion rate, or spike in clicks from a single placement looks suspicious. But Meta treats those as campaign-performance indicators, not billing errors. The platform's automated filters already scanned that traffic and found nothing actionable. Resubmitting the same server-side data won't change the outcome.

What changes the outcome is client-side behavioral evidence captured on your landing page. BotRefund's detection layer records ghost clicks that fire without human intent, honeypot interactions with hidden page elements, robotic linear mouse movements, absence of humanlike mouse tremor, superhuman input speeds under one millisecond, grid-aligned movement patterns, sessions with no scrolling or clicks, and unnatural session durations that are too short, too long, or too uniform. Each of these signals produces a video-grade session replay that demonstrates automation rather than low intent.

Common Documentation Mistakes That Lead to Denial

• Submitting Ads Manager screenshots only. These show what Meta already saw. They don't add new evidence.
• Confusing lead quality with invalid traffic. A weak campaign attracts real people who aren't ready to buy. Disconnected numbers, invalid emails, or burst timing can indicate fraud, but they also appear in legitimate low-intent traffic. Without behavioral proof, Meta classifies this as audience mismatch.
• Failing to preserve attribution before changing campaigns. Pausing ads, switching placements, or rewriting creative destroys the click-to-session chain needed to tie a specific click ID to a bot session.
• Omitting placement-level breakdowns. Audience Network placements historically show high CTRs and near-instant bounce rates. A claim that aggregates all placements dilutes the signal. Isolate the problematic placement first.
• Providing CRM outcomes without session context. High reported leads with zero calls connected suggests fraud, but Meta needs the behavioral link between the click and the empty session.

Timing Errors: The Lookback Window Problem

Meta's refund process is less structured than Google's, and the platform does not publish a fixed lookback window. In practice, claims filed more than 30-60 days after the suspicious activity face steep odds. Advertisers often wait until monthly reporting reveals the waste, by which point the click IDs (FBCLIDs) have aged out of Meta's dispute system. BotRefund auto-captures FBCLIDs at the moment of click and preserves them alongside the behavioral evidence, so the dispute package is ready before the window closes.

How Meta's Automated Detection Falls Short

Meta's systems analyze traffic patterns across its network: rapid clicking, duplicate signatures, known bad IPs, and abnormal server-level patterns. These catch crude automation — data-center bots, simple scripts, obvious click farms. They miss residential proxy botnets that route through real household IPs, click farms using actual mobile devices, and browser automation that replicates human-like scrolling and dwell time. Because these advanced bots operate on real devices with real IPs, they pass server-side checks. The only reliable detection happens on the client side, where mouse tremor, input speed, and movement geometry reveal the absence of a human operator.

Behavioral Evidence That Actually Works

Winning claims share a specific evidence package: click IDs (FBCLIDs) tied to session replays showing one or more bot signatures. The strongest signals are superhuman input speed (interactions faster than 1ms), absence of mouse tremor (the micro-jitter present in every human movement), grid-aligned paths (movement snapping to precise lines instead of natural curves), honeypot triggers (interactions with elements invisible to humans), and ghost clicks (click events without preceding intent signals like hover or approach). Session behavior signals — no scrolling, no field corrections, uniform click paths, zero meaningful time on page — support the case but rarely suffice alone. The combination of a captured FBCLID and a replay showing automated behavior is what moves a claim from "suspicious" to "proven invalid."

The Audit-First Approach That Prevents Denials

Before filing any claim, run a structured audit that compares three data layers: ad-platform data (clicks, placements, FBCLIDs), website sessions (behavioral logs, scroll depth, interaction timestamps), and CRM outcomes (contactability, qualification, revenue). This triad separates normal lead-quality variation from automated fraud. Start by preserving attribution — do not pause campaigns or change targeting until click IDs are mapped to sessions. Then segment by placement, creative, audience expansion, device, and landing page. A sharp lead-quality difference in one segment signals a traffic-quality issue worth disputing. Finally, quantify the waste: BotRefund customers recover up to 20% of paid ad budgets, with an 83% refund approval rate across submitted claims. The audit tells you whether your situation fits that pattern or whether the problem is targeting, creative, or offer.

Key Facts

Limitations and When This Advice Doesn't Apply

• Brand-new campaigns with under 1,000 clicks. Statistical noise dominates; wait for volume before auditing.
• Advertisers who cannot install JavaScript on their landing pages. Client-side detection requires script execution.
• Claims for traffic older than 60-90 days. FBCLIDs expire; Meta's dispute system will not accept them.
• Pure lead-quality complaints without behavioral anomalies. If sessions show human behavior (scrolling, corrections, variable timing), the issue is targeting or offer, not invalid traffic.
• Accounts with policy violations unrelated to traffic quality. Outstanding policy issues can block refund processing entirely.

FAQ

How long does Meta take to review a refund claim?

Meta does not publish a standard timeline. Claims with complete behavioral evidence and FBCLIDs typically resolve in 2-4 weeks. Incomplete claims stall indefinitely or receive generic denials.

Can I get a refund for Audience Network traffic specifically?

Yes. Audience Network placements are a documented source of bot clicks. Isolate the placement in your claim, attach session replays from that placement showing automation, and reference the FBCLIDs. Meta treats placement-level claims the same as campaign-level claims.

What if Meta already issued an automatic invalid-activity credit?

Automatic credits cover only what Meta's server-side systems caught. They rarely exceed 1-2% of spend. You can still file a manual claim for the remainder with client-side evidence. The two processes are independent.

Does BotRefund guarantee a refund?

No. The 83% approval rate reflects historical outcomes across clients who submitted claims with BotRefund evidence. Approval depends on Meta's review, the strength of the evidence, and whether the traffic meets Meta's invalid-activity definition. BotRefund provides the evidence; the platform decides.

How much does BotRefund cost?

Pricing scales with monthly ad spend: under $10K, $10K-$50K, $50K-$250K, $250K-$1M, $1M-$5M, over $5M. A free bot audit is available at every tier. Enterprise plans include dedicated support and custom SLAs.

Can I use this evidence for Google Ads refunds too?

Yes. The same behavioral signals — superhuman speed, absent tremor, grid-aligned movement, honeypot triggers — satisfy Google's invalid-activity credit requirements. BotRefund captures GCLIDs alongside FBCLIDs and generates compliance-ready reports for both platforms.

What happens if my claim is denied?

Review the denial reason. If Meta cites insufficient evidence, strengthen the behavioral package: add more session replays, isolate a narrower date range or placement, and resubmit. If Meta disputes the classification (e.g., calls it low-quality rather than invalid), escalate with a representative using the audit report as a briefing document. BotRefund customers can request a re-audit at no extra cost.

Hypothetical scenario: You run a lead generation campaign on Meta. Ads Manager shows a steady cost per lead, but your sales team gets disconnected numbers, copied messages, and unreachable contacts. A manual audit takes hours and still misses subtle patterns. An AI audit scans thousands of sessions, finds that 35% of leads arrived in bursts of 10+ within 2 seconds, used identical browser fingerprints, and had zero scrolling. You now have clear evidence to stop the campaign and request a refund.

How AI Audits Differ From Manual Checks

Manual audits rely on looking at IP addresses, timestamps, and user-agent strings. AI goes deeper by analyzing session behavior, JavaScript events, mouse movements, and network timing. It can cluster similar sessions and flag anomalies without predefined rules. This is critical because Meta’s own detection systems catch only a fraction of invalid traffic, especially when bots use realistic fake accounts and residential proxies.

Manual review needs a person to read each log entry. That process slows down when traffic volume grows. AI can evaluate millions of sessions in minutes. It reduces the chance of human fatigue and oversight.

AI tools produce a confidence score for each flagged session. The score reflects how many signals point to non‑human behavior. A high score gives advertisers strong evidence for a refund claim.

Human analysts still review edge cases. For example, a power user who fills forms quickly may look like a bot. The analyst decides whether the signal pattern truly indicates automation.

Key Signals AI Can Detect

AI tools look for patterns across multiple dimensions. These include:

• Contactability: Disconnected numbers, invalid email domains, repeated addresses, or an unusual concentration of one country code.
• Timing: Several leads arriving in short bursts, forms submitted immediately after landing, or conversions concentrated at unusual hours.
• Session behavior: No scrolling, no field corrections, uniform click paths, and no meaningful time on the offer page.
• Campaign patterns: Sharp lead‑quality differences by placement, creative, audience expansion, device, or landing page.
• CRM outcome: High reported lead count paired with no calls connected, demos booked, qualified opportunities, or repeat engagement.

Each signal is measured by a specific data point. For example, the tool records the exact timestamp of each form field change. It then calculates the time between the page load and the final submit click.

When many signals align, the AI raises a flag. The system logs which signals contributed to the decision. This transparency helps advertisers verify the finding.

A Practical AI Audit Workflow

1. Keep attribution intact – Do not change campaign settings before collecting evidence. Pause the ad set but keep the records.
2. Install a client‑side tracker – Use a tool like BotRefund that adds a script tag to your site. It captures behavioral data without affecting pixel performance.
3. Let AI analyze sessions – The tool processes clicks, page loads, and form interactions. It flags sessions with high bot probability.
4. Review the evidence – Check session recordings, signal‑by‑signal reasoning, and click IDs. Confirm the flagged traffic truly lacks human engagement.
5. Build a refund report – AI tools generate reports in the format Meta’s team accepts, including timestamps, campaign details, and behavioral logs.
6. File the claim – Submit the evidence through Meta’s refund process. If you use a service like BotRefund, they can help negotiate the claim.

Each step preserves the original data chain. Changing bids or pausing ads after data collection could alter the evidence and weaken a claim.

The client‑side script runs in the browser. It collects mouse movements, key presses, and visibility changes. These data points are sent securely to the analysis engine.

The analysis engine runs in the cloud. It applies machine‑learning models trained on labeled bot and human sessions. The output includes a probability score and a list of triggered signals.

After review, the advertiser can export a PDF or CSV report. The report matches the template Meta provides for invalid‑traffic claims.

Limitations of AI Auditing

AI is not perfect. It can produce false positives if a real user behaves unusually — for example, a power user who fills forms quickly or a tester who clicks repeatedly. The tool’s confidence score matters; low scores should trigger manual review.

AI cannot fix the root cause of bot traffic; it only identifies and documents it. Advertisers still need to adjust targeting, block known bad IPs, or suppress bot activity to prevent future waste.

Platforms like Meta may still reject claims if the evidence does not meet their internal criteria, even with AI‑generated reports. Advertisers should check Meta’s current evidence requirements before filing.

Some sophisticated bots emulate human‑like mouse movements and scrolling. If the bot’s behavior falls within the normal variance of human users, detection confidence drops.

Cost models vary. Some tools charge a monthly fee; others take a percentage of recovered funds. Advertisers should verify pricing with the vendor.

Key Facts About AI Bot Detection for Meta Ads

Frequently Asked Questions

Does Meta detect all bot traffic automatically?

No. Meta’s automated systems catch only a fraction of invalid activity, especially sophisticated bot traffic using residential proxies and realistic fake accounts. Proactive auditing with AI is needed to identify the rest.

How long does an AI audit take?

With a tool like BotRefund, you can install the script in about one minute. The AI processes data in real time, and you can see results within hours or days depending on traffic volume.

Can AI prevent bots from clicking my ads in the first place?

AI primarily detects and documents bot traffic after it happens. Some tools can block bot sessions in real time by suppressing pixels or redirecting, but prevention requires ongoing monitoring and adjustment of campaign settings.

What if the AI says a session is a bot but I’m not sure?

Review the session recording and the signal‑by‑signal explanation. Good AI tools provide transparent reasoning so you can confirm the flags. If you are still unsure, consult with the tool’s support team.

Is AI auditing expensive?

Many AI audit tools offer free tiers or upfront‑free enterprise models. For example, BotRefund charges no upfront fee for enterprise recovery; fees come from recovered funds. Smaller accounts may have monthly subscription options.

Will AI work for small budgets?

Yes. AI auditing is scalable. Even small campaigns with a few hundred leads can benefit from automated analysis. The same detection signals apply regardless of spend level.

What does a refund‑ready report from AI look like?

It includes click IDs, campaign details, timestamps, session recordings, and a clear explanation of each detection signal. The report is structured in the format that Meta’s review team accepts.

Limitation to remember: BotRefund works on the client side only. It cannot catch server-side fraud or bot traffic that never loads the page. Keep this in mind while reading the details below.

Why Privacy Matters in Bot Detection

Advertisers care about privacy for three reasons: user trust, legal compliance, and the quality of the evidence they submit.

Users do not expect every website tool to read their personal data. A detection script that collects names, emails, or browsing history creates a new privacy problem while trying to solve a fraud problem. That trade-off is unacceptable for most businesses.

Laws such as GDPR and CCPA set clear boundaries. Advertisers need to show that data collection is necessary, limited, and safe. BotRefund's approach fits those boundaries because it does not need personal identifiers to detect bots.

There is also a practical reason. Refund claims depend on evidence. If the evidence includes personal user data, the claim becomes harder to defend. Behavioral metadata is easier to explain to an ad platform and to a privacy officer.

Bot fraud is not just a cost problem. It also poisons conversion data. When a bot triggers a pixel, the ad platform learns the wrong pattern. Privacy-safe detection lets you remove that noise without collecting extra personal data.

What BotRefund Does and Does Not Access

BotRefund's script is a small piece of JavaScript. It observes how a visitor interacts with the page. It does not build a profile of who they are.

What it accesses:

• Aggregate ad-performance data, such as click volume and campaign trends.
• Traffic metadata, such as timestamps, IP address, and user-agent string.
• Client-side behavioral signals: ghost click, trap, pointer, motion, speed, path, engagement, and session behavior.

What it does not access:

• Names, email addresses, phone numbers, or other personal identifiers.
• Form contents, passwords, payment card details, or private messages.
• CRM records, lead scores, revenue data, or other business systems.

The behavioral signals are designed to tell machines apart from humans. They do not require reading what a user types, who they are, or what they buy.

How Data Is Collected and Protected

Setup is fast. The vendor says an advertiser can add the BotRefund script in about one minute. No credit card is required for the free audit.

1. Add the script to the site.
2. The script records behavioral metadata during each page session.
3. The data is aggregated and compared with known bot patterns.
4. The report flags visits that match the criteria.

The table below shows the main signals BotRefund uses.

After collection, the protection steps matter.

• Data is stored in anonymized, aggregate form where possible.
• Raw technical identifiers are not shared with third parties.
• Retention is limited to what the audit needs.
• The process is designed to meet GDPR, CCPA, and other major data-protection frameworks.

Advertisers often ask whether this is legal. The answer depends on how the data is used. BotRefund uses it for a specific security purpose and does not sell it.

Practical Steps for Advertisers

You do not need to be a privacy lawyer to use BotRefund. Follow the same workflow the company recommends.

1. Install the script in about one minute.
2. Run the free AI audit on live traffic.
3. Review the report for suspicious behavioral patterns.
4. Export the report with click IDs and video proof for each bot click.
5. Send the report to your Google or Meta representative.
6. Claim a refund for invalid clicks.

BotRefund reports that 83% of customers successfully receive a refund. The vendor also says bot clicks can steal up to 20% of Google and Meta ad budgets. These numbers explain why the audit is worth the time.

Use the same report internally. Stop targeting placements that generate nothing but bot clicks. Then shift that portion of the budget to audiences that convert.

You should also document the date of the audit and the campaign details. That makes the refund request easier to review.

Trade-offs and Limitations

Every detection method has limits. The most important one is scope.

Limitation to remember: BotRefund only sees client-side behavior in the browser. It cannot detect server-side fraud, API abuse, or invalid clicks that never load the page. It also cannot prove that a visit comes from a specific human being.

This limitation means BotRefund is not a complete fraud solution. Use server logs and platform-side filters for the parts it cannot see.

Privacy-safe detection also has a functional trade-off. Because BotRefund avoids personal data, it cannot judge lead quality. A bot can be flagged as suspicious, but a real human with no buying intent will not be flagged. Those are different problems.

False positives can happen. A real user with very little movement or an unusually fast form fill might look automated. The refund workflow is designed for this. It gives the advertiser evidence to review before making a claim.

No model is perfect. Sophisticated bots can imitate human motion and timing. BotRefund updates its models, but advertisers should check reports regularly and combine tools when needed.

Frequently Asked Questions

What personal data does BotRefund see?

It sees only technical metadata such as IP address, user-agent, timestamps, and behavioral signals. It does not see names, emails, or contact details.

Is an IP address considered personal data?

It can be under GDPR and similar laws. BotRefund treats it as metadata and limits its use to fraud detection.

Is data stored permanently?

No. Data is kept only as long as needed for the audit and then deleted or fully anonymized.

Does BotRefund comply with GDPR and CCPA?

Yes. The service is designed around data-protection rules and does not rely on personal identifiers.

Can I opt out?

You can choose not to install the script. Since BotRefund does not collect personal identifiers, there is no separate opt-out.

Does BotRefund guarantee a refund?

No. The vendor reports an 83% success rate, but the final decision belongs to Google or Meta.

When click fraud protection pays off: a spend-and-risk matrix

The decision comes down to two variables: monthly ad spend and how much invalid traffic your vertical attracts. Use this matrix to decide.

How Google’s built-in protection falls short

Google Ads includes automatic invalid click detection, but it has two blind spots that matter for decision-making.

• It catches less than half of invalid traffic. The remainder is classified as sophisticated invalid traffic (SIVT) — bots that mimic human behavior well enough to slip past automated filters.
• It doesn’t protect your conversion pixels. When bots trigger conversion events, Smart Bidding optimizes toward that poisoned data, amplifying waste over time.

According to aggregated audit data, the average invalid click rate across all Google Ads campaigns is 11% to 14%. Google’s own automated filters catch less than 50% of invalid traffic, leaving the rest as SIVT that requires manual evidence submission for refunds.

What third-party tools actually do differently

Not all tools are equal. The ones that move the needle share five capabilities. If a tool lacks any of these, it’s essentially an IP blocklist with a dashboard.

• Behavioral detection — analyzes mouse movement, scroll depth, session timing, and pointer patterns to spot bots using residential proxies and browser automation.
• Conversion pixel protection — prevents invalid sessions from firing your Google Ads conversion tags, keeping Smart Bidding data clean.
• GCLID evidence capture — links every Google Click ID to behavioral proof of invalidity, producing audit-ready reports Google’s refund team accepts.
• Real-time filtering — blocks or flags traffic during the session, not after the budget is spent and the pixel is poisoned.
• Transparent, spend-based pricing — scales with your ad spend, not arbitrary seat limits or hidden fees.

Tools that rely solely on IP blacklists or rate limiting miss modern bot networks that rotate residential IPs and mimic human timing.

Decision framework: buy vs. build vs. ignore

Walk through these steps in order. Stop when you hit a “yes.”

1. Run a free bot audit. Most vendors (including BotRefund) offer a no-cost scan that quantifies invalid traffic percentage and estimated monthly waste. If the audit shows under 5% invalid traffic, you likely don’t need a tool.
2. Check your invalid click report in Google Ads. Go to Campaigns → Columns → Performance → Invalid clicks. If the rate is consistently above 8% and your spend exceeds $3,000/month, move to step 3.
3. Calculate break-even. Monthly tool cost ÷ (monthly spend × invalid click rate × average CPC) = months to break even. If it’s under 2 months, the tool pays for itself quickly.
4. Evaluate pixel poisoning risk. Are you using Smart Bidding (Target ROAS, Target CPA, Maximize Conversions)? If yes, bot-triggered conversions are actively retraining your bid strategy. Pixel protection becomes mandatory, not optional.
5. Decide on refund pursuit. If you want to recover past waste (Google allows refund requests back to 2017), you need GCLID capture and dispute-ready reports. Manual submission is possible but time-intensive at scale.

Key facts from industry data

Common mistakes when evaluating tools

• Comparing on price per click instead of price per recovered dollar. A $0.01/click tool that catches 20% of bots costs more than a $0.03/click tool that catches 80% and automates refunds.
• Assuming Google’s refund process is automatic. It isn’t. You must submit GCLIDs with behavioral evidence for each disputed click. Tools that only “block” without evidence capture leave money on the table.
• Ignoring pixel poisoning. Blocking the click after the conversion pixel fires doesn’t undo the damage to Smart Bidding. The tool must suppress the pixel event in real time.
• Buying enterprise features you won’t use. If you manage under $50,000/month, you don’t need multi-account dashboards, SSO, or dedicated success managers. Pay for detection and refund automation only.

Limitations and when this advice doesn’t apply

• Brand-new accounts with no history. You need at least 2–4 weeks of traffic data before a bot audit or invalid click report is meaningful.
• Pure brand campaigns with exact-match branded terms. Invalid click rates on branded terms are typically under 3% because competitors rarely bid on your brand and bots don’t target it.
• Accounts using only Display or Video campaigns. The fraud vectors differ (impression fraud, viewability fraud). This framework focuses on Search and Shopping click fraud.
• Advertisers in countries where Google’s refund policy is stricter. The 2017 lookback and 83% success rate reflect U.S./EU experience. Local policies may vary.

FAQ

How much does click fraud software typically cost?

Most vendors price as a percentage of ad spend (1–3%) or a flat monthly fee tiered by spend brackets. For a $10,000/month account, expect $100–$300/month. Enterprise tiers ($250,000+ spend) often include custom SLAs and dedicated refund teams.

Can I just block suspicious IPs in Google Ads myself?

You can exclude up to 500 IP ranges per campaign. This works for obvious data-center traffic but misses residential proxy networks, which account for the majority of sophisticated invalid traffic. IP blocking is a band-aid, not a solution.

Does click fraud protection slow down my landing pages?

Reputable tools load asynchronously via a single script tag (usually under 50 KB) and process behavioral signals in the browser without blocking page render. Page speed impact is typically under 50 ms.

What’s the difference between click fraud protection and bot management platforms?

Bot management platforms (e.g., Cloudflare Bot Management, Akamai Bot Manager) protect your entire site from scraping, credential stuffing, and inventory hoarding. Click fraud tools focus specifically on ad traffic: they capture GCLIDs, protect conversion pixels, and format evidence for ad platform refunds. They’re complementary, not interchangeable.

How long until I see results after installing a tool?

Detection starts immediately. Pixel protection takes effect on the next session. Refund recovery depends on Google’s review cycle — typically 2–6 weeks for the first batch. ROAS improvement from clean bidding data appears within 6–8 weeks as Smart Bidding relearns from human-only conversions.

Should agencies manage this for clients or let clients buy directly?

Agencies managing multiple accounts benefit from centralized dashboards, white-label reporting, and volume pricing. If you manage 5+ client accounts, an agency-tier plan usually costs less per account than individual subscriptions and gives you a single view of invalid traffic across the portfolio.

The practical result is two-fold: you continue paying for traffic that will never convert, and you lack the structured evidence package that Meta's review teams accept. BotRefund's data shows that across more than 2,500 brand audits, 83% of clients recover funds from Google and Meta when they submit reports built with 110+ behavioral, browser, hardware, network, and attribution signals, including click IDs, timestamps, session recordings, and signal-by-signal reasoning. In-house teams rarely have the tooling to collect that depth of evidence, nor the repetition to know how Meta's reviewers evaluate each signal.

Why In-House Audits Miss the Hardest Invalid Traffic

Server-side audits examine IP addresses, request headers, and user-agent strings. They reliably catch data-center bots and basic scrapers. They struggle against modern botnets that rotate residential IPs, automate real browsers via tools like Puppeteer or Playwright, and mimic human timing. Meta's own automated systems face the same blind spot: they catch only a fraction of invalid activity, leaving sophisticated traffic to poison pixel data and inflate costs.

Client-side auditing — running JavaScript in the visitor's browser — captures the behavioral layer that server logs cannot see: whether a user scrolled, corrected a form field, moved the mouse naturally, or spent meaningful time on the offer page. Without that layer, a session that loads the page, clicks the button, and fires the conversion event looks identical to a genuine lead. One BotRefund guide notes that "without browser-level auditing, you pay for these visits" and that server-side methods "struggle to detect advanced botnets."

The Evidence Gap: What Meta Accepts vs What You Can Collect

Meta's refund process is less structured than Google's, which makes evidence quality decisive. A successful claim needs click IDs (fbclid), campaign/ad set/ad identifiers, precise timestamps, session recordings, and a signal-by-signal explanation of why each session is automated rather than merely suspicious. BotRefund produces "refund-ready reports" in the exact format platform teams use to review invalid traffic claims. Building that report format internally requires mapping Meta's evidence expectations, maintaining session-recording infrastructure, and writing the narrative reasoning for each flagged session — work that falls outside a typical marketing or analytics team's scope.

In-house teams also face an attribution preservation problem. The practical investigation workflow starts with "Preserve attribution before changing the campaign." If you pause a campaign, adjust targeting, or rewrite creative before exporting click IDs and landing-page parameters, you lose the chain of evidence linking a specific invalid click to a specific spend line. That discipline is easy to break under performance pressure.

Four Operational Limitations That Slow Internal Teams

1. Signal breadth. The 110+ signals used for 99% confidence span behavioral (scroll, dwell, interaction patterns), browser (canvas fingerprint, WebGL, audio context), hardware (battery, memory, CPU cores), network (TCP/IP fingerprint, TLS JA3, proxy detection), and attribution (click ID, campaign hierarchy, UTM integrity). Assembling and maintaining that signal library is a dedicated engineering effort.
2. Session-level reasoning. Meta reviewers expect a clear explanation per session, not an aggregate "invalid traffic estimate." Writing that reasoning at scale requires either a large analyst team or an automated reasoning engine that maps signals to conclusions.
3. Negotiation experience. Across 2,500+ audits, BotRefund has learned how to present evidence to Meta's review teams — which signals they weight heavily, how they handle borderline cases, and what documentation shortens the back-and-forth. That institutional knowledge compounds with each claim.
4. Four-layer audit discipline. BotRefund's four-layer audit framework covers platform delivery, landing-page evidence, lead verification, and sales outcome feedback. Each layer demands different data sources (Ads Manager, web analytics, CRM, sales dispositions) and cross-referencing logic. Keeping that process current as Meta adds placements, creative formats, and attribution changes is ongoing work.

How Pixel Poisoning Compounds the Problem

When bots trigger conversion events, Meta's optimization algorithm treats those events as success signals and seeks more similar traffic. BotRefund's research describes the CMO nightmare: "the campaign starts great, something changes, and performance becomes inexplicably worse even though the creative, offer, landing page, and audience stay the same." If bots make up 30% of early traffic, the model learns from a contaminated sample and redirects spend toward more bot-like users. An in-house audit that runs monthly or quarterly cannot prevent this feedback loop; it can only diagnose the damage after the algorithm has already shifted. Real-time client-side detection that blocks or flags bots before the conversion pixel fires is the only way to keep the training data clean.

A Diagnostic Order for Deciding Whether to Build or Buy

1. Measure your baseline. Calculate landing-page sessions per click, contactable leads, verified leads, qualified opportunities, and revenue by campaign, placement, and audience. Use enough volume to see consistent quality patterns, not single-day noise.
2. Quantify the gap. Compare Meta-reported conversions to CRM-verified outcomes. A persistent 10–30% gap (the range cited for programmatic invalid traffic) signals a problem worth solving.
3. Test server-side only. Run IP reputation, user-agent, and data-center filters for 30 days. Track how many flagged sessions also show behavioral anomalies (instant form submit, no scroll, zero dwell). If most anomalies escape server-side filters, you have a client-side blind spot.
4. Estimate build cost. Count engineering weeks to implement 110+ signals, session recording, report generation in Meta's format, and a claim-submission workflow. Add ongoing maintenance for browser updates, proxy technique shifts, and Meta policy changes.
5. Compare to managed outcome. BotRefund's 83% recovery rate across 2,500+ audits provides a benchmark. If your internal build cannot credibly match that evidence quality and negotiation track record, the managed path recovers money faster.

Key Facts

Terminology

• Invalid traffic (IVT): Clicks or impressions Meta determines are not genuine user interest — bots, click farms, accidental taps, automated scripts.
• Client-side audit: JavaScript running in the visitor's browser that captures behavioral and fingerprint signals invisible to server logs.
• Server-side audit: Analysis of web server logs (IP, headers, user-agent) without browser-level visibility.
• Pixel poisoning: Conversion events fired by bots that train Meta's optimization model to target similar non-human traffic.
• Refund-ready report: Evidence package structured in the format Meta's review teams expect, including click IDs, session recordings, and per-session reasoning.
• Click ID (fbclid): Unique identifier Meta appends to landing-page URLs to tie a click to a specific ad, placement, and auction.

FAQ

Can't I just use Meta's built-in invalid traffic reporting?

Meta's automated systems catch only a fraction of invalid activity. Sophisticated bots using residential proxies and browser automation routinely bypass those filters. To recover spend from that traffic, you must file a proactive claim with behavioral evidence Meta's systems missed.

What's the minimum signal set an in-house team needs to credibly claim a refund?

At minimum: click ID (fbclid), campaign/ad set/ad hierarchy, timestamp, landing-page URL with parameters, session recording or detailed behavioral log (scroll, dwell, form interactions), browser fingerprint, network fingerprint, and a written explanation mapping each signal to the conclusion "automated, not human." Meta's process is less structured than Google's, so completeness matters more.

How often should we audit if we stay in-house?

Monthly is the practical floor. Bot tactics shift weekly; placement mix changes with each campaign launch; Meta's own detection updates without notice. A quarterly audit lets three months of poisoned pixel data accumulate before you catch it.

Does a high lead volume make in-house auditing more viable?

Volume helps statistical confidence but increases the evidence burden. Each flagged session still needs individual reasoning for Meta's reviewers. Without automation, analyst time scales linearly with flagged sessions, making high-volume accounts the hardest to audit manually.

What's the fastest way to test whether our in-house audit is missing sophisticated bots?

Run a parallel client-side detection script on a single high-spend campaign for 14 days. Compare its flagged sessions to your server-side flags. If the client-side layer finds invalid sessions your server logs missed — especially sessions with residential IPs, real browser fingerprints, and human-like timing — you have a measurable blind spot.

When does it make sense to build internal capability instead of buying?

When you have a dedicated security/analytics engineering team, a multi-year roadmap for signal maintenance, and enough claim volume to amortize the build cost. For most advertisers spending under seven figures annually on Meta, the managed path recovers more money per dollar of effort.

Readiness Checklist

Before contacting BotRefund, check for these patterns. They come from real cases of invalid traffic. If you see several of these signs, it is time to act.

• Contactability issues: Leads have disconnected phone numbers, invalid email domains, repeated addresses, or an unusual concentration of one country code. This means the data is not real.
• Timing anomalies: Several leads arrive in short bursts. Forms are submitted immediately after landing. Conversions happen at unusual hours, like 3 AM in your time zone.
• Session behavior red flags: No scrolling, no field corrections, uniform click paths, and no meaningful time on the offer page. Real users pause, scroll, and correct mistakes.
• Campaign patterns: A sharp lead-quality difference by placement, creative, audience expansion, device, or landing page. For example, one placement delivers only bad leads while others perform well.
• CRM outcomes: High reported lead count paired with no calls connected, demos booked, qualified opportunities, or repeat engagement. The sales team gets nothing from the leads.

If you see these signs, you likely have bot traffic. Do not wait. The problem worsens as algorithms learn from bad data.

How BotRefund Detects Suspicious Visits

BotRefund uses client-side behavioral signals. These are actions that happen in the browser. They are hard for bots to fake. Here are the key signals detected:

• Ghost clicks: Clicks that happen without the natural sequence of human intent. A real user moves the mouse, hovers, then clicks. Bot clicks often appear out of order.
• Honeypot traps: Hidden elements on the page that only bots interact with. Real users never see them. If a bot triggers a honeypot, BotRefund flags it.
• Robotic linear mouse paths: Real mouse movement has curves and small corrections. Bots move in straight lines from point A to point B.
• Superhuman input speed: Actions that happen in less than one millisecond. A human cannot type or click that fast. This is a clear sign of automation.
• Grid-aligned movement patterns: Bots often snap to pixel-perfect lines or blocks. Natural human movement is messy and uneven.
• Absence of clicks or scrolling: Real users scroll and click around the page. Bots often load the page and do nothing. They just trigger the pixel.
• Unnatural session durations: Visits that are too short (under 2 seconds) or too uniform (every session exactly 10 seconds). Real users vary widely.

These signals are collected by a small JavaScript snippet. You add it to your site in about one minute. No credit card needed. BotRefund then creates a video proof of each suspicious session. This evidence is used to file refund claims.

Server-Side vs. Client-Side Audits

There are two ways to detect bot traffic. Each has strengths and weaknesses.

Server-side audits look at log files from your web server. They check IP addresses, user agents, and request patterns. This can catch data center IPs and known bad bots. But it misses many modern bots. Those bots use residential proxies and real browsers. They look like normal traffic at the server level. Server-side audits are cheap but often incomplete.

Client-side audits run in the browser. They capture mouse movements, clicks, scrolls, and input timing. This is the only way to see behavioral patterns. BotRefund uses client-side signals. This gives you stronger evidence. You can prove a bot clicked because no human would move that way. Client-side audits are more accurate. They detect the bots that server logs miss.

The trade-off is setup. You need to add a tracking code. But the code is lightweight and does not affect page speed. Once installed, you get real-time data. For refund claims, client-side evidence is required. Google and Meta ask for it. Without it, your claim is weak.

Why does this matter? Bot traffic can look like normal lead-quality variation. A weak campaign might attract uninterested real people. But a bot attack causes sudden, repeatable patterns. Server logs alone cannot tell the difference. Client-side audits can. That is why BotRefund recommends client-side detection for any serious investigation.

Limitations and When This Advice Doesn’t Apply

BotRefund is powerful, but it has limits. Understand them so you know when to act.

• Minimum ad spend threshold: If your monthly ad spend is under $10,000, a refund claim may not be cost-effective. The refund amount might not justify the effort. However, you can still run a free audit to learn about your traffic.
• Tracking code must be active: BotRefund needs its JavaScript snippet on your site. If you remove it or never install it, no evidence is collected. You cannot go back in time. Install it now to protect future spend.
• Reliance on server-side logs alone: If you only look at server logs, you may miss the behavioral signals that prove bot activity. Server logs show IP and user agent, but not mouse movement. Without client-side data, your refund claim is unlikely to succeed.
• Harmless surges vs. sustained invalid traffic: A one-time spike from a viral post is normal. Wait a day or two. If the spike persists and shows the patterns above, then contact BotRefund. Not every surge is fraud.
• Past claims: BotRefund can generate evidence for historic campaigns, but only if the tracking code was active during those campaigns. You cannot prove past fraud without past data.

This advice does not apply if you are running a brand awareness campaign without conversion tracking. Bot traffic there is less harmful. It also does not apply if you are using only organic traffic. Paid ads are the main target for refunds.

Steps to Prepare Your Case

Once you see the signs, follow these steps. They increase your chance of a refund.

1. Gather the metrics from the readiness checklist. Export your ad platform data showing the spike in clicks or leads.
2. Run a BotRefund audit. The free audit gives you a report with video evidence. It takes one minute to set up.
3. Document the impact. Show how cost-per-lead or cost-per-acquisition changed. Compare before and after the suspicious traffic started.
4. Submit the report through the BotRefund support portal. They will help you file a claim with Google or Meta.
5. Respond to any questions from the ad platform. BotRefund provides a compliance-ready report. This speeds up the process.

Do not change your campaign settings before collecting evidence. Pausing campaigns may delete the data you need. Let the audit run first.

FAQ

• What counts as evidence for a refund claim? Video proof of bot behavior, such as linear mouse paths or superhuman speed, along with a report showing the traffic pattern. BotRefund provides both.
• Are Google or Meta refunds automatic? No. You must file a claim. Google and Meta have automated systems, but they miss many bots. You need to submit evidence to get paid.
• How far back can refund claims go? Google allows claims for invalid activity dating back to 2017, but only if you have evidence from that time. Meta has a 60-day limit for most claims. Install BotRefund now to protect future spend.
• What does the 83% success rate mean? That is the percentage of BotRefund clients who successfully received a refund after submitting a claim. It means the evidence is strong enough most of the time.
• What if I see a spike but my conversion rate stays steady? The spike could be harmless. But run a BotRefund audit to confirm. Some bots mimic human behavior and still convert at a low rate.
• How long does the audit take? Setup is about one minute. The first report is ready within minutes of traffic collection. You see results fast.
• Do I need a paid plan to get help? No. The free audit provides enough data to decide if a refund claim is viable. Paid plans offer more features, but the free tier is sufficient for initial evaluation.
• Can BotRefund recover spend from past months? Yes, if the tracking code was active during those months. It can generate evidence for historic campaigns and help you file claims retroactively.