Geo personalised ads and content: show each visitor the facts that are true where they are

Location is a fact about the visitor, not a mood

Most talk about geo personalisation sounds like a magic trick: show the visitor their town, add a little urgency, watch the numbers climb. That framing is why so much of it goes wrong.

Where someone is changes a handful of real facts. How fast their order arrives. What delivery costs. Whether they can walk into your shop this afternoon. Whether the event you are advertising is a short bus ride away or a five hour drive. When a page tells each visitor the facts that are true for them, it helps. When it pretends to know more than it does, or invents urgency it cannot back up, it does the opposite.

So the test I use is simple. Would the page be wrong, or less useful, if it showed the same thing to everyone? If yes, personalise by place. If no, leave it alone, because every variant you add is one more thing to build, test and keep honest.

Everything in this article is my own way of working, stated as mine. Where I lean on an outside fact, mostly the ad platforms' own documentation, Irish and EU law and the Data Protection Commission (DPC), it carries a footnote. The business in the examples is invented.

Worked example: meet the shop

Galtee Kit is an outdoor clothing shop in Cork. It does not exist. Niamh, who runs it, sells rain jackets, walking boots and base layers online at galteekit.example, and runs a small shop near the station where she also does boot fitting. Her bestselling jacket costs €140.

Three people open that jacket's page on the same Tuesday morning. One is in Cork. One is in Letterkenny. One is in Clifden. For the visitor in Cork, the true facts are: next day delivery, or collect it from the shop today. For the visitor in Letterkenny, Niamh's courier takes three working days and charges €6.95. For the visitor in Clifden, it takes two working days.

A single page that says "Free next day delivery" is true for one of the three and quietly false for the other two. That is the problem geo personalisation exists to solve. Not cleverness. Accuracy.

Where location comes from, and how far to trust it

Before you personalise anything, be honest about where the location came from. There are four sources, and they are not equally good.

The best is what the customer told you: an Eircode typed into a delivery checker, or the address saved on their account. An Eircode is seven characters in two parts. The first three are the routing key, shared by every address in one of 139 postal areas, and the last four are a unique identifier for that one address.¹ It is exact and they chose to give it.

Second is the browser's own location, from the Geolocation API. It is precise, but the browser asks the visitor for permission first, and it only works on secure (HTTPS) pages.² On a shop I almost never ask.

Third is the IP address. Your host or CDN looks up the visitor's network address in a database and returns a best guess. It costs the visitor nothing and needs no prompt, which is why everyone reaches for it. It is also the weakest of the three, and weaker in Ireland than in many countries. MaxMind, one of the main providers of these databases, publishes its own accuracy figures: for Ireland, 47% of IP addresses are placed within 50 km of the true location, 21% are placed in a city but further away than that, and 31% get no city at all.³ Mobile networks, office networks and VPNs all blur it further.

Fourth is nothing. Some requests arrive with no usable location, and Cloudflare, for example, marks those with a special country code of XX, and visitors on the Tor network with T1.⁴ Your page needs a sensible default for them.

Read it from the top. The customer's own Eircode wins whenever you have it. The IP lookup is a fallback, and it is only trusted for the coarse decision (which country, which of the four provinces). Anything finer than that, the page asks for.

Worked example: Niamh's month of visitors

Niamh looks at one month of traffic to her product pages: 10,000 visitors. Of those, 1,800 are signed in with a saved address. Another 600 type an Eircode into the delivery checker on the page. That leaves 7,600 who gave her nothing, and for 300 of those the IP lookup returns no country either.

So for 7,300 visitors the only clue is the IP address. If she used it to promise something at town level, MaxMind's own figures for Ireland say roughly half would get it wrong or blank:

$$7{,}300 \times (0.21 + 0.31) = 3{,}796$$

Here $7{,}300$ is the number of visitors located only by IP, $0.21$ is the share placed in the wrong city (more than 50 km away) and $0.31$ is the share with no city at all, so about $3{,}796$ visitors a month would see a town level promise that does not fit them. That is why Niamh uses IP only to tell Munster, Leinster, Connacht and the three Ulster counties apart, and puts an Eircode checker beside the delivery line for everything finer.

