Multi-accounting

The term covers a wide range of entirely ordinary work. An agency holding twenty client Instagram accounts is multi-accounting. So is a seller with storefronts in four countries, a studio maintaining separate accounts per game, or a researcher running the same test from five personas. What they share is a constraint: platforms associate accounts that look related, and association can mean actions taken against one propagate to the others.

Why platforms track association at all

Proving coordinated abuse is expensive. Drawing an edge in a graph is not. A platform does not need to demonstrate that twenty accounts are operated by one person — it only needs a single shared value between them: an exit IP, a device identifier, a cookie, a recovery phone number, a card. Once the edge exists, enforcement travels along it. That is why the characteristic failure of multi-accounting is not losing one account; it is a cluster of accounts going down inside the same hour, including the ones that had done nothing.

It also explains why the platforms that officially support several accounts still punish this work. Instagram lets you keep five accounts signed in behind one in-app switcher, and TikTok has its own switcher. Using them is a voluntary, explicit declaration that those accounts belong to one operator — convenient for a person with a personal and a business profile, and the single fastest way to link accounts that were supposed to be independent.

What links accounts together

• Exit IP — the cheapest edge there is. Two accounts on the same address is a hard link; two accounts on the same /24 at the same hour is a soft one that still gets stored.
• Device identity — a shared device fingerprint, or cloned devices carrying an identical Android ID, IMEI or build fingerprint.
• The advertising ID — one GAID per Android device, readable by every app on it, and persistent across app reinstalls until it is manually reset. Two accounts reporting the same ad ID are the same device.
• Storage residue — cookies, WebView databases and files under /sdcard. Clearing an app’s data does not clear external storage, so an avatar, a cached upload or a token file can outlive the account it belonged to.
• Recovery details — one phone number used to SMS-verify five accounts links all five, permanently, at the strongest possible confidence.
• Payment instruments — the same card or PayPal address across storefronts, matched on a stable token rather than the displayed number.
• The social graph — accounts that follow each other, or that all follow the same thirty seed accounts in the same order within their first week.
• Timing — accounts created inside the same ten-minute window, then active every day inside the same three-minute window.

The links operators forget

The device layer gets the attention, and the content layer leaks anyway. The same avatar file uploaded to twenty accounts is byte-identical and matches on a perceptual hash even after re-encoding. Photos taken on one phone carry the same EXIF camera model and, if location was ever on, the same coordinates. Bios written from one template share phrasing that clusters trivially. A Google account signed into the device for Play Store access links the device to a real identity regardless of what the app-level profile says. And one login from your own personal phone — the emergency, five-minute, just-this-once login — creates an edge that never expires.

Auditing a fleet before it costs you

Most of the fatal links are detectable from your own side in a few minutes, because they are duplicates in a list. The method is always the same: collect one value per device, sort it, and look for repeats.

• Exit addresses — run curl -x <proxy> https://api.ipify.org for every proxy, then pipe the collected output through sort | uniq -d. Any line that comes back is two accounts sharing an address.
• Device identifiers — adb -s <serial> shell settings get secure android_id across the fleet, deduplicated the same way. A cloned image gives you the same value on every device.
• Region coherence — compare adb shell getprop persist.sys.timezone and the device locale against the geolocation of the proxy that device uses. These are set independently, so they drift independently.
• Ad ID — check it per device under Settings, Google, Ads, and reset it whenever a device is reassigned to a different account.
• Account metadata — export creation dates and first-action timestamps. Clustering inside a few minutes is a pattern you created and can still spread out.

Errors precise enough to name

• A device set to America/New_York behind a proxy exiting in Sao Paulo. One timezone-aware request settles it, and the contradiction was introduced by the operator, not the provider.
• Restoring every device from one golden image without regenerating identifiers — same Android ID, same build.prop values, same MAC, twenty times over.
• Handles numbered in sequence: brand_01 through brand_20, registered the same afternoon.
• One phone number reused for verification because SMS numbers cost money and the accounts "are all mine anyway".
• Warming twenty accounts on identical schedules, which describes a pattern more clearly than no warmup at all — see account warmup.
• Rotating an IP mid-session, so a logged-in account changes country between two requests. A sticky session exists precisely to prevent this.

What a working setup looks like is unglamorous: one account, one device, one IP, and behaviour that diverges over time. The hardware layer is handled by giving each account genuinely separate device identifiers; the network layer by one residential or mobile proxy per device, matched to the account’s region. The behavioural layer is the one people skip, and it is where most setups eventually give themselves away.

Scaling this by buying handsets stops working quickly — twenty phones is a drawer of cables, two hundred is a room with a power problem. That constraint is what phone farms exist to remove.