Privacy policy

The provider named in the legal notice is the controller for processing on this website. For the data collected in the product about visitors to our customers’ websites, that customer is the controller; there we act as a processor.

Controller

Kokolorum GmbH
Industriering Ost 66
47906 Kempen

Data protection officer

heyData GmbH
Schützenstraße 5
10117 Berlin
www.heydata.eu
datenschutz@heydata.eu

Contact for data protection matters

privacy@metrunio.com

Competent supervisory authority

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), Kavalleriestraße 2–4, 40213 Düsseldorf

Metrunio processes data in two separate roles. As controller for this website and for our customers’ accounts. As processor for the measurement data collected on our customers’ websites on their behalf — there the customer determines purpose and means, not us. The two roles carry different legal bases, recipients and retention periods, which is why they are described separately.

Art. 6(1)(b) GDPR applies only where you yourself, as a natural person, are our contracting party and the processing is necessary for the contract. Where you act for a business, for example as managing director, employee or appointed agency, the processing is based on Art. 6(1)(f) GDPR. Our legitimate interest lies in setting up and managing the business customer account, sign-in and the security of your access, billing and communication for performing the contract. You may object to processing under point (f) on grounds relating to your particular situation under Art. 21 GDPR.

Signing in with passkeys

If you create a passkey in the portal, you can use it to sign in without a password or as the second step after your password. A passkey is valid only for the portal’s address. For each passkey we store its ID, the public key, your device’s counter, the transports reported by the browser, whether it is backed up or synced, the name you give it and when it was created and last used. So that your device can display the passkey, we pass it your email address, your name and the internal ID of your user account when the passkey is created.

Metrunio does not receive your private key. Your device or the passkey provider you have chosen manages it; depending on the provider and your settings, it may be backed up and synced between your devices. Metrunio stores the public key and the identification and management data described. A PIN or biometric check is carried out by your authenticator; Metrunio receives no fingerprint or face data in the process.

Your device or the passkey provider you have chosen, such as the provider of your operating system, your browser or your password manager, stores the passkey with your email address, your name and the ID of your user account. Whether it backs the passkey up or syncs it with your other devices, and which details it receives in doing so, depends on that provider and your settings. To that extent it is a recipient of these details; your choice does not make it our processor.

Creating and using a passkey on your device is strictly necessary for the sign-in method you expressly request (§ 25(2)(2) TDDDG); we do not ask for separate consent for it. Our processing of the details is based on Art. 6(1)(b) or (f) GDPR, as for the other account data (see below the table).

For every sign-in and every creation we form a challenge from random numbers that is valid once and for five minutes. Only its hash is stored. We delete a redeemed challenge immediately and an unredeemed one at the latest six minutes after it was formed.

We delete a passkey as soon as you remove it, and otherwise with your user account. A user account can belong to several customer accounts, for example if you work for an agency. If a single customer account ends, your user account and your passkeys therefore remain for as long as you belong to another one; when the last one ends, we delete the user account with it 30 days after the contract ends (first row of the table). If an Admin removes you from a customer account, your user account and its passkeys likewise remain; you can ask for it to be deleted at any time. Creating and removing a passkey are recorded with its name and internal ID in the log of every customer account you belong to, and a sign-in with a passkey like any sign-in. Rejected sign-in attempts are recorded in the platform log, and for the sign-in link from the Shopify app in the customer account’s log. We delete these entries after 180 days, even if you remove the passkey earlier, and those in a customer account’s log at the latest with that account. So that a removed passkey does not come back after a backup is restored, we additionally record the removal with the passkey’s internal ID in a separate case journal for 90 days.

Setting up through the Shopify app

When you set up through our Shopify app, Shopify provides us with the shop data needed to link the account (the shop’s identifier, name, language, currency, time zone and domains), the shop owner’s name and email address as stored in the shop’s settings — that address becomes the account’s contact address — and the shop’s billing address. We merely propose the billing address as company name and address for the data processing agreement; what is stored is what the acting person confirms. From the person who operates the app and creates the account we receive their Shopify user ID, name, email address and whether Shopify identifies them as the shop’s owner. That person becomes the owner of the Metrunio account, and their details record who accepted the terms and conditions and the data processing agreement. We use this information to set up and manage the Metrunio account and to connect it to the shop.

