Data processing agreement pursuant to Art. 28 GDPR

The subject matter is the provision of the measurement service “Metrunio”: collecting, storing, linking and evaluating events to measure advertising contacts and conversions on the client’s websites and the publisher placements included in its campaigns independently.

Revenue reconciliation. The subject matter also includes the revenue reconciliation of orders and refunds that the client’s shop reports server-side and for which it transmits no decision on consent to tracking because none was made. The sole purpose is matching revenue, recognising duplicate transactions and assigning refunds.

• Only the tenant and source, the order number as order key, the type of transaction (order, subscription renewal or refund), amount and currency, the business day without time and the environment flag are processed. The contractor removes all other fields before storage, in particular browser, session, customer and advertising identifiers, the subscription ID, IP attribute, page addresses, campaign details and items. The renewal flag is set by the source. It serves solely revenue reconciliation and the recognition of duplicate transactions: it distinguishes a subscription’s renewals from the payment with which the subscription began and which has already been reported as an order, and shows them separately in the reconciled revenue. The contractor does not derive a new-customer or existing-customer attribute from it.
• Excluded are linking to visits, journeys or advertising contacts, attribution, forwarding to advertising platforms, profiling, passing individual orders of this kind to the data assistant and any use of the contractor’s own; the sole exception is attribution via the checkout under the last indent of this section. The data assistant may use metrics that include them; with small case numbers the amount and day of an individual order may be derivable from them.
• The data is deleted with the tenant’s raw-data retention period.
• The client may cancel this revenue reconciliation in the portal at any time; the setting is an instruction that only persons with the Admin role can change, and it is recorded in the tenant’s log. The contractor then rejects such orders; orders already stored are deleted with the raw-data retention period. The extension to orders after a refusal requires revenue reconciliation to be switched on.
• An objection by a data subject to revenue reconciliation is implemented by the client in the portal’s privacy area using the order number as identifier, or by the contractor on the client’s instruction: the data of the transaction including refunds is deleted and the order number is blocked for future reports and imports.
• Orders for which the shop transmits a refusal are processed this way only if the client has given a separate supplementary instruction for it and the contractor has activated it for the tenant; otherwise the contractor rejects them. The client can trigger the revocation of the supplementary instruction itself in the portal under “Privacy”; from then on, the contractor rejects such orders after ten seconds at the latest. A transmitted refusal is never treated as a missing decision. Orders reported with consent that is later withdrawn are not transferred into revenue reconciliation (section 8).
• The client is responsible for the legal basis towards buyers, for informing them about purpose, legal basis and how to object in its own privacy notice and for honouring an objection (section 4).
• Attribution via the checkout. On a separate instruction of the client, which it gives in the portal and may withdraw at any time (Admin role, recorded in the tenant’s log), the contractor attributes an order under this section to the browser that completed the same checkout with consent whose scope includes linking orders and revenue to visits and advertising contacts. Conditions: the order arrived without a decision through the server interface, not after a refusal and not from a historical import; website, environment, order number and checkout identifier match, and exactly one browser carries them; the browser’s event arrives within 24 hours of the order; the consent demonstrably existed at the latest at the time of purchase, has not been narrowed since and was given under consent texts whose identifier the client has confirmed for the website. The process has two steps. First, on this instruction the contractor forms a short-lived matching record as soon as a suitable order arrives, even if no matching browser event arrives later; it consists only of a keyed checksum of the checkout identifier and the exact time of the order. Second, it attributes the order only where consent is demonstrated that existed at the latest at the time of purchase. The contractor uses the checksum and the time of the order only until 24 hours after the order, and the checksum on the browser’s events only until 24 hours after they arrive, even if no attribution results; it then deletes them from the active data in the regular maintenance cycle. Backups and residual copies are governed by section 9; after a restore, expired matching data is no longer used and is deleted in the first maintenance run. The order remains stored to the extent set out in this section. The attributed order is evaluated like a conversion with consent and, where the client has switched on forwarding and the browser’s consent covers it, reported to advertising platforms. If the browser withdraws or narrows its consent, the contractor deletes the attribution, the order and the match and blocks the order number (section 8). The legal basis of the attribution is the consent; the client is responsible for obtaining it and for its content. For the matching record of the first step, which also covers orders that are never attributed, the client is responsible for the legal basis, as a rule its legitimate interest based on its own balancing, and for informing buyers (section 4).