Reading the location at the edge, without storing it

Most modern hosting already does the IP lookup for you and hands the answer to your code as a request header. You do not need your own database or a library that parses addresses.

On Vercel, the country arrives in x-vercel-ip-country as a two letter ISO code, and x-vercel-ip-country-region carries the first level region. Where a country has two levels of subdivision, Vercel's documentation says the header holds the less specific one.⁵ In the ISO code list for Ireland the counties sit inside the four provinces, Connacht (C), Leinster (L), Munster (M) and Ulster (U), so the header should give a province such as M, not a county such as Cork.⁶ That is precisely the resolution Niamh needs, and she checks it on a test request before relying on it. On Cloudflare, the country arrives in the CF-IPCountry header.⁴

Two corrections to code you will still find in older tutorials, including an older version of this article. First, Next.js removed the geo and ip properties from its request object in version 15, because those values come from the hosting provider, not the framework.⁷ Second, the file that runs before every request, long called middleware, is called proxy from Next.js 16 onwards.⁸ And do not read the visitor's address straight out of x-forwarded-for on your own: behind a proxy it can hold a list of addresses, and Cloudflare recommends its own CF-Connecting-IP header for exactly that reason.⁴

The third correction is mine, and it matters more than the other two. The old version set the visitor's country in a cookie. You do not need to. The header arrives on every request, so the page can decide afresh each time and store nothing in the visitor's browser. That keeps a whole category of consent questions off the table, which I come back to in the section on the law.

Worked example: Niamh's proxy file

Niamh's site runs on Next.js on Vercel. Her proxy reads the province from the header and passes it to the page as a request header, so the page can render the right delivery line on the server. Nothing is written to the browser.

// proxy.js
import { NextResponse } from 'next/server'

const PROVINCES = ['C', 'L', 'M', 'U']

export function proxy(request) {
  const country = request.headers.get('x-vercel-ip-country') || ''
  const region = request.headers.get('x-vercel-ip-country-region') || ''

  // Trust the IP for one coarse decision only: which Irish province, or none.
  const province = country === 'IE' && PROVINCES.includes(region) ? region : 'UNKNOWN'

  const headers = new Headers(request.headers)
  headers.set('x-galteekit-province', province)
  return NextResponse.next({ request: { headers } })
}

export const config = { matcher: ['/products/:path*'] }

Step by step. A visitor on a Cork mobile network arrives with country IE and region M, so the page receives M and shows "Next day to most of Ireland, or collect in Cork today". A visitor in Letterkenny arrives with U, so the page shows "Three working days to Cavan, Donegal and Monaghan, €6.95". A visitor on a VPN that exits in the Netherlands arrives with NL, so the page receives UNKNOWN and shows the neutral line with the Eircode checker. If Niamh ran on Rails behind Cloudflare instead, the same decision would read request.headers['CF-IPCountry'] in a controller.

In the ads: decide who counts as being there

Location targeting in the ad platforms has one setting that decides more than any other, and most accounts never look at it.

In Google Ads, you choose between two options. "Presence or interest", the default and the one Google recommends, reaches people who are in your target area, regularly in it, or who have shown interest in it. "Presence" reaches only people who are in it or regularly in it.⁹ Interest is worked out from signals such as what people search for and the content they look at about a place.⁹ Google is candid that all of this is a best effort and that full accuracy is not guaranteed.¹⁰

You can target whole countries, regions, cities, postal codes in many countries, or a radius around an address, and Google does not allow a radius under 1 km.¹⁰

Meta made the same choice for you. Its targeting reference says the location type ['home', 'recent'] is the only option available, which means people who live in the area or were recently there.¹¹ The options to target only residents, or only people travelling through, are gone. A radius around a city runs from 17 to 80 km, and around a custom point, such as your shop, from 1 to 80 km.¹¹