Where the data subject is themselves a party to the contract and the processing is necessary, it is based on Art. 6(1)(b) GDPR. For contact persons of a company it is based on Art. 6(1)(f) GDPR; our legitimate interest lies in managing the business customer account and in communication for performing the contract. You may object to processing under point (f) on grounds relating to your particular situation (Art. 21 GDPR); your other rights are listed under “What you can ask for”. We keep this information like the account data in the first row of the table above: for the term of the contract and after that until the account is deleted 30 days after the contract ends. The record of acceptance and of the conclusion of the contract remains in minimised form after the contract ends for as long as the row “Record of the conclusion of the contract” states, as a rule six years after the year in which the contract was concluded (§ 257 HGB). If the owner’s address stored in the shop differs from the acting person’s address — for example because an employee or an agency set up the app — the shop owner receives this information by email under Art. 14 GDPR.

Signing in with Google Ads and Meta

When customers connect their ad account by signing in with Google or Meta, the platform gives us an access credential: a refresh token from Google, a long-lived access token from Meta. We store it encrypted (AES-256-GCM) and bound to the customer's account. It is never displayed or logged.

With this access we read from the selected ad account:

• the list of accessible accounts with name, ID and currency, so the right one can be chosen;
• cost, impressions and clicks per campaign and day;
• if ad-level reporting is activated for the customer account, also cost, impressions and clicks per ad and day, with the name and ID of the ad and its ad group and, where the platform provides one, the address of a preview image of the ad.

We store the addresses of preview images, the names and IDs of ads and ad groups and their metrics like the other costs, for as long as the customer account exists. We do not keep the preview images themselves permanently: when the report is opened, our servers retrieve them from the platform and keep them in memory for no more than one hour; your browser does not connect to Meta or Google in the process. Preview images and ad names can show or name identifiable people, such as people who appear in the advertising. We show costs per ad only in this report in the portal; the data assistant, exports and interfaces do not return them.

If the customer turns on conversion upload, we also report conversions to their account. This sends the platform’s click ID, the type, time, value and currency of the conversion, depending on the platform an event ID that lets the platform recognise duplicate reports (Meta, TikTok, LinkedIn), the order number (Google, Meta, TikTok) and the address of the page on which the click landed (Meta, TikTok). As the value we send the revenue of the conversion or, if the customer sets this for a destination, for orders the contribution margin (net value minus cost of goods). If the customer limits a destination to first orders, it reports only those; the platform thereby learns indirectly that an order was a first order. We do not send email addresses, phone numbers, IP addresses, browser attributes or our own personal or device identifiers. Reports are sent only with marketing consent, and for Google additionally only with `ad_user_data` consent or the consent category the customer has mapped to it. We do not change campaigns, ads, bids or budgets.

The data is used solely to show customers their own costs next to their own conversions and to report their conversions back to their own account. At the customer's request, the data assistant in the portal may read the same cost figures. It runs on Vertex AI in the europe-west3 region, and its inputs are not used to train models. We do not sell the data, use it for advertising or combine it across customers. We share it with third parties only if the customer connects an AI tool or program to her account and thereby instructs us to transfer her data to it (see “Connecting AI tools from other providers”).

Metrunio's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

If the connection is removed in Metrunio, we delete the credential immediately. Access can also be revoked at any time on the platform, at myaccount.google.com/permissions or under “Business integrations” in Meta's settings. Imported costs are kept for as long as the Metrunio account exists and are deleted with it. Deletion of individual data can be requested at any time at privacy@metrunio.com.

Signing in with Google Search Console

If Search Console is activated for a customer account and a person with the Admin role connects it by signing in with Google, Google gives us a refresh token with permission to read Search Console (`https://www.googleapis.com/auth/webmasters.readonly`). We store it encrypted (AES-256-GCM) and bound to the customer account. It is never displayed or logged. For the connection we also store who established it and when, which Google access it uses (OAuth client) and the property chosen for each website. For the duration of the sign-in we keep a hash of its state and the PKCE verifier; both are valid for ten minutes and are deleted when the sign-in completes, otherwise at the latest eleven minutes after the sign-in began.

With this access we read from Search Console:

