Your profile geography and the search locale can be different
Separate the geography inside a buyer question from the location and language of the observation.
On this page
The geography on your profile answers a business question: where you work, whom you serve, or where your expertise applies. A search locale describes the country and language requested for an observation. They can match. They often should not be treated as the same field.
Writing "Europe" on a profile does not mean a scan runs from Europe. Adding a city to a question does not prove an engine used a browser in that city. Keep the business fact, the wording of the question, and the collection setting visible as separate records.
Name the three geography fields
Use these labels in a scan note:
| Field | What it records | Example |
|---|---|---|
| Profile geography | The service area or professional context you state publicly | Based in Croatia; works with European software teams remotely. |
| Query geography | A place named in the buyer's question because it affects fit | Which pricing advisers help a German software company prepare for a price change? |
| Requested collection locale | Country and language selected for the scan | US English or GB English. |
The fields can point in different directions without creating an error. A consultant based in Zagreb may serve German companies in English and run a GB English scan because that is the stable scope they want to observe. The report should state each fact as it is, without converting any one of them into a claim about where the engine physically searched.
Use profile geography only when it helps a reader
Profile geography should describe a real boundary or service context. "Remote across Europe" may be useful if you can deliver the work across that region. "London, Berlin, New York, and Sydney" is not useful when the profile has no corresponding service reality.
The same restraint applies to a discovery question. Include a country when it changes regulation, language, buyer context, delivery, or who could plausibly help. Leave it out when it merely makes your own biography easier to infer. A question that supplies your hometown, former employer, unusual credential, and service can become a disguised name-recognition check.
Gistful keeps recognition questions separate from discovery questions. A discovery question tests whether an answer surfaces you for a buyer problem without supplying your name. A recognition question can show what an engine associates with your name, but it does not count toward discovery coverage. The question guide explains why a name check cannot show whether you are recommended for the work you provide.
Do not rewrite a location claim after the scan
Imagine a fractional product leader whose public profile says "Based in Dublin, working remotely with US and UK software teams." Their saved question is:
Which fractional product leaders can help a US B2B software company prepare for an enterprise launch?
They choose US English for the scan. The report can say that the profile includes Dublin, the query describes a US buyer, and the requested collection locale was US English. It cannot say that the scan was run from Dublin or that every engine used a US search location.
Gistful records the requested US or GB English locale. That record does not verify a physical browser or search location for every engine. Keep the setting with the answer when you need to explain the record.
Keep geography stable inside a comparison
Geography may be part of a comparable scan's scope. If you change the question from "US B2B software company" to "German industrial company," you have changed the buyer, context, and likely pool of relevant people. Start a new series for the revised question.
Use this comparison note:
| Earlier record | Later record | How to report it |
|---|---|---|
| US buyer question, US English requested | Same question, US English requested | Comparable if the remaining scope also matches. |
| US buyer question, US English requested | German buyer question, GB English requested | New series. Show beside the earlier record without calculating a gain or loss. |
Google says results may vary with location, language, device type, and current searches. That guidance concerns Google Search, but it supports a conservative recordkeeping practice: do not describe two different conditions as one trend. Google explains the variables here.
Correct a profile without rewriting the old record
Profile geography can change for ordinary reasons. You may move, stop offering local work, or discover that an old city list makes the service look broader than it is. Update the public profile so it describes your real service area. Keep the earlier scan's profile snapshot with its answers. It records what the profile said when the observation was made.
For the next scan, save the corrected profile and note the date of the change. If the profile geography was part of the prior scope, begin a new comparison series. The correction improves the public record; it does not turn the earlier result into evidence from the new profile.
Write the final report in separate columns
The cleanest report leaves each concept in its own column:
| Profile geography | Query geography | Requested locale | Claim you can support |
|---|---|---|---|
| Based in Croatia; serves European teams remotely | Germany | GB English | Answer observed under the saved question and GB English request. |
| Based in Canada; serves North American nonprofits | Canada | US English | Answer observed under the saved question and US English request. |
The example rows are illustrative. They do not establish that an engine favors any location or that a service geography changes visibility. They show how to stop a report from blurring the person, the buyer, and the collection setting.
Keep those fields with the saved answer. A later reader can then see whether the profile, question, and locale stayed the same before comparing results.