Fraud Detection

AxiTrace scores every IP address that reaches your website, tells you which of them look automated or abusive, and shows the evidence behind every label. On the Business and Custom plans it can also send the worst offenders to your own Google Ads account as account-level IP exclusions, so you stop paying for those clicks.

What it detects

Fraud Detection is built for three populations, and it says so plainly rather than promising to catch everything:

• Bots and automation. Headless browsers, automation frameworks such as Selenium, Playwright and Puppeteer, browsers reporting a build number that no real Chrome ever shipped, and real browsers running out of a datacenter, cloud or hosting network.
• Click farms. Many apparently different visitors behind one address that all report the same browser build and the same screen size, or a single device that turns up on several unrelated networks within an hour.
• Repeat clickers. The same address arriving through your paid ads day after day, opening one page, never adding anything to the cart, never buying.

What it does not claim

How the mechanism works, step by step

The whole feature is one pipeline that runs every hour for every workspace. Each pass looks at the last seven days of traffic, so an address is judged on a week of evidence rather than on one visit, and a verdict changes as soon as the evidence changes.

1. Collect The AxiTrace tracking script measures each page view: the technical properties the browser reports about itself, and summary counters describing how the page was used. The request itself brings the IP address, the network and the browser identification. On Shopify the in-page part is missing, see reduced coverage.
2. Filter the obvious A bot filter at the edge stops requests that identify themselves as crawlers, that come from known datacenter ranges, or that a bot-detection library running inside the visitor's real browser flags as automation. Nothing stopped here is ever sent to an ad platform. Each stopped request is recorded against its address, and that record becomes one of the factors below. A datacenter network on which several different visitors went on to place an order is treated as a shared exit, such as a VPN or a browser privacy relay, and is no longer stopped for its network alone. Its traffic is still scored like any other.
3. Verify the address Every address is classified by the network behind it: home broadband, mobile carrier, datacenter, cloud, hosting provider, privacy relay, Tor exit node, or one of Google's own published crawler ranges. The lookups run against offline databases on AxiTrace servers; the address is never sent to a third-party reputation service. Addresses that belong to Google's crawlers are removed before anything else happens, because blocking them breaks ad approvals.
4. Protect real people first Before scoring, the whitelist rails are applied: every address a purchase has ever come from, every address your own team logs in from, and everything you whitelisted by hand. A whitelisted address can be shown, but it can never be blocked and never reaches Google Ads. Shared networks, where thousands of unrelated households sit behind one address, are marked so their verdict is capped later. The one exception is your own ad-click limit.
5. Weigh the factors Every factor in the list below is checked against the week of evidence for the address. Each factor that fires contributes its own weight. The weights are added up, group by group, into one score from 0 to 100. No group may contribute more than its ceiling, so no single kind of evidence can carry an address to the top of the scale by itself.
6. Check the structure of the evidence A high score is usually necessary for a High risk verdict but never sufficient. The evidence must also have the right shape: either a conclusive factor fired, or a hard network or automation factor fired together with an independent behavioural or velocity pattern. This is the rule that keeps a merely unusual human out of your exclusion list. Three combinations are High risk by themselves, whatever the score: automation stopped by the bot filter while it carried a Google Ads click, a browser driven by an automation tool on a visit that came through an ad, and repeated paid clicks without intent together with a machine-like pattern (replayed click identifiers, a clockwork interval, or one device rotating through networks). A fourth is your own ad-click limit: one visitor who reached it is High risk on every address they clicked from.
7. Decide and show the evidence The score and the structure become one of the labels described below. The address appears in your Fraud Detection tab with its score, its network, the ad platforms it arrived through, how many sessions and paid clicks it produced, and a plain-language sentence for every factor that fired, with the measured values behind it.
8. Act You can block or whitelist any address by hand. With Google Ads Auto Exclusion enabled, High risk addresses that produced paid Google Ads clicks are written to your own Google Ads account as account-level IP exclusions, and removed again when the evidence expires.

The scoring model

