GDPR compliance for server-side tracking

GDPR does not ban tracking. It requires that every processing activity has a lawful basis, a defined purpose, transparent notice, and a level of collection that is limited to what is necessary. For server-side tracking, that means the merchant should know why each event is collected, which identifiers are included, which destinations receive it, and whether the user has granted the consent needed for that purpose.

Purpose limitation and data minimization are practical design constraints, not policy slogans. A purchase event may need order value, currency, product IDs, consent state, and a hashed email for allowed conversion matching. It usually does not need free-text notes, full addresses, internal support comments, or every field available in the ecommerce database. The smaller the payload, the easier it is to secure, explain, retain, export, and delete.

GDPR also distinguishes controller and processor duties. The controller decides the purposes and means of processing, while a processor acts on documented instructions. Users also have rights: access, rectification, erasure, restriction, portability, and objection. A compliant server-side tracking stack needs operational workflows for those rights, not just a privacy page that says they exist.

In a standard TrackLayer deployment, the merchant is the controller and TrackLayer is the processor. The merchant chooses the tracking purposes, CMP wording, destinations, retention settings, and legal basis. TrackLayer processes events under those instructions and provides the technical controls needed to make that instruction set enforceable.

GDPR provides six lawful bases. Choose the basis before data is collected and document the reasoning. For tracking, the wrong basis often creates downstream problems: consent cannot be hidden inside terms, legitimate interests cannot be used as a blanket substitute for opt-in advertising, and contract necessity should not be stretched to cover remarketing.

1. ConsentThe user gives a specific, informed, freely given, and unambiguous opt-in. This is the usual basis for advertising cookies, remarketing, personalized ads, and many analytics setups in the EU.
2. ContractProcessing is necessary to perform a contract with the user. For ecommerce, this can cover order fulfillment, payment status, fraud checks, delivery communication, and account access.
3. Legal obligationProcessing is required by law, such as tax records, accounting retention, regulatory reporting, or responding to valid legal requests.
4. Vital interestsProcessing is necessary to protect someone's life or physical safety. This basis is rare in ecommerce and should not be stretched to cover marketing or analytics.
5. Public taskProcessing is necessary for official authority or a task in the public interest. It is mainly relevant to public bodies and specific delegated public functions.
6. Legitimate interestsProcessing serves a real business or third-party interest, is necessary for that interest, and does not override the user's rights. It requires a documented balancing test and is risky for behavioral advertising.

Compliance becomes durable when it is mapped into specific systems and owners. The checklist below is the minimum practical baseline for a merchant using server-side tracking in the EU, UK, or Switzerland.

• Consent banner (CMP) with granular opt-in for ad_storage, analytics_storage, ad_user_data, and ad_personalization.
• Privacy policy naming TrackLayer as a processor and explaining the categories of data, purposes, retention, recipients, and user rights.
• DPA signed with TrackLayer, including processor commitments, security measures, subprocessor terms, and transfer clauses. See the TrackLayer DPA.
• Data subject request handling for delete, export, and rectify workflows, with accountable timelines and internal ownership.
• Data retention policy defined for event payloads, identifiers, logs, audit records, and destination delivery history.
• Security controls including encryption in transit and at rest, access controls, least-privilege operations, and audit log review.

The DPA is not optional paperwork. It defines TrackLayer's processor role, the categories of processing, confidentiality, assistance obligations, breach communication, return or deletion, audit rights, subprocessor handling, and international transfer terms. Keep it linked from your vendor register and review it when your tracking purposes or destinations change.

GDPR rights matter more once tracking becomes server-side because data may exist beyond the browser. A user who clears cookies does not automatically delete event records, logs, destination delivery history, or identifiers retained under a configured policy. The merchant needs a repeatable way to find relevant data and instruct processors to act.

Cross-border transfers require safeguards when personal data moves from the EEA, UK, or Switzerland to a country without an adequacy decision. The common mechanism is Standard Contractual Clauses, often called SCCs. SCCs create contractual commitments between the exporter and importer, but they do not replace the need to assess whether the transfer is actually protected in practice.

That practical review is usually captured in a Transfer Impact Assessment, or TIA. A TIA considers the data categories, transfer route, importer, access risks, legal environment, technical measures, encryption, key management, support access, and onward transfers. For tracking systems, it should include advertising destinations and subprocessors, not only the primary processor.

Adequacy decisions simplify transfers because the receiving jurisdiction is treated as offering an adequate level of protection. The UK and Switzerland have their own transfer regimes and adequacy concepts, so merchants operating across Europe should keep EEA, UK, and Swiss data flows documented separately where the legal instruments differ.

The highest-risk GDPR failures are usually boring implementation gaps. They happen when a banner says one thing, the browser does another, and the server sends a third version of the truth to downstream destinations.

TrackLayer is built to make compliance controls operational inside the tracking pipeline. The goal is not to turn a processor into a legal advisor. The goal is to give the merchant reliable controls for consent, minimization, residency, rights handling, and vendor transparency.

GDPR requires controllers to notify the competent data protection authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in risk to individuals. If the risk is high, affected individuals may also need to be informed.

TrackLayer's role is to support the merchant's assessment. As processor, TrackLayer notifies the merchant without undue delay after becoming aware of a breach affecting processed data, shares relevant facts as they become available, assists with containment, and helps identify affected categories, time windows, systems, and remedial steps. The merchant remains responsible for the regulator decision as controller.