People You May Know: link prediction and recipient-side metrics

Prompt: "Design 'People You May Know' — the connection suggestion system on a social or professional network."

The course closes with the one problem whose data is fundamentally a graph rather than a table, and whose optimisation target, taken literally, produces harm.

This lesson frames the problem and sets its metrics, and both are shaped by one fact: a bad suggestion costs someone who never used the feature.

The clarifying questions

1. What counts as a good suggestion? An accepted invitation? An accepted invitation that leads to actual interaction? These differ more than they sound, and the metrics lesson is about that difference.
2. Are connections symmetric? A mutual connection (both parties agree) or a one-way follow? Symmetric connections need consent from both sides, which makes a bad suggestion cost someone else's attention as well as the sender's.
3. How large is the network, and what is the degree distribution? The average matters less than the tail — accounts with tens of thousands of connections break every naive algorithm.
4. Which signals may we use? Contact-book uploads, profile views, message metadata, and location history are all technically available and each carries a distinct privacy and legal position. This is a design constraint, not a formality, and the serving and monitoring lesson develops it.
5. Where is it shown, and how often? A sidebar module, a dedicated page, or a notification. Notifications raise the cost of a bad suggestion sharply.

The constraints we design against

Invented. The product is Beacon, a professional network.

Framing it as machine learning

• Input: a member, and a set of candidate members.
• Output: a ranked list of 10 candidates.
• Objective: maximise the probability of an invitation that is sent, accepted, and followed by real interaction — subject to a hard constraint on unwanted contact.

Why the obvious objective is dangerous

Take the objective literally — maximise invitation acceptances — and consider what the model learns to do.

Acceptance is highest when the recipient recognises the sender. Recognition is highest for people who have interacted recently, share a workplace, or live nearby. So far so good.

But acceptance is also high in cases the product must not enable:

• Suggesting a person to someone who has previously blocked or reported them, if the block was on another account or the graph signal is strong enough to override.
• Suggesting a person's private-life contacts to their professional network, or the reverse — the two-worlds problem, where an accurate suggestion is an unwanted disclosure.
• Suggesting someone to a person who has repeatedly ignored suggestions of them. Acceptance probability is not zero, and persistence eventually produces one — at the cost of pressure the recipient did not ask for.
• Suggesting a person to many strangers because a shared signal makes them look connected — turning one member into a target for unsolicited contact at volume.

An acceptance-maximising system does all of these, and each is locally optimal. This is why the metrics lesson puts an unwanted-contact guard metric at the same level as acceptance rather than below it, and why the framing above says "subject to a hard constraint" rather than listing it as a consideration.

The baseline first

Rank by number of mutual connections, descending. No model, no training, one query.

It is a strong baseline. Two people with 40 mutual connections almost certainly know each other, and mutual-connection count alone captures most of the available signal in a well-connected part of the graph.

Where it fails, and each failure motivates something later:

• New members have no connections, so nothing has mutual connections with them (see Serving, monitoring and follow-ups).
• All mutual connections are treated equally, so a shared connection who knows 20,000 people counts the same as one who knows 30. The graph features lesson fixes exactly this.
• It ignores attributes — the same employer, the same university, the same city — which is most of what makes two people plausible contacts on a professional network.
• It has no notion of the recipient's experience, which is the whole of the section above.

Metrics

The offline metrics are conventional. The online metric set is where this problem is unusual, because one of the guards is not a quality signal — it is a safety requirement.

Offline metrics

Build the evaluation set from the future, which this problem makes easy: take the graph as of a date, hold out every connection formed in the following 30 days, and ask whether the model would have suggested them.

The temporal split is natural here and is not optional. A random split over edges means the graph used to compute features contains the edge being predicted — the most direct possible leakage, and the model achieves near-perfect scores by reading the answer out of the input. Cut the graph at a timestamp, compute all features from before it, and evaluate on edges formed after.

That subtlety — that the features are computed from the graph whose future you are predicting — is the leakage trap specific to this problem, and it is worth naming explicitly.

Online metrics

The guard metric that defines the system

Send rate and acceptance rate measure the sender's experience. Every guard metric above measures the recipient's, and the recipient did not ask to be in this transaction.

This is the structural point. In every other case study in this course, a bad recommendation wastes the user's time. Here, a bad recommendation generates an unsolicited contact request to a third party. The cost lands on someone who was not using the feature.

A system optimised purely for acceptance will, reliably:

• Suggest a member to hundreds of strangers who share a weak signal, generating unwanted invitations at volume for that one person.
• Keep suggesting someone who has been dismissed repeatedly, because the model's estimate of acceptance probability does not decrease when a third party ignores them.
• Surface connections across contexts a member deliberately keeps separate.

So the metric set is not "acceptance, plus some monitoring". It is:

Maximise acceptance-with-interaction, subject to hard ceilings on report rate, block rate, and per-recipient unsolicited invitation volume.

Report rate and block rate are release gates: a model that raises acceptance by 5% and report rate by 15% does not ship. Say the rule with a number attached, in the metrics section, not at the end.

Per-recipient volume, specifically

The metric almost nobody names, and the one that matters most for the harm case.

Track, per member, the number of unsolicited invitations received per week from people with no mutual connections or with only weak shared signals. The distribution's tail is where harm lives: most members receive a handful, and a small number receive hundreds.

That tail is invisible in every averaged metric. Aggregate report rate stays flat while a small group of members has an unusable inbox. Monitor the 99th percentile of received-invitation volume, and cap it — the system can decline to make a suggestion when the target has already received many recent unsolicited invitations, regardless of how good the match looks.

That cap costs measurable acceptance rate. It is the correct trade, and defending it as a design requirement rather than as an ethical footnote is what this case study is testing.

The interaction requirement

Acceptance is a weak endpoint on a professional network, because accepting is socially cheaper than declining. Many accepted connections never produce a single interaction.

The stronger target is acceptance followed by interaction within 30 days — a message, a comment, a profile visit, a shared context. It is a smaller, slower, noisier label, and it is much closer to the thing worth building. Predict both, weight toward the second, and report both. This is the Section 10 multi-objective pattern at small scale.