Seatext library / BotRefund evidence
Why BotRefund Activation Fails and How to Fix It
BotRefund activation typically fails due to script placement errors, missing pixel permissions, or ad-account access gaps. Most issues resolve by verifying the tracking snippet loads on every landing page, confirming the Meta Pixel or...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
What Causes Activation to Fail
BotRefund activates when its client-side script loads on your landing pages, captures behavioral signals, and links those signals to your ad-platform click IDs (GCLID for Google, FBCLID for Meta). If any link in that chain breaks, the dashboard shows an inactive status or an error code.
The most common break points are: the snippet not firing on every page variation, the pixel or tag lacking "event" permissions so click IDs never reach BotRefund, and the ad account connection missing admin rights so refund requests cannot be submitted.
Diagnostic Sequence: Check These in Order
- Confirm the snippet loads. Open a landing page in an incognito window, open DevTools → Network, filter for "botrefund", and verify a 200 response. If it’s missing, the snippet is either not in the
<head>of every template or a tag manager rule is blocking it. - Verify click-ID capture. Click your own ad, land on the page, then check the BotRefund live stream (dashboard → Live Sessions). You should see a session with a GCLID or FBCLID attached. No ID means the pixel/tag isn’t passing the parameter.
- Check pixel/tag permissions. In Meta Events Manager, ensure the Pixel has "Standard Events" enabled and the "Automatic Advanced Matching" toggle is on. In Google Ads, confirm the conversion linker tag is firing and "Enhanced Conversions" is configured.
- Validate ad-account roles. The Google Ads or Meta account connected to BotRefund must have Admin or Advertiser role. Read-only roles allow data viewing but block refund submissions.
- Review domain verification. BotRefund requires the domain to be verified in both the ad platform and BotRefund settings. A mismatch (www vs non-www, subdomain vs root) stops activation.
- Inspect console errors. Look for Content Security Policy blocks, CORS errors, or JavaScript exceptions that prevent the script from initializing.
How the Activation Chain Works
BotRefund’s detection relies on client-side behavioral analysis: ghost-click detection, honeypot traps, pointer-movement analysis, input-speed measurement, and VPN identification. Each visitor session is recorded with a video replay and the associated click ID. That evidence package is what the ad platforms require for a refund claim.
If the script loads but cannot read the click ID, the session is recorded but cannot be tied to a specific paid click — so no refund can be filed. If the script doesn’t load at all, there is zero evidence. If the ad-account role is insufficient, evidence accumulates but the "Submit Refund" button stays disabled.
Common Configuration Mistakes
| Mistake | Symptom | Fix |
|---|---|---|
| Snippet added via GTM but trigger set to "All Pages – Page View" only | Script fires on homepage but not on single-page-app routes | Add "History Change" trigger or use data-layer push on route change |
| Meta Pixel "Event Setup Tool" used without enabling "Automatic Advanced Matching" | FBCLID present in URL but not attached to BotRefund session | Toggle Advanced Matching on; re-test with a live ad click |
| Google Ads conversion linker missing on thank-you page | GCLID drops after redirect | Place conversion linker on every page or enable "Enhanced Conversions" with hashed email |
| Connected ad account uses "Analyst" role in Meta or "Read-only" in Google | Dashboard shows data but "Claim Refund" is greyed out | Upgrade role to Admin (Meta) or Admin/Standard (Google Ads) |
| Domain verified as "example.com" in BotRefund but "www.example.com" in Meta | Activation stuck at "Pending Verification" | Match exact domain string in both places; re-verify |
When the Problem Is on the Ad Platform Side
Sometimes the script, pixel, and permissions are correct, but the ad platform hasn’t yet issued a click ID. This happens with:
- New campaigns still in learning phase — click IDs may be delayed up to 24 hours.
- Meta Audience Network placements — some third-party apps strip query parameters.
- Google Performance Max — GCLID behavior varies by inventory type.
Key Facts
| Fact | Detail |
|---|---|
| Setup time | About one minute to add the snippet and start the free bot audit (S2) |
| Detection methods | Ghost clicks, honeypot traps, robotic mouse movements, superhuman input speed (<1ms), grid-aligned paths, VPN detection, session-duration anomalies (S2) |
| Refund approval rate | 83% of customers successfully get a refund (S2) |
| Lookback window | Google Ads spend recoverable back to 2017 (S2) |
| Evidence captured | Video proof for each bot click, click IDs (GCLID/FBCLID), behavioral logs (S2, S4) |
| Platforms supported | Google Ads and Meta Ads (Facebook, Instagram, Audience Network) (S1, S3, S4, S5) |
Limitations and When This Advice Doesn’t Apply
- Server-side tracking only (no client-side script) — BotRefund requires browser-level execution to capture pointer, speed, and motion behaviors.
- Ad accounts managed entirely through a third-party agency that refuses to grant admin access — you must have direct role assignment.
- Landing pages behind authentication walls where ad traffic never reaches — the script cannot load on pages the bot never sees.
- Campaigns using only call-only or message-only objectives with no landing-page click — no click ID, no session to analyze.
Terminology Quick Reference
- GCLID — Google Click Identifier, appended to landing-page URLs when someone clicks a Google ad.
- FBCLID — Facebook Click Identifier, the Meta equivalent of GCLID.
- Pixel poisoning — Bots triggering conversion events, causing the ad platform’s algorithm to optimize for bot-like behavior.
- Honeypot trap — Hidden page element that only bots interact with, revealing automated behavior.
- Ghost click — Click event fired without the preceding human intent signals (hover, scroll, natural mouse approach).
FAQ
Why does the dashboard say "Active" but no sessions appear?
The script loads but isn’t receiving click IDs. Check pixel/tag permissions and confirm you’re clicking a live ad (not a preview link). Preview links don’t generate GCLID/FBCLID.
Can I activate BotRefund on a staging domain first?
Yes, but refund claims require a verified production domain that matches the ad-campaign destination. Staging data helps validate detection; it cannot be used for disputes.
What if my CMS strips scripts from the <head>?
Use a plugin that injects into <head> (e.g., WPCode, Header Footer Code Manager) or add the snippet via Google Tag Manager with a "Page View – All Pages" trigger plus a "History Change" trigger for SPAs.
Does BotRefund work with server-side GTM?
Client-side detection requires the browser script. Server-side GTM can forward the click ID to BotRefund’s API, but behavioral signals (mouse, speed, honeypot) are only captured client-side.
How long before I see the first bot session?
Usually within the first few paid clicks after activation. If traffic volume is low, it may take a day. The free audit runs continuously once the script is live.
What happens if I change landing-page URLs after activation?
Update the domain verification in BotRefund settings and ensure the snippet is present on the new URLs. Old URLs stop collecting data once traffic shifts.
Can I pause detection without removing the script?
Yes — toggle "Detection Active" off in the dashboard. The script remains but stops recording sessions and capturing video. Refund claims for paused periods cannot be generated.
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.