Authenticated data collection often uses multiple accounts, and throttling is frequently caused by more than the script itself. Breaking association risk into device traits, network egress, session state, and request cadence makes the controllable variables much clearer.
Ecommerce data collection generally falls into two categories: collecting public pages that do not require login, and authenticated collection, such as viewing competitor back-office data or retrieving results shown after personalization.
For the first category, controlling request frequency is usually enough. Once the second category involves multiple accounts, success depends less on how clever the script is and more on whether those accounts can exist independently. If this layer is not handled well, throttling and bans can look random, and changing the script, lowering the frequency, or switching selectors will not improve the situation.
Where does the risk come from
Platforms determine whether several accounts are being operated by the same party through cross-checking: network addresses, browser and device characteristics, Cookie and session data, and usage patterns. Heavy overlap in any one category can cause the accounts to be grouped under the same controller.
A boundary is important here. Detection logic keeps changing, so relying on short-lived tricks to counter it offers little durable benefit at high cost. This article therefore does not discuss how to bypass risk controls. The useful question is different: once the sources of risk are clear, which variables can we control and keep stable over time? Those variables determine whether multiple legitimate accounts can affect one another.
Device and browser characteristics
One of the easiest ways to create problems is to open multiple windows on the same machine and log in to different accounts. Even after clearing cache or using incognito mode, those windows still share the same system environment and browser data. Their characteristics continue to overlap, so the platform sees one device repeatedly switching identities.
A controllable approach is to give each account its own environment: one independent environment per account, with separate fingerprints, Cookies, and local storage. The key is to keep that environment fixed for the account rather than generate a random one every time it starts. Random combinations are often internally inconsistent: time zone, language, resolution, and UA can conflict with one another, making the setup look more unusual than a stable configuration.
In the end, stability comes from consistency, not randomness.
Network egress
The egress endpoint should be bound to the account: one environment, one endpoint, with the endpoint region aligned with the account profile, time zone, and language. If multiple accounts have separate environments but share the same egress, most of the earlier isolation is effectively lost.
The egress should also remain relatively stable. Frequent region changes make the account-location signal difficult to explain. When choosing an endpoint, residential addresses are generally more likely than data-center addresses to resemble normal user access. It is also important to avoid addresses that have already been heavily used, because such addresses may already be under closer monitoring.
Cookies and sessions
Session state is itself an identity record. If multiple accounts share the same Cookie set or local storage, that creates a direct link between them, no matter how cleanly the environments are otherwise separated.
A session in a new environment also should not be used at high intensity immediately. Build up a period of normal browsing history first, then increase the workload gradually. This principle applies beyond data collection as well: whether an account has an established usage history directly affects how much activity it can reasonably sustain.
Request cadence
Request density is a behavioral signal. Scripts often have a telltale regularity: fixed visit intervals, a fixed page order, and no activity outside the collection task. Adding random numbers does not solve this kind of regularity because the larger issue is the overall volume.
The controllable direction is to keep workload within a reasonable range: stagger execution times across accounts, avoid driving every account at full load at the same moment, leave sensible intervals between pages, and separate high- and low-priority collection tasks. The boundary is straightforward: your collection should not put pressure on the target service. Any increase in collection speed that comes at the cost of disrupting that service is not a sound tradeoff.
Why a fixed environment per account is more stable than random switching
The motivation behind random switching is to look different every time, but association checks look at whether signals remain stable across dimensions and whether they contradict one another. If an account exits from one place today and another tomorrow, with a different characteristic combination each time, that inconsistency is itself an abnormal signal.
A fixed environment follows the opposite logic. From registration onward, the account has a consistent identity: a fixed environment, a fixed egress, matching time zone and language, and session history that accumulates gradually. The longer that consistency persists, the easier it is for the activity to resemble that of a normal user. This is the value of the environment layer: long-term stability rather than flashy variation.
This also explains why a collection script should not manage browser instances by itself. Environments need to be independently schedulable so dedicated environments can be assigned to different accounts; their state needs to be queryable so abnormal environments and invalid accounts can be detected; they need to be reclaimable so long-running operations do not accumulate zombie instances; and collection retries often need to use another environment, which is only practical when environments can be scheduled independently. In this type of architecture, PurpleMark is the environment-resource layer. The script handles collection logic, while identity and resources are delegated to the environment layer.
Compliance boundaries
The following points matter more than any optimization above.
Follow the target site's terms of service and robots rules. Many ecommerce platforms explicitly restrict automated access in their terms, so confirm that your intended use is permitted before starting. Collect only public product, price, and inventory information, and do not collect personal information. Do not bypass technical protection measures. When you encounter safeguards such as CAPTCHAs or encrypted interfaces, adjust the collection strategy or seek authorization instead of trying to break them. Control request frequency regardless of how many accounts you have, and never interfere with the normal operation of the target service.
The premise of this discussion is how multiple legitimate accounts can remain independent without interfering with one another, not how to evade platform rules. The former is operational hygiene; the latter is a different matter.
