Why multi account setups get linked together
Why multi account setups get linked together
An agency that buys lines from me ran twelve ad accounts on twelve dedicated mobile IPs. Twelve browser profiles, twelve device fingerprints, the whole setup, and a monthly bill to match. Every one of those accounts was funded by the same virtual card, because the finance person wanted a single statement to reconcile.
They lost the batch in the same week. The network was never the problem. The card was.
That is the shape of almost every one of these failures I get told about. Money goes into the layer that is easiest to buy, and the layer that does the actual linking is free to fix and gets skipped.
The order that actually matters
Ask ten operators how platforms group accounts and nine will say the IP address. It is the answer that gets repeated because it is the answer that has something to sell attached to it.
Here is the ranking I would use, strongest first: shared payment instruments and recovery contacts, then behavioural timing, then the browser fingerprint surface, then the network path. The address comes last.
The logic is not mysterious. A detection system wants joins that are cheap to compute, hard for a person to change, and unlikely to fire on honest users. An IP address fails the last two badly. Millions of ordinary people share carrier space, a phone hops address walking down a corridor, and treating an address as identity would suspend a large slice of a platform’s real customers.
Tier one: money and the way back in
Payment data and recovery contacts are the strongest joins available, and they are the ones nobody audits.
A card number, a bank account, a payout destination, a billing address, a wallet, a phone number used for 2FA, a recovery email. Each of these is verified by someone outside the platform, tied to a real person’s money or a real person’s inbox, and expensive to duplicate honestly. If you were designing the account graph yourself, these are exactly what you would key on.
Payment carries an extra property that people underrate: it travels between companies. Processors and fraud vendors share signals across merchants. A card that funded an account which later got suspended arrives at the next platform already carrying that history. You are not starting clean, you are starting with someone else’s file on you.
Recovery contacts are the quieter killer because they are invisible in day to day use. You set one when you create the account and never open that screen again. Two years later it is still the single line of data that ties forty accounts to one person.
Two habits do most of the damage here.
Plus addressing. Adding a plus and a tag to a Gmail address gives you a mailbox that receives mail, not a separate identity. The part before the plus is the account, and any system parsing addresses at scale strips the tag as a matter of routine. It is a filing convenience that has been widely mistaken for isolation.
Catch-all domains. If every account recovers to a different name at one domain you control, the domain is the join. Forty labels, one identity. This is the version that catches people who are otherwise careful, because it feels like separation, and the accounts do have genuinely different addresses.
This is why paying more for proxies sometimes changes nothing measurable. Dedicated mobile line per account, different carriers, different cities, and one shared card and one shared recovery mailbox sitting underneath the lot. The expensive layer works. The free layer cancels it.
Tier two: your own working hours
Second on the list, and the one almost nobody plans for, is timing.
Accounts belonging to genuinely different people drift apart on the calendar. Different login hours, different quiet days, different weeks where nothing happens. Accounts belonging to one operator move in lockstep, because the operator is one person with one schedule.
They all come alive when you sit down. They all go dark when you sleep. They all skip the same public holiday. They all get a catch-up burst on the same afternoon.
Correlated timing is trivial to compute, hard to fake, and it survives every other precaution. I have seen accounts on infrastructure I know was separate get grouped on nothing more than a shared daily rhythm.
The fix is unglamorous and slightly annoying: deliberately different active windows per account, actually kept to, with some accounts left alone for days. The reason people do not do this is that batching is efficient for the operator. Optimising your own time is what creates the pattern.
There is a finer signal beneath the calendar one, which is pacing inside a session. Time from page load to first interaction, whether pauses vary the way a reading human’s pauses vary, whether every form fills at an identical speed. I cannot tell you how any specific platform weights that and neither can anyone else outside the company, but automation that never hesitates is the most regular thing on the internet.
Tier three: the fingerprint surface
Third, and this is the layer the whole anti-detect industry is built on. It is real. It is still third.
The surface is wide: canvas and WebGL rendering, installed fonts, screen dimensions, window size, timezone, language headers, header ordering. Individually these are shared with thousands of people. Combined, they get narrow quickly.
The mistakes come in two opposite flavours. Too little variation is forty profiles cloned from one template with a randomised canvas value bolted on, which is one machine in forty hats and clusters on similarity alone. Too much variation is a profile so aggressively randomised that it describes a device nobody has ever owned: an Android user agent with a desktop resolution, a timezone in one country and a language in another, a font list no real install produces.
The second one is worse, and it is the mistake careful people make, because carefulness causes it. An impossible device is far more visible than a common one.
Mobile is where this gets underrated. Apps see more than browsers do, and a phone carries identifiers that survive an app reinstall. Recycle a cloud phone between accounts without a proper wipe and the second account inherits the first one’s install history. I have had customers treat a phone reset as equivalent to a fresh browser profile. It is not, and the gap between those two things has cost people accounts.
Tier four: the network path
The address still does real work, in two situations.
Bad neighbourhoods. Every address belongs to an autonomous system, and the ASN says whether it is a hosting company or a consumer carrier. Signups arriving from a hosting range are cheap to score and accurate to score, which is exactly why the cheapest datacenter proxies fail in such a boring, predictable way. They get identified as what they are. No amount of browser profile care changes the fact that a residential customer is not shopping from a rack in Frankfurt.
Recycled space. Residential and mobile ranges rotate through users, and a pool that is sold hard is reused hard. You inherit the previous tenant’s behaviour. I have handed over a line I knew was clean and been told it was already flagged somewhere before the customer touched it, and the honest answer is that reputation on a rotating address is a shared resource nobody controls.
That is the real case for a dedicated line rather than a rotating pool. Its history is your history, and when something breaks you can trace it to a decision you made.
The audit that takes an afternoon
One sheet. One row per account. Columns for the email, the recovery contact, the phone number, the payment method, the browser profile or device, the line, and the usual working hours.
Then read down each column and look for repeats.
Every time I have asked an operator to build this, they found a shared cell they did not know existed. Usually the recovery email. Sometimes the payout destination. Once, a shared referral link that quietly tied a whole batch back to the account that invited them.
The target state is one identity, one of everything, and no cell repeated anywhere. In practice you will not get to zero, and the useful outcome is knowing precisely where your overlaps are instead of assuming you have none.
Then keep every account dull. Same place, roughly the same hours, roughly the same activity, month after month. Boring is the objective. Clever adds signal.
What I had backwards
For about a year I told people the network layer was most of the fight. I sell network infrastructure, which makes that a convenient belief, and I held it sincerely rather than cynically. It was wrong.
What changed it was my own support queue. Customers losing accounts on lines I could see were clean, and when I started asking what else those accounts shared, it was the recovery mailbox, or the card, or the fact that the whole batch got worked between 9pm and 11pm on weekdays.
None of that is fixable with a better proxy. I was selling the right product with the wrong reasoning attached, and the customers who took that reasoning literally and spent everything on the network layer are the ones who came back unhappy.
Dedicated mobile lines are still worth what they cost. They are not the part that saves you.
Untangling without announcing it
If you already have a tangle, do not fix it in one weekend. A simultaneous change across a whole fleet is itself a pattern, and a loud one. Forty accounts all updating their recovery email on the same Tuesday is a stronger group signal than the shared email was.
Change one thing, on one account, then leave it alone. Move to the next one days later. It takes weeks and there is no fast version that does not draw attention to itself.
Work top down through the ranking. Recovery contacts and payment instruments first, since that is where the strongest joins are. Browser profiles and devices next. The addresses whenever you get to them, which is a strange thing for someone who sells addresses to write, and it is still the right order.
The tested picks and the full setup guides are at Multi Account Ops.
Get new guides and videos first — join the Telegram channel.