The setting you want depends on one question. Does your offer need the person to be physically there? An online shop that delivers anywhere in Ireland can live with "presence or interest". A boot fitting, a shop event, or a same day delivery promise cannot.

Worked example: the boot fitting campaign

Niamh spends €1,200 a month on a Google Ads campaign for boot fitting at her Cork shop. It targets a 15 km radius around the shop, left on the default "presence or interest". In a month it gets 800 clicks at €1.50 each.

The location report shows that 220 of those clicks came from people physically outside Co. Cork, mostly people in Dublin searching for walking boots in Cork ahead of a trip to Kerry. They will not come in for a fitting. The share of clicks spent outside the area is a simple rate:

$$\text{share}_{\text{outside}} = \frac{\text{clicks from outside the area}}{\text{all clicks}}$$

Here $\text{share}_{\text{outside}}$ is the fraction of paid clicks that came from people outside the target area, the numerator counts those clicks, and the denominator counts every click in the same period. It is a ratio of events to opportunities, explained from scratch in Foundations: ratios and rates.

$$\text{share}_{\text{outside}} = \frac{220}{800} = 0.275$$

So 27.5% of the clicks, $220 \times €1.50 = €330$ a month, paid for people who could not use the service. Niamh switches the fitting campaign to "presence" and keeps "presence or interest" on her online shop campaigns, where a visitor from Dublin buying a jacket for that trip is exactly who she wants.

For the shop's gear swap evening she runs a Meta ad with a custom location pinned on the shop and a 10 km radius. She accepts that "recently in" will include a good few visitors to Cork, because Meta no longer lets her exclude them, and she says the date and the address in the first line of the ad so nobody travels by mistake.

In the ad text: name the place only where the promise holds

Google can put the place into the ad for you. With location insertion in responsive search ads, you type a brace while writing the ad text, choose location insertion, and Google fills in a city, a state or a country from your campaign's location targeting, with default text for when it cannot.¹² One location can go in a headline and up to two in the descriptions.¹²

It cuts both ways. The ad now claims something about that place, and if the promise is not true there, you have bought a click and a disappointment with the same euro.

Worked example: the headline that nearly misled

Niamh's online campaign targets Cork, Kinsale, Mallow and Midleton. Her first draft headline with location insertion reads "Boot fitting in [city]". In Kinsale it would read "Boot fitting in Kinsale". There is no fitting in Kinsale. The shop is in Cork city.

She rewrites it around a promise that is true in every targeted place: "Walking boots to [city] tomorrow", with default text "Walking boots, delivered tomorrow". Next day delivery holds for all four towns, so the place name adds relevance without adding a lie. The fitting gets its own ad, in the Cork only campaign, where "in Cork" is simply typed out. And the landing page repeats the promise in the same words, because the ad and the page have to agree, or the visitor feels the switch.

On the landing page: change the facts, keep the pitch

The page is where location earns its money. My rule is that the pitch stays the same everywhere and the facts change. The product, the photos, the reasons to buy are identical for Cork and Letterkenny. What changes is the delivery promise, the delivery cost, whether the shop is close enough to visit, and whether an item is in stock where it ships from.

The number to watch is the conversion rate for each place on its own, never the site average. The average is dominated by wherever most of your visitors are, and it will hide a region that is quietly failing.

$$\text{CR}_{r} = \frac{\text{orders from region } r}{\text{visitors from region } r}$$

Here $\text{CR}_{r}$ is the conversion rate for one region $r$, the numerator is the number of orders placed by visitors from that region in the period, and the denominator is the number of visitors from that region in the same period. Like the click share above, it rests on Foundations: ratios and rates, and the warning there applies here too: a rate from a small region with few visitors moves around a lot from month to month.

Worked example: the gap in the three Ulster counties

Niamh splits three months of orders by province, using the delivery address for orders and the IP province for visitors who did not buy.

The horizontal axis is the visitor's province. The vertical axis is the conversion rate as a percentage, orders divided by visitors for that province alone. The takeaway: the three Ulster counties in the State convert at about a third of Munster's rate, and Connacht at under three quarters of it.