The agreement runs for as long as the main contract for use of the software; no separate termination is required.

It continues to apply beyond that for as long as the contractor still processes the client’s data, i.e. until return or deletion under section 9, including remaining backups and copies held by sub-processors. During that period in particular the duty to follow instructions, confidentiality, security of processing, notification of breaches and assistance with data subject rights remain in force.

Only data transmitted by the client, or caused to be transmitted by the client, through the provided interfaces is processed. The sole purpose is the provision of the measurement service.

• receiving and validating events (delivery, viewability, click, site visit, interaction, conversion)
• linking events into journeys through unambiguous identifiers
• calculating attribution shares according to the models chosen by the client
• providing reports, exports and interfaces
• on explicit instruction: forwarding conversions to the advertising platforms named by the client
• revenue reconciliation of server-side orders without consent to tracking, to the extent set out in section 1
• on explicit instruction: attribution of orders without a decision via the checkout, to the extent set out in section 1
• on instruction: transmission to recipients that the client determines itself and enters in the portal, in particular outgoing webhooks with the order or lead identifier, value and time of individual transactions, summaries of reports and alerts to a Slack or Teams channel, and retrieval by tools the client connects through a read key or an OAuth authorisation. The client gives the instruction to disclose data to such tools either for each connection or in advance as a separate supplementary instruction; the latter is voluntary, this agreement can be concluded without it, and only its current version applies. If the client revokes the supplementary instruction, all read keys and authorisations of the account end immediately. These recipients do not thereby become further processors of the contractor. The contractor no longer sends messages not yet delivered that are affected by an erasure, objection or withdrawal (section 8)
• on instruction: providing the script that writes source details (lead identifier, source, medium, campaign, advertising platform and, with marketing consent, additionally the click identifier) into hidden fields of forms on the client’s websites; by default only with consent to analytics, without it only where the client expressly switches it on for a website, and then only source, medium and campaign from the address of the page being viewed. The form data goes to the client’s systems, not to the contractor
• on instruction: accepting answers to the post-purchase question, only with consent to analytics; the answer is linked to the order and the journey
• attributing a subscription renewal reported with consent to the first order of the same subscription through the subscription ID; if the first order ceases to exist, the renewal is recalculated and remains unattributed
• where ad-level reporting is activated for the tenant: attributing visits to an ad through the ad ID in the campaign parameter `utm_content`
• on instruction: retrieving costs and metrics from the client’s services whose credentials the client stores or grants by signing in, for display next to the measurement. From ad accounts and further cost sources, cost, impressions and clicks per campaign or shop and day, and with ad-level reporting activated also per ad, with the names and IDs of ads and ad groups and the address of a preview image; the images themselves are not stored but kept in memory for no more than one hour. From a shared spreadsheet, the columns of the cost import. From the client’s email platforms, for each campaign sent, ID, name, send time, campaign parameter and the number of recipients, deliveries and unique clicks, without data on individual recipients. From the client’s Google Search Console, clicks, impressions, click-through rate and position per day, page and search query; they are not stored but kept in memory for no more than one hour. The providers of these services do not thereby become further processors of the contractor
• on instruction: sending a monthly report with totals for a client account to recipients named by the client, and honouring their unsubscription
• on a question from an authorised person of the client in the portal: answering through a data assistant. Metrics and individual conversions and journeys go to the language model of a further processor (annex) – at most 300 rows per question; the tenant’s order numbers and journey identifiers only as codes that apply to this one request; earlier answers containing individual records not again; orders reported without consent not individually. A number typed in that cannot be matched to a record of the tenant goes to the model as text

