Data Processing Agreement

Controller: The organisation using the TJDA Pulse platform ('Client')
Processor: TJDA (Thijs Joosten Digital Acquisition), KvK 83495975 ('Processor')

1. Introduction and Purpose

This DPA has been drawn up in accordance with Article 28 GDPR and is based on the EU Model Contract for Processors. The Processor provides TJDA Pulse — a server-to-server (S2S) conversion tracking and analytics platform. Pulse receives conversion events from the Client's website(s) and applications, stores them, and forwards them server-side to the connected advertising and analytics platforms (Google Analytics 4, Google Ads, Meta, LinkedIn, Microsoft Advertising and ChatGPT Ads). In the execution of this service, the Processor processes personal data on behalf of the Client as data controller.

2. Definitions

Personal Data	Any information relating to an identified or identifiable natural person (Art. 4(1) GDPR).
Controller	The Client, who determines the purposes and means of processing personal data.
Processor	TJDA, who processes personal data on behalf of the Controller.
Sub-processor	A third party engaged by the Processor for processing activities.
Data Subject	Website visitors, customers and application users of the Controller.
Platform	TJDA Pulse, including its event-ingestion endpoints, stored data, dashboards, and data-access connectors (including MCP/AI access).

3. Processing Activities

3.1 Purpose of Processing

• Receiving conversion events from the Client's websites and applications via the Pulse server-to-server endpoint
• Storing those events in the Pulse platform to enable cross-channel analytics, dashboards, reporting and audits
• Forwarding conversions server-side to Google Analytics 4 (Measurement Protocol), Google Ads (Google Ads API and gtag endpoint), Meta (Conversions API), LinkedIn (Conversions API), Microsoft Advertising (UET and Conversions API) and ChatGPT Ads (OpenAI conversion API)
• Sending a count of conversions without marketing consent to the Client's own Pulse GA4 property, without any identifier of the visitor, so that the Client's first-party measurement remains complete (see 3.4)
• Making the stored data available to the Client for analysis, including via dashboards and data-access connectors
• Account and license validation for the use of the Platform

3.2 Categories of Personal Data

