Paying for ad clicks from the wrong country

Written by Claude (AI) · research signals and editing by Nathan Pankowsky · see AI usage at the end

Most paid clicks on three small sites came from the country each site sells to. The exceptions were concentrated: on a UK lettings site, one Google campaign got all 9 of its clicks from Egypt, Sudan, Algeria, Bangladesh, Brazil, Nigeria and Sri Lanka, 7 of them from inside phone apps.

Across all ad clicks, 0.4% came from abroad on an Israeli store and 4–6% on two UK sites. Most of these visitors really were abroad: on the UK sites, 14 of the 18 had a clock set to the country their IP pointed to. They browsed about as far into the site as local visitors did. The fix sits in the campaign's settings, not in an IP block list.

Our data

The same three sites as our previous post on residential-proxy flags, over two to four days of October 2026. We withhold their names.

• An ad click is a Google, Microsoft or Meta click ID in the landing URL. Verified crawlers are removed.
• The IP's country comes from ipinfo. Two ad-click IPs without an ipinfo record are left out.
• The device's country comes from the browser itself: its time zone and language setting, read by our script. This is the cross-check that tells a traveller or a VPN user from someone who is really abroad.
• In-app means the page opened inside another app's built-in browser, which our script can tell apart. We don't publish how.

Result 1: few paid clicks came from abroad

Unpaid traffic is a different story. 87% of the UK shop's unpaid IPs and a third of the lettings site's were foreign, mostly datacenter addresses (91% and 56% of them): France, the Netherlands and the US on the shop; the US, China and Singapore on the lettings site. None of that costs ad money, so the rest of this post is about paid clicks only.

The Israeli store's three foreign clicks are not a problem. One came from a datacenter in Amsterdam. The other two were phones with Hebrew or Israeli settings: one on a Cyprus address with an Israeli clock, one on a US mobile network with a Hebrew-language phone.

Result 2: on the lettings site, one campaign bought abroad

On the UK lettings site, the foreign clicks were not spread evenly. They sat in two Google campaigns.

Campaign A got no UK clicks at all in four days. Its clicks opened inside a lock-screen app, a launcher, a mini-games app, a wallpaper carousel and similar apps, mostly on budget Android phones. Apps like these show ads to earn money, and a tap on one opens the advertiser's page in the app's own browser.

Google doesn't document what gad_source=5 means (we looked). On this site, 8 of the 25 clicks with that value came from abroad, against 7 of 177 clicks with gad_source=1 (32% against 4%).

We don't know Campaign A's settings. It may be meant to reach people abroad, for example overseas investors. If it isn't, its location settings are letting it serve in places the business can't sell to.

Result 3: foreign clicks were real people abroad who browsed normally

This compares the 18 foreign ad clicks on the two UK sites with the 291 local ones.

• The IP's country and the device agree. 16 of the 18 foreign clicks had a clock set outside the UK, and 14 of those matched the IP's country: Cairo, Khartoum, Dhaka, Colombo and so on. The other two were a Nigerian address with a Los Angeles clock and the travel eSIM below. None of the 291 UK clicks had a foreign clock. Where address and clock agree, the visitor is most likely really abroad, not a VPN user or a bot borrowing a foreign address.
• They browsed like local visitors. They went as deep into the site and left after one page about as often.
• Two reached the lettings site's contact page, from Pakistan and Brazil. We see the page view, not whether a form was sent, so we can't say if these were real enquiries or spam.

What is not a mismatch

An IP address can point to the wrong country for ordinary reasons. These cases don't belong in a "wrong country" count:

• Travel eSIMs. One UK shop click came from a travel eSIM's address in Frankfurt, on a phone with an Albanian clock: a traveller, routed through Germany.
• One proxy, maybe. One lettings click came from a Pakistani address on a device with a London clock, and ipinfo flags that address as a residential proxy. Either a UK visitor's traffic went out through a proxy abroad, or someone abroad set a London clock. It is the only foreign click with a UK clock.
• People abroad with home settings. The Israeli store's two foreign phones had Israeli or Hebrew settings. They are probably Israelis travelling or living abroad, and they can still buy.
• iCloud Private Relay. Apple keeps the user's rough location when it routes traffic, so these visits geolocate to the right country. They showed up as UK or Israeli here, not foreign.
• Roaming phones. A phone roaming abroad usually still gets its address from its home carrier, so it looks local. The opposite case, a tourist on a local SIM, looks local too.

That is why we check the device's clock and language before calling a click foreign. Where the IP's country and the device agree, as with seven of Campaign A's nine clicks, the person is most likely really there.

Limits

• Small numbers. The two UK sites had 18 foreign ad clicks between them, and Campaign A had nine. One or two clicks move any percentage here a long way.
• Short windows. Two to four days per site.
• IP location is sometimes wrong, more often for mobile carriers, satellite links and travel eSIMs. We used the device's clock and language as a check on it, not as a replacement.
• We don't know the campaigns' settings. Campaign A may be meant to reach people abroad. We only see where its clicks came from.
• Goals are page views (cart, contact page), not submitted forms or paid orders.
• Some clicks are missing. About 1 in 10 IPs only send the first request, which carries no URL, so their ad clicks aren't in any count here. The shop's export leaves out the first request altogether.
• The in-app counts can't be reproduced. They rely on an indicator we don't publish.

What to do with it

1. Check each campaign's location option. Google's default, "Presence or interest", also shows ads to people outside your target area who search for it or show interest in it. A business that only serves local customers usually wants "Presence", which targets people in or regularly in the area. See Google's help page on location options.
2. Look at where display and app clicks come from. The placement report shows which apps and sites your ads ran in. Mobile-app placements far from your market are the first candidates to exclude.
3. Check the device before calling a click foreign. A British phone on holiday has a British clock and language and a foreign address. A click whose address, clock and language all point abroad is a person abroad.
4. Don't use IP exclusions for this. As the previous post showed, most IPs click once, so excluding an address after its click rarely stops the next one.

Try it on your own traffic

Button Solutions shows where your paid clicks come from, per campaign, and a check of whether the device agrees with the IP is rolling out now. Sign up.

Reproduce it yourself

The scrubbed data and scripts are on GitHub, shared with the previous post: ip-quality-reproduction-oct-14-2026. The data has IP country, device clock and device language columns. reproduce_geo.py recomputes every figure in this post except the in-app counts, which rely on an indicator we don't publish. Site names, IPs, campaign IDs and click IDs are replaced with random tokens or removed.

The data and scripts are licensed CC BY-NC-ND 4.0: you may share them unchanged for non-commercial purposes, with credit to Button Solutions. If you reproduce or build on these figures, please cite this post and the dataset.

AI usage

This post was researched and written by Claude (Anthropic), with research signals and editing by Nathan Pankowsky. Claude wrote the analysis code and the text; every figure comes from that code.

References

• Google Ads Help, About advanced location options.