• the list of properties the signed-in Google account can access, with the type of permission, so that the right one can be chosen for each website;
• for the chosen properties, clicks, impressions, click-through rate and average position in Google web search, per day, per page and per search query.

We do not change anything in Search Console. The data is used solely to show the customer its own search figures in the “Organic search” report, next to its own measured visits and conversions. We compare them per page; we do not link any individual search query to a visit, a person or a conversion. We fetch the figures when the report is opened and keep them in memory for no more than one hour, only for the customer account, connection and property for which they were fetched; they are not kept permanently. Once the connection is removed, we no longer return them and discard them. The figures are not included in exports, interfaces, email reports or the data assistant. We do not sell the data, do not use it independently for our own purposes, do not use it for advertising, do not combine it across customers and do not use it to train models. It is processed only by the processors through which we provide the feature (see “Recipients”).

Metrunio's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Search queries and pages can identify people, for example by name. Google does not list rare queries individually; that does not rule out every conclusion. We therefore treat these figures as personal data that we process on the customer’s behalf (Art. 28 GDPR); the customer, as controller, determines their legal basis.

When signing in and with every request, Google receives from us the credential, the property and the parameters of the query (period and breakdown by day, page or search query); we do not send any visitor or measurement data. The interface is provided by Google LLC in the US. This transfer is based on the European Commission’s adequacy decision for the US (EU-US Data Privacy Framework), under which Google LLC is certified. Here Google is the source of the data and the recipient of these requests, but does not thereby become our processor; separately, Google Cloud, on which we operate Metrunio, remains our processor.

We are responsible for the details of the connection. The legal basis is Art. 6(1)(b) GDPR where you yourself, as a natural person, are our contracting party and the processing is necessary for that. Where employees or agents of a customer, such as an agency, connect, it is based on Art. 6(1)(f) GDPR; our legitimate interest lies in an authorised and secure connection to the customer’s service. You may object under Art. 21 GDPR. Granting access at Google is not consent to this processing. If the person who connected loses their role or membership in the customer account, the connection remains until an Admin removes or reconnects it; the customer account’s admins see a notice about this.

If the connection is removed in Metrunio, we delete the refresh token and the chosen properties immediately; on request we also revoke access at Google. Access can also be revoked at Google at any time, at myaccount.google.com/permissions. The customer account’s log records connecting, choosing a property (with that property) and disconnecting, each with the time and the acting person; we delete these entries after 180 days, at the latest with the customer account.

Further data sources of our customers

Our customers can connect further services from which we retrieve costs and metrics on their behalf. To do so, they enter a key, a token or the address of a spreadsheet: for ad costs from TikTok, LinkedIn and Microsoft Advertising, for costs from releva.nz, for their newsletter metrics at Klaviyo or Brevo and for costs from a shared spreadsheet (Google Sheets or a CSV file). For Klaviyo, Brevo and releva.nz this applies only if these sources are activated for the customer account. Connecting is done by the Admin role, and for a spreadsheet also by the Analysis role.

From ad and cost sources we read cost, impressions and clicks per campaign or shop and day. From a spreadsheet we take only the intended columns into the evaluation: campaign, day, cost and, where present, currency, impressions, clicks and platform; further columns may be transferred temporarily when the file is retrieved. From Klaviyo and Brevo we read, for each campaign sent, its ID, its name, the send time, the campaign parameter `utm_campaign` and the number of recipients, deliveries and unique clicks; no opens, no email content and no details about individual recipients. Totals, campaign names and addresses can also relate to individual persons, for example with very small numbers; we therefore treat them like the other data we process on our customer’s behalf.

We use the costs like those from Google Ads and Meta: in the customer account’s reports, in exports, through the read API, in the data assistant and in email reports. We show the metrics from Klaviyo and Brevo only in the portal on the “Newsletter” page, next to the visits and conversions we measure ourselves; they are not included in exports, the read API, the data assistant or the analytics mirror.

We store the keys and tokens of these sources encrypted (AES-256-GCM) and bound to the customer account and their purpose, and likewise the address of a spreadsheet, because knowing it alone gives access to the spreadsheet. They are not logged and are not displayed in full in the portal: at most the last four characters are visible, and for a spreadsheet the host and the last four characters of the address.