Take Cavan, Donegal and Monaghan. In the three months, 4,000 visitors and 36 orders: $\text{CR}_{\text{U}} = \frac{36}{4{,}000} = 0.009$, so 0.9%. Niamh walks through the checkout as a Letterkenny customer and finds the leak at once. The page says "Free next day delivery". The checkout then adds €6.95 and three working days. That is the moment people leave.

The fix is not a trick. The product page now shows the true line for those three counties from the first screen, "Three working days to Cavan, Donegal and Monaghan, €6.95, free over €150", and the checkout says the same. For Connacht, where the IP cannot tell Galway city from Clifden, the page shows "Next day to most of Connacht" with the Eircode checker right beside it. Niamh does not assume this will work. She tests it, which is the next idea.

Prove it with a holdout, not with a story

Personalisation is a change to the page, so it gets tested like any other change. The cleanest way is a holdout: a random half of the eligible visitors keeps seeing the old page, the other half sees the personalised one, and you compare the two over the same weeks. Comparing this month with last month tells you nothing, because the weather, the season and your ad spend all moved too.

Decide the size of the test before you start, from the smallest lift you would care about. The formula for a test between two conversion rates is:

$$n = \frac{(z_{\alpha/2} + z_{\beta})^2 \left[p_1(1-p_1) + p_2(1-p_2)\right]}{(p_1 - p_2)^2}$$

Here $n$ is the number of visitors needed in each half of the test, $z_{\alpha/2}$ is 1.96 for a 5% significance level, $z_{\beta}$ is 0.84 for 80% power (an 80% chance of spotting a real lift of the size you chose), $p_1$ is the conversion rate you expect without the change and $p_2$ is the rate you hope for with it. The full derivation and what each choice means are in Foundations: sample size.

When the test is over, the result is a relative change from the old rate to the new one:

$$\Delta\% = \frac{v_{\text{new}} - v_{\text{old}}}{v_{\text{old}}} \times 100$$

Here $\Delta\%$ is the relative change, $v_{\text{new}}$ is the conversion rate with personalisation and $v_{\text{old}}$ is the rate without it. Keep it apart from the change in percentage points, which is simply $v_{\text{new}} - v_{\text{old}}$. The difference between the two is explained in Foundations: percentages.

And to tell a real lift from luck, a two proportion test:

$$z = \frac{p_1 - p_2}{\sqrt{p(1-p)\left(\frac{1}{n_1} + \frac{1}{n_2}\right)}}$$

Here $z$ is the test statistic, $p_1$ and $p_2$ are the two observed conversion rates, $p$ is the pooled rate across both halves, and $n_1$ and $n_2$ are the visitors in each half. A $z$ further from zero than 1.96 means the gap is significant at the 5% level. The reasoning is in Foundations: hypothesis tests.

Worked example: Niamh's six week test

The three Ulster counties alone are too small to test on, so Niamh tests the whole package of location aware delivery lines across every visitor the IP places in an Irish province. Her current rate is 2.0%. She would act on a lift to 2.4%. With 1.96 and 0.84, the first bracket is $(1.96 + 0.84)^2 = 7.84$, and the variance term is $0.020 \times 0.980 + 0.024 \times 0.976 = 0.043024$. The gap she wants to detect is $0.024 - 0.020 = 0.004$. Putting it together:

$$n = \frac{7.84 \times 0.043024}{0.004^2} = \frac{0.33731}{0.000016} = 21{,}082$$

She needs about $n = 21{,}082$ visitors in each half, 42,164 in all. With 30,000 eligible visitors a month, that is a little over six weeks, so she sets the end date before she starts and does not peek.

At the end, the old page converted 422 of 21,100 visitors (2.0%) and the personalised page 485 of 21,100 (about 2.3%). The relative lift:

$$\Delta\% = \frac{2.3 - 2.0}{2.0} \times 100 = 15$$

