Signals That Link Accounts

When a platform decides two accounts are related, it does not usually cite a single reason. It accumulates evidence from several layers, and the layers differ sharply in how easy they are to fix.

This is the complete list, organised by layer, with the practical note attached to each.

Account data

The highest-signal layer, and the least technical.

Payment instrument. A card, bank account or payment processor identity reused across accounts. This is the strongest link available to most platforms, and it is hard to argue with.

Recovery email. The same recovery address on two accounts links them immediately, regardless of anything else.

Recovery phone. The same, with the added weight that phone numbers are harder to obtain in quantity legitimately.

Name and address details. Matching billing or shipping details.

Recovery codes and backup access. Overlapping codes or shared backup contacts.

Fix: one distinct instrument and one distinct recovery method per account. In an agency setting this is a client-authorisation matter as well as an operational one, covered in Multi-Account Management for Agencies.

Network layer

The layer that gets discussed most and is easiest to correct.

Shared exit address. Two accounts from one IP, consistently. The clearest technical link.

Subnet and ASN reuse. Different addresses in the same range, especially a small hosting range. Related addresses are weaker evidence than the same address, but they still cluster.

Datacenter and hosting ranges. Not a link by itself, but a reputation penalty that raises the weight of every other signal, per Why Residential IPs Are Trusted.

Address reuse across time. An address that previously belonged to a restricted account and now serves a fresh one carries the association.

Geo inconsistency. An account claiming one country with an address in another.

Fix: one address per account, held stable, on a consumer range in the account's country. Retire rather than recycle, which is the argument in Avoiding Residential IP Reuse.

Device and browser layer

Addressable with profile isolation, and easy to get partly right and still fail.

Cookies and local storage. A shared cookie jar links accounts on the first request.

Canvas and WebGL fingerprints. Rendering output varies by hardware and driver and is stable per device, so two profiles that produce identical output look like one machine.

Font fingerprint. Installed fonts and their metrics.

User agent and client hints. Identical, implausible or mismatched combinations.

Screen and viewport. The same unusual resolution across profiles.

Timezone and locale. The same combination that does not match the address.

WebRTC candidates. A leak exposes the host address and links every profile on that machine.

Fix: one isolated profile per account, with coherent rather than randomised signals, and a leak check. The criteria are in Evaluating an Antidetect Browser and the binding workflow in Assigning Proxies to Browser Profiles.

Behavioural layer

Cannot be fixed by configuration, only by practice.

Timing correlation. Accounts that act within seconds or minutes of each other, repeatedly. Visible from timestamps alone.

Sequence similarity. The same navigation path, the same order of actions, across accounts.

Cadence similarity. The same daily or weekly pattern.

Content overlap. The same text, links or media across accounts.

Interaction graphs. Accounts that follow, like or reply to the same set of others, particularly in a cluster.

Fix: vary schedules, vary sequences, do not run accounts as a synchronised set. The general principle is in Human-Like Behaviour in Automation.

Operational layer

The layer that is invisible from outside and still causes most incidents.

Shared credentials. One password or one password-manager entry across accounts. A leak of one compromises the set, and it is also detectable if it ever appears in a breach.

Shared operator. One person running twenty accounts by hand creates behavioural correlation by definition.

Shared notes and artefacts. A single spreadsheet with everything is fine; a single browser bookmark folder used across profiles from one machine is not.

Shared support history. Contacting platform support about several accounts from one email or one address.

Fix: one credential per account, separate support identities where an account needs its own, and an access model rather than informal sharing.

Which layers to fix first

Order by signal strength per unit of effort:

1. Account data. Strongest signal, cheapest fix. Distinct recovery details and payment instruments.
2. Network. Strong signal, cheap fix. One stable consumer-range address per account.
3. Device. Moderate signal, moderate effort. Isolated profiles with coherent signals and a leak check.
4. Operational. Invisible individually, decisive in aggregate. Credentials and access discipline.
5. Behavioural. Weakest individually, hardest to fix, and the one that defeats otherwise correct infrastructure.

Most people invest in 3 and ignore 1 and 2, which is the reverse of the return on effort. The infrastructure layer that covers 1 through 3 is described in Multi-Accounting, and the address products are Residential, Mobile and ISP proxies.