When a connection is removed, we delete its key immediately, and for Klaviyo and Brevo the metrics retrieved as well. Costs from releva.nz, from a spreadsheet and from the other ad and cost sources remain, like all imported costs, for as long as the customer account exists and are deleted with it; when a spreadsheet is removed, its retrieval ends and we delete its address. Connecting, replacing the key and disconnecting a newsletter platform, and adding and removing a spreadsheet, are recorded with the time and the acting person in the customer account’s log, without the key and for a spreadsheet only with its host; we delete these entries after 180 days, at the latest with the customer account.

We are responsible for the details of the connection; as for the other account data, the legal basis is Art. 6(1)(b) or (f) GDPR (see below the table). We process the costs and metrics retrieved on our customer’s behalf (Art. 28 GDPR); the customer, as controller, determines their legal basis. The providers of these services are our customer’s providers and do not become our processors through the retrieval. This also applies to Brevo, which we use separately for our own newsletter (row “Newsletter” in the first table).

Connecting AI tools from other providers

If you connect an AI tool from another provider to your account via the consent page in the portal, for example Claude by Anthropic or ChatGPT by OpenAI, or if you create a read key, this tool or program receives a continuing read authorization for the account's measurement data. Within the authorization granted, the connected tool can request data for your analyses; it decides which requests to make as part of its own processes. Only the account's admins can grant access or create keys, and only after a notice explaining what the authorization means.

Available are metrics and breakdowns, including ad costs imported from Google Ads, Meta and other connected ad accounts, individual conversions with time, value and the order number in plain text, and pseudonymous customer journeys with identifier, times and channels. For subscriptions, renewals are flagged; only the read API with a read key returns the subscription ID in plain text, an AI tool connected via the consent page does not receive it. Metrics are aggregated; conclusions about individual transactions may nevertheless be possible. The connection does not return names, email addresses, IP addresses, browser identifiers, click identifiers of the ad platforms or the pages visited. Orders the shop reported without tracking consent are not returned as individual records; they are included in permitted metrics such as counts and revenue totals, and with small numbers conclusions about individual orders may be possible from them.

We release the measurement data of our customers' visitors and buyers as a processor on our customer's instruction; our customer, as the controller, determines the legal basis for this transfer. The provider of the tool is not our sub-processor. It processes the data it retrieves under the terms of the account our customer holds with it, possibly also outside the European Union. Our customer ensures the contract with the provider, any data processing agreement that is required and the conditions for transfers to third countries; our own obligations as a processor remain. We are the controller for the details of the authorization itself; they are listed in the table above.

The specific safeguards of our data assistant in the portal do not apply to this connection: order numbers and journey identifiers are not replaced by short codes, the limit on individual rows per question does not apply, and storage, training and deletion at the provider are governed by its terms, not those of Google Cloud for Vertex AI.

You can disconnect an authorization at any time in the portal under “Exports & AI connections”; you also revoke a read key there. From its next request on, the tool then receives no more data. Disconnecting does not delete data the tool has already retrieved at the provider; that depends on your contract with it.

Partners recommend Metrunio and receive a commission for it. From partners who are natural persons and from contact persons of a partner company we process name, address, email address for billing, tax number or VAT identification number, tax status and the date of the partner agreement, together with the net amount paid and the month of payment for each referred customer. The purpose is assigning referred customers to the partner, calculating the commission, issuing the self-billed credit note (section 14(2) UStG) and bookkeeping.

The legal basis is Art. 6(1)(b) GDPR (partner agreement); for contact persons of a partner company Art. 6(1)(f) GDPR (performing the partner agreement with the company; you may object under Art. 21 GDPR); for retention Art. 6(1)(c) GDPR in conjunction with section 147 AO and section 257 HGB. We keep credit notes as accounting records for eight years from the end of the calendar year; master data until the end of the partnership and beyond for as long as a credit note naming it must be kept. Recipients are our tax adviser and, for operations, the processors listed under “Recipients”.

