Why do accounts get linked? The five factors platforms weigh

The word linkage gets thrown around as though it were a switch: cross the line and you are banned, stay behind it and you are safe. The actual logic works nothing like that. Platforms collect dozens of signals, assign each one a weight, sum them into a similarity score, and only act when that score crosses a threshold.

That distinction changes what you should do. The job is not to eliminate one signal, it is to keep the total below the line. This guide works through five factor groups in order: hardware and network, the browser layer, identity details, business data and behavioral rhythm. For each one it covers what it includes, roughly how much weight it carries, and whether any tool can address it. The last section gives a summary table and what to do once accounts are already linked.

First principle: linkage is a probability, not a switch

No platform declares two accounts to belong to one person because a single value matched. What happens is that dozens of signals are collected, each is weighted, and the sum becomes a similarity score that triggers manual review or automated action above a threshold. The weights are not equal: the harder a signal is to forge and the more stable it is, the more it counts.

That explains two things people notice constantly. One person changes nothing but the IP and immediately hits trouble, because the other groups already overlapped heavily and the change itself matched a pattern of one device rotating exits. Another changes nothing at all and stays fine, because the account count is low, the business data is genuinely separate, and nothing about the behavior is synchronized, so the total never reaches the line.

One more thing worth knowing: scoring is continuous, not a one-time check at signup. Platforms recompute at registration, at login, when details change, when a payout method is bound, when a transaction is disputed. So three quiet months does not mean safe. It means you have not yet hit an event that triggers a recount.

Factor 1: hardware and network, where platforms look past the IP

This is the familiar group, and the one most often reduced to just change the IP. What platforms actually read is a cluster of network traits, plus whether those traits agree with each other.

• The exit IP itself, its location, and its type: residential, datacenter or mobile
• The history of that address: whether many accounts have used it before, whether it carries a flag
• Whether the IP location agrees with the browser time zone, language and geolocation, which trips a flag more readily than a repeated IP does
• Whether DNS egress sits in the same region as the proxy exit or exposes a second path
• Whether WebRTC exposes real local and public addresses outside the proxy
• TLS handshake characteristics (JA3/JA4), determined by the order of client cipher suites and highly consistent within one client build

The third item is the one people skip. An IP claiming to be in the United States paired with a UTC+8 system clock and a Simplified Chinese browser language is a contradiction that barely exists among real users, and it stands out more than two accounts sharing an address. Whenever you change proxy, change time zone, language and geolocation with it. They are one group, not three separate settings.

This group is solvable with tooling: bind a separate proxy exit to every profile, align time zone and language to the exit region, and configure WebRTC behavior per profile. Just note that using free or heavily abused IPs hands the platform the bad-history signal voluntarily.

→ How to configure a proxy IP：Format, bulk import and 8 fixes when it will not connect

Factor 2: the browser layer, where storage and fingerprint are two different things

The browser layer splits in two, and conflating the halves is how people end up solving only one of them.

Storage identifiers: clearable, therefore lightly weighted

Cookies, LocalStorage, IndexedDB and Service Worker caches all live here. Platforms write long-lived identifiers into them and read them back for comparison on the next visit. The defining trait of this layer is that it can be cleared, and precisely because it can be cleared, no platform relies on it alone. Clearing your cache handles this layer, and nothing beyond it.

The browser fingerprint: the heaviest technical signal

This is the heaviest technical signal and the hardest to deal with. JavaScript can read a large number of environment characteristics, and combined they discriminate extremely well. Most of them are set by hardware and operating system, so they survive any amount of data clearing, which is exactly where the term fingerprint comes from.

• Canvas fingerprint: the browser draws a graphic off-screen and the result is hashed, and different GPUs and drivers differ by pixels the eye cannot see
• WebGL fingerprint: graphics card model, driver version, and the list of supported extensions
• Font list: the particular combination of fonts installed, which is highly distinctive
• AudioContext: differences in the floating-point output of the audio processing pipeline
• Base values: screen resolution and color depth, time zone, language, CPU core count, device memory, User-Agent and client hints

This is why changing IP alone so often fails. If two visits return an identical Canvas hash, font list and screen values, a different exit address does not change the conclusion. This group is also solvable with tooling, provided the values are configured at the engine level and stay consistent with each other, rather than being rewritten on the page by an extension, which merely adds a patched-interface trait of its own.

→ How to test a browser fingerprint：A per-item audit table and the three causes of inconsistency

Factor 3: identity details, which no tool can fix

From here on the situation changes. The first two groups are technical signals that software can handle. The three that follow are beyond any profile isolation, and they happen to be the ones that carry the most weight.

