The symptom that brings most advertisers here: you suspect billed invalid traffic. Google's About invalid traffic page lists GCLIDs among the items to gather for an investigation: "The Google click identifiers associated with the suspicious clicks." The same page says "Google limits investigations to the past 60 days," while the Click view keeps 90 days, so the 60-day window is the one that binds. The Click view is a lookup table, not a verdict: it tells you which clicks Google recorded, and your logs tell you what each click did.
How we checked this. No ad-account test was run. Report fields and limits come from Google Ads API and Google Ads Help pages read on 13 November 2026, the sample query passed the validator in the Google Ads Query Builder for API v26 that day, and Google API team positions come from dated forum replies.
What does the Google Ads click view report show, and what does it leave out?
The Click view shows one row per click ID with its campaign, ad group, keyword, location, device and network, valid and invalid clicks mixed together, and it leaves out the IP address, user agent, time of day and any validity flag.
Google's API page describes the resource as "A click view with metrics aggregated at each click level, including both valid and invalid clicks." It adds: "For non-Search campaigns, metrics.clicks represents the number of valid and invalid interactions." (click_view, Google Ads API v26). Google's auto-tagging page says a GCLID is sometimes created at the impression, and "In the click view report, multiple clicks on the same ad by the same user are counted as multiple clicks in the same GCLID row" (About auto-tagging). Include metrics.clicks in every query: a value above 1 means repeat clicks on one GCLID row.
| Field | What Google says it is | Use as evidence |
|---|---|---|
| click_view.gclid | "Output only. The Google Click ID." | The join key to your logs, GA4 and CRM |
| click_view.keyword_info.text and match_type | "The text of the keyword"; keyword exists only when "the click corresponds to the SEARCH channel." | Shows which keyword a suspect burst hit |
| campaign.name, ad_group.name, click_view.ad_group_ad | Segmenting resources on click_view; the ad is "Output only. The associated ad." | Campaign and ad group names Google asks for, and the ad clicked |
| click_view.location_of_presence and area_of_interest | "The most specific location criterion associated with the impression" | Tests clicks against your location settings |
| click_view.page_number | "Page number in search results where the ad was shown." | Spots clicks concentrated on one page |
| segments.device, ad_network_type, click_type, slot | Segments available on the resource | Device and network for each row |
| metrics.clicks | The only metric on the resource | More than 1 means repeat clicks on one GCLID |
The field list has no IP address, no user agent, no timestamp finer than segments.date and no valid or invalid flag. Location fields return a location criterion, Google's ID for a place, not a city name, so look each ID up in Google's geo targets list before reading it. Google's ValueTrack mapping page calls it "The ID of the geographical location of the click." (ValueTrack mapping).
The Invalid clicks column is different: it counts clicks Google already filtered, at campaign level, with no GCLIDs, as covered in how to check invalid clicks in Google Ads. The Click Quality Form is different again: Google says you "can submit an investigation request using the Click Quality Form", so the form asks Google to look at clicks you doubt.
How do you pull Click view data: API, Google Ads scripts or BigQuery?
You pull Click view rows through a GAQL query to the Google Ads API, a Google Ads script that runs the same query, or the BigQuery Data Transfer table, one day per query and up to 90 days back.
Google's help center documents no click-level report in the Google Ads web interface; every documented route to the rows runs through the API or the BigQuery transfer that Google maps to it. The limit is strict: "Queries including ClickView must have a filter limiting the results to one day and can be requested for dates back to 90 days before the time of the request." Google also notes: "GCLIDs are not available in this report for App Campaigns for Installs (ACi) and App Campaigns for Pre-registration (ACpre)." (both from the click_view page).
This query passed Google's validator for v26 on 13 November 2026:
SELECT
click_view.gclid,
click_view.keyword_info.text,
click_view.keyword_info.match_type,
click_view.page_number,
click_view.location_of_presence.most_specific,
click_view.area_of_interest.most_specific,
campaign.name,
ad_group.name,
segments.date,
segments.device,
segments.ad_network_type,
segments.click_type,
metrics.clicks
FROM click_view
WHERE segments.date = '2026-11-12'
Two negative checks in the same validator show the limits: adding click_view.ip_address returned "'click_view.ip_address' is not a valid field in the SELECT clause", and replacing the date with a seven-day range returned "a filtering condition must be present in the WHERE clause specifying a single day within the last 90 days." The validator checks syntax and field rules, not your account data.
To pull one day of Click view rows:
- Pick one date inside the last 90 days.
- Run the query above with that date in segments.date.
- Save the result as one file for that day, keeping each GCLID exactly as returned.
- Repeat for each day you want to investigate, then combine the files into one clicks sheet.
- Google Ads API. Run the query once per date. Google says the API needs "dedicated developer tokens and OAuth credentials" (Google Ads scripts start page).
- Google Ads scripts. Google says scripts reporting "is backed by the Google Ads API and uses" GAQL, through AdsApp.search() and AdsApp.report(), with exportToSheet() for a spreadsheet (scripts reports). That reports page does not name click_view, so treat a script as the same GAQL query. Google says scripts work "without provisioning servers or managing developer credentials", so this is the route without a developer token.
- BigQuery Data Transfer. Google maps the table p_ads_ClickStats_customer_id to the "Click View" API resource (Google Ads transformation). Check its columns in your own dataset.
Rule of thumb, ours rather than Google's: save each day's rows every week. The data ages out at 90 days, and an investigation covers only the last 60.
Why do some clicks have no GCLID?
A click arrives without a GCLID when auto-tagging is off, a redirect strips the parameter, the click came from an iOS app and carries a wbraid instead, or the campaign is an App campaign.
Auto-tagging adds "a parameter called GCLID, short for 'Google Click Identifier'" to the URL, so a landing URL looks like www.example.com/?gclid=123xyz. Google says that "If your website uses redirects, it's also important to make sure the GCLID is passed to the final landing page" (About auto-tagging). Google's settings path is the Admin icon, Account settings, the Auto-tagging section, then the box next to "Tag the URL that people click through from my ad". Google also says "App campaigns don't respect auto-tagging features."
Some iOS traffic carries other identifiers. Google defines gbraid as present "when a user clicks on an ad on the web and is directed to your iOS app", and wbraid as present "when a user clicks on an ad in an iOS app and is directed to your webpage". Where several exist, Google uses "gclid, then wbraid, then gbraid" (upload click conversions). The click_view field list has a gclid field and no gbraid or wbraid field, so a visit that arrives with only a wbraid has no GCLID to match to a Click view row. For Performance Max, Google lists {gclid} as "Limited support." (ValueTrack parameters). Store each GCLID exactly as received: "The GCLID is case sensitive" (offline conversion import).
The reverse case also happens: a GCLID in your logs with no Click view row on the visit date. Google's clicks vs sessions page notes that if users bookmark your site with the gclid parameter, "Google Ads doesn't record the clicks and advertisers are not charged for these sessions since they're not actual clicks on the ads" (clicks and sessions troubleshooter). A bookmarked visit replays the GCLID of an earlier click, so query the days before the visit before calling a GCLID missing.
A Google Ads API Team forum reply of 16 January 2025 went further: "it's very likely that these missing GCLIDs are in fact included in the invalid clicks" (forum thread). That reply conflicts with the API page, which says the resource includes invalid clicks, so Google's position on missing GCLIDs is not settled in its documentation. An earlier thread got a flat answer on 24 June 2024: "it's not possible to identify whether it's a valid click or invalid click and there is no other workaround for this" (forum thread).
A GCLID that reached your site but is absent from the Click view is a question for Google, not proof of fraud.
How do you match Click view GCLIDs to your logs, GA4 and CRM?
Join on the exact GCLID string: Google's row supplies the date, campaign, keyword, location and network, and your records supply the IP, user agent, seconds-level timestamp and what the visitor did.
To match Click view rows to your own records by GCLID:
- Server access log. Parse the gclid out of each landing request URL, keeping its case. The line gives the timestamp, IP and user agent.
- GA4. Query the BigQuery export field collected_traffic_source.gclid, which Google describes as "The Google click identifier that was collected with the event." (GA4 BigQuery export schema). It shows which GCLIDs produced further events.
- CRM. Pull the GCLID stored on each lead record. Google's investigation page asks for "GCLIDs for each lead" when the issue is invalid leads.
- Join on the exact GCLID string, never on time. The Click view carries a date and no hour. Google's resource name for each row is
customers/{customer_id}/clickViews/{date}~{gclid}, so the date and the GCLID together identify a click. - Check the date. Each matched row's server-log date should equal its Click view segments.date. A visit that replays a bookmarked GCLID matches a row on an earlier date.
Hypothetical example, not real data: one day (12 November) for a local service account using Presence targeting.
| GCLID (hypothetical, not real data) | Click view (campaign, keyword, presence, network, clicks) | Server log and page events (time, IP, user agent, seconds on page) | GA4 and CRM | Read |
|---|---|---|---|---|
| gclid-A1 | Generic, plumber near me, target city, Google Search, 1 | 09:14:02, 198.51.100.24, Chrome on Windows, 184 s | form_submit; lead qualified by phone | Normal visit, leave out |
| gclid-A2 | Generic, emergency plumber, target city, Search Partners, 1 | 02:41:10, 203.0.113.7, headless Chrome, 1 s | No events; no lead | Pattern, include |
| gclid-A3 | Generic, emergency plumber, target city, Search Partners, 1 | 02:43:55, 203.0.113.7, headless Chrome, 0 s | No events; no lead | Pattern, include |
| gclid-A4 | Generic, emergency plumber, target city, Search Partners, 1 | 02:47:31, 203.0.113.7, headless Chrome, 2 s | No events; no lead | Pattern, include |
| gclid-A5 | Brand, brand name, target city, Google Search, 1 | 11:30:48, 192.0.2.40, Edge on Windows, 95 s; same IP, 140 s visit on 11 Nov | Events both days; one lead | Likely shared office network, leave out |
| gclid-A6 | No row on 11, 12 or 13 Nov | 10:02:17, 198.51.100.81, Safari on iPhone, 40 s | GA4 session; no lead | Ask Google, not proof |
| gclid-A7 | Generic, plumber near me, outside targeted country, Google Search, 1 | 15:20:44, 203.0.113.150, Chrome on Android, 3 s | No events; no lead | Include, outside targeting |
In this hypothetical example, rows 2 to 4 are three GCLIDs from one address within six minutes, on one keyword and network, with no engagement. Google notes a zero-second visit on its own does not mean the visitor left, so the no-events column carries the weight here, not the seconds. Row 5 is what Google warns about: "An IP address isn't always unique to one device", and Google adds that NAT lets "hundreds or thousands of devices" share one public address (About invalid traffic). Row 6 may be a bookmarked visit whose click falls before 11 November, or a click Google filtered, and the file cannot say which until earlier dates are queried. You would attach rows 2 to 4 and row 7, plus a note on how you joined them.
Which click patterns count as evidence of invalid clicks?
Patterns that repeat across many GCLIDs and show up in your own logs count as evidence; single events, absences and column readings do not.
| Pattern | Counts when | Does not count on its own when |
|---|---|---|
| Same IP or device behind many GCLIDs | Many GCLIDs in a short window, with no engagement | An office or carrier IP whose visits engage |
| location_of_presence outside your targeted locations | Your location option is Presence | Your option is Presence or interest, which allows them |
| Repeat clicks on one GCLID (metrics.clicks above 1) | Many rows show repeats and none engage | One visitor double clicked once |
| Concentration on one network, keyword or page_number | Search Partners or one keyword takes the clicks, none engage | Change history shows a budget, keyword or location change |
- Many GCLIDs from one IP within minutes, with no engagement, count as evidence; one office or carrier IP whose visits engage does not.
- Clicks located outside your targeted locations count when your location option is Presence; under Presence or interest they can be the setting working as designed.
- Repeat clicks count when many rows show them and none engage; one visitor who double clicked once does not.
Two things never count on their own. A GCLID with no Click view row may come from an earlier click date (bookmarks reuse old GCLIDs), an App campaign or a click Google may have filtered. A single bad lead, a high-CPC day, a gap between Google Ads clicks and GA4 sessions, or a high or low Invalid clicks column is a prompt to look, not a finding.
The repeat-click row rests on Google's wording that "A user might click your ad multiple times in a short period" (clicks and sessions troubleshooter). For location, Google lists "clicks outside of location targeting" among the issues the Click Quality Form covers (Issues with clicks and clickthrough rate). Google adds that it identifies location from signals such as IP address and settings and "doesn't guarantee location accuracy in every situation", so treat a few out-of-area rows as a prompt and a repeated cluster as the pattern (About invalid traffic). Settings are in our guide to clicks from other countries.
Tying a pattern to a named rival is a separate job, covered in how to prove competitor click fraud. To cut that exposure, see how to stop competitors clicking your ads.
Our verdict: file when a pattern repeats across GCLIDs, your logs show it and it falls inside 60 days. Otherwise keep collecting.
Packaging the file against Google's gather list, inside 60 days
Build one clicks sheet and one leads sheet keyed by GCLID, map their columns to each item on Google's gather list, and keep the activity inside the last 60 days.
The first column below is Google's "Prepare for an invalid traffic investigation" list, copied verbatim from About invalid traffic on 13 November 2026. The other two columns are ours.
| Google's item (verbatim) | Column(s) in your file | Where it comes from |
|---|---|---|
| Customer ID: Your 10-digit Google Ads account number. | Header line of the file | Your Google Ads account |
| Specific date range: The exact dates when you noticed the suspicious activity. Google limits investigations to the past 60 days. | date | Click view segments.date, checked against server log timestamps |
| Campaign and ad group names: The names of the campaigns and ad groups where you noticed the traffic spike or suspicious behavior. | campaign, ad_group | Click view campaign.name and ad_group.name |
| Suspicious keywords: Any keywords that drive the unusual traffic. | keyword, match_type | Click view keyword_info |
| Web server logs: Detailed logs of your website traffic. Specifically you should identify the following: | The next three rows | Server access log |
| IP addresses: A list of IP addresses that generate repetitive clicks or clicks without conversions. | ip | Server access log |
| Platforms and devices: Browser or device information from the suspected activity. | user_agent, device | Server log user agent; Click view segments.device |
| GCLIDs: The Google click identifiers associated with the suspicious clicks. This helps Google map the visit back to a specific ad interaction. | gclid | Server log landing URL, confirmed against the Click view |
| Lead details: If your issue relates to invalid leads, share a spreadsheet that contains: GCLIDs for each lead. Your assessment of each lead, such as outcomes from emailing or calling them. | gclid, lead_outcome | CRM lead record and your call or email result |
| Trend indicators: A brief explanation of why the traffic is suspicious. For example, a 300% spike in clicks without more conversions, or clicks that originate outside your targeted locations. | A short note above the rows | Your reading of the joined table |
Google's page also says an investigation "won't be able to confirm if specific clicks were marked as valid or invalid", and that later-detected invalid activity is credited "in the form of a billing adjustment". Traffic caught before billing is never charged, "so no refunds are necessary". The remedy is a credit.
Filing steps and wording for the Click Quality Form are in our Click Quality Form template. How credits appear on your invoice is in the invalid-click credits guide.
How ClickFortify logs the same evidence per click
ClickFortify keeps a click record for every block, with the timestamp, IP, device and network data and landing-page behavior that the Click view lacks, plus the GCLID when present, so you can match its records to Click view rows yourself.
ClickFortify scores each visit on 100+ device, network and behavior data points, and flagged sources are added to Google Ads IP exclusions automatically, at IP level. Every block keeps an evidence trail (click record: timestamp, IP, device and network data, behavior on the landing page, the gclid when present) that advertisers can use for invalid-click credit requests through Google's Click Quality Form.
ClickFortify lets you export your click data, with each click's status, to support an invalid-click investigation request to Google. That status is ClickFortify's score, not Google's billing decision. You match those records to your Click view pull by GCLID; ClickFortify does not pull the Click view or do the join. See click-level evidence for what each record holds.
ClickFortify never files the request for you and cannot promise Google will grant a credit. It does not see Google's validity decision for any click. It protects the landing-page path only, so lead form assets, call assets and Local Services Ads leads are invisible to it; validate those leads in your CRM. See ClickFortify for Google Search for the setup.
Our verdict: the Click view tells you which clicks Google recorded against your campaigns, not which were fraud. The proof comes from your side of the GCLID. Once the file is built, the response plan covers what to do next, and the complete guide to Google Ads fraud covers the wider picture.