If a customer registers with a partner’s referral code, we store with the account which partner it is assigned to and, for the commission, the amounts paid per month. The partner receives no breakdown by customer: their credit note states only the total and the number of customers for each commission rate. With small groups, for example where only one customer falls under a commission rate, conclusions about the amount of individual customers may be possible. The legal basis is Art. 6(1)(f) GDPR (settling the partner programme); the amounts per customer are kept as the basis of the credit note for as long as the credit note itself. We pay no commission for customers who already had an account with us in the twelve months before registering with a referral code. To check this, we compare the company name and email domain of the registration with existing accounts. For deleted accounts we keep, for twelve months from deletion, only a checksum formed with a secret key (HMAC) of the company name and of each email domain of the admins, excluding domains of general email providers and without plain text. The legal basis is Art. 6(1)(f) GDPR; our legitimate interest lies in protecting the partner programme against abuse. Without this link, we can assign you to the partner retroactively on the partner’s notice within 30 days of your registration; the partner then learns the same as with a registration via their link.

• Pseudonymous identifiers for session and device, where consent has been given. Before the decision in the consent banner the script keeps events only in the page’s memory; after consent it sends them with that consent, after a refusal or when the page is left it discards them.
• Campaign details from creatives and from the campaign parameters of the page visited, such as `utm_source`, `utm_medium`, `utm_campaign` and `utm_content`. If ad-level reporting is activated for our customer’s account, we assign a visit to the ad whose ID is in `utm_content`; this ID is the same for all clicks on the same ad. Individual click and impression identifiers, our own as well as the advertising platforms’ (such as gclid or fbclid), only with marketing consent; with consent to statistics only, all that remains is which platform a click came from.
• Event data such as page views, interactions and conversions with value and currency.
• We process IP addresses in transit and to limit requests and do not store them in the event data, not even as a checksum. Since 14 October 2026 we no longer form the truncated checksum previously stored there and have deleted existing values. Other technical attributes are stored truncated or hashed.
• No plain-text email addresses or phone numbers in analytics events. Events rejected on receipt (invalid format, a time outside the permitted window, or an email address or phone number in plain text) are not stored. For troubleshooting we record only the reason for rejection, time, source, website, event type and the names of the affected fields with the type and length of the value, no field contents and no identifiers. These details are deleted with our customer’s raw-data retention period (default 180 days).
• The consent state is stored and evaluated with every event. Without matching consent no advertising event is stored, not even in raw form; all that is recorded, without any identifier, is that an event was not stored for this reason.
• A view identifier for post-view: a cookie on our customer’s measurement address (`metrunio_view`, 30 days, for that address only). It is set only with marketing consent, by the impression pixel and viewability tag on the advertising site or by the measurement script in the shop; the browser returns it on a visit to the shop. If the browser drops it, nothing replaces it: no fingerprinting, no probabilistic matching. If the person withdraws marketing consent, the measurement address removes the cookie when the withdrawal is reported; if they withdraw consent entirely, the script also deletes the pseudonymous identifier and the session in the browser. Advertising contacts already recorded that are linked to that browser are deleted; any later consent starts without them.
• For orders a shop reports with consent, a pseudonymous customer identifier: the shop’s customer number or a checksum (SHA-256) of the email address, as transmitted by our Shopify app and our plugins for Shopware and WordPress. On receipt we combine each of these values with a key that differs for every customer and store only the result; the same person yields two different values at two customers. The identifier links purchases by the same person across devices and is not transmitted to any advertising platform.
• A redirect for clicks on creatives: our measurement address forwards to our customer’s website. Without a consent signal from the advertising site it appends only the campaign identifier to the target address (`metrunio_camp`, the same for all clicks of a campaign) and stores no click; all that is recorded, without any identifier, is that a click was not stored for this reason.
• If our customer runs its own measurement domain under its domain, we also store the pseudonymous visitor identifier as a cookie on that domain (`metrunio_aid`), only with consent to analytics. The cookie makes the same identifier readable on all subdomains of that domain, for example in the shop and in the checkout, and recognises a browser even after the site’s storage has been cleared. The purpose is to link visits and orders of the same browser. It lasts 13 months; Safari limits it to seven days. Withdrawing consent removes it.
• If our customer has switched on the post-purchase question, the page after the purchase asks how you became aware of the customer, with a fixed list of answers and no free text. The question is only asked with consent to analytics. We store the answer with the order number and the browser’s pseudonymous identifier and link it to the order and the visit history; it is therefore not an anonymous survey. It goes to no advertising platform and is deleted with the other events.
• If our customer has switched on source in forms, the script writes source details into hidden fields of its forms: an identifier of the enquiry, source, medium, campaign and advertising platform and, with marketing consent, also the click identifier. By default this only happens with consent to analytics; without it, the script writes nothing into forms and does not read the page address for this purpose either. For individual websites our customer can switch it on without consent; then only source, medium and campaign from the address of the page being viewed are taken over, and our customer must justify this setting itself. The fields go with your enquiry, that is together with name and email address, to our customer’s system, such as its CRM, not to us. There it can link your enquiry to its source and, if it later imports the deal into Metrunio, to the pseudonymous visit history. This happens on its instruction and under its responsibility; its system does not thereby become our sub-processor.
• For subscriptions, the subscription ID as the shop or payment provider assigns it, and whether a payment is a renewal; both are stated by the source, we do not guess them. We store the ID in plain text like the order number, but only for purchases with consent. A renewal with consent takes over the attribution of the first order of the same subscription on the same website; it is not sent to any advertising platform and does not count as a new customer. If the first order ceases to exist through erasure, objection, withdrawal or the expiry of its retention period, we recalculate its renewals immediately, and they remain unattributed. We return the subscription ID only in the conversions CSV export and through the read API. The portal shows only the renewal flag; the data assistant and an AI tool connected via the consent page likewise receive only this flag, the analytics mirror in BigQuery stores only the flag, and webhooks contain neither.

