Building a naming system for a fleet of accounts

Most people running more than a handful of accounts start with a spreadsheet that has one column: “account.” Maybe two, if they remember to note the password. That works for ten accounts. It falls apart somewhere around fifty, and the failure mode isn’t cosmetic. It’s operational. You lose track of which account is tied to which proxy, which browser profile, which device, and how far along it is in warm-up. Once you lose that thread, you start reusing resources across accounts by accident, and that’s exactly the kind of cross-contamination that gets accounts clustered together on the platform side.

A naming convention isn’t about tidiness. It’s the index into your isolation stack. If you run antidetect browsers, residential or mobile proxies, and cloud phones, the name of each account should tell you, at a glance, everything that account is bound to. Get this right early and it scales cleanly to hundreds of accounts. Get it wrong and you’ll spend a weekend untangling which profile goes with which SIM.

Why ad hoc naming breaks fleets

Detection on most platforms works by clustering. Account behavior, device fingerprint, IP history, and login patterns get compared against other accounts, and when enough signals overlap, the platform treats them as linked. This isn’t paranoia, it’s how fraud and multi-accounting detection systems are built, and it’s public in general terms from every major platform’s own enforcement documentation.

The practical risk for an operator isn’t that naming itself leaks anything. It’s what bad naming lets happen behind the scenes. If your naming scheme doesn’t tell you, unambiguously, which proxy port and which browser profile belong to a given account, you will eventually launch the wrong profile behind the wrong proxy, or reuse a mobile IP that’s still warm from another account’s session. That’s how isolated accounts stop being isolated. The name is your safeguard against your own mistakes, not a defense against the platform.

What the name needs to encode

A working convention has to answer four questions the moment you read it: what platform, what batch, what resource it’s pinned to, and what stage it’s in. I use a token structure that looks like this internally:

{brand}-{platform}-{cohort}-{seq}

For example, mao-plt-0811-014 would be the fourteenth account created in the August 11 cohort for a given platform, under a given internal brand or client bucket. That’s the label used in the ops database, not necessarily anything visible on the platform itself. Usernames on the platform side follow whatever pattern looks normal for that platform’s user base, because a visibly systematic username pattern is its own signal. The internal name and the platform-facing username are two different things, and conflating them is a common mistake.

The cohort token matters more than people expect. Accounts created in the same batch tend to share creation-time conditions: same proxy pool, same device image, same warm-up script. If one account in a cohort gets flagged, you want to be able to pull every other account in that cohort and check them, without grepping through free text notes.

Binding the name to a proxy and a profile

This is the part that actually prevents incidents. Every account should map to exactly one antidetect browser profile and one proxy assignment, and that mapping should live next to the name, not in your memory. In practice this means a row in a database or sheet with columns for account name, profile ID, proxy pool and port, device or cloud phone slot, and current status.

The rule I hold to: a proxy is assigned to a profile for the life of that account, and that profile is only ever launched with that proxy. Mobile and residential IPs have their own churn (carrier-side reallocation, pool rotation), so “same proxy” really means “same assigned port or session, from the same pool, consistently.” If you’re running mobile proxies out of a modem farm, the port number should be recorded, because ports get reassigned and IPs change when a modem rotates. The account name should be the key you use to look that mapping up before every session, not something you launch from muscle memory. That lookup step is boring and it’s also the single most effective thing I’ve found for avoiding accidental IP or profile reuse across accounts.

Naming across cloud phones and devices

If part of the fleet runs on cloud phones instead of desktop browser profiles, the device identity is another axis that needs to show up in the record. A cloud phone slot has its own hardware fingerprint, its own carrier IP path if it’s on mobile data, and its own factory-reset history. The naming record should note which device slot an account is bound to, and whether that device has ever hosted another account before it. Reusing a device slot for a new account after a prior account was banned on it is a real risk, because factory reset doesn’t touch everything a platform might check, and it definitely doesn’t reset the IP history if the device is still behind the same carrier connection. Track device reuse explicitly instead of assuming a wipe clears the slate.

Encoding warm-up stage without guessing

Fleets fail quietly when accounts get pushed into active use before they’re ready, simply because nobody could tell at a glance which accounts were still warming up. I keep a status field, not baked into the name itself but attached to the record: new, warming, active, flagged, retired. New accounts get light, human-paced activity for a set period before any automation touches them. Once an account crosses into active status, that’s recorded with a date, so you can always answer “how long has this account actually been active” without relying on memory.

Flagged accounts get pulled from rotation immediately, and I don’t reuse their name, their proxy port, or their device slot for a new account without a deliberate cooldown decision. Retired names stay retired. Reusing a name is a small convenience that creates a real trap: six months later you’re looking at logs referencing mao-plt-0811-014 and you can’t tell if that’s the original account or a second one that got the same label reassigned.

The convention is only as good as the record it lives in

None of this works if the naming convention lives only in filenames or usernames. It needs a real record behind it, whether that’s a spreadsheet with locked columns or a small database table. The name is the primary key. Everything else, proxy assignment, device slot, cohort, warm-up stage, ban history, hangs off that key. When something goes wrong with one account, being able to query “everything else tied to this cohort” or “everything else on this device slot” in under a minute is what turns a single incident into a contained one instead of a fleet-wide one.

I’ve seen operators try to encode too much into the visible name itself, things like sequential numbers that make the fleet size obvious, or platform-specific tells that stand out against normal usernames. Keep the systematic part internal. The platform-facing identity should look like any other user’s; the operational name is for your own database, not for display.

Start before the fleet gets big

The honest reason most people skip this is that at ten or twenty accounts, you genuinely can remember which proxy goes with which account. The convention pays for itself exactly at the point where memory stops working, which is usually right when you can least afford to stop and rebuild your records from scratch. Set the structure up before you need it. It’s a spreadsheet and a discipline, not a tool you have to buy.

If you want to see how this plays into the rest of the stack, proxy selection, browser fingerprinting, and cloud phone provisioning, we cover the operational side of running fleets like this on the Multi Account Ops site and channel.

Get new guides and videos first — join the Telegram channel.