
Guides
Part of Professional networks: how to judge profile claims
Professional networks by country: the fields to record
Professional networks by country entries record separate fields, not one cell, with the regulator and identity rows worked through for France.
"Country" is the most requested column in any catalog of professional networks and the hardest to fill honestly, because it is not one column. It is at least three, and the three disagree.
A service can be operated from one country, available in a second, dominant in a third, and legally constrained in a fourth. A single cell labeled "country" collapses all of that into whichever one the editor happened to be thinking of. This page is about pulling the column apart into fields that can actually be checked, and about what varies between countries that a catalog should record.
A professional networks by country entry is therefore a set of fields, not one label. Each row records what a document or a test settles, and where nothing does, the entry says so.
One country, France, is used as the example below with LinkedIn as the named service, to show which rows official sources fill and which stay with the service's own documents.
What to take away
- Replace one country field with threewhere the operator is established, where the service is offered, and where it is the default. The first two are checkable. The third is not, from the outside.
- What genuinely differs by country is the rules around work identity: reference practices, identity documents, data protection, and language. Record those, not popularity.
- Where a service is the default in a market is a claim you can only report with a source, and usually the only sources are the service's own.
Three fields, not one
The three are the part of an entry that cannot be merged. The checkable entry table below keeps each as its own row and adds the surrounding rows a reader needs, from regional terms and identity documents to the date the entry was checked.
Operator jurisdiction. The country whose law the terms of service invoke and where the operating entity is registered. Source: the terms, usually the governing law clause, and the legal entity named in the privacy policy. This is a fact with a document behind it. It matters because it decides which regulator a complaint goes to and which data protection regime applies by default.
Three fields, not one
Operator jurisdiction
- What it is
- Law and entity
- Source
- Terms of service
- Verifiable
- Yes, document
- Why it matters
- Regulator applies
Availability
- What it is
- Where you can register
- Source
- Registration flow
- Verifiable
- Yes, tested
- Why it matters
- Regional rules apply
Local default
- What it is
- What people use
- Source
- Named survey
- Verifiable
- No, blank if unsure
- Why it matters
- Readers want it
Availability. Where the service will let you register and which regional versions of its terms exist. Source: the registration flow from the country in question, and the service's own list of regional policies where it publishes one. Many services publish separate terms or privacy notices for particular regions, and the existence of a regional notice is itself informative: it usually means the service has had to adapt to that region's rules.
Local default. Which service people in a given occupation and country actually use. This is the one readers want, and it is the one no catalog can verify. The service's own regional figures are self-defined and unaudited; independent surveys, where they exist, measure a sample at a moment. The honest entry says "widely reported as common in" with the source named, or leaves the field blank.
Keep the three separate. An entry that says a service is "in" a country when it means "registrable from" that country is telling the reader something it cannot support.
What actually varies by country
The differences that matter to a reader of a professional network catalog are not which logo is biggest, any more than they are for video services read country by country. They are the surrounding rules about work identity that the service has to accommodate.
Reference and background practice. In some countries a prospective employer expects to contact former employers directly and a public profile is a courtesy. In others, an employer's written reference is a regulated document with its own conventions, and a profile is at most a pointer to it. This shapes what a profile is for, and therefore what fields matter. Record which convention applies; the source is the labor ministry or an employment law body for that country, not the network.
Identity documents used for verification. A service that verifies identity has to pick a document, and the document is national. Where a national digital identity scheme exists, verification may run through it, with the assurance questions that identity and access management work raises anywhere; where it does not, the service falls back to a work email or a phone number. Record what document the service accepts in that country, from its own help article for that region.
Data protection regime. The regulator, the legal basis the service claims for processing, and whether the member has a right to erasure and to data portability. Source: the regional privacy notice, and the regulator's own site. Do not summarize the law; name the regulator and quote the notice.
Language and profile conventions. Whether the interface and the help documentation exist in the local language, and whether profile fields match local CV conventions (a photograph expected or discouraged, a date of birth field present or absent, qualifications structured in a way that maps to the local system). These are observable from the registration flow and they decide whether the service is usable, which is a more honest question than whether it is popular.
Employer verification norms. Whether a company page can be claimed by anyone with a matching email domain, or requires a registry document. This varies by region within the same service, and the help article for the region is the source. Employer verification norms are one of the professional networks facts that only the regional help article can settle.
None of the fields above is settled by geography, and it is still worth seeing how uneven the physical picture is. Where a service is reachable, where it is fast enough to be pleasant, and where it has bothered to publish a regional policy are three different maps, and none of them is the map of national borders.
A country entry that can be checked
| Field | Content | Source class |
|---|---|---|
| Operator jurisdiction | Country named in governing law clause | Terms of service |
| Regional terms | Whether a country-specific policy exists, and its date | Service's policy index |
| Registrable from | Yes, no, or partially, with what was tested | Registration flow |
| Identity documents accepted | As listed for this region | Regional help article |
| Data protection regulator | Named body | Regional privacy notice; regulator's site |
| Interface language | Available or not | Observation |
| Profile conventions | Notable differences from the service's default | Observation, with a note of what differed |
| Reported local usage | The source and its date, or blank | Named survey or the service's own regional figure |
| Checked | Date and from where | Your record |
Filling the regulator and identity rows for one country: France
Two rows can be filled from official sources before you open any service, because they belong to the country rather than to the network.
- Data protection regulator.For an EU country, the European Data Protection Board's member list names each national authority; for France it is the Commission Nationale de l'Informatique et des Libertés (CNIL). The regime behind it is the General Data Protection Regulation, Regulation (EU) 2016/679. The regional privacy notice then tells you which entity of the service answers to it.
- Identity documents and schemes.Under the eIDAS Regulation, EU Member States could, on a voluntary basis, notify national electronic identification schemes, and recognition of notified schemes by other Member States became mandatory in 2018. The European Digital Identity Framework that builds on it, Regulation (EU) 2024/1183, requires Member States to provide EU Digital Identity Wallets to citizens by the end of 2026. Whether a given network accepts either is a separate fact, and it comes from that network's help article for France, not from the regulation.
Applied to one named service, the regulator row splits in two. LinkedIn's members in the EU are served by LinkedIn Ireland Unlimited Company, so under the GDPR's one-stop-shop Ireland's Data Protection Commission acts as its lead supervisory authority, while a member in France can still complain to the CNIL, which passes a cross-border case to the lead authority. An entry for LinkedIn in France therefore records Ireland in the operator jurisdiction row, and both bodies, each with its role, in the regulator row.
The usage row shows the opposite case. A claim often repeated about the field, cited in Wikipedia's article on professional network services to the Society for New Communications Research, is that LinkedIn, Facebook and Twitter are among the top used. It names no country, so it cannot fill the reported local usage row for France or anywhere else; the row stays blank until a source about that country exists.
"From where" matters. Registration flows, visible fields, and even which policies are linked can depend on the network location of the person checking. An entry made from one country describes what that country sees.
Country entry checklist
- Operator jurisdictiongoverning law clause
- Regional termspolicy exists and date
- Registrable fromyes, no, partially
- Identity documents accepted for region
- Data protection regulator named
- Interface language available or not
- Reported local usagesource and date
- Checkeddate and from where
What not to do
Do not rank countries by usage. The figures are not comparable across services, and often not across regions within one service, for the reasons set out in the notes on platform figures.
Do not infer a country from a language. Languages cross borders and services localise unevenly.
Do not treat the operator's home country as the market. The two are correlated and not the same, and the difference is the whole reason the field exists.
Do not carry a "dominant in" claim forward from year to year. It was a claim with a date when you wrote it, and it is a stale claim now.
Common questions
A reader just wants to know what to use in one country. Is this too cautious?
For that reader, the useful answer is a question back: who in your occupation do you need to be found by, and where do they look? That is a fact about their peers and it is checkable by asking three of them. A catalog that pretends to know is guessing on their behalf. The professional networks overview covers the search side.
Should the catalog include services that operate in only one country?
Yes. Single-market services are often the ones a reader in that market most needs to know exist, and they are the ones global lists omit.
How do I record a service that has withdrawn from a country?
As a dated event with the source, in the availability field: registrable until, no longer registrable as of, with what you observed. Withdrawal is usually announced; the announcement is the document.
What if the regional terms differ from the main terms?
Then the regional terms are the ones that apply to that reader, and the entry should quote the difference. That difference is frequently the single most useful sentence in the whole entry.







