You saw invalid clicks in Google Ads, then a vendor page called part of your traffic "SIVT." The letters tell you who is supposed to catch each kind of bad traffic, and whether you can do anything yourself.
Below we quote Google's nine categories word for word, set each beside the MRC standard, mark which IP field can see it, and run five real addresses through our API. For the wider case of detecting click fraud by IP without an exclusion list, start with our hub guide.
We opened every Google and MRC page quoted here at 05:38 UTC on 21 October 2026.
What is invalid traffic (IVT)?
Invalid traffic is ad activity that does not come from a real person with real interest. Google's Ad Traffic Quality page puts it in one line:
"Invalid traffic is any activity that doesn't come from a real user with genuine interest."
Clicks, impressions, interactions and conversions can all be invalid, and not all of it is malicious. Google's examples run from accidental clicks to "fraudulent clicking by competing advertisers" and "advertising botnets."
Google Ads help does not use the GIVT and SIVT terms. They come from the MRC, and Google uses them in its DV360 help, home of the nine categories.
Don't confuse the nine with the Ad Traffic Quality page's own examples. That list had eleven headings when we checked: Invalid user activity, Accidental Clicks, Ad Hiding, Ad Injection, Ad Stacking, Botnets, Clickjacking, Falsely Represented Inventory, Misrepresentation of in-stream and out-stream video, Malware, and Pop-under ad. Google calls it "not an exhaustive list" and does not sort it into tiers.
Publishers have their own rules on AdSense's invalid traffic page.
GIVT vs SIVT: what separates the two tiers, and who decides
The tiers differ in how the traffic is found, not in how bad it is. The MRC's Invalid Traffic Detection and Filtration Standards Addendum, June 2020 Update defines GIVT on page 5 as traffic "identified through routine means of filtration executed through application of lists or with other standardized parameter checks." SIVT, on page 6, covers "more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention, etc., to analyze and identify."
DV360's Filtering invalid traffic to ensure quality page says the same thing in plainer words: GIVT "is identified using lists of known spiders and robots, or other routine checks," while SIVT "requires human intervention or more in depth analysis."
Timing follows from that. DV360 says Google removes invalid traffic "either before inventory is bid on, or after an event occurs," and the MRC notes on page 8 that SIVT detection "may take time to execute and may not be feasible to apply to real-time processes."
One click can fit more than one category. The MRC says on page 49 that categories "are often not mutually exclusive as invalid traffic is likely to be detected by or result from more than one category."
Several groups share the work:
- The MRC writes the standard and accredits measurement vendors against it.
- Industry lists feed GIVT. The MRC names the IAB/ABC International Spiders & Bots List on page 9 and the Trustworthy Accountability Group (TAG) Data Center IP list on page 10.
- Platforms and vendors apply it. Google's Ad Traffic Quality page states that "Google's Sophisticated Invalid Traffic (SIVT) detection processes are accredited by the Media Rating Council."
Google's nine invalid traffic categories next to the MRC lists
Google sorts invalid traffic into three GIVT and six SIVT categories, and most have a rough counterpart in the MRC lists. The Google wording is copied from the DV360 page. The MRC column is our pairing, because DV360 points to MRC section 1.1.2 as a whole, not item by item.
| Tier | DV360 category and Google's definition | Closest MRC wording (our pairing, 2020 addendum) | IP field you can check | Our lookup, 21 Oct 2026 |
|---|---|---|---|---|
| GIVT | Data center: "Ad traffic originating from servers in data centers whose IPs are linked to invalid activity (typically non-human traffic)." | "Known invalid data-center traffic (determined to be a consistent source of invalid traffic; not including routing artifacts of legitimate users or virtual machine legitimate browsing)" (p. 5) | detection.is_hosting, asn.asn_type | 45.33.32.156: hosting, score 10, allow |
| GIVT | Known crawler: "Ad traffic from a program or automated script that requests content and declares itself as non-human (through a variety of identification mechanisms)." | "Bots and spiders or other crawlers" (p. 5) | threat.crawler.verified | 66.249.66.1: verified Googlebot, score 0, allow |
| GIVT | Irregular pattern: "Ad traffic that includes one or more attributes (for example, a user cookie) associated with known irregular patterns, such as auto-refresh traffic or duplicate clicks." | "Activity-based filtration using transaction-level data and parameters from campaign or application data" (p. 5) | None in the lookup. Count clicks per IP and prefix in your own log | None |
| SIVT | Automated browsing: "A program or automated script that requests web content (including digital ads) without user involvement and without declaring itself as a crawler, such as and primarily referring to botnets." | "Automated browsing from a dedicated device" and "from a non-dedicated device: infected and hijacked devices" (p. 6); crawlers "masquerading as legitimate users" (p. 7) | Partly: threat.is_scanner, threat.is_botnet | 162.142.125.10: scanner, score 0, allow |
| SIVT | False representation: "An ad request for inventory that is different from the actual inventory being supplied, including ad requests where the actual ad is rendered to a different website or application, device, or other target (such as geography)." | "Domain and App misrepresentation: App ID spoofing, domain laundering and falsified domain / site location" (p. 7) | None at the IP layer | None |
| SIVT | Misleading user interface: "A web page, application, or other visual element modified to falsely include one or more ads. This includes rendering ads that are not visible to the user, injecting ads without a publisher’s consent, or tricking users to click on an ad." | "Hidden/stacked/covered/transparent/invisible or otherwise intentionally obfuscated ad serving" and "Adware and Malware that conduct deceptive actions including ad injection" (p. 7) | None at the IP layer | None |
| SIVT | Manipulated behavior: "A browser, application, or other program that triggers an ad interaction without a user’s consent, such as an unintended click, an unexpected conversion, or false attribution for installation of a mobile application." | "Manipulated activity: Forced new browser window opening, forced tab opening, forced mobile application install (mobile re-direct), forced clicking behavior" (p. 6) | None at the IP layer | None |
| SIVT | Incentivized behavior: "The use of an explicit incentive to drive users to interact with one or more ads for the sole purpose of receiving said incentive and without any advertiser knowledge of its presence." | "Incentivized human invalid activity" (p. 6) | None at the IP layer | None |
| SIVT | Undisclosed classification: "Invalid traffic that cannot be classified using any of the other categories in the taxonomy, or sensitive invalid traffic that cannot be disclosed." | No single MRC item | None | None |
| SIVT (MRC only) | No DV360 label of its own | "Invalid proxy traffic (originating from an intermediary proxy device that exists to manipulate traffic counts or create/pass-on invalid traffic or otherwise failing to meet protocol validation)" (p. 7) | Partly: detection.is_vpn, is_proxy, is_tor, is_relay | 185.213.155.73: Mullvad, 100, block. 185.220.101.1: Tor, 100, block |
Two rows carry a qualifier. Hosting is not automatically invalid: DV360 counts IPs "linked to invalid activity," and the MRC excludes legitimate users' routing and virtual-machine browsing. Not every proxy is invalid either: the MRC counts one "that exists to manipulate traffic counts." The MRC also lists GIVT items DV360 doesn't name, such as pre-fetch traffic and 0x0 or 1x1 placements.
Is invalid traffic the same as click fraud?
No. Click fraud is the deliberate part of invalid traffic, and a large part of IVT has no intent to deceive at all. Verified search crawlers, pre-fetched pages and accidental taps all count as invalid, and none of them is fraud.
Googlebot shows the gap. In our lookup, 66.249.66.1 came back as a verified Googlebot, score 0, allow. It is GIVT under Known crawler, and you also want it on your site, so keep it out of ad and analytics counts but never block it. If a request claims to be Googlebot, check that a Googlebot request really comes from Google before you trust the name. Google publishes the ranges it uses on its crawler verification page.
Do you get refunded for invalid traffic?
If Google catches it in time, you are never charged. Google's About invalid traffic page says invalid traffic found before the end of the month is removed from billing and reports. If it is found after you were billed, "you'll receive credits in the form of a billing adjustment for the value of the invalid activity." You can request an investigation for activity "within the last 60 days."
The Invalid Activity Credit Report breaks those credits down by campaign, and the same page links the Click Quality Form for investigation requests.
Which invalid traffic categories can an IP lookup see, and which can't?
An IP lookup sees two of Google's nine categories cleanly and one partly. Your own click counts cover a fourth, and the IP layer cannot see the other five.
Sees cleanly:
- Data center.
detection.is_hostingandasn.asn_typesay the address belongs to a hosting network. Whether that network is linked to invalid activity, as Google's definition requires, is a separate judgment. We explain what makes an address a datacenter IP in a separate post. - Known crawler.
threat.crawler.verifiedis true when the address is in one of 19 official range feeds from 10 operators.
Sees partly:
- Invalid proxy traffic. The VPN, proxy, Tor and relay flags show the route. They cannot show whether the proxy "exists to manipulate traffic counts."
- Automated browsing.
threat.is_scannermarks known internet-wide scanner ranges.threat.is_botnetand thethreat.botnetgroup come from botnet command-and-control data, which describes the servers that run botnets, not the hijacked home devices that send the clicks. We have no safe botnet-flagged address to show. - Spoofed crawlers. The API never sees a User-Agent. A bot that claims to be Googlebot is caught only when your code compares the claimed name with
crawler.verified. - Irregular pattern. This is your own count of clicks per IP and per /24 or /64 prefix, not a field.
Cannot see: pre-fetch and pre-render, non-rendering sessions, non-browser user agents (header data, not IP data), invalid placements, hidden or stacked ads, clickjacking, manipulated activity, falsified measurement, domain and app spoofing, hijacked tags, adware injection, cookie stuffing, misappropriated content, incentivized humans and click farms, and traffic sent through residential proxies. Click farms and residential proxies arrive on ordinary ISP addresses, and the IP layer cannot tell them from real customers.
Five real lookups
We looked up five public addresses between 05:30 and 05:31 UTC on 21 October 2026, keyless, which our API allows at 30 per minute. None of them sent anyone an ad click. They stand in for addresses a click log contains.
| IP, what it is | Key fields | Score, action | detection_methods | What it shows |
|---|---|---|---|---|
| 45.33.32.156, scanme.nmap.org on Akamai Connected Cloud (Linode) | asn_type hosting, is_hosting true, crawler.verified false | 10, allow | datacenter_ip | A data-center IP is a GIVT candidate, not a verdict |
| 66.249.66.1, Googlebot | is_hosting true, crawler.verified true, name Googlebot, category search_engine | 0, allow | datacenter_ip, verified_crawler | Known crawler: GIVT and welcome |
| 185.213.155.73, Mullvad server in Frankfurt | is_vpn true, vpn_provider Mullvad, is_hosting true, is_anonymous true | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | A VPN is a risk signal, not an IVT tier |
| 185.220.101.1, Tor exit in Hamburg | is_tor true, is_hosting true, is_spammer true, dnsbl_sources zen.spamhaus.org | 100, block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer | Strongest proxy evidence, still not proof for one click |
| 162.142.125.10, Censys scanner in Ann Arbor | is_scanner true, threat_types scanner, is_hosting false, asn_type unknown | 0, allow | (empty) | Automation a hosting filter misses |
One address, end to end
The request puts the IP in the path:
curl https://api.geoiphub.com/v1/lookup/45.33.32.156 \
-H "x-api-key: YOUR_API_KEY"
This is a trimmed copy of the 05:30 UTC response, nesting kept and values unedited:
{
"ip": "45.33.32.156",
"asn": {
"asn": 63949,
"org": "AKAMAI-LINODE-AP - Akamai Connected Cloud",
"asn_type": "hosting"
},
"detection": {
"is_vpn": false,
"is_tor": false,
"is_hosting": true
},
"threat": {
"is_scanner": false,
"crawler": {
"verified": false,
"name": "none"
}
},
"scoring": {
"fraud_score": 10,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip"]
}
}
The data-center signal fired and nothing else did, so the score stayed at 10. Against both standards, this address is a candidate for GIVT review, not invalid by default. Googlebot at 66.249.66.1 is also on a hosting network, but it is verified, and it scored 0.
You can check whether an IP belongs to a data center for free, or read the API field reference.
Three things the lookups taught us
A hosting IP is not automatically GIVT. A plain cloud server with no other signal stays in allow.
Our block is not an IVT label. Mullvad and Tor both scored 100 and block, a risk verdict for your own flow. The MRC excludes "routing artifacts of legitimate users" from data-center GIVT, and a VPN user can be a real buyer.
The scanner hides from a hosting filter. Censys returned is_hosting: false, a score of 0 and empty detection_methods, yet threat.is_scanner was true. The flag does not move the score, so read it directly.
Where IP evidence is getting weaker
The MRC itself warns that IP-based filtering is weakening. Its 2024 IVT Interim Updates, published 24 April 2024, say on page 2 that "Limited or no IP address and less granular User Agent (UA) string may impair list-based approaches, particularly current Specific Identification, Data Center GIVT approaches" and activity-based techniques. Page 6 says all measurement organizations "must periodically assess (at least annually) IVT detection capability reliance on IP address, UA and user-level analysis."
Our own limits are plain. GeoIPHub does not classify IVT and holds no MRC accreditation. We return network evidence, and the advertiser or platform classifies. Lookups are a point in time, because ranges and lists change daily.
What to do with each category
Filter data-center and crawler traffic by field, score anonymizers, and stop expecting an IP check to find SIVT it cannot see. Here is the rule per category.
| Category | What to do | Field to read |
|---|---|---|
| Data center | Score at click time and keep it out of conversion signals. Don't blanket-exclude it, because the 500-entry Google Ads IP exclusion limit cannot hold a hosting network | detection.is_hosting, asn.asn_type |
| Known crawler | Allow it, and keep it out of ad and analytics counts | threat.crawler.verified, threat.crawler.name |
| Invalid proxy traffic | Score it and step up risky actions. Don't ban shared exits | detection.is_vpn, is_proxy, is_tor, is_relay |
| Automated browsing | Read the scanner and botnet flags. Compare the claimed User-Agent with crawler.verified in your code | threat.is_scanner, threat.is_botnet |
| Irregular pattern | Rate-limit per IP and per /24 or /64 prefix in your own log | None, your counts |
| Everything else | Rely on Google's filtering, your placement reports and the credit process | None |
For crawlers, the choice of which to let in is yours. We cover deciding which AI crawlers to block and verifying AI crawlers by reverse DNS and published ranges in separate posts. For Tor, our guide explains how Tor exit detection works. For bots in general, read what an IP can and can't tell you about a bot.
One caution applies to every row. threat.is_cgnat marks carrier NAT addresses, where one address carries many users, so never ban one on a click count. When a verdict surprises you, scoring.detection_methods lists the reasons behind it.
How to measure invalid traffic on your own account
Start with what Google already filtered, then add your own view. Google's help page tells you to add the "Invalid clicks" column to your campaigns table. It shows clicks Google filtered before billing, and Google does not charge you for them.
Your own view comes from your server. Log the click ID and client IP on your landing page, run one lookup per IP, and count clicks by field: hosting, verified crawler, VPN, Tor, scanner. Then count by /24 and /64 prefix to find irregular patterns. That is the IP-visible part of your invalid traffic. The rest stays with Google's filters and the credit process.
Pick one day of paid clicks, look up each address, and compare what you find with the "Invalid clicks" column.
Start Scoring Every IP in Real Time
GeoIPHub gives fraud, security, and engineering teams a single API for IP geolocation, VPN & proxy detection, threat intelligence, and an explainable 0 to 100 risk score.
Get Your Free API Key
Sign up in minutes, no credit card required. Upgrade only when you need more volume.
Frequently Asked Questions
What is the difference between GIVT and SIVT?
General invalid traffic is caught with lists and routine checks, such as known crawlers and data-center IPs tied to invalid activity. Sophisticated invalid traffic needs advanced analytics and human review, such as bots posing as users, hijacked devices and incentivized clicks.
What are Google's invalid traffic categories?
Google's Display & Video 360 help names three GIVT categories (data center, known crawler, irregular pattern) and six SIVT categories (automated browsing, false representation, misleading user interface, manipulated behavior, incentivized behavior, undisclosed classification).
Is VPN traffic GIVT or SIVT?
Neither by default. The MRC excludes routing artifacts of legitimate users from data-center GIVT, and it counts a proxy as SIVT only when it exists to manipulate traffic counts. A VPN flag tells you the route, not the intent.
Is all data center traffic invalid traffic?
No. Google's category covers data-center IPs linked to invalid activity, and the MRC excludes legitimate virtual machine browsing. In our lookup a plain cloud server scored 10 and was allowed.
Is invalid traffic the same as click fraud?
No. Invalid traffic includes activity with no intent to deceive, such as verified search crawlers and pre-fetch requests. Click fraud is the deliberate part of it.
Can an IP lookup detect sophisticated invalid traffic?
Only part of it. An IP lookup can show anonymizers, scanners and botnet feed matches. It cannot see click farms, residential proxies, hidden or stacked ads, cookie stuffing or domain spoofing.