The legal basis for identifiers and events from the browser is the data subject’s consent under Art. 6(1)(a) GDPR and section 25(1) TDDDG. On our customer’s website their consent management platform obtains it. For advertising contacts on third-party websites the delivering ad server transmits the consent signal; we receive no separate proof of it. Where our customer uploads conversions from a file, they state for each row the source, time and a reference to proof of consent; we check these details for completeness and contradictions, not the consent itself. Without consent only what the following paragraphs describe takes place; the legal basis for it is determined by our customer as controller. The retention period is set by the customer within their plan; the default is 180 days for raw data.

A withdrawal in the consent banner applies to the browser in which it is declared. If the person withdraws only marketing consent, we delete that browser’s advertising events and the advertising contacts linked to it and remove click and impression identifiers from its remaining events; whatever rests on consent to statistics remains. If they withdraw entirely, we delete all events of that browser, including orders the shop reported with its identifier. Reports to advertising platforms not yet transmitted are stopped. Those already transmitted are held by the platform and we cannot recall them; we name the recipients to our customer so that they can meet their duty to inform them under Art. 19 GDPR. We store the consent state with the time of withdrawal against the browser’s pseudonymous identifier as proof that the withdrawal has been carried out and to reject later events from that browser; it remains as long as it is needed for the processing or for enforcing the withdrawal. A consent state is deleted once the browser has neither changed its decision nor visited the website for 13 months; we keep the state after a withdrawal as proof until the end of the third calendar year after the withdrawal. Both are deleted at the latest when our customer’s website or account is deleted. A withdrawal in the banner is not a request under Art. 15 to 21 GDPR: anyone seeking access, erasure of all data about them on all devices or an objection should address our customer, who implements it in the product’s privacy area.

Reach measurement for visits without consent can no longer be switched on since 29 September 2026. For websites where our customer switched it on before then: no personal or device identifier is stored where consent is missing. Each view creates an event with time, page without query string, page title, referring origin and campaign details, which is condensed into a count per day, website, channel and source. Neither the event nor the count contains an identifier through which an access or erasure request could find a person. The legal basis is determined by our customer as controller; we process on their instruction. Sources with fewer than five views appear pooled rather than individually, and events and counts expire on the same schedule as other raw data.

