When a platform determines that several accounts belong to the same person, what dimensions does it usually look at?

A seller received review notifications on two Amazon accounts one after another.

His first reaction was to change the IP for the second account—switching from a shared proxy to a dedicated line, re-verifying, and logging in again. Three days later, the review notice came back. His problem is typical: on what basis does the platform determine that these two accounts belong to the same person?

The answer does not lie in any one field, but in the overlap of a set of fields.

Platforms usually draw data from four layers: network egress, device and browser fingerprints, identity and payment information, and behavioral and operational traces. Each layer extracts several signals; after cross-account comparison, similarity is calculated, and account pairs with high similarity are more likely to be placed into the same risk association group.Changing the IP only touches the first layer; the remaining three layers stay as they are, so the overlap naturally cannot be reduced.

The underlying logic: the platform is not looking for sameness, but calculating overlap

The basic way a risk control system works is to build a set of signal vectors for each account, then calculate the distance between the two vectors. The reason is very practical: someone who really wants to hide an association will not fill in every field exactly the same. Therefore, the determination does not rely on a single field, but on whether multiple weak signals simultaneously point in the same direction—the same segment of network history, the same set of device parameters, the same funding path, and the same operating rhythm. Any two or three layers stacking together is enough to place the two accounts in the same observation group.

This brings two direct consequences.

First, no single-point isolation constitutes a “safe” conclusion: an independent IP, an independent browser, and an independent phone number—missing any one of them can cause the overlap score to climb back up.

Second, the determination is a threshold issue rather than a binary “hit”: when the overlap score is low, accounts are merely placed in the same observation group; only when the threshold is exceeded are secondary verification, review, or restrictions triggered.

The association prompt you see is a scoring result, not a precise hit. The specific reasons for a platform's action are usually not fully disclosed, and account notifications and official policies should be taken as authoritative.

Layer one: Network egress—IP is the entry point, not the whole story

The network layer is the only layer most people have seriously dealt with, but the items examined go far beyond “whether the IP is the same”:

• Egress IP history: How many accounts have logged in on this IP, and what state those accounts subsequently ended up in. IPs from shared proxy pools often carry a long history of reuse.
• IP type and attribution: Whether it is residential, data center, or mobile network, and whether the ASN is clearly inconsistent with the account's registration location, shipping location, or commonly used login location.
• Proxy tier: Whether it is a public proxy pool, and whether a large number of accounts have shared the same address range during the same time period.
• DNS resolution path: Whether the DNS egress and browser egress are consistent, and whether the resolution location is separated from the actual login location.
• Time zone, language, system time: The degree of match with IP geolocation and account registration information.
• WebRTC and other channels: Whether they can expose the real internal network or local public address, bypassing the proxy to directly expose the local environment.

A dedicated IP is a necessary condition, but it only solves one layer of the problem. A more common mistake is frequently changing egress—using this line today and switching to another tomorrow, which makes the account's network history fragmented and unstable, itself an anomaly signal. Being stable, dedicated to one account, and unchanged over the long term is closer to normal user behavior than “switching to a new one every time.”

Opening two windows on the same computer, the screens look different, but the device parameters collected underneath are almost identical.

Second layer: Device and browser fingerprinting—why multiple instances on the same computer can't evade detection

Browser fingerprinting is not complicated in principle: without relying on login status, platforms collect a set of environment parameters through scripts and HTTP headers, and the identifier formed by combining these parameters can remain stable for a considerable period of time. If you open two Chrome windows on the same computer, the following values are almost completely identical:

• Canvas and WebGL rendering results (differences in graphics cards and drivers are directly reflected in pixel output)
• AudioContext audio-processing characteristics
• System font list and font metrics results
• Screen resolution, available area, color depth, page zoom ratio
• hardwareConcurrency, deviceMemory, platform identifier
• User-Agent, language, time zone
• Plugin list, media device enumeration (microphone and camera counts, device IDs)
• Cookie, LocalStorage, IndexedDB, and various local caches

Changing the User-Agent or installing a few plug-ins can only modify a few of these fields; it cannot change the similarity of the entire vector. What fingerprint isolation should do is not randomize parameters, but give each account a set ofindependent and self-consistentcombination: this combination makes sense within the real-device distribution, and remains stable every time that account logs in. Randomization, by contrast, creates combinations that do not exist among real devices, increasing the anomaly score.

For a complete breakdown of this layer, you can refer toWhat Amazon store anti-association is actually preventing: an item-by-item breakdown of IP, browser fingerprint, payment information, and operation traces; how fingerprints are composed and how they are read,What Is a Fingerprint Browser: A Complete Analysis from Browser Fingerprinting Principles to Multi-Account IsolationThere is a more basic explanation in it.

Third layer: Identity and payment information — shared entities or receiving accounts are basically directly linked

Among the first three layers, this layer is the hardest to isolate because it is not a technical configuration problem but an entity problem.

It is necessary to distinguish between “violation” and “being linked.”

Amazon’s official explanation of multiple selling accounts states: typically one account is operated per region; multiple accounts may be held when there is a legitimate business need, and a policy issue with one account may affect related accounts.

In other words, operating multiple accounts is not absolutely prohibited in itself; the real risk lies in whether the entity, materials, and account status can withstand scrutiny.Amazon’s official guidance on multiple selling accounts and account healthThis can serve as a first-hand basis for determining the boundary.

Fourth Layer: Behavioral and operational traces—login cadence and operating habits also leave traces

The behavioral layer is easily overlooked because, unlike IP, it does not have a clear “unique value”; it is more like pattern matching:

