Guides
Reading a major social network by structure instead of size
Major social networks read by structure rather than size: identity, graph, who decides a post is seen, and what leaving costs, with fields to record.
A catalog built around size goes stale the moment it is published. Audience counts move, they are reported by the companies that benefit from them, and every service counts them differently. Any page that opens with a league table is telling you about the week it was written.
So this catalog is built around structure instead. A large general-purpose network has a shape, and the shape changes slowly. Once you can read the shape, you can work out what a service will be like to use, to build on, or to leave, without anyone telling you how many people are on it.
What to take away
- Four things determine how a service behaveshow identity works, how the connection graph is built, who decides that a post is seen, and what leaving costs.
- Nothing on this site states a company's audience figures, launch dates, ownership or feature list as fact, because all four move faster than a reference page can.
Reach is a property of arrangement, not of totals. That is what a network effect actually describes: value that comes from who else is present and how they are connected, rather than from a headcount.
The four questions
These are the load-bearing ones. Everything else is decoration on top.
Four structural questions
Identity
- What it decides
- Cost of being wrong
- Common options
- Real, pseudonym, disposable
- Why it matters
- Candor, moderation
Graph
- What it decides
- Reach ceiling
- Common options
- Mutual, one-way, per-post
- Why it matters
- Travel control
Distribution
- What it decides
- Who sees posts
- Common options
- Reader-led, ranked, mixed
- Why it matters
- Follower list value
Exit cost
- What it decides
- Portability of audience
- Common options
- Archive, audience
- Why it matters
- Bad year setback
How is identity handled?
How is the graph built?
Who decides a post is seen?
What does leaving cost?
The audience cost is whether you can reach the people you assembled once you are no longer there. Services differ enormously on the second, and it is the one that decides whether a bad year on a platform is a setback or a total loss.
A usable archive is a file you can open elsewhere: posts with dates, media files, and the addresses of people you followed. A read-only archive is a screen that shows the same material but gives you no file to move. The difference decides whether moving to another service is a migration or a fresh start.
The version that favors you
- Identity
- You choose what is attached to your name
- Graph
- Stable connections you can enumerate
- Distribution
- Readers decide, by subscribing
- Archive
- A full export in open formats, on demand
- Audience portability
- Contact details you hold yourself
- Interoperation
- Other software can read and post
The version that favors the service
- Identity
- The account is your legal identity and cannot be separated from it
- Graph
- An audience assembled per post from signals you cannot see
- Distribution
- A ranking system decides, and the rules are not published
- Archive
- Screens you can read and nothing you can take
- Audience portability
- A follower count and no way to reach it elsewhere
- Interoperation
- A single official client and a closed interface
Read it as a set of trade-offs, not a scorecard. A service that hands you everything in the middle column is usually harder to grow on, because the same closure that traps you also concentrates attention.
The axes are easier to see on named services. Facebook and LinkedIn base the connection graph on mutual confirmation. X allows one-way follows, so an account can assemble an audience without following back. TikTok builds much of each feed from topic signals rather than a stable follower list.
On identity, Facebook has long required a real-name style account, while Reddit has allowed persistent pseudonyms. On leaving cost, a full export in an open format is a different product from a screen you can read.
Why size is the least useful column
A published audience number is an answer to a question you did not ask. It usually counts accounts rather than people, over a window the publisher chose, using an activity threshold the publisher set. Two services quoting the same figure can mean genuinely different things by it, and neither definition is stable between reporting periods.
A network with a fraction of the audience can be far better at reaching the particular few thousand people you care about. Those people are arranged there in a way that lets a message travel.
Features are the wrong axis for a reference
Feature lists converge. Any capability that works on one large service shows up on its rivals within a season or two. A comparison built from feature checkboxes is out of date before it is proofread.
What a catalog entry should carry
Each entry on this site is built from fields that stay true longer than a marketing page does.
Field / What it records
- Identity model
- Whether real names, persistent pseudonyms or disposable accounts are allowed, and what a wrong public post costs.
- Graph type
- Whether connections are mutual confirmations, one-way follows, or assembled per post from topic signals.
- Distribution control
- Who decides what a post reaches: readers by subscription, a ranking system, or a mix.
- Archive and export
- What an owner can download, in what format, on demand, and whether it is usable elsewhere.
- Audience portability
- Whether contact details travel with the owner, or only a follower count remains.
- Interoperation
- Whether other software can read and post, or only an official client can.
- Source and date checked
- The page, terms or developer document the entry came from, and the day someone last confirmed it.
Catalog entry fields
- Categorypurpose in one line
- Identity modelnamed, pseudonymous, disposable
- Graph typemutual, one-way, group, per-post
- Distribution controlreader-led, ranked, mixture
- Content shapebuilt-around formats only
- Exportwhat download contains, how to ask
- Interoperationread/post terms
- Sourcepage checked and date
That last row matters more than the rest. A catalog is only worth reading if a reader can go and confirm an entry, and a field with no source behind it is an opinion in a table.
Checking a platform claim yourself
- Read the current terms and the current help pages rather than a summary. Both are edited without announcement, and a summary is a photograph of an older version.
- Prefer what the service tells its own developers over what it tells the press. Developer documentation is written for people who will notice if it is wrong.
- Test the export before you need it. Request a full download, time how long it takes, and open what comes back.
- Measure your own distribution mix rather than accepting a description of it. The share of your reach that comes from people who deliberately subscribed is the single most informative number you can get, and it is yours.
- Treat an audience figure as a claim with an author. Ask who counted, over what period, and what they counted as one user.
What this catalog will not tell you
It will not give you user totals, founding dates, ownership chains or a definitive feature grid. Those are all real things, and they all change on a schedule no reference page can match.
Stating them here would produce a page that is confidently wrong most of the time, which is worse than a page that sends you to the source.
What it will do is describe the shape of each service, say where each description came from, and mark clearly when something is a structural observation rather than a measured fact.
Common questions
If not size, what should I use to choose between two services?
The job you want done. Pick one outcome, do comparable work on both for a defined period, and compare the same fields on each. A matched trial answers the question you actually have; a comparison table answers a question nobody asked.
Is a small network ever the better choice?
Often. If the people you need are arranged in one place and can reach each other easily, a small service can outperform a large one for your purpose by a wide margin. Total audience is only useful when your audience is undefined.
How often does the structure of a service change?
Less often than features, more often than people expect, and usually in one direction: toward more ranking control and less portability. Treat any structural entry as needing a recheck rather than as settled, and note the date it was last confirmed.
Why not just cite the company's own numbers?
Because a number is not more reliable for being official. A company defines the metric, chooses the window, and publishes when it is favorable. Repeating that in a reference page launders a marketing claim into an apparent fact.
In this guide
- Major social networks facts: why user counts differMajor social networks facts: why platforms report different user numbers, what each definition counts, and how to check a figure in five steps.
- Major social networks by year: four shifts in who sees whatMajor social networks by year, told as four shapes in order: topic first, person first, the feed, and ranking, with what each did to who sees what.
- Reading major social networks data without fooling yourselfMajor social networks data: every field has a half-life, blank means four different things, and corrections have to keep the old state beside the new.
- Major Social Networks Updates 2027: Where to LookMajor social networks updates 2027: Ofcom's dated Online Safety Act milestones, plus the changelogs, policy pages and filings to check each month.