If our customer’s shop reports orders and refunds server-side without consent to tracking, we process them on the customer’s behalf solely for revenue reconciliation: matching their revenue, recognising duplicate transactions and assigning refunds. This purpose is separate from tracking. For it we store the order number as the necessary order key, the type of transaction (order, subscription renewal or refund), amount, currency and the day of the order without the time, but no browser, customer or advertising identifiers: pseudonymous visitor identifier, session, pseudonymous customer identifier, click identifier, IP attribute, page visited, campaign details, the subscription ID and items are removed before storage. The renewal flag shows payments from running subscriptions separately in the reconciled revenue; we do not derive a new-customer attribute from it. The data generally remains personal data because our customer can assign the order number to a person. The order is not linked to any visit or advertising contact and is not transmitted to any advertising platform; the only exception is set out in the next paragraph. This applies to orders for which the shop transmits no decision on consent because none was made. Where the shop transmits a refusal, we store the order to this extent only if our customer has given us a separate instruction for it; without that instruction we do not store it. Such an order is never linked to a visit. The legal basis is determined by our customer as controller; their legitimate interest in complete revenue figures may apply (Art. 6(1)(f) GDPR). Our customer is to inform about this processing, its legal basis and how to object in their own privacy notice. Refusing tracking is not in itself an objection to revenue reconciliation. Please address an objection under Art. 21 GDPR to our customer; if they implement it in the product’s privacy area, we delete the data relating to your order and block the order number for further transmissions. Withdrawing your consent to tracking means that orders transmitted with that consent are deleted; they are not transferred into revenue reconciliation.

Attribution via the checkout. It concerns only orders for which the shop transmitted no decision, never orders after a refusal, and only where our customer has switched it on separately. If you consented in the same checkout to tracking measurement whose scope includes linking orders to visits and advertising contacts, and that consent already existed at the time of purchase, we link the order to your visit on that basis. This happens in two steps. As soon as the order arrives, we create a short-lived matching record, even if no matching browser event follows later: a keyed checksum of the checkout identifier and the exact time of the order. This also covers orders that are never linked to a visit; the legal basis for this is determined by our customer as controller, its legitimate interest being a possible basis (Art. 6(1)(f) GDPR). The order is linked only in the second step and only with your consent. We use 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; we then delete them in regular operation. Backups are subject to their own periods; after a restore, expired matching data is no longer used and is deleted in the next maintenance run. If you withdraw your consent, we delete the link and the order.

Output to recipients our customer determines. On its instruction we transmit data to destinations it enters itself: webhooks to its own system with the order or lead identifier, value and time of individual orders, enquiries or refunds; summaries of reports and alerts to a Slack or Teams channel; exports and retrieval through the read interface or a connected tool. The recipients do not thereby become our sub-processors. If an erasure, objection or withdrawal concerns a message that has not yet been delivered, we no longer send it. We cannot recall data already delivered; we name the recipients to our customer so that it can meet its duty under Art. 19 GDPR. So that we can still name the recipients later, we keep for each delivery only the destination, the time and a checksum of the order or lead identifier, without content, for as long as the other raw data. Output without names or email addresses can still be personal data, and the same applies to the analytics mirror in BigQuery that we keep for all customers’ accounts in the same region and from which reports are calculated per account once data volumes are larger: order numbers and keys of records and visit histories can be linked back, and with small numbers even totals allow conclusions about individual persons.

Metrunio customers, such as agencies, can name people for a customer account who receive a report on that account as a PDF by email every month. We process the report recipients named by our customer solely on the respective customer’s behalf. Who is responsible for sending it and where your address comes from is stated in the message. Unsubscribing blocks further reports from this customer account. Only the block record this requires remains, for as long as this sending purpose exists.

The full information under Art. 14 GDPR is provided by the controller; the message refers to it. We store your email address, your name if given, the customer account, who added you and when, and a hash of the unsubscribe token. For the customer account we record who the controller is (the agency or its client), the link to the controller’s privacy notice and who entered both and when; the details in the message come from there. The sole purpose is sending the monthly report and honouring your unsubscription. The report contains only totals for the customer account, no individual orders and no visitor identifiers; with small numbers, totals too can allow conclusions about individual persons. We send it via Google Workspace, without tracking pixels and without tracked links.