Always processed	GA4 Client ID and Session ID (received where the event includes them, but stored in events and forwarded only with marketing consent; see 3.3), Transaction/Event ID, Order value, Currency, Product information, page/URL context, Channel hints (channel names derived from observed ad clicks; category data without identifiers), UTM campaign metadata (source/medium/campaign/content/term)
With marketing consent (see 3.3)	SHA-256 hashed email, SHA-256 hashed phone, Google click IDs (gclid, wbraid, gbraid), Meta click ID (fbc), Meta browser ID (fbp), LinkedIn click ID (li_fat_id), Microsoft click ID (msclkid), ChatGPT Ads click and view references (oppref, obref), a customer reference in SHA-256 hashed form (external_id; for the Shopify and Lightspeed integrations the customer ID or, without an account, the order reference), and a per-channel first/last click store with click timestamps (pulse_ids)
Technical metadata	Timestamps, HTTP status codes, per-channel delivery outcome, and the IP address of the system that submits events. The Platform does not add the IP address to stored event data (an ip or user_agent field that the Controller's own API integration includes is stored as sent and, with marketing consent, forwarded to Meta); it is recorded in the Platform's access log in truncated form (last octet removed) and cleared after 90 days. Where the Client's own browser tag posts directly to the Platform, this is the visitor's IP address, truncated in the same way; the web-server access log then also records the referring page and the browser's user agent (see 4.3). Web-server error logs may contain the full IP address and the request URL; they are kept on the server for at most eight days (the current log plus seven daily archives) and in the back-ups for the back-up period in 4.7.

Pseudonymisation: direct identifiers such as email and phone are stored and forwarded only in SHA-256 hashed form. The Shopify and Lightspeed integrations receive them readable from the shop system and hash them on receipt (see 3.6); a readable email or phone field received through the API is cleared on receipt. Stored data consists predominantly of pseudonymous identifiers and click IDs.

3.3 Legal Basis
The Controller determines the legal basis for each processing activity. Marketing identifiers (hashed contact data and click IDs) are forwarded to the advertising platforms exclusively on the basis of the data subject's consent, obtained by the Controller via a certified Consent Management Platform (CMP); the Platform respects the consent status transmitted with each event and never forwards marketing data without valid consent. Current versions of the Pulse WordPress connector and the Shopify and Lightspeed integrations include these identifiers only where consent was given. The Platform also enforces this itself on receipt: when an event carries no valid marketing consent, it clears the click and browser identifiers listed in 3.2, the click store (pulse_ids), the GA4 client and session ID and the hashed contact fields before storage and forwarding, whatever the sending integration puts in these fields, and keeps only the names of the cleared fields, so that the channel category of the conversion stays visible. Events stored before this safeguard took effect may still contain such identifiers. Not cleared on receipt: an ip or user_agent field that the Controller's own API integration includes (see 3.2), the GA4 client and session ID that the Shopify and Lightspeed integrations keep in their own tracking tables, and fields outside this list that the Controller's own integration includes (such as other names for click identifiers, or the content of UTM fields), which are stored as sent. The minimal measurement data listed under "Always processed" — including the channel and campaign category fields, which contain channel names and campaign labels only, without identifiers or click timestamps — is processed for the Controller's own first-party conversion measurement, typically on the basis of the Controller's legitimate interest, and is not shared with the advertising platforms for data subjects who did not give marketing consent.

3.4 Measurement without marketing consent
Where a data subject has not given marketing consent, the Platform still records the conversion for the Controller's own first-party measurement, and additionally transmits an anonymous count of that conversion to the Client's own Pulse GA4 property. That transmission contains no identifier of the visitor: a single-use client identifier generated per hit that is not derived from the visitor, the device or the order, no session or user identifier, no hashed contact data, no location data and no transaction identifier, with the consent signal set to denied and personalisation disabled. It does contain the event name, the value and currency and, per product line, the product code, quantity and price, so that the count is useful. Its sole purpose is to keep the Controller's own conversion totals complete; Google cannot link it to a data subject, and it is never used for advertising purposes. No other connected platform receives any data about a data subject who did not give marketing consent.

3.4a Replacement GA4 client identifier
Where marketing consent is given but the event carries no usable GA4 client ID, the Platform derives a replacement client identifier from the event's own identifier (not from the visitor or the device), so that the conversion can still be counted. Without an event identifier nothing is derived: the conversion is not sent to GA4, and the Client's Audit records this.

3.5 No storage before consent
From connector version 1.3.5 onward, the Platform stores no persistent identifier on the data subject's device before the consent choice has been made. Advertising click identifiers and the channel store are held for the duration of the browser session only; they are written to persistent storage exclusively after marketing consent has been given. Where consent is refused or not given, nothing persistent remains.

3.6 Hashed fields are enforced
Every field intended for a hashed contact identifier (hashed email, hashed phone, hashed customer ID) is checked on receipt. A value that is not a valid SHA-256 digest is not stored and not forwarded: the field is cleared, the event is processed without it, and the Client's Audit reports the affected field and the number of events concerned. For events received through the Platform's API, the Platform does not hash a readable value on the Client's behalf, because doing so would mean processing a contact identifier that the Controller has not hashed, and would hide an integration error from the Controller. The Platform's own integrations for Shopify and Lightspeed receive order data directly from the shop system; for those, the Platform hashes the email address, the phone number and the customer ID (or, without a customer account, the order reference) with SHA-256 on receipt, before storage and forwarding. For the API, the Controller is responsible for hashing before transmission; the Platform's developer documentation specifies the required form. A readable email or phone field received through the API is cleared on receipt, not hashed, and reported in the Client's Audit.

4. Obligations of the Processor

4.1 The Processor processes personal data only on documented instructions from the Controller, as set out in this DPA and the use of the Platform.

4.2 The Processor ensures that persons authorised to process the personal data are bound by confidentiality.

4.3 Security Measures (Art. 32 GDPR)

• AES-256 encryption of stored credentials (OAuth tokens, API secrets, access/refresh tokens)
• SHA-256 hashing of email addresses and phone numbers before storage and transmission
• TLS 1.2+ for all outbound and inbound connections
• Access to the platform database restricted to the Processor; data-access connectors authenticate per Client via revocable, rate-limited tokens
• A Client's stored data is logically isolated per Client; a Client token can never retrieve another Client's data
• Application and web-server logs with automatic rotation; no readable email addresses or phone numbers in application logs; web-server error logs may contain full IP addresses and request URLs for troubleshooting (see 4.7)
• No persistent storage of advertising identifiers on the data subject's device before a consent choice has been made (connector 1.3.5 and later)
• A single, central consent rule across the Platform and all connectors: only an explicit affirmative consent signal permits forwarding of marketing identifiers, and the storage in events of the identifiers that 3.3 lists as cleared on receipt; a missing, refused or unrecognised signal is treated as refusal
• Delivery of each conversion is recorded per channel with its outcome and reason, so that a failed or skipped delivery is visible rather than silent
• Validation of hashed fields on receipt: a value that is not a valid SHA-256 digest is cleared and reported, never stored or forwarded
• Logical isolation between Clients: an analytics property, Search Console property or advertising account can be linked by one Client only; an attempt to link an identifier already in use by another Client is refused
• Access-log IP addresses are truncated on write and cleared after 90 days. Web-server access logs store the IP address in truncated form, together with the time, the request line (with keys and tokens masked), the status code, the size, the referring page and the browser's user agent; web-server error logs may contain full (non-truncated) IP addresses and request URLs for troubleshooting. Web-server logs are rotated daily and kept on the server for at most eight days (the current log plus seven daily archives).

4.4 Sub-processors

TransIP B.V.	Hosting of the Pulse platform, including the database, the back-ups (made every four hours, plus weekly) and the staging environment. Netherlands (EU).
Anthropic PBC	AI processing for the Platform's data-access connector (MCP). Applies only where the Client actively uses the AI connector. United States; Standard Contractual Clauses.

The Processor informs the Controller of any intended change of sub-processors and gives the Controller thirty (30) days to object on reasonable grounds relating to data protection.

4.4a Platforms to which the Platform forwards
The Platform forwards conversions only to accounts that the Controller itself holds and has itself linked in the Platform. For each of these platforms the Controller is the contracting party and account holder, and has accepted that platform's own data processing terms; they are therefore not sub-processors of the Processor. Only the platforms the Controller has actually linked receive any data. Section 6 describes the transfer mechanisms that apply to them.

Google LLC	Google Analytics 4 (Measurement Protocol) and Google Ads (API and gtag endpoint).
Meta Platforms Ireland Ltd.	Meta Conversions API.
LinkedIn Ireland Unlimited Co.	LinkedIn Conversions API.
Microsoft Ireland Operations Ltd. / Microsoft Corporation	Microsoft Advertising UET and Conversions API.
OpenAI Ireland Ltd.	ChatGPT Ads conversion API.

4.5 Data-subject requests
The Processor assists the Controller, taking into account the nature of the processing, in fulfilling the Controller's obligations regarding data-subject requests (Art. 12–23) and security, breach notification and DPIAs (Art. 32–36). In practice: on the Controller's written instruction, and on the basis of an identifier the Controller supplies (such as an order reference or a hashed email address), the Processor removes the identifying fields from the stored events of that data subject within 30 days. Removal from back-ups follows the back-up period in 4.7. The Processor keeps a register of deletion requests outside the server, accessible only to TJDA, that contains no personal data of data subjects; it records the Client, the date and the written instruction, so that the deletion can be carried out again from that instruction if a back-up is ever restored. The conversion itself is retained as an anonymous count, so that the Controller's historical totals remain correct. The Processor confirms the removal in writing. Data already transmitted to a connected advertising platform is subject to that platform's own retention and deletion procedures; the Controller addresses such requests to the platform concerned, and the Processor assists on request.

4.6 Data Breach Notification
The Processor will notify the Controller without undue delay and at the latest within 48 hours of discovering a personal data breach, with at least the information required under Article 33(3) GDPR.

4.7 Retention and Deletion

• Marketing identifiers (hashed email, hashed phone, click identifiers and the click store) are retained for a maximum of 25 months from the date of the event, after which they are removed from the stored event. That period allows a full year-on-year comparison plus one month of reporting margin.
• Measurement data without identifiers (conversion counts, values, currency, channel and campaign categories) is retained for as long as the Client's account is active, to provide the analytics, historical comparison and reporting functionality that is the purpose of the service.
• Upon termination of the account, or upon written request by the Controller, the Processor deletes all of the Client's personal data within 30 days; removal from back-ups follows the back-up period below.
• Stored credentials are deleted upon disconnection of the relevant integration or termination of the account.
• Application logs are rotated automatically and are not used for long-term storage of personal data.
• Web-server logs (access and error logs) are kept on the server for at most eight days and are included in the back-ups described below.
• Back-ups of the whole server are made every four hours and weekly, and are kept for no longer than six weeks, after which they are overwritten; they are not edited individually. Personal data deleted in the live database therefore remains in the database's transaction logs for up to 30 days and in the back-ups until they expire, at the latest after six weeks, and is not restored from either. If a back-up is ever restored, earlier deletions are carried out again before the data is used.
• Staging environment. Alongside production the Platform runs a staging environment on the same server that holds a copy of production data for testing. Retention periods and deletions apply to both environments.
• Access log. The IP address of the submitting system is stored in truncated form and cleared after 90 days; the remaining log entry (timestamp, endpoint, status code) contains no personal data and is retained for operational purposes.

5. Obligations of the Controller

• Ensuring a valid legal basis for the processing of personal data via the Platform
• Correctly configuring and maintaining an active Consent Management Platform (CMP), and transmitting consent status with events
• Informing data subjects, via an up-to-date privacy policy, about server-to-server conversion tracking and the use of the Pulse platform
• Accepting the data processing terms of Google, Meta and LinkedIn for the respective connected platforms
• Managing access to the Platform and its connectors within the Client's own organisation, including safeguarding access tokens
• Ensuring timely renewal of the account/license

6. Transfers to Third Countries

The Processor itself stores and processes personal data in the Netherlands (TransIP). The only transfer outside the EEA on the Processor's own account is to Anthropic PBC (US), and only where the Client uses the AI data-access connector, under Standard Contractual Clauses.

The platforms listed in section 4.4a receive data because the Controller has linked its own accounts there. The Controller is responsible for the lawfulness of those transfers under its own agreements with each platform. For the Controller's information: Google LLC, Meta Platforms and Microsoft Corporation are certified under the EU-US Data Privacy Framework (adequacy decision 10 July 2023); LinkedIn relies on Standard Contractual Clauses (Decision EU 2021/914); OpenAI processes EEA data through OpenAI Ireland Ltd. with onward transfers to the United States under Standard Contractual Clauses, and is not certified under the Data Privacy Framework. The Controller should verify the current status of each mechanism with the platform concerned.

7. Duration and Termination

This DPA runs in parallel with the Client's use of the Platform. Upon termination, the Processor deletes all of the Client's personal data within 30 days of written request (removal from back-ups follows the back-up period in 4.7), save where Union or Member State law requires storage.

8. Liability

The Processor's liability is limited to the fees paid by the Controller in the 12 months preceding the damage-causing event. The Controller indemnifies the Processor against third-party claims arising from the Controller's failure to fulfil its GDPR obligations.

9. Governing Law

This DPA is governed by Dutch law. Disputes are submitted to the competent court in the district where the Processor is established.

Based on the EU Model Contract for Processors (Art. 28 GDPR) and Standard Contractual Clauses (Decision EU 2021/914).