{"id":10800,"date":"2026-05-28T08:15:00","date_gmt":"2026-05-28T08:15:00","guid":{"rendered":"https:\/\/www.clickcease.com\/blog\/?p=10800"},"modified":"2026-05-28T08:15:01","modified_gmt":"2026-05-28T08:15:01","slug":"what-evidence-should-i-collect-before-requesting-a-refund","status":"publish","type":"post","link":"https:\/\/www.clickcease.com\/blog\/what-evidence-should-i-collect-before-requesting-a-refund\/","title":{"rendered":"What evidence should I collect before requesting a refund?"},"content":{"rendered":"\n
\n

Requesting a refund for invalid PPC clicks is not just about telling an ad platform that the traffic looked suspicious. To make a credible case, you need evidence that connects specific paid clicks to technical signals, abnormal behavior, wasted spend, and clear patterns of invalid activity.<\/p>\n\n

The stronger your documentation, the harder it is for the issue to be dismissed as poor performance, weak targeting, or normal campaign fluctuation. A refund request should read like a structured investigation: what happened, when it happened, which campaigns were affected, how the traffic behaved, and why the clicks should be treated as invalid.<\/p>\n\n

This is especially important when the issue may involve more than one traffic source. Invalid clicks can come from search campaigns, display placements, audience networks, social platforms, botnets, competitors, or low-quality publisher inventory. If you are comparing suspicious activity across several paid channels, this broader guide to evaluating traffic quality across paid media channels<\/a> can help you organize the investigation before submitting a claim.<\/p>\n\n

Start with the basic click record<\/h2>\n\n

The foundation of any refund request is a clean click-level record. You need to document which clicks you believe were invalid and provide enough detail for the platform to review them. That usually includes the campaign, ad group, keyword or placement, landing page, click timestamp, IP address, device type, browser, user-agent string, and geographic location.<\/p>\n\n

This information gives your claim structure. Instead of saying \u201cwe received bad traffic,\u201d you can show that a specific campaign received a suspicious cluster of clicks from repeated IP ranges, unusual locations, abnormal devices, or traffic sources that do not match the campaign\u2019s intended targeting.<\/p>\n\n

For Google Ads campaigns, it is also useful to capture the Google Click ID when possible. Matching GCLIDs to server logs and analytics sessions can help connect the paid click to what actually happened after the visitor reached your site. That makes the evidence much stronger than screenshots from the ad platform alone.<\/p>\n\n

Document IP addresses and location patterns<\/h2>\n\n

IP and geolocation data are usually the first technical signals advertisers examine. A single suspicious IP address does not prove fraud on its own, but repeated patterns can be powerful. Look for high click volume from the same IP address, repeated clicks from the same subnet, traffic from regions outside your targeting, or sudden spikes from locations that have no business relevance.<\/p>\n\n

Location mismatches are especially important when your campaign is geographically restricted. If you are targeting a specific metro area but receiving paid clicks from foreign data centers, proxy-heavy locations, or regions with no commercial relevance, that belongs in the evidence file.<\/p>\n\n

You should also separate harmless anomalies from repeatable patterns. One strange click is not enough. A cluster of clicks with similar timing, similar behavior, and similar technical characteristics creates a much stronger case.<\/p>\n\n

Collect user-agent and device signals<\/h2>\n\n

User-agent strings help show what browser, device, and operating system were used during a visit. Suspicious activity may involve outdated browsers, non-standard user agents, headless browser signals, unusually repetitive device profiles, or traffic that shows very little variation across many sessions.<\/p>\n\n

This matters because modern bots are not always obvious. Some can rotate IP addresses, simulate human browsing, load JavaScript, scroll pages, and trigger basic engagement events. A proper review should therefore look beyond IPs and include the full technical environment around each click.<\/p>\n\n

If you are dealing with suspected bot activity inside Google Ads campaigns, it is worth comparing your evidence against the patterns described in this guide on how to diagnose bot traffic and fake leads in Google Ads campaigns<\/a>. It can help you distinguish between weak traffic, accidental clicks, fake leads, and more systematic automated behavior.<\/p>\n\n

Match click data with on-site behavior<\/h2>\n\n

Technical signals become more useful when they are connected to behavior on the site. A suspicious click followed by a normal user journey is less persuasive than a suspicious click followed by a one-second session, no scroll, no page interaction, and no conversion intent.<\/p>\n\n

Useful behavioral evidence includes session duration, bounce rate, pages viewed, scroll depth, form interaction, button clicks, add-to-cart behavior, call clicks, and any micro-conversions that indicate real interest. If a large group of paid sessions shows almost no meaningful engagement, that supports the argument that the traffic was not commercially valid.<\/p>\n\n

For lead generation campaigns, this layer is critical. A fake form submission can make the campaign look successful inside the ad platform while creating no real business value. If the leads use disposable email addresses, invalid phone numbers, repeated naming patterns, or unreachable contact details, include that evidence as part of the refund request.<\/p>\n\n

Show the financial impact clearly<\/h2>\n\n

A refund request should also quantify the damage. Start with the direct cost: how many suspicious clicks were identified and what was the average cost per click for the affected campaign, ad group, keyword, or placement.<\/p>\n\n

A simple calculation can help frame the issue:<\/p>\n\n

Suspicious clicks \u00d7 average CPC = estimated wasted ad spend.<\/p>\n\n

Where possible, calculate this at the most granular level. If the suspicious activity happened in one ad group with a higher CPC than the account average, use that ad group\u2019s actual cost data. If the issue came from a specific placement or network, isolate that spend instead of using account-wide numbers.<\/p>\n\n

For lead generation campaigns, also include operational cost. If fake leads forced the sales team to call, email, qualify, and disqualify invalid contacts, that cost matters. The real damage is often larger than the media spend alone.<\/p>\n\n

Separate platform metrics from your own evidence<\/h2>\n\n

Ad platforms may already filter some invalid clicks automatically, but their filters do not always capture every type of low-quality or fraudulent activity. Your own server logs, analytics data, CRM records, and lead-quality reports can reveal patterns that do not appear clearly inside the platform interface.<\/p>\n\n

This is why advertisers should avoid relying only on the platform\u2019s invalid-click column. It is useful, but it is not the whole picture. If your backend data shows that a group of clicks produced no engagement, no valid leads, repeated technical patterns, or suspicious geographic behavior, that evidence should be documented separately.<\/p>\n\n

A dedicated PPC click fraud software<\/a> layer can help advertisers collect, organize, and act on these signals across multiple paid channels, rather than relying only on native platform reporting.<\/p>\n\n

Build a clear evidence file<\/h2>\n\n

The best refund submissions are easy to review. Instead of sending scattered screenshots, prepare a structured file that explains the issue clearly.<\/p>\n\n

Include a short summary of the affected date range, the campaigns involved, the suspected source of invalid activity, the amount of spend affected, and the evidence categories you are submitting. Then attach the supporting data in a format that can be reviewed: spreadsheet exports, server-log extracts, analytics screenshots, CRM lead-quality notes, and any relevant traffic-quality reports.<\/p>\n\n

A useful structure might include:<\/p>\n\n