So a 15% relative lift, or 0.3 percentage points. Is it luck? The pooled rate is $p = \frac{422 + 485}{42{,}200} = 0.0215$, and then:

$$z = \frac{0.023 - 0.020}{\sqrt{0.0215 \times 0.9785 \times \frac{2}{21{,}100}}} = \frac{0.003}{0.001412} = 2.12$$

With $z = 2.12$, beyond 1.96, the lift is significant at the 5% level (the two sided p value is about 0.03). It is smaller than the 2.4% she hoped for and still well worth keeping. Notice what she does not do: quote one region's best week as the headline. A big number from one test, in one season, is a story. The holdout is the evidence.

In email: use the address you already have

Email is the easiest place to get location right, and the place it most often goes wrong. People reach for the IP address of the last email open, which might be a work network, a phone on a train or an email provider's own image proxy. Meanwhile the customer's delivery address sits in the order history, exact and given freely, Eircode and all.

So in email I personalise from the last delivery address and nothing else. Every email platform with conditional blocks can do this, and if the email is built on your own server, it is a few lines of code.

Worked example: the winter boots email

Niamh sends a winter boots email in November. The line about delivery has to be true for each customer, and her courier's terms set three groups by routing key: a three day list covering most of Cavan, Donegal and Monaghan, a two day list for parts of Mayo and Connemara, and the rest of Ireland. Her shop runs on Rails, so the email picks the line from the saved address:

class DeliveryPromise
  # Routing keys on the courier's lists (Niamh's own contract)
  THREE_DAY_KEYS = %w[F92 F93 F94 H12 H14 H16 H18 H23 A75].freeze
  SLOWER_KEYS = %w[F23 F26 F28 F31 H71].freeze

  def self.for(eircode)
    # The routing key is the first three characters: a letter and two digits, or D6W
    key = eircode.to_s.upcase.delete(" ")[/\A[A-Z][0-9][0-9W]/]
    return "Three working days to you, €6.95, free over €150" if THREE_DAY_KEYS.include?(key)
    return "Two working days to you, free over €75" if SLOWER_KEYS.include?(key)
    return "Next day delivery, free over €75" if key

    "Free delivery over €75 to most of Ireland"
  end
end

Step by step. A customer on Cork's southside has an Eircode starting T12, which is on neither list, so the email says "Next day delivery, free over €75". A customer in Clifden has the routing key H71, on the two day list, so the email says two working days.¹³ A customer in Letterkenny with F92 gets the three day line. A newsletter subscriber who has never ordered has no Eircode, so the email falls back to the neutral line rather than guessing from where they opened the last one. Niamh keeps the lists in one place, the same file her product page uses, so the email and the page never contradict each other.

The law: what location data means in Ireland

None of this is legal advice, and when real risk is in play I check with a solicitor. But three points shape how I build it, and each comes from the regulation itself, the courts or the regulator.

First, an IP address is personal data. The EU GDPR names online identifiers in its definition of personal data in Article 4(1), and Recital 30 gives internet protocol addresses and cookie identifiers as examples.¹⁴ The Court of Justice of the European Union confirmed in Breyer that even a dynamic IP address is personal data for a website operator that has the legal means to identify the person behind it.¹⁵ So looking one up, even for a moment, is processing personal data. It needs a lawful basis and a line in your privacy notice, and it is a good reason to use it for one coarse decision and then let it go.

Second, the location rule in the ePrivacy Regulations 2011 (S.I. No. 336 of 2011) is narrower than people think. Regulation 9 allows location data other than traffic data to be processed only when it is made anonymous or the person has consented, to the extent needed for a value added service. Regulation 2 defines location data as data processed in an electronic communications network or by an electronic communications service that shows where a user's device is.¹⁶ That is the data networks and telecoms services create, such as tracing a phone through mobile masts. As I read it, a shop estimating a province from an IP address header on its own web server is not handling that kind of data, so regulation 9 is not the rule that governs it. The GDPR is. That reading is my own, and it is the first thing I would put to a solicitor if a project leaned on it.