Data subjects are visitors to the client’s websites and to the publisher placements included in its campaigns, for server-side reported completions the client’s customers, the recipients of reports named by the client, persons identified or shown in search queries or page addresses from Google Search Console or in the names and preview images of campaigns and ads, and the client’s persons entitled to issue instructions, to the extent their details are needed for instructions and processing operations.

• pseudonymous identifiers for session, device, click and impression
• tenant-specific pseudonymised customer identifiers; a plaintext or hashed value passed in, such as the SHA-256 of the e-mail address, is pseudonymised on receipt via HMAC with a tenant-specific key and stored only in that form
• order and case numbers, the subscription ID (only for reports with consent; it is not stored on revenue reconciliation orders), values and currencies
• campaign and ad parameters of the page visited, such as `utm_content` with the ID of an ad
• technical attributes in truncated or hashed form; IP addresses are processed in transit and for rate limiting and are not stored in the event data, not even as a checksum
• answers to the post-purchase question from a fixed list, without free text
• the consent state for each event
• for persons entitled to issue instructions: name, e-mail address, role and the logged instructions
• metrics from the client’s services: cost, impressions and clicks, names and IDs of campaigns, ad groups and ads, addresses of preview images and metrics on newsletter campaigns; with small numbers or names that identify a person, they can relate to individuals
• from Google Search Console: search queries and page addresses with clicks, impressions, click-through rate and position, without an identifier of individual searchers
• for recipients of reports: e-mail address, name (optional), client account, who added them and when and a hash of the unsubscribe token; per client account the controller (agency or its client), the link to the controller’s privacy notice and who entered both and when; after unsubscription only a block record (HMAC of the normalised address, time of unsubscription and of an invitation), during an invitation to resubscribe additionally address, name and a hash of the invitation token; the sole purpose is sending the monthly report and honouring the unsubscription

The contractor processes the data only on documented instructions from the client, including with regard to transfers to third countries, unless it is required to do so by Union or Member State law; in that case it informs the client before processing unless that law prohibits it.

The settings in the product, in particular retention period, attribution windows, forwarding to platforms, consent mapping and the data assistant, constitute instructions; their changes are traceable in the tenant’s log. Instructions outside the product are given by the client in text form. Product settings do not extend the purpose under section 2.

Persons with the Admin role in the tenant and further persons the client names in text form are entitled to issue instructions. Where there is doubt about authorisation, the contractor has the instruction confirmed by one of these persons.

If the contractor considers an instruction unlawful, it informs the client without undue delay and suspends the part concerned until it is clarified. It does not carry out an instruction recognised as unlawful even if it is repeated.

The client is responsible for the legal basis, informing data subjects, any necessary consents and the lawfulness of its instructions.

Where the client is itself a processor, for example as an agency acting for its own customer, it acts on the instructions and with the required authorisation of that controller; to that extent the contractor becomes a further processor. The client names the controller for the client account concerned and ensures that the controller’s authorisation covers the use of the contractor and of annex 2; the chain of instructions is documented for the client account.

All persons involved in the processing are bound to confidentiality and instructed in data protection requirements. Support access to tenant data is possible only while the client allows it in the settings of its tenant; the setting is switched on by default, and the client can switch it off at any time. Such access serves only to handle a request of the client or a fault. Each access is time-limited, is separately logged with its reason and is shown in the tenant’s change log. If the client switches the setting off, any running access ends. By concluding this agreement the client gives the standing instruction for such access to the extent described; it can revoke it at any time through the setting, for future and running access.

The contractor implements the measures described in the separate annex “Technical and organisational measures” pursuant to Art. 32 GDPR. Changes may not fall below the level of protection.

The client consents to the use of the further processors listed in the annex “Further processors”.

Direct sub-processors. The contractor announces a new or replaced further processor that it engages itself at least 30 days before its engagement on the website under “Documents” and in text form to the address stored in the account. Within this period the client may object on objective grounds relating to data protection. As long as the objection is unresolved, the new processor receives no data of the client. If no solution is reached, the client may terminate this agreement and the main contract for cause before the change; the contractor refunds fees paid in advance for the period after that on a pro-rata basis.

