After stores grew from 3 to 8, many teams still switch windows to log in on the same computer, until one day they receive an association warning and realize no one can clearly say who logged into which accounts in which environment over the past seven days. The problem is not too many passwords, but shared environments and operations without a trail, making it impossible to pinpoint the issue when an exception occurs.
The official Amazon seller announcement states: typically one account per region, and when there is a legitimate business need, you may have multiple accounts; a policy issue with one account may affect related accounts. This determines that the goal of multi-account management is not to hide stores, but to give each store an explainable business entity, an independent and fixed login environment, and operation records that can be reviewed. For rule details, theAmazon seller account health tipsand seller backend notifications shall prevail.
Account grouping: split into three layers by entity, marketplace, and responsible person; do not group by store nickname
Grouping by nicknames like "US store A, Europe store B" will become chaotic once there are many people, because nicknames carry no environment information. Grouping must follow variables:
- First layer: legal entity and payment collection details.Stores under the same business license and the same receiving account are grouped together. Stores under different entities cannot share a browser Profile, nor can they share the same proxy exit.
- The second layer: Amazon marketplaces and regions.North America, Europe, and Japan each form their own group. If different regions are mixed in the same environment, the time zone, language, and login rhythm will all appear abnormal.
- The third layer: operations owners and permissions.A store corresponds to only one primary operations owner during the same time period; cross-group temporary transfers require modifying the binding relationship rather than temporarily borrowing an account.
Naming uses "entity abbreviation-site-store sequence number-owner", for example HK-A-US-03-Lin. This number must be written into the browser environment name, proxy notes, and login records at the same time; only when all three are consistent will they match. The process for adding a new store is to assign the number first, then create the environment, and only then start logging in; do not fill in records in reverse.
Login records: what frontline operations should fill in every day, so that when troubleshooting you know where to look
The objects recorded are the environment and the exit, not passwords. Only if the fields are fixed and the field names are unchanged can they be retrieved and compared.
| Field | How to fill in | Purpose during troubleshooting |
|---|---|---|
| Date and time | Precise to the minute, with a unified time zone for the entire team | Aligned with platform notification time |
| Store and account | Group number first, store name second | Confirm the owning entity and site |
| Browser environment ID | Profile name or ID, not “Default Environment” | Determine whether the environment is shared across stores |
| Proxy exit | IP or region + proxy ID | Determine whether the exit is reused |
| Operator | Real name; do not use nicknames or initials | Identify the responsible person |
| Login result | Normal / Verification required / Failed | Track anomaly frequency |
| Anomaly notes | Summary of the original verification or warning text, and actions already taken | Basis for appeal and retrospective review |
Retain for at least 90 days. When performance notices, related investigations, or deactivation appeals are involved, archive them separately and save them together with the environment screenshots from that time; do not rely solely on chat records.
Exception handling process: first freeze shared variables, then determine whether to escalate
Platform determinations of association are usually based on a combination of multiple signals. The specific reason is subject to the account notification; do not draw conclusions on your own based on a single symptom. Handle them in order of signal severity:
- Occasional login verification.Passing for that attempt is sufficient, but it must be noted in the login record. If it occurs three or more times for the same store within one week, proceed to the next step.
- Frequent verification.Immediately stop logging in to other stores in this environment, and save the Profile ID, proxy egress, time, and screenshots. Then log in to the same store from another device or another environment as a control to determine whether the problem lies with the environment or the account itself.
- Receive an association warning.Suspend bulk operations and cross-store copying for the affected stores, check the login records and environment bindings for the last 7 days, and identify the shared variables.
- Performance notification or deactivation notification.Submit the materials as required by the platform and retain the submission number. The person in charge shall handle external communications uniformly, and other members should not submit repeatedly. Do not resume daily operations before the cause is confirmed.
Team permissions and audit cadence: replace post-incident firefighting with fixed checks
- Operations staff can only access the store Profile assigned to them; supervisors can view login records but do not share the same environment with operations staff.
- On the day of a transfer or departure, revoke environment permissions, log out of all logins in that environment, replace the proxy exit for that store, and leave a change entry in the records.
- Every week, check the anomalous fields in login records: number of verifications, exit changes, and logins by non-primary owners.
- Every month, check the grouping table, proxy exit ownership, employee permissions, and whether every Amazon Account Health notification has someone following up to closure.
If switching accounts itself already takes up a large amount of work hours, it means the issue is not only a lack of processes but also a lack of an environment management approach; you can refer toA breakdown of how much time multi-store operation tools can actually save, and put the switching actions and record actions into the same structure.
Frequently Asked Questions
Do Amazon multi-store operations necessarily require different computers?
There is no official requirement that one computer correspond to one store. The key variable is that environments should not be shared across stores: one computer can host multiple stores through mutually isolated browser environments, but the same Profile and the same proxy exit should not be repeatedly switched across stores under different entities.
What is the minimum retention period for login records to be useful for investigation?
At least 90 days. Association investigations and performance appeals usually target behavior over the past 30 to 60 days. Ad hoc backfilling or keeping only a week of records cannot support an explanation. When archiving, save environment information together, refer toKey Configuration Points for Four-Layer Environment Isolation.
Can I immediately change the IP or browser environment after receiving an association warning?
It is not recommended to change them first. The correct order is to freeze the shared variables, save an environment snapshot, check the login records from the last 7 days, and confirm which variable is shared before making adjustments. For environment details, seeThe Most Problem-Prone Areas in Multi-Store Operationsas a comparison.
After an employee leaves, how should the store environments they operated be handled?
On the same day, revoke permissions, log out all sessions in that environment, replace the store's proxy exit, and transfer ownership to the new primary owner. The environment itself does not need to be deleted, but ownership must be updated synchronously in the grouping table and login records. For permission division in team collaboration, refer toAccount Isolation and Team Collaboration in Multi-Store Operations.
