多账号运营者的GDPR合规
GDPR applies to you. If you operate accounts that interact with EU residents — managing ad campaigns, scraping marketplaces, running social accounts, processing customer data across profiles — you're processing personal data under GDPR jurisdiction. The fact that your operations involve anti-detect browsers and multiple accounts doesn't create an exemption. It creates additional obligations.
Most operators either ignore GDPR entirely or assume it only applies to "real" companies with customer databases. Both positions are wrong, and both expose you to fines of up to €20 million or 4% of global revenue.
GDPR and Multi-Account Operations
GDPR regulates the processing of personal data of EU residents. "Processing" includes collection, storage, use, transfer, and deletion. "Personal data" is any information that identifies or could identify a natural person.
In a multi-account operation, you're likely processing personal data in ways you haven't considered:
Account creation data. Every account you create uses a name, email, phone number, and sometimes an address. If these are real (even partially), they're personal data. If they belong to someone other than you, you're processing that person's data.
Scraped data. Product listings that include seller names, reviews that include usernames, public profiles that include photos — all personal data under GDPR. Scraping publicly visible data doesn't exempt you from GDPR obligations.
Customer interaction data. If your accounts interact with customers (ad responses, messages, support tickets), you're processing their personal data.
Analytics and tracking. IP addresses, device fingerprints, and behavioral data collected by platforms about your accounts' visitors are personal data.
Cookie and session data. The cookies and session tokens stored in your anti-detect browser profiles may contain personal data about users who interacted with your accounts.
The scope is broader than most operators expect. If any EU resident's data touches your operation at any point, GDPR applies to that data.
Data Processing in Multi-Account Contexts
GDPR distinguishes between data controllers (who determine the purposes and means of processing) and data processors (who process data on behalf of controllers).
When You're a Controller
You're a controller when you decide what data to collect and how to use it. This applies when:
- You scrape marketplace data and store it in your database
- You create accounts using personal information you've collected
- You run ad campaigns targeting specific audiences
- You manage social media accounts that collect follower data
As a controller, you bear the full weight of GDPR obligations: legal basis, transparency, data subject rights, breach notification, and records of processing.
When You're a Processor
You're a processor when you process data on behalf of a client. This applies when:
- You manage a client's ad accounts and access their customer data
- You run accounts as a service for another business
- You scrape data under contract for a client who specifies the targets
As a processor, you need a Data Processing Agreement (DPA) with the controller and must process data only as instructed. You're still liable for security failures on your end.
The Joint Controller Trap
Many multi-account operations involve joint controllership — you and the platform jointly determine the processing. Facebook's Custom Audiences, Google Ads customer matching, and Amazon's seller analytics all involve joint processing where both you and the platform are controllers.
Joint controllership requires an arrangement between the parties defining each party's responsibilities. In practice, platforms define this in their terms of service. You're bound by those terms for the personal data you share with them.
Consent and Legitimate Interest
Every instance of personal data processing requires a legal basis. The two most relevant for operators are consent and legitimate interest.
Consent
Consent must be freely given, specific, informed, and unambiguous. For multi-account operations, obtaining valid consent is usually impractical — you're not directly interacting with the data subjects whose data you process.
Consent is viable when: you collect data from people who knowingly provide it (form submissions, account registrations on your own platforms).
Consent is not viable when: you scrape public data, process data from platform analytics, or collect data through automated systems without user interaction.
Legitimate Interest
Legitimate interest is the most common legal basis for business-to-business operations. It requires a three-part balancing test:
- Purpose test: Is there a legitimate interest? Business operations, market research, security testing, and competitive analysis are recognized legitimate interests.
- Necessity test: Is the processing necessary for that purpose? Could you achieve the same goal with less data or less intrusive processing?
- Balancing test: Do the data subjects' rights and interests override your legitimate interest? This is where most operators fail.
Document the assessment. GDPR doesn't require you to prove legitimate interest upfront, but you must demonstrate it if challenged. Write a Legitimate Interest Assessment (LIA) for each category of processing.
Example LIA structure for web scraping:
| Element | Assessment |
|---|---|
| Purpose | Market research: pricing intelligence for competitive positioning |
| Data processed | Public product listings: product names, prices, seller names |
| Necessity | Pricing data not available through other means; minimum data extracted |
| Impact on subjects | Low — data is publicly visible, no additional exposure created |
| Safeguards | Data aggregated within 24h, individual seller names not retained |
| Conclusion | Legitimate interest applies — minimal impact, genuine business need |
Risk Mitigation Strategies
Even with valid legal basis, GDPR requires ongoing compliance practices. Here's what matters for operations.
Data Minimization
Collect only what you need. If you're scraping product data, do you actually need the seller's name? If you're managing ad accounts, do you need to store the audience data locally? Every unnecessary data point is unnecessary risk.
Practical implementation:
- Define data retention periods per category (e.g., scraped data: 30 days, account data: duration of operation)
- Automate deletion — manual processes fail at scale
- Pseudonymize where possible (hash identifiers, remove direct identifiers from analytical datasets)
- Regularly audit what you're storing and delete what's no longer needed
Access Controls
Limit who in your organization can access personal data. In a multi-account operation, this means:
- Anti-detect browser profiles containing personal data should have access controls (most anti-detect browsers support team permissions)
- Scraped databases should require authentication
- Credentials and account data should be encrypted at rest
- Access logs should record who accessed what and when
Data Processing Agreements
If you process data on behalf of clients, you need DPAs. If you use sub-processors (proxy providers, cloud hosting, anti-detect browser vendors), you need DPAs with them too.
Key DPA elements: scope of processing, security measures, breach notification obligations, sub-processor approval, data return/deletion on termination, and audit rights.
Records of Processing
GDPR Article 30 requires records of processing activities. For multi-account operations, this means documenting:
- Categories of data processed per operation type
- Legal basis for each category
- Data retention periods
- Security measures applied
- Third parties who receive the data (platforms, clients, sub-processors)
- International data transfers (if any)
Breach Notification
If personal data you control is breached, you have 72 hours to notify the relevant supervisory authority and must notify affected individuals without undue delay if the breach poses a high risk.
For multi-account operations, a "breach" includes: unauthorized access to your anti-detect browser profiles, exposure of scraped databases, and compromise of account credentials that contain personal data.
Have an incident response plan documented before you need it.
FAQ
Does GDPR apply if I'm based outside the EU? Yes, if you process data of EU residents. GDPR has extraterritorial reach — it applies based on the data subjects' location, not yours. If you scrape European marketplaces, manage EU-targeted ad accounts, or operate accounts that interact with EU users, GDPR applies.
How long can I retain scraped data? GDPR doesn't specify exact retention periods — it requires that data not be kept longer than necessary for the stated purpose. Define your purpose, determine the minimum retention needed, and document it. For market research scraping, 30-90 days is typically defensible. For ongoing competitive monitoring, maintain only current data and purge historical records.
What if someone submits a Subject Access Request (SAR)? You have 30 days to respond to a SAR. You must provide all personal data you hold about the requester. For scraping operations, this means you need the ability to search your databases by individual identifiers. If you can't identify which data belongs to which individual (because you've properly pseudonymized), you may be exempt from certain SAR obligations — but you must still respond to the request explaining this.
Am I a controller or processor when managing client ad accounts? Usually a processor — you're acting on the client's instructions regarding their data. However, if you make independent decisions about targeting, audience selection, or data use beyond the client's instructions, you may become a joint controller. The legal analysis depends on the degree of autonomy you exercise. Clarify this in your service agreement.
Do proxy providers need DPAs? If they process personal data on your behalf — yes. A proxy provider that routes your traffic doesn't necessarily process personal data (they see IP addresses and encrypted traffic). However, if they log traffic, perform analytics, or store session data, they are processing personal data and need a DPA. Check your provider's privacy policy and terms of service.