Further tiers: secured notice. For the client’s data the contractor uses only sub-processors that have undertaken to announce the engagement of a new further processor at least 30 days before it receives data; exceptions only under the paragraph “Sub-processors without secured notice”. The annex states this undertaking for each sub-processor. The contractor forwards such a notice without undue delay, at the latest five working days after receiving it, by the route described in the previous paragraph. Before forwarding it, the contractor checks on the basis of the provider’s information which of the client’s data the new tier can access, including backups and copies pending deletion (residual copies). The notice states the recipient, activity, place of processing, transfer basis, the day from which the new further processor receives data (start date) and the result of this check.

Objection to a further tier. The client may object on grounds relating to data protection until ten days before the start date, and in any case for at least 14 days after receiving the notice. The contractor resolves the objection with the client, for example through an undertaking or restriction by the provider or through a different route of processing. Until it is resolved, the contractor ensures that the new tier gains no access to the objecting client’s active data; to do so it suspends the route concerned or routes it through another sub-processor named in the annex. The contractor cannot exclude access by a new tier to residual copies held by the cloud provider (section 9); the provider offers neither a per-customer exception nor a technical separation for this. For these residual copies, by concluding this agreement the client gives general authorisation for the further processors the cloud provider engages under its contract, including future ones after notice (Art. 28(2), second sentence, GDPR), until the residual copies expire under section 9. Its right to object to a new tier and to terminate for cause under the following paragraph remains unaffected; the notice states whether the new tier can cover residual copies.

If that is technically impossible, the contractor tells the client without undue delay, and the client may terminate this agreement and the main contract for cause before the start date. The contractor then accepts no further data of the client from receipt of the termination, makes the data available for export on request and deletes the active data under section 9 before the start date, at the latest five working days after receiving the termination. Backups and residual copies held by the cloud provider expire under section 9; the contractor does not undertake to delete them immediately, and the notice states whether the new tier can cover them. The contractor refunds fees paid in advance for the period after termination on a pro-rata basis.

Late notice. If the contractor receives a sub-processor’s notice late or forwards it later than agreed, it says so without undue delay, giving the reason for the delay and whether the new tier could already access the client’s data. The client may then object within 14 days of receiving the notice even if the start date is earlier; the two previous paragraphs apply to the objection. At the client’s request the contractor suspends acceptance of new data until the objection is decided. The later period opens up the client’s rights; it does not make access that took place before the notice permissible after the fact. The client’s rights arising from such access remain unaffected.

Sub-processors without secured notice. Where the annex names a sub-processor without this undertaking, it receives the client’s data only to the extent described there. If it announces a new further processor, from receipt of the notice the contractor no longer routes the client’s data through it but through another sub-processor named in the annex, and gives notice as above. Data of the client already held by it at that point is deleted there by the contractor to the extent the sub-processor’s interfaces allow; otherwise the notice states the type and retention period of that data.

With every further processor the contractor concludes a contract in writing, including in electronic form, imposing the same data protection obligations: adherence to instructions, confidentiality, the measures under Art. 32 GDPR at a level that does not fall below this one, assistance with data-subject requests and notification duties, audit and evidence rights, and deletion or return at the end. The contractor is liable for their compliance as for its own conduct.

The contractor assists the client in fulfilling data subject rights. Access, erasure and objection can be carried out in the product’s privacy area without involving the contractor. Rectification, restriction of processing and data portability are carried out by the contractor on instruction in a documented procedure; a restriction keeps the data in a protected store and is not replaced by erasure. Requests from data subjects received by the contractor are forwarded to the client without undue delay and not answered by the contractor itself.

An erasure continues to apply through a suppression list, so that the same identifier is not captured again immediately afterwards. Only a checksum of the identifier is stored, not the identifier itself. The checksum remains pseudonymous personal data: it recognises the identifier but cannot be turned back into it. It is used for no purpose other than enforcing the erasure or objection.

