Andrea, Jean, Kim: the names where the answer depends on the country

The expensive failure in name-to-gender is not the name nobody can resolve. A null is visible: you can count it, filter it, route it to a human.

The expensive failure is the name a system answers confidently and wrongly, and the largest single source of those is a small class of ordinary, high-frequency names whose dominant gender flips across borders.

The class

Every row below is our engine's own answer for that name with that country passed, taken from the live data:

None of these are edge cases in the "weird input" sense. Andrea is among the most common given names in both Italy and Germany, pointing in opposite directions.

Why this is worse than it looks

If an API returned a random 8% error rate you could reason about it as noise. This error is not noise. It is concentrated in one segment of your list.

Take a customer file that is 12% Italian. A country-blind lookup returns the globally dominant reading of Andrea — female, on 24,743 observations at 98% — and is therefore wrong for close to every Italian Andrea in the file. Your Italian segment now has a systematically broken gender column while the aggregate error rate still looks fine.

Aggregate accuracy hides this by construction. The only way to see it is to slice your evaluation by country, which is the same argument as splitting coverage from accuracy.

What the country parameter does

Pass a country and the lookup resolves against that country's data first rather than the global pool.

curl "https://namegender.com/api?name=Jean&country=FR" \
  -H "Authorization: Bearer YOUR_KEY"

{
  "q": "Jean",
  "name": "Jean",
  "gender": "male",
  "country": "FR",
  "total_names": 1910805,
  "probability": 100,
  "source": "db",
  "confidence": "high"
}

Change one character — country=US — and the same name comes back female, on 38,983 observations at 95%. Same string, opposite answer, both backed by national registration data.

That is the test worth running against any vendor in this category, ours included: if the answer does not change when the country does, the country parameter is decorative.

In bulk files the same thing is done with a country column — see adding a gender column to a spreadsheet. It is the highest-leverage column you can add to an upload.

Where the country data actually comes from

This is the part most vendors leave vague, so here it is explicitly.

Counted registration data — real birth-registration volumes, from which a probability can be observed rather than asserted — comes from seven national statistics offices:

Everywhere else, coverage comes from WGND 2.0, which spans 195 countries and territories but carries no counts at all. It can tell you a name is attested as male in a country. It cannot tell you how many people that was.

You can see the seam in the responses. Jean with country=FR returns 1,910,805 observations and confidence: high, because INSEE publishes the counts. Andrea with country=IT returns the correct answer — male — but with total_names: 0, a probability capped at 95, and confidence: unverified, because Italy publishes no name registration counts and the answer rests on attestation rather than volume.

Both answers are useful. They are not equally strong evidence, and the response says so rather than making you guess. The mechanics of those fields are in reading a gender response properly.

The endpoint we deliberately did not call "country of origin"

There is a /api/countries endpoint returning a name's distribution across countries. Competitors ship something similar and label it country of origin. Ours does not carry that name, and the reason is a measurement rather than a scruple.

Query Mehmet and the registration table opens with France, with Turkey absent entirely — because Turkey does not publish name registration counts and France does. The table is a faithful record of where we have measured data. Selling it as origin would mean presenting diaspora birth registrations as the etymological home of a name.

So the response returns two separate lists and declares its own limit:

• registrations — measured volume, only from the seven counted sources
• attested_in — presence, from the wider countless data
• basis — which of the two the answer rests on

If you have no country column

Three honest options, in order of preference.

Derive one. A phone prefix, a billing country, a shipping address, an email TLD (.it, .de) or the country recorded at signup are usually already in your database. Any of them beats nothing.

Treat the ambiguous rows as unknown. Filter on probability and route everything below your threshold to review rather than writing it to a customer record. A shorter, correct column is worth more than a complete, quietly wrong one.

Accept it and write it down. If the segment is small and the use is low-stakes — a salutation in a newsletter — accept the error, but record the assumption somewhere your successor will find it. A gender column with no provenance note becomes a fact nobody questions two years later.

A threshold that works in practice

Where the global pool genuinely disagrees with itself, the response tells you directly. Jean with no country and a UK bias comes back at probability 55 on 755 observations; Noa in the Netherlands sits at 72. Those numbers are the signal, and they are the reason probability exists as a separate field from gender.

Filter on it. Rows below 85, or carrying confidence of low or unverified, are the ones to hold back. On a typical Western list that is a small fraction; on mixed international data it is a much larger one — which is exactly the fraction you would rather find in a review queue than in a mail merge.

All of the above is reproducible on your own list with a free key: 100 credits a day, no card. The endpoints are documented in the API reference, and the product overview is on the gender API page.