• Login time distribution: Two accounts have long gone online at the same minute and offline at the same minute, and their routines on rest days are completely synchronized.
• Operational cadence: Similarity in click intervals, mouse trajectories, form-filling speed, and page dwell time.
• Product overlap: Listing highly similar products, reusing the same set of main images and detail pages, and adjusting prices simultaneously for the same batch of SKUs.
• Customer service scripts: Reply templates, signature formats, and commonly used sentence patterns are repeated across accounts.
• Ad creatives: The same batch of creatives, the same ad account, or the same payment card is used to run ads across multiple stores.
• Logistics information: Shipping addresses, return addresses, carrier combinations, and tracking number ranges overlap heavily.
• ERP and third-party tools: Whether the source IP, authorization records, and operator account of API calls are reused across stores.

Real business entities are inherently different: different schedules, different scripts, different product rhythms. When the same group of people operates multiple accounts, these differences are smoothed out, and the convergence of patterns is itself a statistically detectable signal.Running 5 stores simultaneously: the most error-prone parts of operating multiple stores and how to address themIn it, there is a more specific troubleshooting sequence for failure points at the behavioral layer and the tool layer.

How to determine combinations of the four layers of variables: shared variable matrix and several common misjudgments

Looking at the four layers together, risk is not simply additive; rather, it depends on which layers overlap at the same time. The matrix below describes relative risk levels and is used to prioritize isolation:

With respect to this table, several recurring misjudgments are worth calling out separately.

“Switching to an independent IP means you are safe”overlooks that session-layer cookies and local storage are still being reused across accounts;

“Using different browsers isolates them”This does not hold; Chrome and Edge share a large number of system-level parameters on the same machine;

“Having different addresses and phone numbers is enough”often exposes the underlying entity via the receiving account and tax ID;

“The more thoroughly fingerprints are randomized, the safer it is”will instead generate parameter combinations that do not exist on real devices, raising the anomaly score.

For how these types of residual traces behave during actual troubleshooting, refer to4 Environment Isolation Points for E-commerce Multi-Account Management, Revisited After Being Flagged by Platform Risk Controland check them item by item.

Isolate by risk priority: the configuration order from identity to behavior

The order of isolation actions is more important than their quantity. First do what the lower layers cannot do, then make configuration adjustments at the upper layers; otherwise, you will repeatedly invest in ineffective steps.

1. First confirm whether the entity layer can be separated.Confirm whether the company entity, receiving account, and tax ID corresponding to each store can be independent. If this step cannot be done, no matter how much you do in the next three layers, it will only reduce the probability and cannot change the fact of entity overlap.
2. Then fix the network egress.Bind one account to one fixed egress line, preferably residential or a stable dedicated line, and keep it unchanged long term. Do not have multiple accounts take turns sharing the same batch of proxies, and do not frequently change egress for the sake of being 'safer'.
3. Then set up an independent browser environment.One account, one independent Profile; fingerprints, Cookie, LocalStorage, and cache are not shared with each other. Before logging in, first confirm that the proxy is already in effect, then open the backend.
4. Finally, standardize behavioral pacing.Stagger login times, avoid moving images, copy, customer service templates, and logistics tracking numbers across accounts, and separate ad accounts and payment methods by store.
5. Keep records and verify regularly.Record the environment, egress, person responsible, and most recent verification time bound to each account. When a review alert appears, troubleshoot layer by layer according to the records rather than changing the IP first. For execution details, refer toMulti-account management in Amazon multi-store operations: account grouping, login records, and exception handling processes。

It is recommended to reverse the troubleshooting order: first confirm whether identity and payment are truly independent, then check the network egress, then verify whether the browser environment is isolated, and finally review whether the behavioral footprint shows obvious synchronization. In most cases where “changing the IP does not help,” the problem is stuck at the first and third layers.

The standard for isolation is not distance, but that each account has its own independent egress, environment, and operator.

The criterion for one account per environment is very intuitive: Account A and Account B each have their own independent browser Profile, independent fixed egress, their own entity and payout information, and staggered operating hours. If any item is shared by two accounts, it is equivalent to leaving a comparable interface on this chain.

Frequently Asked Questions

After an account receives a related-account notice, does changing only the IP still help?

Usually not enough. IP is only one of the inputs at the network layer. If the browser fingerprint, local storage, payout account, or operating rhythm is still reused across accounts, changing the egress will not significantly change the degree of overlap. The correct order is to first identify which layers are shared, and then decide which layer to change.

If multiple Amazon stores are registered under the same company entity, will they definitely be linked?

Amazon officially allows multiple selling accounts when there is a legitimate business need, but a policy issue with one account may affect related accounts. Having the same entity creates a naturally strong association signal between accounts. Whether enforcement action is taken depends on account status, document completeness, and the specific review results, and is subject to account notifications and official policies.

Can using a fingerprint browser completely prevent association?

No. A fingerprint browser addresses isolation at the browser environment layer. It cannot replace genuine business qualifications, nor can it cover overlaps at the level of business entity, receiving account, and operational behavior. It is one of the four layers, and its role is to minimize the shared variables at this layer.

When multiple team members operate the same batch of stores, how can behavioral-layer association be avoided?

Fix the 'account—environment—responsible person' relationship: an account logs in only in one fixed environment, a responsible person is designated, and handovers are handled through sub-account permissions within the account rather than by sharing the main account. At the same time, stagger the daily operating hours of each account to avoid all accounts being processed intensively by the same group of people at the same time.

If an association is falsely flagged, what should be provided first when appealing?

Prioritize materials that can prove the independence of the business entity and operations: each party's business license and legal representative information, proof of independent receiving accounts, independent supply chain and logistics records, and an explanation of the actual differences between the two accounts in operations. Environment records at the technical level can serve as a supplement, but business entity independence is usually the focus of the verification.