Standing instruction on withdrawal. When a withdrawal of consent reaches the consent interface, the contractor ends, without any further order, the processing based on that consent, including reports to advertising platforms not yet transmitted. It deletes the attributable data based on that consent without undue delay unless a separate legal basis or an exception under Art. 17(3) GDPR supports further storage. The withdrawal applies to the browser in which it is declared; the client implements a request by the person going further through the privacy area.

Retention despite a withdrawal is limited to the data, purposes and period concerned; the client notifies such cases specifically in advance. There is no change to another purpose solely because of the withdrawal, in particular no transfer into revenue reconciliation. Implementation covers operational data, mirrors, pending transmissions and existing exports within the contractor’s control. The contractor cannot recall data already transmitted to recipients; it names the recipients to the client so that the client can meet its notification duty under Art. 19 GDPR, and assists it in doing so.

The contractor also assists the client, taking into account the nature of the processing and the information available to it, with the obligations under Art. 32 to 36 GDPR, that is with the security of processing, with notifications and communications under Art. 33 and 34, with data protection impact assessments and with a prior consultation of the supervisory authority. To this end it provides the necessary information on the processing, measures, risks and incidents and takes part in the assessment and in necessary remedial measures. A personal data breach is notified to the client without undue delay and at the latest within 24 hours of becoming aware of it.

On termination the data is returned or deleted at the client’s choice. The client communicates its choice in text form and may change it until the period expires.

Active data. For return, the data remains available for 30 days in the export formats provided; the client retrieves it itself or requests it from the contractor. An export during the term is possible at any time at no additional charge. Thereafter the contractor deletes the data in the database, analytics mirror and exports; if the client makes no choice, deletion applies.

Own backups. The database backups from which the contractor can restore expire in their cycle: at most the last 14 daily backups and seven days of transaction log are kept (Annex 1 and Annex 3). They are not specifically searched and until they expire serve solely for restoration. If a backup is restored, the contractor reapplies all erasures, restrictions, blocks and withdrawals made since then before processing resumes. If that state cannot be fully reapplied, the data concerned is not released for processing.

Residual copies held by the cloud provider. These are to be distinguished from copies from which the contractor cannot restore: the cloud provider removes deleted data from its systems under its contract as soon as reasonably practicable and at the latest after 180 days (Google Cloud Data Processing Addendum, section 6.1); if the contractor’s agreement with it ends, a recovery period of up to 30 days is added (section 6.2). Until then this agreement continues to apply to those copies.

Discontinuation. If the contractor discontinues the service, it announces this under the main contract; return and deletion follow the paragraphs above.

Deletion is evidenced on request, stating time and scope. Log data that serves the duty of proof and documents subject to a statutory retention period are not affected; they are blocked for any other use.

The contractor demonstrates compliance on request and allows for audits, including inspections, by the client or an auditor mandated by it. An audit is announced with reasonable notice and must not unreasonably disrupt operations; after an incident or on reasonable suspicion it is possible without that notice.

The main resources are located in the europe-west3 region (Frankfurt). Individual stores – in particular global logging areas of the cloud provider – and maintenance and support access by group companies of the further processors may be located or take place outside the EU; the annex names recipients, countries and transfer basis per service. Any further transfer to a third country takes place only on documented instruction and under the conditions of Art. 44 et seq. GDPR.

This agreement is concluded electronically (Art. 28(9) GDPR): in the customer portal under “Privacy” or when setting up through the Shopify app, in each case by a person who declares that they are authorised to conclude it for the client. It is concluded separately from the main contract and for each tenant. Until it is concluded the software accepts no measurement data for that tenant.

The annexes, in the same version as this agreement, are: Annex 1 “Technical and organisational measures”, Annex 2 “Further processors”, Annex 3 “Deletion policy”. The portal keeps the agreed wording under “Privacy”; every version also remains available on the website under its date.

Changes require text form. The contractor offers a new version for conclusion in the portal; until then the version concluded continues to apply. Notices under section 7 are not a change to this agreement.

In the event of conflict this agreement takes precedence over the main contract as far as the processing of personal data is concerned. German law applies.