Third, storing things in the visitor's browser has its own rule. Under regulation 5(3), storing information on the visitor's device needs consent, and regulation 5(5) exempts only what is strictly necessary for a service the visitor explicitly asked for.¹⁶ The DPC's guidance accepts that a cookie recording a language or country preference the visitor set can be strictly necessary, and it is just as clear that cookies used to track the location of a user or a device need consent.¹⁷ A cookie holding a country guessed from the IP is not a preference the visitor chose. It is an estimate of where they are. Deciding on each request from the header, as Niamh's proxy does, avoids the question entirely.

Worked example: Niamh's three line check

Before launch, Niamh checks three things. Her privacy notice now says, in plain words, that the site uses the visitor's IP address to estimate which province they are in, so it can show the right delivery information, and that this estimate is not stored. Her proxy writes no cookie and logs no location. And the browser's location prompt never appears, because she never calls the Geolocation API. If she ever wanted a "find my nearest stockist" button, she would trigger that prompt only when the visitor presses the button, never on page load.

For the wider question of how far personalisation should go before it stops feeling helpful, the story in the ethics of personalisation is the one I keep coming back to.

Where to start on Monday

You do not need a personalisation platform for this. You need a short list of facts that genuinely differ by place.

Start with the delivery promise, because it is the fact most likely to be wrong for somebody today. Split your conversion rate by province or county and look for the one that is quietly failing. Set the ad platforms' location option on purpose, campaign by campaign, asking whether the offer needs the person to be there. Put the place name into an ad only where the promise holds in every place it will be inserted. Use the customer's own Eircode wherever you have it and the IP address only for the coarse call. Store nothing you do not need. And test the whole thing with a holdout, sized before you begin.

Selling across borders, with other currencies, languages and tax rules, is a bigger job with its own traps, and I cover it in cross border PPC and scaling internationally. Opening a new town from scratch is in bootstrapping local market growth.

Footnotes

1. Eircode, What is Eircode, eircode.ie, https://www.eircode.ie/what-is-eircode

2. MDN contributors, Geolocation API, MDN Web Docs, Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API

3. MaxMind, GeoIP Accuracy Comparison, MaxMind, https://www.maxmind.com/en/geoip-accuracy-comparison

4. Cloudflare, Cloudflare HTTP headers, Cloudflare documentation, https://developers.cloudflare.com/fundamentals/reference/http-headers/

5. Vercel, Request headers, Vercel documentation, 2025, https://vercel.com/docs/headers/request-headers

6. Wikipedia contributors, ISO subdivision codes for Ireland (provinces and counties), Wikipedia, https://en.wikipedia.org/wiki/ISO_3166-2:IE

7. Vercel, How to upgrade to version 15, Next.js documentation, https://nextjs.org/docs/app/guides/upgrading/version-15

8. Vercel, proxy.js file convention, Next.js documentation, https://nextjs.org/docs/app/api-reference/file-conventions/proxy

9. Google, About advanced location options, Google Ads Help, https://support.google.com/google-ads/answer/1722038

10. Google, Target ads to geographic locations, Google Ads Help, https://support.google.com/google-ads/answer/1722043

11. Meta, Basic Targeting, Marketing API documentation, Meta for Developers, https://developers.facebook.com/docs/marketing-api/audiences/reference/basic-targeting

12. Google, About location insertion for responsive search ads, Google Ads Help, https://support.google.com/google-ads/answer/9773001?hl=en-GB

13. Wikipedia contributors, List of Eircode routing areas in Ireland, Wikipedia, https://en.wikipedia.org/wiki/List_of_Eircode_routing_areas_in_Ireland

14. European Parliament and Council of the European Union, Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4(1) and Recital 30, EUR Lex, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

15. Court of Justice of the European Union, Patrick Breyer v Bundesrepublik Deutschland, Case C 582/14, judgment of 19 October 2016, EUR Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0582

16. Government of Ireland, European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, regulations 2, 5 and 9, Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

17. Data Protection Commission, Guidance note on cookies and other tracking technologies, DPC, April 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf