Tikra legal texts

Pilot version. A lawyer has not reviewed this text yet. It applies to the pilot stores that accepted it.

This is an earlier version (2026-10-02-pilot). The current version is at https://tikratracking.com/legal/dpa.

Tikra Data Processing Agreement

Version 2026-10-02-pilot. Last updated 2 October 2026.

This Data Processing Agreement ("DPA") is made between:

1. the business that uses Tikra under the Tikra Terms of Service ("Merchant", "you"); and
2. MB Euruvizija, a small partnership (mažoji bendrija) registered in the Register of Legal Entities of the Republic of Lithuania, company code 307863521, registered office V. Nagevičiaus g. 3, LT-08237 Vilnius, Lithuania, e-mail support@tikratracking.com ("we", "us").

It forms part of the Terms of Service (the "Agreement") and takes effect when the Agreement does. You accept it together with the Terms, by ticking the box that refers to both in the Tikra dashboard, or by signing an order form that refers to it. The store owner or an admin of the store ticks the box; for a Shopify store, every staff account that can open the app in the Shopify admin counts as an admin (Terms, section 1.3). Until you accept, the Service stores nothing for your store: no orders, no pixel sessions, no store events and no copies of orders. We record which version you accepted, when, for which store and by which user (for an order form: the name or e-mail address of the person who signed it and the order form's reference); the record holds no IP address. You can save or print this DPA from its page. If you want a copy signed by us, write to support@tikratracking.com and we send one with the same content. Pilot and trial stores accept the same DPA. This is the pilot version: a lawyer has not reviewed it yet.

1. Scope and roles

1.1. This DPA applies to personal data of your customers and of the visitors of your store that we process to provide the Service ("Customer Personal Data"). Annex 1 describes it.

1.2. For Customer Personal Data you are the controller and we are your processor. For data about you and your staff (account, login, billing and support data) we are the controller. Our Privacy Policy covers that data, not this DPA.

1.3. "Data Protection Laws" means the laws that apply to the processing: Regulation (EU) 2016/679 ("GDPR"), the Law of the Republic of Lithuania on the Legal Protection of Personal Data, the UK GDPR and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection, and US state privacy laws such as the California Consumer Privacy Act as amended. Terms such as "controller", "processor", "personal data breach" and "data subject" have the meaning given in the GDPR.

1.4. Agencies and other representatives. If you accept the Agreement for a store you do not own, for example as an agency, you accept it in the name of the store owner and confirm that the store owner has authorised you to do so. The store owner is then the Merchant under the Agreement and this DPA, and the controller, and we are its processor. You act for the store owner and are not a party to this DPA for that store. If you did not have that authority, you are responsible to us for any loss this causes. If the store owner tells us that you were not authorised and does not accept the Agreement itself, we stop processing Customer Personal Data for that store and delete it under section 12, unless the store owner instructs us otherwise. For Shopify stores, the Merchant is always the owner of the Shopify store where the app is installed, also when a staff or collaborator account installs it. We send notices under this DPA to the store's contact addresses, which may include yours.

1.5. If this DPA and the Agreement conflict on the processing of personal data, this DPA prevails. If Standard Contractual Clauses apply under section 14 and conflict with this DPA, the Standard Contractual Clauses prevail.

2. Details of the processing

2.1. The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex 1.

3. Your instructions

3.1. We process Customer Personal Data only on your documented instructions. Your instructions are:

• the Agreement and this DPA;
• your settings in the Service: which platforms you connect, pause or disconnect, the store events each platform gets, the consent mode you choose, test destinations, and replays you start; and
• other written instructions that we accept in writing.

When you pause a platform, Shopify orders paid during the pause are recorded as not sent and are never sent later. On WooCommerce stores, orders paid in the last 24 hours before you resume a paused platform may still be sent after the resume.

3.2. Connecting a platform instructs us to send that platform the data listed for it in Annex 1, section F.2: for each eligible order, and, once that platform gets store events (Terms, section 3.8), for each store event the visitor's consent allows, except the store events you turn off for that platform. This includes the transfer this involves to the platform's country.

3.3. If the law of the EU or a Member State requires us to process Customer Personal Data in another way, we tell you before we do, unless that law forbids telling you.

3.4. We tell you at once if we think an instruction infringes Data Protection Laws. We may refuse to carry out that instruction until you confirm or change it.

4. Your responsibilities

4.1. You are responsible for the lawfulness of the processing you instruct. In particular you:

• have a legal basis for sending your customers' data to each platform you connect;
• tell your customers and visitors about the Service and the platforms in your privacy notice and cookie notice (Annex 1, section I lists what our pixel and plugin keep in the browser);
• collect and record consent where the law requires it, through Shopify's customer privacy settings or your consent tool;
• choose a consent mode (section 5) that is lawful for the markets you sell to;
• accept each platform's terms, including any data processing or controller terms the platform requires, and remain responsible for the platform's use of the data under your contract with it; and
• keep the store's checkout, theme scripts and consent tool working with the Service, and tell us before you change them.

4.2. Special categories of data. You must not use the Service for a store whose products or services mainly concern health, sex life or sexual orientation, such as a pharmacy, a shop for medicines, medical devices or health tests, or a sexual wellness shop. For such a store, a purchase event sent to an advertising platform can by itself reveal data concerning health, sex life or sexual orientation (Art. 9 GDPR), even without product names (CJEU C-21/23 Lindenapotheke; C-184/20 OT). If only some of your products concern these matters, you are responsible for assessing the legal basis before you connect a platform; for these data it will usually be the customer's explicit consent (Art. 9(2)(a) GDPR). Meta receives product IDs, quantities and prices, and Google Analytics 4 also receives product names and SKUs (Annex 1, F.2). We may suspend the Service for a store that breaches this section (Terms, section 12).

4.3. You keep a working contact e-mail address for notices under this DPA. For Shopify stores we use the shop owner's e-mail address from Shopify until you give us another one.

5. Consent handling

5.1. The Service applies the consent choices your customers and visitors make. It is a tool you use to meet your obligations. It does not decide for you which consent is legally required.

5.2. Shopify stores. Our web pixel runs in Shopify's pixel sandbox on your storefront and checkout pages.

• At checkout started, at payment information submitted and on the order confirmation page it runs for every visitor, so that a refusal reaches the Service as well as a consent. Without consent it sends only the store, the checkout token and the visitor's consent choices, and reads no cookie. From the checkout steps it never sends the page address.
• It reads the advertising click and cookie identifiers (Annex 1, F.1, row 11) only when the visitor allows marketing and has not opted out of the sale or sharing of data. It reads the Google Analytics identifiers (row 12) only when the visitor allows analytics: to find the _ga_<property> cookies it then reads the browser's cookie string and uses nothing else from it. Click IDs in the address of the page the visitor lands on are held in the page's memory until the visitor chooses; they are kept in the browser (Annex 1, section I) only if the visitor allows marketing on that page, and dropped otherwise.
• It sends store events (rows 20 to 26) only when the visitor allows marketing and has not opted out of the sale or sharing of data. Before the visitor makes a choice, events of the open page stay in the page's memory; they are sent once if the visitor allows marketing on that page, and dropped otherwise. Your consent mode (5.4) does not apply to store events: without a clear marketing consent nothing is sent.
• When the Service counts store events for the free diagnosis (Annex 1, note C), the pixel sends only the names of three events, and only when the visitor allows analytics.
• When a visitor withdraws marketing consent, the pixel deletes what it keeps in the browser (Annex 1, section I). On a store that uses our browser ID (section I), it also sends Shopify's browser ID of the visitor once more where the Service keeps click IDs under it (Annex 1, row 25), so that our server can delete them. While the Service keeps nothing there, that message is not needed; if a pixel still sends it, our server discards it and stores nothing.
• On the free diagnosis the pixel runs in the same way: with marketing consent it keeps the click IDs in the browser (Annex 1, section I) and reads the cookies of rows 11 and 12 at checkout started, at payment information submitted and on the order confirmation page. Our server stores nothing from the checkout steps and, from the order confirmation page, keeps only the consent decision and discards the identifiers (Annex 1, note B).

The server checks the same rules again before it stores or sends anything.

5.3. For each order the Service takes one consent decision and stores it with the order. All platforms and all later re-sends use that decision. Before the decision is taken, a later signal can only make it stricter: a stored refusal is never turned into consent.

5.4. You choose one of two consent modes for orders:

• Strict (the default): an order is sent to a platform only if the customer allowed that platform's category (marketing for advertising platforms and Klaviyo, analytics for Google Analytics 4).
• Standard: an order is sent to a platform unless the customer refused that platform's category. Customers whose order country is in the EEA, the United Kingdom or Switzerland are always handled under strict mode, whatever mode you choose.

In both modes, the order of a customer who opted out of the sale or sharing of data is not sent to advertising platforms or Klaviyo. Google Analytics 4 is not affected by that opt-out: it still receives the order when analytics is allowed, with the advertising consent signals (ad_user_data, ad_personalization) set to DENIED.

5.5. Orders the Service may not send because of consent are not sent. The dashboard shows them, with the reason, apart from the orders that were sent.

6. Confidentiality and personnel

6.1. We allow only persons who need access to provide the Service to process Customer Personal Data. They are bound by confidentiality obligations. Today this is the founder of MB Euruvizija.

6.2. We use AI-assisted engineering and operations sessions (Anthropic's Claude) to build and run the Service and to handle incidents. These sessions see pseudonymous order-level data through our admin tools: order IDs and numbers, payment times, amounts, consent decisions, delivery statuses and platform error texts, and store domains. They see no contact data, hashes, IP addresses or stored order copies, and they do not decrypt credentials. Error texts from Meta, and from Google Analytics 4 apart from the shortened IP address we send it (Annex 2, section 1), are stored as the platform returns them and can repeat values we sent to it. When our team does a setup you ordered, AI sessions do not open the pages of your store or platform accounts that show your customers' contact data. Anthropic is therefore our sub-processor (Annex 3). The sessions that can see this data run only under Anthropic's Commercial Terms of Service, which incorporate Anthropic's Data Processing Addendum and the Standard Contractual Clauses, and never under a consumer plan. Under those terms Anthropic may not train models on the data.

7. Security

7.1. We implement the technical and organisational measures in Annex 2. They take into account the state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks to your customers (Art. 32 GDPR).

7.2. We may change these measures if the change does not lower the overall level of protection.

8. Sub-processors

8.1. You give us general written authorisation to engage sub-processors. The sub-processors in use today are listed in Part A of our sub-processor page at https://tikratracking.com/legal/subprocessors. That list is Annex 3.

8.2. We engage each sub-processor under a written contract that imposes data protection obligations giving sufficient guarantees that the processing will meet the requirements of the GDPR, as required by Art. 28(4) GDPR.

8.3. We remain fully liable to you for the performance of each sub-processor's obligations.

8.4. We tell you at least 30 days before we add or replace a sub-processor in Part A, by e-mail to your contact address and by a notice in the dashboard. The notice names the sub-processor, its address, what it will do, where it will process the data and the transfer safeguards. You may object in writing within 15 days after the notice, on reasonable grounds relating to data protection. We answer within 10 days and look for a solution with you in good faith, for example a change in how the Service works for your store. Where we can, we keep the new sub-processor from processing your customers' data until we have agreed a solution. If we cannot agree one before the change applies, you may end the Agreement for the affected store with effect from the day before the change applies, and we refund the fees you prepaid for the period after that date. Fees billed through Shopify are refunded through Shopify.

8.5. The advertising and analytics platforms you connect, and Shopify, are not our sub-processors (sub-processor page, Part C). You choose them and contract with them directly.

8.6. Our sub-processors use their own sub-processors under their own terms, which include notice of changes. Their lists are linked in Part A. We pass on to you, without undue delay, the changes they notify to us that affect your customers' data.

9. Requests from your customers

9.1. We help you respond to requests from your customers to exercise their rights under Chapter III GDPR, by appropriate technical and organisational measures.

9.2. Shopify stores. Shopify sends us three privacy notifications, and the Service acts on them automatically:

• Customer data request: we collect what we hold about that customer (hashed identifiers, pseudonymous IDs, consent decisions, delivery records and the platforms that received the data) into an export and send it to you within 30 days of Shopify's notification.
• Customer erasure request: we remove the customer's identifiers from the order records, delete the customer's pixel sessions and delete the stored order copies at once.
• Store erasure request: see section 12.2.

We find a customer's records by the order IDs and customer ID in the notification, and by hashing the e-mail address and phone number it contains. We do not store those plaintext values. Store events leave little to find: the counts hold no identifiers, and the queue that carries the events keeps them at most 1 day (Annex 1, section J). Where the Service keeps a visitor's advertising click IDs under the hashed visitor ID (Annex 1, row 25), a customer erasure request deletes those of the customer's orders, and a customer data request includes them.

9.3. Other stores (WooCommerce and custom). Send requests to privacy@tikratracking.com. We act on them within 10 business days, so that you can answer your customer within the one month that Art. 12(3) GDPR allows. For an erasure request we delete the same data, in the same way, as for a Shopify customer erasure request (section 9.2).

9.4. If a customer contacts us directly, we forward the request to you without undue delay and do not answer it ourselves, except to say that we passed it on.

9.5. Data already sent to a platform is held by that platform under your contract with it. Requests about that data must be made to the platform. We tell you which platforms received data for the customer.

10. Other assistance

10.1. Taking into account the nature of the processing and the information available to us, we help you meet your obligations under Articles 32 to 36 GDPR: security, personal data breach notification, data protection impact assessments and prior consultation. We give you the information about the Service that you reasonably need for these tasks.

10.2. Assistance that the Service provides automatically, and the documents we publish, are free of charge. So is our assistance with a personal data breach on our side or on our sub-processors' side, and anything the law requires us to do free of charge. For other assistance, for example a data protection impact assessment written for you, or a second questionnaire in the same year (section 13.2), we may charge EUR 90 per hour. We give you a written estimate before we start, and we start only when you agree to it. Our charges will never be so high that they stop you from using your rights under this DPA.

11. Personal data breaches

11.1. We notify you of a personal data breach affecting Customer Personal Data without undue delay after we become aware of it, and in any case within 48 hours.

11.2. The notice describes, as far as we know them:

• the nature of the breach, the categories and approximate number of customers and records concerned;
• the name and contact details of our contact point;
• the likely consequences of the breach; and
• the measures we have taken or propose to take to address the breach and reduce its possible adverse effects.

If we do not have all this information at once, we provide it in phases without further undue delay.

11.3. We take reasonable steps to contain and investigate the breach and to reduce its effects, and we record the facts, effects and remedial action.

11.4. You decide whether to notify a supervisory authority and your customers. We do not notify them on your behalf unless you instruct us or the law requires it. When the breach concerns data from a Shopify store, our agreement with Shopify also requires us to inform Shopify.

11.5. Notifying a breach is not an admission of fault or liability.

12. Deletion and return

12.1. While you use the Service, we delete or reduce Customer Personal Data automatically on the schedule in Annex 1, section J.

12.2. Shopify stores, when you uninstall the app:

• at once: the Service stops receiving your orders and store events, our access tokens for your store are deleted, and we delete every record of your store: order records (IDs and numbers, amounts, items, consent decisions and the customers' identifiers), pixel sessions, stored order copies, delivery records including platform error texts, counts of store events, customer data request exports, settings, contacts and logins, your platform credentials and your store's encryption key. If the deletion is interrupted, an hourly job finishes it. Store events still in the queue are dropped without being sent;
• when Shopify sends the store erasure request (Shopify sends it 48 hours after uninstall): nothing of your store is left to delete. If the deletion has not finished by then, we delete the customers' identifiers, pixel sessions, stored order copies, your platform credentials and your store's encryption key at once, and the rest at the next hourly run.

If you install the app again before an interrupted deletion has finished, what has not been deleted yet stays with the new installation (the deletion removes the order and delivery records before the settings, contacts, logins, platform credentials and encryption key), and the records of your earlier orders (order records, delivery records, pixel sessions and stored order copies) are deleted at the next hourly run unless you accept the Terms and this DPA again before it. The same deletion runs at once when we remove a WooCommerce or custom store from the Service at your request.

We keep the audit log entries about your store for 24 months, and the records of privacy requests (type, dates and counts, no customer data: the order IDs a customer data request named are removed from its record and its audit log entry at the deletion) as evidence that we met our obligations.

12.3. Free diagnosis and the end of a subscription.

For each order paid while a Shopify store is on the free diagnosis (Terms, section 5.2), the Service keeps only a diagnosis record: the order ID and number, the checkout token that links it to the consent decision reported at checkout, the payment time, the amounts and currency, the test flag, whether the buyer's country is in the EEA, the United Kingdom or Switzerland, and the consent decision (Annex 1, note B). It keeps no contact data (hashed or plain), names, addresses, country, IP addresses, user agents, advertising or analytics identifiers, items or order payloads: the identifiers our pixel sends from the checkout steps and the order confirmation page are discarded, and only the click IDs the pixel keeps in the visitor's own browser with marketing consent remain there (Annex 1, section I). These records are never sent to a platform, also not after a plan starts, and they are deleted 30 days after payment. The free diagnosis may also count store events without any identifier (Annex 1, note C). Full processing under this DPA starts with a plan, for the orders paid from then on. A store that returns to the free diagnosis after a subscription keeps the records of the orders paid under it as Annex 1, section J provides (hashed identifiers removed 90 days after payment, the records without identifiers while the Service is installed); the Service sends none of the store's orders while it is on the free diagnosis; only checks with made-up data and no Customer Personal Data reach a Platform (the check when an access key is saved, a test the Customer sends, the hourly check of each key).

When a subscription ends without an uninstall (WooCommerce and custom stores, and Shopify stores that keep the app installed without a subscription after the trial), the Service stops sending at the end of the paid period. Orders are still received and stored under Annex 1, section J, and nothing is sent for them while no plan runs. For WooCommerce and custom stores we delete Customer Personal Data within 30 days after the Agreement ends.

12.4. Return: the source data of every order stays in your store platform. If you ask before the Agreement ends, we send you an export of the delivery records we hold for your store (order IDs, delivery status per platform, times and platform reference IDs), within 30 days. Otherwise we delete, and do not return, Customer Personal Data at the end of the Agreement.

12.5. Backups and database history:

• Encrypted backups of the database are kept for 20 days and then deleted.
• The database provider keeps a point-in-time history of the database for 30 days (Cloudflare D1 Time Travel). It cannot be switched off or shortened.
• We use backups and the history only to recover the Service after a failure. Before restored data is used, every uninstall, erasure and other change listed in Annex 1, section J that was made after the restored point is applied again from the restore journal, which is kept 28 days and holds only the IDs, hashes and settings values needed for that.
• When you uninstall the Shopify app, we delete your store's data at once (section 12.2), and we delete a customer's identifiers at once when we receive a customer erasure request (section 9.2).

As a result, every copy of erased data is gone within 30 days after the erasure, and for Shopify stores within 30 days after uninstall.

12.6. We keep Customer Personal Data after the end of the Agreement only where the law of the EU or a Member State requires us to.

12.7. On request we confirm the deletion in writing.

13. Information and audits

13.1. We make available to you the information necessary to demonstrate compliance with Art. 28 GDPR: this DPA and its annexes, our sub-processor page, a summary of our security checklist, and the audit reports and certifications our sub-processors publish (for example Cloudflare's SOC 2 and ISO 27001 reports, available from Cloudflare).

13.2. We answer one reasonable security or privacy questionnaire per year at no charge.

13.3. We allow for and contribute to audits, including inspections, by you or by an independent auditor you mandate. When you decide whether an audit is needed, you may take into account the information in 13.1 and 13.2. Audits:

• need at least 30 days' written notice, except where there are indications that we do not comply with this DPA, after a personal data breach, or at the request of a supervisory authority;
• take place at most once every 12 months, except in the cases just listed;
• are agreed with you in good faith as remote or on-site audits, and the final choice is yours;
• take place during business hours, without access to other customers' data or to security details beyond what the audit needs;
• are made by persons bound by confidentiality. We may object to an auditor who is our competitor, and you then choose another one; and
• are at your cost. If the audit shows that we materially breached this DPA, we pay the auditor's reasonable costs and fix the breach without delay.

We make the results of audits available to the competent supervisory authority on request.

14. International transfers

14.1. The Service stores Customer Personal Data in Cloudflare's EU jurisdiction: the production database and storage buckets were created with it. Two exceptions: the queue that carries store events for at most 1 day (Annex 1, row 20) may be processed outside that jurisdiction, and Cloudflare's request logs (7 days, Annex 1, section J) are stored in the United States, under the safeguards in 14.2.

14.2. Cloudflare, Inc. is based in the United States, and Cloudflare runs our code in data centres worldwide, usually the one nearest to the sender of each request. Transfers to Cloudflare are covered by Cloudflare's certification under the EU-U.S. Data Privacy Framework. Where that does not apply, they are covered by the Standard Contractual Clauses in Cloudflare's Data Processing Addendum (Module 3, processor to processor), with the UK Addendum and the Swiss amendments.

Our contract with Anthropic is with Anthropic Ireland, Limited, under Anthropic's Commercial Terms of Service. Anthropic also processes the data in the United States. Anthropic's Data Processing Addendum incorporates the Standard Contractual Clauses (Module 2 and Module 3). Where the clauses are needed for the data we process for you, Module 3 (processor to processor) applies. We keep a written transfer impact assessment for these transfers (clause 14 of the Standard Contractual Clauses). It relies on the European Commission's assessment of US law in the EU-U.S. Data Privacy Framework adequacy decision of 10 July 2023, because the US safeguards assessed there apply to all transfers to the United States, whatever the transfer tool.

14.3. Transfers to the platforms you connect are made on your instruction (section 3.2). You are responsible for the transfer mechanism under your contract with each platform.

14.4. If you are established outside the EEA:

• Sending your customers' data to us in the EU is governed by your local law. UK law and Swiss law treat the EU member states as providing adequate protection.
• When we make your customers' data available to you, for example in the dashboard, in exports and in our notices, the data leaves the EEA. If your country has no EU adequacy decision, the Standard Contractual Clauses of Commission Implementing Decision (EU) 2021/914, Module 4 (processor to controller), apply to this transfer and form part of this DPA. We are the data exporter and you are the data importer. Clause 7 does not apply. Under clause 17 the clauses are governed by the law of the Republic of Lithuania, and under clause 18 disputes are resolved by the courts of the Republic of Lithuania. Annex 1 of this DPA describes the transfer.
• Sending your customers' data to the platforms you connect is covered by section 14.3.

15. US state privacy laws

15.1. Where the California Consumer Privacy Act or another US state privacy law applies, we act as your service provider or processor. You disclose Customer Personal Data to us only for these business purposes: (a) receiving your paid orders, checkout signals and store events; (b) applying your customers' consent and opt-out choices; (c) sending purchase events and store events to the platforms you connect, on your instruction; (d) monitoring delivery and re-sending missed orders; (e) showing you, per order, what was sent and why; (f) counting orders for your plan and store events for your platforms; and (g) keeping the Service secure and fixing errors. We: do not sell or share Customer Personal Data (when the Service sends data to an advertising platform you connect, it does so on your instruction, and that disclosure is your sale or sharing to that platform under that law); do not retain, use or disclose it for any purpose other than the business purposes above, including any other commercial purpose, or outside our direct business relationship with you; do not combine it with personal information we receive from others or collect ourselves, except as that law permits; comply with that law and give Customer Personal Data the same level of privacy protection it requires of you, including reasonable security (Annex 2) and help with consumer requests (section 9); bind any subcontractor that processes Customer Personal Data by a written contract with the same obligations (section 8); and tell you if we decide that we can no longer meet these obligations.

15.2. You may take reasonable and appropriate steps to make sure that we use Customer Personal Data in line with your obligations under that law, including the questionnaire and audits in section 13, at least once every 12 months. After notice to us, you may take reasonable and appropriate steps to stop and remedy unauthorised use.

15.3. Opt-outs of the sale or sharing of data that your customers make through Shopify's customer privacy settings stop the Service from sending their orders and store events to advertising platforms and Klaviyo, and Google Analytics 4 then receives the advertising consent signals as DENIED (section 5.4). Our WooCommerce plugin reads the consent tool's marketing and statistics choices. It does not read an opt-out of the sale or sharing of data or the Global Privacy Control signal, so on WooCommerce stores in standard mode such an opt-out does not stop the Service.

15.4. To the extent that, when we send data to advertising platforms, we are a third party and not a service provider under that law, we also: use the data only for the purposes in 15.1; comply with that law and give the data the same level of privacy protection it requires; honour the opt-outs that reach the Service or that you forward to us; allow you to take the steps in 15.2; and tell you if we can no longer meet these obligations.

16. Liability

16.1. Each party's liability under this DPA is subject to the limits in the Agreement (Terms, section 17), including the minimum amount in section 17.1 and the exceptions in section 17.3 (intent, gross negligence, injury to health, loss of life and non-pecuniary damage).

16.2. These limits apply only between you and us. They do not limit the rights of your customers or other data subjects under Art. 82 GDPR.

16.3. We are liable for damage caused by processing only where we did not comply with the obligations of the GDPR directed specifically to processors, or acted outside or against your lawful instructions (Art. 82(2) GDPR). If one of us has paid full compensation to a data subject, it may claim back from the other the part that corresponds to the other's share of responsibility for the damage (Art. 82(5) GDPR).

16.4. Each party bears the administrative fines imposed on it.

17. Term

17.1. This DPA applies for as long as we process Customer Personal Data for you, including the deletion periods in section 12. Sections 11, 12 and 16 survive its end.

18. Governing law and jurisdiction

18.1. This DPA is governed by the law of the Republic of Lithuania. The courts of the Republic of Lithuania in Vilnius have exclusive jurisdiction, except where Standard Contractual Clauses that apply under section 14 require otherwise.

19. Changes

19.1. Each version of this DPA has a version name and a date at the top. Earlier published versions stay readable at https://tikratracking.com/legal/dpa followed by a slash and the version name.

19.2. We tell you about a proposed change to this DPA at least 30 days before it is to apply, by e-mail and in the dashboard. It applies to you only once you accept it; until then the version you accepted continues to apply. If a change is needed for us to comply with the law or to keep providing the Service and you have not accepted it within 30 days, we may end the Agreement for your store under section 13.3(a) of the Terms and refund the fees you prepaid for the period after that date. Changes of sub-processors follow section 8.4, and changes to Annex 2 follow section 7.2.

19.3. Features that process data this version does not describe are not switched on for your store until you accept a version that describes them.

Annex 1. Description of the processing

A. Subject matter

Server-side conversion tracking for your online store: receiving your paid orders and the related checkout signals, deciding per order and platform whether the customer's consent allows sending, sending a purchase event to each advertising and analytics platform you connect, monitoring delivery, re-sending missed orders, and showing you per order what was sent and why. For Shopify stores also: receiving the store events of visitors who allow marketing (page views, product views, add to cart, checkout started and payment information submitted), counting them, and sending them to the platforms you connect once a platform gets them (Terms, section 3.8).

B. Duration

The term of the Agreement plus the deletion periods in section 12 and section J below.

C. Nature of the processing

Collection (from Shopify webhooks and the Shopify Admin API, from our WooCommerce plugin, and from our web pixel on your storefront and checkout pages), normalisation, hashing, encryption, storage, matching of each order with its checkout session, consent evaluation, counting, transmission to platforms, retries and re-sending, reconciliation and reporting to you, handling of privacy requests, backup, and deletion. For the free diagnosis the Service also reads, in memory only, the landing pages of the customer journey Shopify keeps for up to 250 recent orders, to count the orders that came from an advertising click; the landing page addresses and anything in them are not stored, and only the counts are kept. With a plan, when a purchase of a customer who allowed marketing reaches us without an advertising click ID from our pixel, the Service reads, in memory only, the landing pages of the first and last visits of that order's customer journey that Shopify keeps, and sends the click ID found there with that purchase (row 11); these addresses are not stored.

D. Purposes

1. Reporting your paid online orders (orders placed through your store's checkout; Terms, section 2) as purchase conversions to the platforms you connect, so those platforms can measure and attribute your advertising. To link each order to the consent choices and identifiers of its checkout, the Service records them already when the checkout starts and keeps them only a short time if no order is placed (section J).
2. Reporting store events to the platforms you connect, so those platforms can measure, attribute and optimise your advertising, once a platform gets them (Terms, section 3.8).
3. Proving for each order what was sent to each platform, when, and with what result, or why it was not sent.
4. Detecting and correcting delivery failures (hourly checks, re-sending, incident handling under the service guarantee), and comparing our counts of store events with the platforms' own counts.
5. Counting orders for your plan's order limit, and counting store events (counts only).

We do not use Customer Personal Data for any other purpose. We do not sell it, build profiles from it or combine data across merchants.

E. Data subjects

Your customers who place orders in your store, including guest buyers, and the persons whose data appears in those orders. On Shopify stores also the visitors of your storefront and checkout who allow marketing (store events). On Shopify stores also the visitors who start a checkout: their consent choices, and the identifiers their choices allow, kept at most 7 days when no order is placed (row 15, section J).

F.1. Types of personal data and how they are stored

Note A. WooCommerce stores in standard mode: when the buyer gave no consent signal at all and the order country is outside the EEA, the United Kingdom and Switzerland, rows 10 to 14 are also collected without consent, because standard mode sends unless the customer refused (section 5.4). The WooCommerce plugin does not read opt-outs of the sale or sharing of data (section 15.3). The Shopify web pixel collects rows 10 to 14 only with consent, in both modes. Rows 20 to 26 exist only for Shopify stores.

Note B. Orders paid while a store is on the free diagnosis (section 12.3): per order only the order ID and number, the checkout token, the payment time, total, subtotal, tax, shipping, currency and the test flag (row 16 without items), whether the buyer's country is in the EEA, the United Kingdom or Switzerland (in place of row 6), and the consent flags and signal of row 15. Rows 1 to 5, 7 to 14 and 18 are not stored: the order is not kept as received, and from the web pixel request our server keeps the consent decision only and discards the identifiers it carries (the pixel itself runs as section I describes). Nothing is sent to a platform (row 17).

Note C. Free diagnosis count: while a Shopify store is on the free diagnosis or has no running plan, the Service may count the add to cart, checkout started and payment information events of visitors who allow analytics. Our pixel then sends only the event names; the Service keeps only daily counts (row 26), with no ID, IP address or user agent, and sends nothing.

Note D. Orders that are not online orders (Terms, section 2), for example sales at a point of sale: per order only the order ID and number, the payment time, total, subtotal, tax, shipping, currency, the test flag and where the order came from (row 16 without the checkout token and items). Rows 1 to 6, 8, 9, 13 and 18 are not stored, and the order is not linked to a pixel session (rows 10 to 12, 14 and 15): a pixel session stored under the order's checkout token before the order arrived is deleted when it arrives. For a WooCommerce order only, the checkout token of row 16 (the hashed order key, no customer data) is kept, for two uses: a later request from the plugin's order confirmation page stores nothing, and an erasure or access request (section 8) reaches the same key as for any order. Nothing is sent to a platform; each platform gets a final record that the order was not sent (row 17). On the free diagnosis, the record of such an order (note B) keeps no checkout token, no EEA flag and no consent decision either. Such orders stored before this rule took effect were brought to the same form on the day it took effect; their copies are deleted within 30 days like any copy.

Row 18 is the minimal copy since 2026-09-28. Copies stored before then hold the whole order as received and are deleted within 30 days like any copy.

F.2. Data sent to each platform you connect

This table lists the platforms you can connect today. When we add a platform, we add it to this table before it appears in the dashboard, and no data reaches it until you connect it. Test orders are never sent to live platform accounts.

A store that connected another platform before this version keeps it until it disconnects it; for such a store the data that platform receives is the one listed in our sub-processor page, Part C, "Platforms connected earlier".

G. Special categories of data

None intended. See section 4.2.

H. Frequency

Continuous, for every paid order and every store event of your store from your acceptance of this DPA while the Service is installed. For orders paid on the free diagnosis, only the diagnosis record of note B, and store events only as the counts of note C. For orders that are not online orders, only the record of note D.

I. Storage on your customers' devices

On Shopify stores, our web pixel runs inside Shopify's pixel sandbox and sets no cookies. With the visitor's consent it reads these existing cookies at checkout started, at payment information submitted and on the order confirmation page: _fbp, _fbc, _gcl_aw, _ttp, _epik and _scid (marketing consent), _ga and _ga_<property> (analytics consent; to find the _ga_<property> cookies it reads the browser's cookie string and uses nothing else from it). With store events (rows 20 to 26) it reads _fbp and _fbc (marketing consent). With marketing consent it keeps in the browser's storage:

Browser storage has no expiry of its own, so the pixel applies these times when it reads a key: tikra_clicks is removed when the pixel reads it (at the next advertising click, at checkout, and on every page of a store that gets store events) and finds every click past 90 days; tikra_fbp is replaced when the pixel needs a browser ID (the store uses our browser ID and the visitor has no valid _fbp) and finds it past 90 days, and otherwise stays until the next page that opens without marketing consent; tikra_ic is written back without entries past 24 hours at the visitor's next checkout step. The pixel deletes all three keys when the visitor withdraws marketing consent and when a page opens without marketing consent (for example after a Global Privacy Control opt-out). On the free diagnosis the pixel keeps tikra_clicks and reads the cookies above in the same way, and our server then keeps only the consent decision (note B); when the Service counts store events for the free diagnosis (note C), those count messages carry no identifier and read no cookie or storage.

On WooCommerce stores, our plugin script (tikra-woo.js) sets first-party cookies on the store's own domain:

• _tikra_gclid, _tikra_gbraid, _tikra_wbraid (Google click IDs), _tikra_ttclid (TikTok), _tikra_epik (Pinterest), _tikra_sccid (Snapchat) and _tikra_fbc (Meta click ID in Meta's fbc format): the advertising click ID from the landing page URL, kept 90 days. They are set when the consent tool reports marketing consent, and in standard mode also when the store has no supported consent tool at all, for every visitor, including visitors from the EEA, the United Kingdom and Switzerland (the server then drops the IDs of buyers from those countries unless they consented). They are deleted when the visitor refuses marketing.
• _tikra_consent: a copy of the consent tool's marketing and statistics choices, kept 180 days, so the plugin can read them at checkout. Set only when a supported consent tool reports a choice.

With the matching consent (or in standard mode without a consent tool) the plugin also reads _fbp, _fbc, _gcl_aw, _epik, _ga and _ga_<stream>.

Include this in your cookie notice.

J. Retention schedule

Daily jobs apply these periods, so an item can remain up to about one day after its period ends.

Annex 2. Technical and organisational measures

This annex describes the measures in place on the date of this version. Measures that are not in place yet are named as such.

1. Minimisation and pseudonymisation

• E-mail addresses, phone numbers, names, cities, regions, postal codes and customer IDs are normalised and hashed with SHA-256 in memory as each order arrives. The database stores only the hashes, apart from the plain postal code and country code that Google requires.
• Checkout e-mail addresses and phone numbers of store events, and the visitor and customer IDs sent with them, are hashed when our server receives them. Plain values are never queued, stored or logged. Store events are not stored as such: only daily counts are.
• IP addresses from orders are stored only encrypted. IP addresses from pixel requests are shortened before storage in our database. IP addresses of store events are encrypted while they wait in the queue and are never stored. Apart from this, our hosting provider's request logs keep the full IP address of each request to our servers for 7 days (Annex 1, section J).
• The copy of each order kept for re-sending holds no names, addresses, contact data, IP addresses or user agents. Only for a store with Klaviyo connected (no longer offered) it holds the customer's e-mail address, phone number and first name, encrypted with the store's own key.
• Click, cookie and analytics identifiers are stored only for the consent category the customer allowed. Exception: WooCommerce stores in standard mode, for buyers outside the EEA, the United Kingdom and Switzerland who gave no consent signal (Annex 1, note A).
• Identifiers go to a platform only when they are well-formed. Google Ads never receives the IP address of customers in the EEA, the UK or Switzerland. Google Analytics 4 receives an IP address only shortened (the first three parts of an IPv4 address, the first 48 bits of an IPv6 address), never in full, and no user agent.
• Error texts from Google Ads, TikTok, Pinterest, Snapchat and Klaviyo are cleaned of the IP addresses, postal codes, e-mail addresses, phone numbers and access keys we sent before they are stored. Error texts from Google Analytics 4 are cleaned of the shortened IP address we sent. Error texts from Meta are not cleaned yet.
• The dashboard and our admin tools report identifiers only as present or absent. They never display hashes, contact data, checkout tokens or IP addresses.
• Test orders never reach live platform accounts, and test destinations never receive live orders.
• Our server accepts store events only from stores that accepted this DPA, from the store's own web addresses, and within limits per store and per visitor, and it drops traffic from known bots and data centres. Checkout e-mail addresses and phone numbers are accepted from one visitor at most 10 times a minute.

2. Encryption

• In transit: all traffic to and from the Service uses HTTPS (TLS). All calls to platforms, Shopify, Stripe and Resend use HTTPS.
• At rest (provider): Cloudflare encrypts the database (D1) and object storage (R2) with AES-256-GCM.
• At rest (application): each store has its own data key (AES-256-GCM). It encrypts the store's platform credentials, Shopify and WooCommerce access tokens, webhook secrets and customers' IP addresses. The data keys are themselves encrypted with a master key held as a Cloudflare Worker secret. Deleting a store's key row makes all of that store's encrypted values in the live database unreadable. If a backup is restored, the restore journal deletes the key row again.
• Backups: every night the database is exported, compressed and encrypted with AES-256-GCM under a backup key that is separate from the master key. The manifest of each backup is signed (HMAC-SHA256), and every part is read back and checked before the backup counts.

3. Access control

• Our admin interface requires both a secret admin key and a Cloudflare Access login, verified on every request (RS256 token, audience, issuer, expiry). In staging and production it refuses all requests if Cloudflare Access is not configured. Production runs as its own environment, with its own database, storage, queues and keys.
• Merchants inside Shopify are authenticated with Shopify session tokens, verified on every request (signature, audience, expiry, issuing store).
• Merchants outside Shopify sign in with a single-use e-mail link valid for 15 minutes. Sessions last 30 days, are stored server-side and end at once on logout or when the user is removed. Cookies are Secure, HttpOnly, SameSite=Lax and host-only. Requests that change data must come from our own origin.
• Each merchant sees only its own store's data. Viewer accounts are read-only.
• Sign-in requests are rate-limited per e-mail address and per IP address, and answer the same way for known and unknown addresses.
• Only the founder holds production credentials. Secret values are kept in a password manager and entered by him. AI operator sessions see only the pseudonymous order-level data our admin tools return, never contact data, hashes, IP addresses or stored order copies (section 6.2).

4. Integrity and authenticity

• Shopify webhooks, Shopify app requests and OAuth callbacks are verified by HMAC-SHA256 with the app secret. Invalid requests are refused.
• WooCommerce orders are signed by the store's own secret with a timestamp. Stale or reused signatures are refused.
• Stripe notifications are verified by signature with a 5-minute tolerance.
• Each Shopify notification is processed once. Each order is sent to each platform once, protected by an atomic claim in the database. A re-send of an already delivered order needs an explicit override. A store event is sent at most once: after an unclear answer from the platform it is not sent again.

5. Availability and resilience

• Orders are queued. Failed sends are retried up to 12 times with growing delays (1 minute at first, at most 12 hours between attempts); after that they go to a dead-letter queue and stay visible.
• Every hour the Service reads recent paid orders from Shopify's Admin API and processes any order whose webhook did not arrive.
• Every hour it compares expected and delivered orders per platform over the previous 24 hours, re-queues missing ones and, when at least 10 orders were expected, opens an incident below 97 %.
• Every hour it checks that each platform key still works, where the platform offers a check that records nothing.
• Nightly encrypted backups (20 days) and Cloudflare's 30-day point-in-time history. Restores are tested by automated tests. A monthly restore drill in an isolated environment is not in place yet.

6. Logging and monitoring

• An audit log records every admin request (who, what, which store, IP address, time), every settings change by merchants (never secret values), installs, uninstalls, privacy requests, purges and billing actions. Entries are kept 24 months. The log is kept in the Service's own database and is not yet protected against changes by the application.
• Failures of scheduled jobs and delivery incidents raise alerts to the on-call person.

7. Deletion

• Daily jobs apply the retention schedule in Annex 1, section J.
• A store's records are deleted by the uninstall itself; an hourly job finishes a deletion that was interrupted (section 12.2).
• Shopify privacy notifications are handled automatically (section 9.2).

8. Secure development

• Every module has automated tests, including tests that check no plaintext contact data reaches the database. Each module is reviewed twice before it is merged.
• Platform API versions are pinned and checked against the platforms' published documentation.
• The Service has one runtime dependency (the Hono web framework).

9. Organisation

• Written incident response plan with 48-hour notice to merchants.
• Two-factor authentication on the accounts that give access to production or to customer data.

Annex 3. Sub-processors

Part A of our sub-processor page (https://tikratracking.com/legal/subprocessors) as published on the date of acceptance. Today: Cloudflare, Inc. (hosting, database, queues, storage) and Anthropic Ireland, Limited, with Anthropic, PBC (AI-assisted operator sessions, section 6.2).

MB Euruvizija, company code 307863521, V. Nagevičiaus g. 3, LT-08237 Vilnius, Lithuania. support@tikratracking.com