Detection is additive. There is no single test that decides the outcome; instead every factor that fires adds its weight to a running total, and the total is what you see as the score in the list. Three rules shape that total:

• Every factor has a fixed weight. A conclusive factor, one with no plausible human explanation, weighs the most. A strong factor is a hard technical or network fact that has an innocent explanation only rarely. A moderate factor is a pattern that fraud produces more often than people do. A weak factor is a consistency check that on its own means little. The exact point values are deliberately not published.
• Weights are summed within a group, and each group has a ceiling. The factors are organised into five groups: network, technical browser tells, behavioural aggregates, velocity and click stream, and geography consistency. A group can contribute up to its ceiling and no more, however many of its factors fired. The behavioural ceiling sits below the High risk cut-off, which is the mechanical reason behaviour alone never reaches High risk. Geography has the smallest ceiling of all.
• Some factors suppress rather than add. A shared network, a verified Google crawler, a declared crawler and a whitelisted address all override the arithmetic: the first caps the verdict below High risk (except for your ad-click limit), the other three take the address out of scoring entirely and only count it.

The final score is compared with fixed cut-offs. Above the upper cut-off, and with the structural condition satisfied, the address is High risk. Above the middle cut-off it is Suspicious. Below that it is Low risk and stays out of the default view. The evidence panel of every row lists each factor that fired and its group, so you can see exactly what added up.

The full list of factors

Thirty-one factors are evaluated for every address, plus six click-layer factors that are recorded as evidence and score nothing, and four whitelist rails that override them. The tables describe what each factor looks at and how much it weighs. They do not describe the exact thresholds, windows or measurements, and that is deliberate: publishing them would hand the people this feature targets a manual for staying just under the line.

Weight legend: Conclusive no plausible human explanation, can carry High risk on its own  Strong a hard fact that needs one corroborating pattern to reach High risk  Moderate adds to the score and can corroborate a strong factor  Weak adds a little, never decides  Override scores nothing, changes the outcome directly  Evidence scores nothing, recorded with the verdict for refund claims

Network and IP verification

These factors come from the request itself and from the network the address belongs to. They need no script on the page, so they work for every store, including Shopify.

Factor	What it looks at	Weight
Automation stopped at the gate	The bot filter stopped a request from this address because the browser reported a build number no real Chrome ever shipped, or because the bot-detection library running inside the visitor's real browser reported automation. A weaker reading of the same library counts for less.	Conclusive
Automation on a paid click	The bot filter stopped automation from this address while it carried a Google Ads click identifier. Only a definite detection counts, and only when AxiTrace verified the address the request came from. A bot that clicked your ad is the clearest case there is, so this factor produces High risk on its own, before any score arithmetic.	Conclusive
Datacenter request stopped by the filter	The bot filter stopped a request from this address because it came from a known datacenter range. Servers do not shop.	Strong
Real browser on a hosting network	A session that passed the filter and looked like a normal browser, but the address belongs to a cloud, hosting or datacenter operator rather than to a residential or mobile network. Either a bot with a well-faked browser or a corporate gateway; the corroboration rule separates the two.	Strong
Tor exit node	The address is on the published list of Tor exit nodes. Legitimate shoppers use Tor too, which is why this is strong rather than conclusive.	Strong
Shared network	The address belongs to a mobile carrier, a privacy relay such as iCloud Private Relay or Cloudflare WARP, or a broadband network that puts many households behind one address. AxiTrace also recognises the pattern itself: many distinct visitors, many distinct devices, and real purchases from one address in one day, or orders from many different addresses of the same address range, which is how a mobile carrier pool looks when it hands every visitor a new address. The verdict is capped below High risk and the address is never excluded automatically.	Override
Verified Google crawler	The address is inside a range Google publishes for its own crawlers: AdsBot, the inspection tool, Lighthouse. Removed before scoring, counted, never blocked, not even by hand.	Override
Declared crawler	The client honestly identifies itself as a crawler: link previews in e-mail and chat clients, uptime monitors, search and AI crawlers. They cost you no ad spend, so they are counted in the filtered-traffic figure and never scored.	Override

Technical browser tells

