Prompt Localisation

You write the prompt once, tick the cities, and press Save. GeoBubbles then builds a separate request for every model and every city — and handles the fact that the models disagree about what a "location" even is.

This page explains what happens after Save, so you can read your results correctly.

What you do

1. Write the prompt the way a customer would ask it. Do not add a city yourself — no "in Copenhagen", no "near me". If you have already written a location into the prompt, GeoBubbles will detect it and swap it for the city being checked rather than stacking a second one on top.
2. Pick the country, then tick the cities.
3. Save.

That is the whole job. You never need to know which model can target which city — if one of your selections cannot be reached, the page tells you before you save.

Why we do not simply add the city to the end

Two of the models have no concept of a city at all. The obvious workaround — pasting " in Copenhagen" onto the end of every prompt — breaks in ways that quietly corrupt your data:

• Punctuation. "What does migraine surgery cost?" becomes "What does migraine surgery cost? in Copenhagen".
• Locations already in the prompt. "Who is best at treating migraine in Denmark?" becomes "...in Denmark in Copenhagen".
• The end is not always the right place. "private pain clinic that treats complex migraine" reads correctly as "private pain clinic in Copenhagen that treats complex migraine".
• Language. A Danish prompt needs the Danish connector and the local spelling — "i København", not "in Copenhagen".

GeoBubbles rewrites grammatically instead of concatenating, in the language the prompt is written in, and the rewrite is generated once and reused for every measurement cycle so your wording never drifts between runs.

The two mechanisms

Native targeting. The model's API accepts a real location, so your prompt is sent word for word and the city travels separately. This is the cleanest signal: it measures what someone in that city sees when they ask your exact question.

Localised prompt. The API has no city field, so GeoBubbles keeps the country as the targeting signal and names the city inside the question instead. This measures whether you surface for city-intent phrasing — how people actually talk to a chatbot — which is a slightly different question, but it is the only way to get city-level data from these models.

Every city on a given model is treated identically, which is what keeps your city-to-city comparison valid.

Which model supports what

Country coverage

Coverage differs per model, and the gaps are real rather than cosmetic.

Claude's 36 countries: Argentina, Australia, Austria, Belgium, Brazil, Canada, Chile, China, Denmark, Finland, France, Germany, Hong Kong, India, Indonesia, Italy, Japan, Malaysia, Mexico, Netherlands, New Zealand, Norway, Philippines, Poland, Portugal, Russia, Saudi Arabia, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Turkiye, United Kingdom, United States.

If a country you need is missing from a model, that model is simply skipped for those prompts. The others still run. And if a city has no coverage anywhere but you still want it on your map, add it under Business Targets — see the section at the end of this page.

Prompts that should not be localised

Not every question has a local answer. "Can migraine be operated on?" and "When should you consider surgery?" have clinical answers, not geographic ones. Running them per city produces three near-identical results, and a report that shows no difference between cities invites exactly the wrong conclusion — that your visibility is flat, when in truth the question was never about place.

When you save, GeoBubbles classifies each prompt:

• City scope — the answer depends on where you are: who, where, which clinic, what does it cost here. These are localised per city as described above.
• Country scope — the answer does not depend on the city. These run once per country and are labelled Country in your reports, with no per-city breakdown.

Every prompt is measured against a place: there is no unlocated call. The only question is whether the place is a city or the country.

You can override the classification on any prompt. Change it once and leave it: flipping a prompt between city and country scope later breaks its trend line, because you are no longer measuring the same thing.

What you see in the app

On the Add prompts page, each selected city carries a badge per model:

• City — targeted natively, prompt untouched
• Localised — the city is named in the prompt, the country is targeted
• Country — country-level only, no city breakdown for this model
• Not supported — this model has no coverage for this country and will be skipped

Nothing is silently dropped. If a combination cannot be measured, it is shown as unavailable before you save, not discovered as a gap in your report weeks later.

Reading your results

• Compare cities within one model. Copenhagen against Aarhus on Gemini is a fair comparison — both got identical treatment.
• Do not compare one model's number against another's. They reach the city by different mechanisms, so a gap between them measures our plumbing, not your visibility.
• A small city returning national answers is a finding, not a failure. Where a model has too little local signal it falls back to national brands. That tells you local optimisation has less leverage there.
• Watch for cautious answers. On regulated topics — health, finance, legal — models often hedge or decline. GeoBubbles records that as its own outcome rather than counting it as an absence.

How the cartesian product works

When you define a prompt template and select N cities, GeoBubbles generates prompt × city combinations:

Prompts:    "best dentist in {city}"   →  3 cities: Zurich, Geneva, Basel
Result:     3 active prompts
            • "best dentist in Zurich"
            • "best dentist in Geneva"
            • "best dentist in Basel"

Each combination is a distinct prompt with its own:

• Measurement history.
• LLM responses (3 runs per cycle per provider — see Free trial overview).
• VS / SOV / TMR metrics.
• Position on the city map.

Why per-city matters

AI providers return different answers depending on location context, even for an identical prompt. Measuring per city reveals:

• Coverage gaps — cities where competitors appear and you don't.
• Strength clusters — regions where your brand is consistently cited.
• Local SERP differences — useful when planning local SEO investments.

Quota implications

Every (prompt × city) combination counts as one prompt toward your plan's prompt quota.

• 10 prompt templates × 5 cities = 50 prompts against your quota.
• Soft-deleting a (prompt × city) frees up one slot in the quota.

Plan carefully when adding cities — broad city lists multiply quota usage quickly.

Adding or removing cities later

• Adding a city re-runs the cartesian product for matching prompt templates and creates new (prompt × city) entries on the next cycle.
• Removing a city soft-deletes the (prompt × city) entries for that city; their historical data is preserved and they free up quota immediately.

City matching

City names are matched diacritic-insensitively and resolved against a curated catalog (e.g. København → Copenhagen, Zürich → Zurich). You can pick any city from the in-app City Finder.

Map-only locations (Business Targets)

Some businesses operate in cities that are not available as SEO SERP check locations — there is no Google SERP data for them, so they cannot be used as regular target cities for prompt measurement. To still display these cities on the map and include them in reporting, GeoBubbles lets you add them as Business Targets.

Business Targets are map-only locations sourced from a worldwide reference catalog of 45,000+ cities with coordinates. They are purely additive:

• They never create SERP checks or LLM runs.
• They never consume prompt quota.
• They never change the site's SEO country or existing prompt-location assignments.
• Their markers appear on the map alongside regular SEO-tracked cities.

How to add Business Targets

1. Open Site → Settings → Business Targets.
2. Select a country from the worldwide list.
3. Search for cities in that country and click to add them.
4. Added cities appear immediately on the map with grey markers and are included in reporting views.

Example: Denmark, Greenland, and the Faroe Islands

Consider a business headquartered in Denmark with offices in Copenhagen, Aarhus, and Odense — all valid Danish SEO SERP cities — that also operates in Sisimiut and Aasiaat (Greenland) and Tórshavn (Faroe Islands).

SEO SERP cities (Google Denmark):
  • Copenhagen
  • Aarhus
  • Odense

Business Targets (map-only, no SERP data):
  • Sisimiut      — Greenland
  • Aasiaat       — Greenland
  • Tórshavn      — Faroe Islands

Greenland and Faroe Islands cities are not available as Google SERP locations in the Danish locale, so they cannot be used as SEO target cities. By adding them as Business Targets, all six locations appear on the map and in reporting — while the site's Denmark SERP configuration, prompt quota, and existing prompt-location assignments stay completely untouched.