Identity details means everything you submit to prove who you are: registration email and phone number, verification documents, passport or national ID, business registration and legal representative, tax number, bank account paperwork. Platforms normalize these fields and compare them directly. A match is a strong link, and usually the end of the discussion.

• Email: adding a dot or a plus alias does not create a different address, because major platforms normalize both
• Phone number: reusing one number across accounts is among the most direct links there is, and number ranges from SMS reselling services are frequently flagged wholesale
• Verified identity: several entities under one personal name, or one document submitted twice, are matched almost by definition
• Business registration: sharing a legal representative or a registered address across stores is something platforms check explicitly
• Recovery email and security phone: the one people forget entirely, since several accounts pointing at one recovery address connect themselves for you

Factor 4: business data, where multi-store operations usually come undone

Business data is everything produced once accounts are actually running, and it is where e-commerce and advertising teams most often slip, because these are exactly the things people share to save effort.

• Payout accounts: several stores withdrawing to one payout account or one bank card, which is the detail e-commerce platforms check most carefully
• Payment methods: ad accounts sharing one credit card or one PayPal, a common reason a whole set of ad accounts goes down together
• Shipping and return addresses: a repeated return address, warehouse or dispatch point is hard to explain across supposedly separate stores
• Products and creatives: the same product photos, the same description copy or the same brand name appearing in several stores
• Logistics and supplier details: one fulfillment warehouse, one forwarder account, the same contact details printed on labels
• Invoice and tax details: repeated invoice titles or tax numbers

Judgments here are rarely real-time. They surface retroactively when something triggers a review: a verification round, an unusual withdrawal, a buyer complaint, an ad audit. That delay is what makes the group dangerous. Six quiet months does not mean the data is not sitting there waiting to be compared.

Again, no tool fixes this. Profile isolation can stop a platform seeing that two accounts came from one computer. It cannot make two stores withdrawing to one bank account look unrelated. The only remedy is designing the operation so they genuinely are independent.

→ Amazon multi-store operations：The environment signals a platform sees, and what re-verification checks

Factor 5: behavioral rhythm, the signal that tips a borderline score

This group is not a technical fingerprint and rarely carries the heaviest weight, but it has one property worth respecting: when everything else sits near the threshold, synchronized behavior is usually the item that pushes the score across it.

• Login timing: several accounts signing in within the same ten-minute window every day
• Action paths: the same click order and the same pages dwelt on, as though one person were working through one habit
• Interaction: accounts following, liking or commenting on each other, or all engaging with the same target
• Content rhythm: publishing times, posting frequency and creative style that match closely
• Transaction rhythm: order times, average order value and refund rates that move on visibly parallel curves
• Profile discipline: one profile used to log into several accounts in quick succession, or one account hopping between profiles

That last item deserves its own sentence. Plenty of people build clean separate profiles and then open whichever window was last used, which quietly destroys the mapping between account and profile. One account, one profile, always. It is a discipline rather than a feature, and it affects the outcome directly.

Nothing technical substitutes here either. Automation can take repetitive clicking off your hands, but how operations are distributed across the day, whether accounts interact, and whether content is differentiated are operating decisions that depend on how you use the accounts.

What tools fix and what they cannot, in one table

Seen together, the boundary is obvious. The point of this table is not to sell software but to direct effort: the first two groups are solved by buying the right tool, the last three only by process and discipline.

Which is why the familiar sales line, use this and you will never be linked, does not hold. Any tool covers the first two groups and no more. The honest version is that profile isolation takes the technical evidence apart, and the remaining three depend on how you prepare details, design the operation and use the accounts.

What to do once accounts are already linked

1. Stop first: do not keep logging other accounts into the same device and browser, or you pull accounts that are still clean into the same net.
2. Use the official appeal channel: technical measures cannot undo an association a platform has recorded, and only the appeal process addresses an existing judgment. Prepare evidence that entity, details and payouts are genuinely separate.
3. Find the shared item: walk the five groups one by one to find what actually overlapped. Nine times out of ten it is not the environment, it is a recovery email, a payout account or a return address.
4. Separate new accounts from the first login: independent profile, independent exit, independent identity and payout details, and never a profile that has already been flagged.
5. Accept one premise: fully unlinking accounts that are already connected is rare. Effort spent making sure new accounts do not repeat the pattern is worth more than repeated appeals.

A closing reminder: rules on multiple accounts vary widely, with some platforms permitting one person to run several stores under separate legal entities and others allowing one account only. Confirm the terms of your target platform before you start, and make sure the way you obtain and use accounts is permitted in the first place. Everything technical rests on that.

→ Multi-account profile management：Taking the first two factor groups apart properly