These factors come from properties the browser reports about itself. Automation tools announce themselves through properties that page scripts cannot rewrite, and a faked browser identity rarely patches every one of them at once.

Factor	What it looks at	Weight
Remote-control flag	The browser sets a standard flag when it is being driven by an automation tool rather than by a person at the keyboard. The flag was set in at least one session from this address. When that session arrived through an ad, the address is High risk on its own: software clicked your paid link. Your own team and the addresses you whitelist are protected, which is where a legitimate test run belongs.	Strong, Conclusive on a paid visit
Software renderer	The graphics renderer the browser names is a software fallback rather than a graphics card. A browser rendered inside a container on a server has no graphics card to name; a laptop or a phone always does.	Strong
Browser identity mismatch	The platform and device class the browser publishes through its structured client hints disagree with the user agent string it sends. Real browsers keep the two consistent; a tool that rewrote one of them usually forgot the other. Only genuine Chrome and Edge hints are compared, and the two known-consistent cases (Android tablets, Android's "request desktop site" mode) are left alone.	Moderate
Hardware class anomaly	The processor core count and the device memory class the browser reports do not fit the kind of device it claims to be.	Moderate
Input capability contradiction	Touch, pointer and hover support disagree with each other or with the claimed device: a phone with no touch support, a desktop that reports a coarse touch pointer only.	Moderate

Behavioural aggregates

These factors describe how the page was used, from summary counters only. AxiTrace never records pointer coordinates, key identities, typed text or a session replay; it counts and averages, and only the counts leave the browser. Every factor in this group is measured per session and an address is charged for the sessions that showed the pattern.

Factor	What it looks at	Weight
Paid session with zero engagement	A session that arrived through a paid ad and then did nothing at all: no pointer movement, no scroll, no click, no key press, no measurable active time. The cheapest advertising bot lands, renders and leaves. Slow mobile connections produce this too, so the weight is added per session and capped per address.	Moderate
Ghost session	The page was loaded but was never visible in the foreground and never active. Prefetching and background tabs look like this, so it weighs little.	Weak
Straight-line pointer	The pointer moved, but along a straight line, without changing heading and at a near-constant speed. Hands wobble; scripted pointers do not. The thresholds were set from the real distributions of human sessions, with a wide margin outside them.	Moderate
Script-generated clicks	The browser engine itself marks each click as user-generated or dispatched by a script. Every click in this session was marked as script-generated and no mouse movement, touch or key press was ever seen alongside them. A synthetic click next to a person's real clicks does not count: password managers, themes and consent tools dispatch those all day. When your own site dispatches synthetic clicks on most visits, this factor is switched off for your workspace automatically (see the site-noise guard below).	Moderate
Rapid-fire clicks	Clicks arrived at a rate no hand can sustain, many times per second. There is no human production mode for this.	Conclusive
Fast clicks	Clicks arrived quickly, at a rate a determined person can still sustain. This corroborates other evidence and never decides on its own.	Moderate
Instant interaction	The first click or key press came before the page could possibly have been read, practically at the moment it finished loading.	Weak
Instant full scroll	The page jumped to the very bottom while it was still painting, on a fresh visit, with no mouse movement, touch or key press in the session. Scripts that scroll to trigger lazy content do this. A reload or a return through the back button is not counted, because the browser restores the previous scroll position itself, and neither is a page a person scrolled or that scrolled itself while a person was present.	Moderate

Velocity and click stream

These factors look at the address over hours and days rather than at one page view. AxiTrace joins the ad click to the session and the session to the order, so it can see cost repeating with nothing on the other side of it. They need no script on the page, so they work on Shopify as well.

Factor	What it looks at	Weight
Paid repeat without intent	The same address keeps arriving through paid ads, opens about one page per visit, never adds to a cart and never buys. The factor has three tiers by volume and by how many days the pattern persists, and the higher tiers weigh more. A shared network counts for half. On its own it stays at Suspicious, because real customers click ads many times before they order. Together with click identifier reuse, a metronomic cadence or one device rotating through networks, on repeated paid Google Ads visits from a verified address, it is High risk.	Strong
Burst	One address produced far more sessions in one hour than your own store normally sees from any address, measured against your workspace's own baseline rather than a fixed number. It weighs more when the burst consists of many "different" visitors that all report the same browser build.	Strong
Click identifier reuse	An ad platform creates a new click identifier for every ad click. This address carried several identifiers that were each opened by several different visitors on several unrelated networks within a short time, none of whom bought anything, so the landing links were replayed rather than clicked. A link that merely does the rounds (shared on social media, kept in a paginated category URL) spreads over days and gives each visitor a single identifier, which is why neither counts. Google's cohort identifiers (gbraid, wbraid) are shared by design and are never read here.	Moderate
Metronomic cadence	Several visits in one day arrived at almost exactly the same interval, with next to no variation between the gaps. People return at irregular times; software on a timer does not.	Conclusive
Many visitors, one device	Many apparently distinct visitors behind one address that all report the same browser build and the same screen size. Real households behind a shared address show a spread of devices; a click farm shows one image cloned many times.	Strong
One device, rotating networks	The same visitor turned up on several unrelated networks within a short time. Phones switch between wifi and mobile data, so a modest change is normal; a device that hops between many networks in an hour is rotating proxies.	Strong
Ad-click limit	One visitor, recognised across every address they used, reached your ad-click limit: by default 20 Google Ads clicks in 30 days without adding anything to the cart, or 30 clicks for a visitor who added to the cart, and never ordered. Every address the visitor clicked an ad from is High risk, including mobile network addresses, unless a purchase was made from that address in the last 7 days or it is an anonymising relay (iCloud Private Relay, VPN, Tor). This weight is added on top of everything else rather than sharing the velocity ceiling.	Conclusive
One visitor, many paid clicks	Used instead of the ad-click limit when you switch the limit off, on an address where a purchase was made in the last 7 days, and on anonymising relays. One visitor, recognised across every address they used, came back through your Google Ads far more often in the last month than your buying customers do before they order, and never ordered. This weight is added on top of everything else rather than sharing the velocity ceiling. It is a cost signal for you to review, not proof of a bot: such a visitor is often a competitor or someone on your own team checking the ads.	Moderate

Geography consistency

A proxy changes the address, not the clock or the language of the machine behind it. These are weak signals by design, they carry the smallest ceiling of any group, and they are skipped entirely on networks where the exit country says nothing about where the person is.

Factor	What it looks at	Weight
Country outside your campaign targets	The address is in a country your Google Ads campaigns do not target. The targets are read from the location settings of your enabled campaigns once a day; when the account cannot be read, the fallback is every country your store received an order from in the last 90 days, and the evidence says which of the two was used. A campaign that targets the whole world, a region such as a continent, or a very long list of countries makes the factor stay silent, and so does a store selling into many countries.	Weak
Address country versus device time zone	The country of the address and the country implied by the device's time zone disagree.	Weak
Time zone versus browser language	The device's time zone and the language the browser asks for do not fit together at all.	Weak

Click layer

When your Google Ads tracking template sends clicks through the AxiTrace click tracker, each paid click is recorded on the server before the visitor is redirected, and compared with the visit your site records for the same click id. These factors are evidence for refund claims. They add no points to the score and never block an address on their own. Test clicks sent by AxiTrace's own release checks are never counted.

Factor	What it looks at	Weight
Click without a visit (C1)	The ad was clicked, but no visit with that click id reached your site shortly afterwards. Consent banners and ad blockers can also hide a visit, so this factor alone never puts a click into a refund claim.	Evidence
Click and visit from different addresses (C2)	The visit that carried the click id came from a different address than the click itself.	Evidence
Implausible time to the visit (C3)	The visit arrived faster than a browser can load a page after a redirect, or much later than a person waits for one. Clicks Google reports through parallel tracking are not measured.	Evidence
Different device at the visit (C4)	The browser, the operating system it reports, or the fingerprint of its encrypted connection differs between the click and the visit.	Evidence
Click from a datacenter (C5)	The click came from a hosting or cloud network. Addresses that bought from your store are left out.	Evidence
Replayed click id (C6)	The same Google click id was clicked from more than one address. Google issues a click id once per click, so a second address replayed a copied ad link.	Evidence

Whitelist rails

Four rails sit outside the score. They are applied before scoring and they win over everything above.

Rail	What it does	Weight
Bought from your store	A purchase has come from this address at some point. The address is whitelisted automatically and can never be blocked.	Override
Your team	The addresses your users log in to AxiTrace from over the last 90 days are whitelisted automatically and labelled as your team.	Override
Added by you	Anything you put on the whitelist by hand: an agency, a warehouse, a partner. Kept until you remove it.	Override
Site-noise guard	When one factor fires on a large share of all sessions on your site, it is describing your website rather than your visitors. The factor is switched off for your workspace and the settings card tells you which one and why.	Override

What each label means

Label	Meaning
High risk	The evidence is structural, not just numerical: either the score is above the high threshold and a conclusive signal fired, or a conclusive network or automation signal fired together with an independent corroborating pattern, or one of the three combinations that are High risk by themselves was seen (automation stopped on a paid click, an automation-driven browser on a paid visit, repeated paid clicks together with a machine-like pattern). These are the only verdicts that can be excluded automatically.
Suspicious	Enough signals fired to be worth your attention, without the structural evidence a High risk verdict needs. Nothing happens automatically. The address stays in the list with a Block button, and you decide.
Low risk	A few weak signals fired. Hidden by the default filter, available when you widen it. Shown so that a rising address can be watched before it becomes a problem.
Shared network	The address belongs to a mobile carrier, iCloud Private Relay, Cloudflare WARP, or a broadband network that shares one address between many households. Thousands of unrelated people sit behind it, so the verdict is capped below High risk and the address is never excluded automatically. It is still shown, because the traffic may still be worth investigating.
Verified bot	The address is inside one of Google's own published crawler ranges, for example AdsBot, the Google inspection tool or Lighthouse. These are removed from the analysis before scoring, can never be blocked, not even by hand, and are only counted. Blocking them would break your ad approvals and landing page checks.
Declared bot	A crawler that identifies itself honestly: link scanners in e-mail and chat clients, uptime monitors, AI crawlers. They cost you nothing in ad spend, so they are counted in the filtered-traffic figure and never excluded. A client that names itself as a crawler but arrives from a paid ad click is scored like any other visitor.
Limited signals	A tag on an individual verdict, not a verdict of its own. It means no browser telemetry was available for that address in the window, so only the network, velocity and geography groups could run. You will see it on backfilled days from before the feature launched, on stores still running an older SDK build, and on Shopify traffic (see below).

Reading the list

The Fraud Detection tab lists one row per address. Every column header carries a short explanation on hover; the important ones are:

• Risk and Score. The label and the number behind it. Open the row to see every factor that fired, in plain language, with the measured values.
• Network. The class of network the address belongs to and the operator's name. This is where a datacenter or a shared network shows up.
• Platforms. The ad platforms whose paid clicks brought this address to you, with Google Ads broken out on its own because only Google Ads accepts exclusions.
• Sessions and Paid. All sessions from the address in the selected window, and the subset that started with a paid ad click. The paid figure is the number that cost you money: every one of those sessions was a click you were charged for.
• Status. Whether the address is blocked, whitelisted, queued for Google Ads, or untouched.

The whitelist has its own page, reachable from the settings card, with the entries grouped by where they came from: bought from your store, your team, or added by you. Only the entries you added by hand can be removed there; the automatic ones are re-derived every hour and would return.

Ad-click limit

Some visitors click your Google Ads again and again and never buy: a competitor, a curious regular, or someone paid to drain your budget. None of them looks like a bot, so no automation factor will ever catch them, but every click costs you. The ad-click limit on the settings card lets you decide how many clicks you pay for before such a visitor is blocked.

• Two limits. One for a visitor who never added anything to the cart (default 20 clicks in 30 days), and one for a visitor who added to the cart but never ordered (default 30). Measured across AxiTrace stores, buyers click a median of once before their first order, and almost none click 20 times.
• Counted per visitor, blocked per address. Clicks are counted for one visitor across every address they used. When the limit is reached, every address the visitor clicked an ad from is High risk.
• Mobile networks included. This is the one rule that also applies on shared networks, because visitors of this kind mostly click from their phones. An automatic entry lasts 7 days after the last click, so a mobile address that changes hands is released again.
• Buyers are protected. A visitor who ever placed an order is never counted, an address where a purchase was made in the last 7 days is never blocked, and whitelisted addresses are never sent to Google.
• Anonymising relays are left alone. iCloud Private Relay, VPN and Tor exits serve many unrelated people at the same time and hand out a new address on every connection, so blocking one would hit whoever uses it next while the heavy clicker has already moved on. Such addresses are listed for review instead.
• Switching it off. The visitors are then still shown for review under "One visitor, many paid clicks", but never blocked.

Addresses reach your Google Ads account only while Google Ads Auto Exclusion is on and live.

How real customers are protected

The expensive failure of a feature like this is not a bot that slips through. It is a real customer, or your own office, quietly excluded from your ads. These safeguards run before scoring, not as an appeal afterwards:

• Anyone who has bought from you is never blocked. If a purchase has ever come from an address in your workspace, that address is whitelisted automatically and can never be excluded.
• Your own team is recognised. The addresses your users log in to AxiTrace from over the last 90 days are whitelisted automatically and labelled as your team. Your office clicking your own ad is the most embarrassing false positive there is, so it is handled for free from data AxiTrace already holds.
• A manual whitelist. Add an address or a small range by hand: an agency, a warehouse, a partner. Whitelisted entries are never raised by a later re-evaluation and are never sent to Google.
• Shared networks are capped. Mobile carriers, privacy relays and shared broadband addresses can never reach High risk and are never excluded automatically. The same holds for any address in a range where customers of AxiTrace stores placed orders from ten or more different addresses in the last 30 days. The only exception is the ad-click limit you set yourself.
• Google's own crawlers are excluded from the analysis entirely. Their addresses are removed before scoring, a manual Block on one is rejected, and the range lists are re-checked immediately before every write to your Google Ads account. If the lists cannot be refreshed, the write does not happen.
• One behavioural signal never decides alone. Each signal group has a ceiling, and a High risk verdict needs a conclusive signal, a conclusive network signal plus independent corroboration, one of the three combinations described above, or your own ad-click limit. Repeated paid clicks alone are never enough.
• A signal that fires on a large share of your own sessions is switched off. Some sites dispatch synthetic clicks from their own scripts, or render in unusual ways. When a signal starts describing your website rather than your visitors, AxiTrace disables it for your workspace and tells you in the settings why.
• Nothing is permanent. An automatic entry expires 7 days after the last signal for that address, or 90 days for datacenter and hosting networks, and the expiry removes the Google Ads exclusion as well. It also ends as soon as the current detection rules no longer rate the address High, so a rule correction releases every address it wrongly blocked. Entries you add by hand stay until you remove them. A blacklist must not quietly turn into a list of innocent people.

The limits of this feature

Shopify stores: reduced coverage

On Shopify, tracking runs inside the Web Pixel sandbox. The request still comes from the visitor's real browser, so AxiTrace does see the real user agent and the real IP address, and the network, velocity and geography groups work exactly as they do everywhere else. What the sandbox does not expose is the page itself: there is no automation detection, none of the technical browser tells, none of the behavioural aggregates, and no bot beacon.

In practice that means a Shopify workspace gets network-layer coverage and the click-stream rules, and its verdicts carry the Limited signals tag. High risk verdicts are still reachable, because the conclusive network and velocity signals need no in-page telemetry, but fewer of them will be found than on a store running the AxiTrace JavaScript SDK. The tab says so in a banner rather than leaving you to guess.

Which plans include what

Detection runs for every workspace on every plan. What differs is what you can see and do with it:

• Free, legacy Starter and Pro: the number of suspicious addresses found in the last 30 days, and nothing more.
• Business and Custom: the full list, the evidence behind every verdict, manual Block and whitelist actions, the whitelist page, the ad-click limit, Google Ads Auto Exclusion and refund claims.

The Google Ads click tracker, which records paid clicks on the server before your page loads, is available on every plan.

Two-track protection

On Google Ads, Fraud Detection acts on two tracks that complement each other:

• Track 1: exclude the address right away. Google Ads Auto Exclusion, described below, writes high-risk addresses into your own account as IP exclusions, so your ads stop being shown to them. It prevents future spend and changes nothing that was already charged.
• Track 2: claim the money back afterwards. Paid clicks that high-risk addresses produced before they were excluded are collected into a refund claim that you send to Google for review. The ad platform decides whether, and how much, to credit.

Google Ads Auto Exclusion Available after the Google Ads verification step

When you enable it, AxiTrace maintains IP exclusions at account level in your own Google Ads account. What that covers, and what it does not:

• Coverage. Account-level IP exclusions apply to Search, Shopping, Display, YouTube, Demand Gen and Performance Max campaigns. App and Hotel campaigns are not covered.
• Google's own caveat. Google states that it cannot guarantee that an excluded address is blocked on every Display Network placement. That is Google's limitation, not a setting, and it is the reason AxiTrace reports what it excluded rather than promising a result.
• A hard limit of 500 entries. Google allows 500 account-level IP exclusions. AxiTrace ranks candidates by score and by how much paid traffic they actually produced, so the slots go to the addresses that cost you the most.
• Exclusions you or another tool added are counted, never touched. AxiTrace only ever removes entries it created itself. Everything else in the account is left exactly as it is, and simply counted against the 500. If the account is already full of entries AxiTrace does not own, the settings card says so instead of failing silently, and warns you when free capacity runs low.
• Queued: limit reached. When there is no free slot, an eligible address is held in that state and shown in the list. It is not lost: it is pushed when a slot frees up, or earlier if it is clearly stronger than an address AxiTrace already excluded.
• Replaced by a stronger address. When the account is full, a queued address can take the slot of an automatic exclusion only if its priority (score weighted by the paid traffic it produced) is at least 1.5 times higher, and only after that exclusion has been in your account for at least 24 hours. Replacements are capped per synchronisation and per day, so the list changes gradually rather than all at once. An address you blocked manually can replace an automatic one without that margin. Manual exclusions and the exclusions you or another tool added yourself are never replaced. A replaced address stays blocked in AxiTrace, is shown as "Replaced by a stronger address" in the list, and goes back to Google Ads as soon as a slot frees up.
• The fast path. Most exclusions come from the hourly analysis. A few signals are clear enough to act on sooner: a visitor who went over your own limit of paid clicks, automation that arrived carrying a Google click id, and repeated paid clicks with replayed click ids, a clockwork rhythm or rotating networks. When one of those arrives from a workspace in live mode, AxiTrace re-scores that address on its own and, if it is high risk, excludes it typically within a few minutes of the click instead of at the next hourly run. The address is scored by the same rules as in the hourly analysis, and the hourly run still re-checks every block, so a fast exclusion that does not hold up is lifted there. The list marks such rows "Fast" and shows how many minutes after the last click each address was excluded; the exclusions page shows the 30-day median for each path.
• IPv6. IPv6 addresses are held as a /64 network. Whether that form can be written to Google Ads is settled by the verification step; if Google rejects it, those entries are marked as not pushable and the interface says so rather than pretending they were excluded.
• A 7-day dry run first. Every account starts in dry run. For seven days AxiTrace computes exactly what it would add and remove and records it, without changing anything in the account. The first real write happens only after a human has compared that list against reality.
• Expiry removes the exclusion. When a blacklist entry expires or you remove it, the matching exclusion is removed from the Google Ads account on the next synchronisation.
• Only the address is sent. No behavioural data, no browser characteristics, no personal data, and only to your own account.

Beside your own number: Google's invalid clicks

Google filters some invalid traffic itself and credits it back before it reaches your invoice. AxiTrace reads that figure from your account and shows it next to its own count of flagged paid sessions. Google's number is usually several times larger, and that is expected:

• Google filters at the moment of the click, on its own ad server, before your page even loads. The biggest categories are double and accidental clicks, and bots that hit the ad link without ever rendering a page. Those clicks never create a session on your site, so they do not exist in your data and cannot be counted by AxiTrace.
• AxiTrace counts sessions that did load your page, ran the tracking script and came from addresses rated High risk or Suspicious. These are the clicks Google let through as valid and charged you for.
• The two are never added together. They overlap in ways neither side can measure, and a summed figure would be a number nobody could defend. Google's figure is money you never spent; the AxiTrace figure is money you did.

Refund claims

Google's own filter works at the moment of the click. For invalid clicks it did not catch, the advertiser can ask Google for a review, covering roughly the last 60 days. On the Business and Custom plans AxiTrace prepares that request:

• Selection. Paid Google Ads clicks with a verified IP address from addresses rated High risk, or with hard click-level evidence. Buyers, whitelisted addresses, your staff and Google's crawler ranges are always left out, and a click is claimed at most once.
• Readiness. A claim is prepared when the selected clicks reach 30 clicks or an estimated cost of 50 in your account currency (both configurable), for the last 52 days up to yesterday, at most one new claim per Google Ads account every 30 days.
• The pack. Per-click, per-address and daily CSV files, a printable summary and ready-to-paste texts for Google's Invalid Clicks form. You send the form yourself and enter the case number; a ready claim that is not sent within 7 days expires.
• The outcome. Google reviews the request with its own data and decides. A credit shows up as an invalid activity adjustment in Google Ads billing, separate from the invalid clicks Google filters automatically and that are described above.

The full workflow, from the evidence pack to each claim status, is in Google Ads Refund Claims.

What data is collected

Fraud Detection is security telemetry. It is collected for all traffic, including visitors who declined marketing consent, and it is never used for marketing, audience building or campaign measurement. For visitors without consent, scoring happens at address level only and the result is never shown next to a visitor profile. The full description is in the privacy policy, section 3.8. In short:

• Technical browser properties. The remote-control automation flag, plugin count and notification permission state, whether a graphics context can be created and the vendor and renderer it reports, processor core count and device memory class, touch and pointer capability, window and screen geometry, time zone and primary language, and the browser brand and platform hints published alongside the user agent.
• Behavioural aggregates. Counters and averages for one page view: pointer sample count and speed statistics, how straight the pointer path was, scroll count and deepest point reached, click and key-press counts, how many clicks the browser marked as user-generated, time to first interaction, active and visible time, and standard page load timings.
• Network classification of the address. The autonomous system number and network operator name, the approximate country, and a network class such as residential, mobile carrier, datacenter, hosting, privacy relay or Tor exit. These lookups run against offline databases and published address lists on AxiTrace servers. The visitor address is not sent to any third-party reputation service.
• Click tracker records. When the click tracker is in your tracking template, each paid click passing through it is recorded with its time, IP address, user agent, low-entropy client hints, accepted languages, referring host, click identifier and campaign parameters. No cookies are set. These records are kept for 100 days.
• What is deliberately not collected. No canvas or audio fingerprint, no font list, no pointer coordinates, no key identities and no typed text, no form field contents, and no session replay. A key press is counted; what was typed never leaves the browser.
• Retention. Records of filtered bot traffic are kept for 92 days, the daily aggregates used for scoring for 100 days, and verdicts for 45 days after the last signal for that address, with a cap on how many verdicts are kept per workspace. Automatic blacklist entries expire after 7 days, or 90 days for datacenter and hosting networks. Entries you add by hand, and your whitelist, stay until you remove them or delete the workspace.

Need help?

If a verdict looks wrong, open the address in the list: every fired signal is shown with the values behind it, so you can judge it yourself, whitelist it in one click, and tell us at info@axitrace.com what we got wrong. False positives reported with the evidence are how the thresholds get better.