You can unsubscribe through the link in every message. We then delete your entry immediately. For this customer account only a block record remains: a hash of your normalised email address formed with a secret key (HMAC) with the time of unsubscription, without the address itself, your name or the unsubscribe token. It prevents your address from being added there again; it does not block other customer accounts. We delete it as soon as this sending purpose ends: with the customer account or the agency’s account, as soon as the agency no longer manages the customer account, and 30 days after sending to named recipients has been switched off for the agency. Only your own wish lifts the block. For this, our customer can send you an invitation at most once every 30 days, valid for seven days; you receive reports again only once you confirm the invitation through the link in that email. While an invitation is open, the block record holds your address, your name if given, and a hash of the invitation token; afterwards we clear these details. Our customer cannot lift the block itself. If our customer removes you as a recipient before you unsubscribe, we delete your entry. Please direct your rights under Art. 15 to 21 GDPR to the controller; we support it in this.

The main processing takes place in the European Union: application, database, analytics mirror, the application logs and the language model behind the question feature in the portal run in region europe-west3 (Frankfurt). In each case the contracting party is a company established in the EU.

That alone would not be a complete answer. There are exceptions. Administration and system logs of the cloud platform are held in global logging buckets of the provider that cannot be moved to a region, for up to 400 days. For administration and support, group companies and service providers of our providers can access the systems from outside the EU; the basis is the European Commission’s adequacy decision for the USA (EU-US Data Privacy Framework) to the extent the recipient is certified under it, and in addition, and for companies that are not certified, the EU standard contractual clauses; the list states the basis for each recipient. You can obtain information and a copy of the relevant safeguards via privacy@metrunio.com. Tools and channels that our customer connects itself are run by their provider, where applicable outside the EU. Which recipient processes where, who the contracting party is, and what access is possible, is stated per entry in the list of further processors and in the overview “Service providers and recipients”.

We use service providers who run servers, deliver e-mail and process payments for us. The role in which they process is not the same everywhere — and that determines which contract applies and whose instructions they follow.

• Processors under Art. 28 GDPR: operation of the application, mailbox and e-mail delivery. They process solely on instruction.
• The payment provider in a dual role: for the contract data we pass on, it is a processor. For the payment itself it is an own controller — payment services law and anti-money-laundering law impose duties of its own, and whoever has duties of their own does not follow instructions in that respect.
• Advertising platforms are not processors. They receive something only if our customer switches on conversion pushback, and then process as own or joint controllers for their own purposes.

We pass nothing to advertising platforms unless our customer explicitly switches on conversion upload. Even then, for advertising attribution we send the platform’s click ID and, for each destination, the order or event identifiers described above for reporting and de-duplication; we do not send our own personal or device identifiers. What else is transmitted is described above under “Signing in with Google Ads and Meta”.

Documents for your review

• Access to the data processed about you (Art. 15 GDPR).
• Rectification of incorrect data (Art. 16 GDPR).
• Erasure (Art. 17 GDPR).
• Restriction of processing (Art. 18 GDPR).
• Data portability (Art. 20 GDPR).
• Objection to processing based on legitimate interests (Art. 21 GDPR).
• Withdrawal of consent with effect for the future (Art. 7(3) GDPR). This does not affect the lawfulness of processing up to the withdrawal.
• Complaint to a supervisory authority (Art. 77 GDPR).

If your request concerns measurement data from one of our customers’ websites, please address it to that customer — they are the controller there. We support them: the product has its own area for access, erasure and objection, and an erasure keeps working through a suppression list so the same identifier is not collected again a minute later.

• No fingerprinting through device characteristics.
• No probabilistic matching.
• No linking across account boundaries.
• No sale and no disclosure for our own advertising purposes.
• No permanent storage of raw IP addresses: to limit requests, they are held in memory for no more than ten minutes.

Changes to this statement appear in the changelog under Status.

Every version stays available under its date, permanently and unchanged; the confirmation email sent after a contract is concluded in the portal or through the Shopify app links to these addresses, and the portal keeps the agreed wording itself.

• Version of October 17, 2026 · current
• Version of October 16, 2026
• Version of October 15, 2026
• Version of October 14, 2026
• Version of October 13, 2026
• Version of October 12, 2026
• Version of October 11, 2026
• Version of October 10, 2026
• Version of October 7, 2026
• Version of October 4, 2026
• Version of October 3, 2026
• Version of October 2, 2026
• Version of October 1, 2026
• Version of September 30, 2026
• Version of September 26, 2026
• Version of September 25, 2026
• Version of September 24, 2026