Data Processing Agreement

How LinkTrail processes personal data on your behalf — your instructions, our security measures, our sub-processors, international transfers, and what happens to the data when you leave.

Last updated: 29 July 2026 · effective on acceptance of the Terms of Service.

Change notice

This DPA corrects material inaccuracies in the version previously published. Section 9 and Annex I previously described probabilistic matching as comparing "IP address and platform only" and stated that screen dimensions, timezone, language and locale were "not collected anywhere in the Service." That was wrong: the Service compares the full signal set now described in section 9.1. Annex I and Annex II also stated that server and request logs contain no IP addresses, and that backups expire after 7 days. Both were wrong and are corrected below. Customers who accepted the earlier version are being notified separately.

In plain language

When you use LinkTrail, we handle personal data about the people who click your links and install your apps. You decide why that data is collected; we only do what you tell us. This agreement is the legally required contract covering that arrangement — it sets out what we do with the data, who helps us do it, how we protect it, how we help you answer your users' requests, what happens if something goes wrong, and what happens to the data when you leave. It applies automatically to every customer; you don't need to sign a separate copy, though we will sign one on request.

Section 9 is the part to read closely. Our attribution uses device fingerprinting, and that has legal and app-store consequences you need to decide about.

1. This agreement and who it binds

1.1. This Data Processing Agreement ("DPA") is between LinkTrail Ltd, a company registered in England and Wales (company number 17312947) with its registered office at 66 Paul Street, London, EC2A 4NA, United Kingdom ("LinkTrail", "we", "us") and the customer that accepts the Terms of Service ("you", "Customer").

1.2. This DPA forms part of, and is incorporated into, the LinkTrail Terms of Service (the "Agreement"). It applies whenever we process Customer Personal Data on your behalf.

1.3. If this DPA conflicts with the Agreement on the processing of personal data, this DPA prevails. If this DPA conflicts with the Standard Contractual Clauses or the UK Addendum, those prevail.

1.4. This DPA applies automatically and requires no separate signature. If your procurement process requires a signed copy, email legal@linktrail.io and we will execute one on these terms.

2. Definitions

"Data Protection Law" means, as applicable: the UK GDPR and the Data Protection Act 2018; Regulation (EU) 2016/679 ("EU GDPR"); the Privacy and Electronic Communications Regulations 2003 ("PECR") and national implementations of Directive 2002/58/EC; and any other data protection law applicable to a party's processing under this DPA.

"Customer Personal Data" means personal data that we process on your behalf through the Service — principally data about the end users of your apps and links, as described in Annex I.

"End User" means an individual who clicks a link you create or uses an app in which you have integrated our SDK.

"Sub-processor" means a third party engaged by us to process Customer Personal Data.

"Personal Data Breach", "controller", "processor", "data subject", "processing", and "supervisory authority" have the meanings given in the UK GDPR.

"SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914.

"UK Addendum" means the ICO's International Data Transfer Addendum to the EU SCCs, version B1.0.

Terms defined in the Agreement have the same meaning here.

3. Roles of the parties

3.1. You are the controller; we are the processor. For Customer Personal Data, you determine the purposes and means of processing and we process only on your instructions. Where you are yourself a processor for another controller, we are a sub-processor and your instructions must be consistent with that controller's.

3.2. We are a controller for our own data. We act as an independent controller for your account, billing, support, and marketing data — the data about *you*, not your end users. That processing is governed by our Privacy Policy, not this DPA.

3.3. We are also a controller for Service improvement. As disclosed in section 7.3 of the Agreement, we act as a controller when we use End User data to develop and improve fraud detection and to produce aggregated statistics, as set out in section 11 below.

3.4. Your responsibilities as controller. You warrant that: you have a valid lawful basis for the processing you instruct; you have given End Users the transparency information Data Protection Law requires; and you have obtained any consent required under PECR or Article 5(3) ePrivacy before the relevant data is collected. We rely on these warranties, and section 9 explains why they matter technically and commercially.

4. Scope and instructions

4.1. Documented instructions. We process Customer Personal Data only on your documented instructions, which comprise: this DPA, the Agreement, the configuration choices you make in the dashboard and API (including which attribution methods and integrations you enable), and any further written instructions you give.

4.2. Subject matter, duration, nature, purpose, data categories, and data subjects are described in Annex I, as Article 28(3) requires.

4.3. Unlawful instructions. We will tell you if, in our opinion, an instruction infringes Data Protection Law. We may suspend processing of the affected instruction until it is withdrawn or amended.

4.4. Legally required processing. If law requires us to process Customer Personal Data other than on your instructions, we will tell you first unless that law prohibits it on important grounds of public interest.

4.5. Restricted data. You must not submit through the Service, including in custom deep link payloads: special category data (Article 9), criminal offence data (Article 10), or data relating to children. The Service is not designed for those categories and our security measures are not calibrated to them.

4.6. Children. You must not integrate our SDKs or use our link endpoints in apps directed to children under 16, or under the age of digital consent applicable in the End User's country where that is lower, without our prior written agreement. Where we agree, you are responsible for establishing a lawful basis before sending us data about children and for configuring the Service accordingly, including disabling probabilistic matching.

5. Confidentiality

5.1. We keep Customer Personal Data confidential and ensure that everyone we authorise to process it is bound by an appropriate duty of confidentiality that survives the end of their engagement.

5.2. We limit access to personnel who need it to provide the Service or to meet a legal obligation.

6. Security

6.1. We implement appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, taking account of the state of the art, implementation costs, and the nature and risk of the processing (Article 32).

6.2. Our current measures are described in Annex II.

6.3. We may update our measures over time, provided the level of protection is not materially reduced.

7. Sub-processors

7.1. General authorisation. You give us general authorisation to engage Sub-processors on the terms in this section.

7.2. Current Sub-processors are listed in Annex III. That annex names only the Sub-processors that process Customer Personal Data. Other vendors we use — such as our payment processor and email providers — handle data for which we are the controller and are disclosed in our Privacy Policy instead.

7.3. Flow-down. We impose on each Sub-processor data protection obligations no less protective than those in this DPA, by written contract. We remain fully liable to you for a Sub-processor's performance of its data protection obligations.

7.4. Changes and objection. We will give you at least 30 days' notice before adding or replacing a Sub-processor, by email to your account address and by updating Annex III. If you reasonably object on data protection grounds within that period, we will work with you in good faith to find a solution. If we cannot, you may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees for the unused period, as your exclusive remedy.

7.5. Customer-configured integrations are not Sub-processors. When you connect a third-party service (for example an ad network or analytics tool) and instruct us to send data to it, that third party receives the data on *your* instructions and is your processor, sub-processor, or independent controller — not ours. You are responsible for the legal basis for that transfer and for your relationship with that third party. Annex III does not list them.

8. International transfers

8.1. Where data is processed. Customer Personal Data is hosted in the European Union. We do not operate a US region. Annex III gives each Sub-processor's processing location.

8.2. Onward access from outside the UK/EEA. Some Sub-processors are established outside the UK and EEA or provide support and engineering access from outside those areas, even where the data is stored in the EU. Where that results in a restricted transfer, it is made under an approved mechanism: the EU SCCs for transfers subject to EU GDPR and the UK Addendum for transfers subject to UK GDPR, in each case supported by a transfer risk assessment and any additional measures required.

8.3. Transfers between you and us. Where your provision of Customer Personal Data to us, or our return of it to you, constitutes a restricted transfer, the parties agree that the SCCs (Module Two: controller to processor, or Module Three: processor to processor where you act as a processor) and the UK Addendum apply, and are incorporated into this DPA by reference, with:

  • the data exporter being you and the data importer being us;
  • Annex I of this DPA completing Annex I to the SCCs;
  • Annex II of this DPA completing Annex II to the SCCs;
  • Annex III of this DPA completing Annex III to the SCCs;
  • Clause 7 (docking) applying; Clause 9 option 2 (general written authorisation) applying with the notice period in section 7.4; Clause 11 optional redress not applying; Clause 17 governed by the law of Ireland; and Clause 18(b) courts of Ireland — with the UK Addendum applying the law and courts of England and Wales for UK transfers.

*For clarity: the reference to Ireland is not an error and does not conflict with section 15.4. Clause 17 of the SCCs requires the law of an EU member state, so Irish law is specified for SCC purposes only. This DPA as a whole remains governed by the law of England and Wales.*

8.4. Government access requests. If we receive a legally binding request from a public authority for Customer Personal Data, we will notify you unless legally prohibited, challenge requests that appear unlawful or overbroad, and disclose only the minimum required.

8.5. EU representative. A representative under Article 27 EU GDPR has been engaged and we are awaiting confirmation of the appointment. Their name and address will be published here and in our Privacy Policy once confirmed. In the meantime, EEA data subjects and supervisory authorities can contact us at privacy@linktrail.io.

9. Fingerprinting and attribution methods — allocation of responsibility

This section is unusual for a DPA. It is here because our attribution methods have specific legal and app-store consequences that you, as controller, must understand and decide about. It was materially inaccurate in the version of this DPA previously published and has been rewritten from the current SDK behaviour.

9.1. What the Service does. Our attribution waterfall attempts deterministic matching first, using the Google Play Install Referrer or a deferred click token. Where neither is available, it falls back to probabilistic matching — inferring that a click and an install belong to the same device by comparing:

  • IP address
  • User agent
  • Screen metrics
  • Timezone
  • Language and locale

within a matching window of 7 days by default, configurable per workspace through the attribution settings API. The comparison produces a confidence score, and the match type is recorded.

This is device fingerprinting. We describe it as such and do not present it as anything narrower. The Service does not access advertising identifiers — not the Apple IDFA, with or without App Tracking Transparency permission, and not the Google Advertising ID — but that does not make the practice something other than fingerprinting, and we do not rely on it to suggest otherwise.

The Service also reads a vendor-scoped device identifier (iOS IDFV or Android App Set ID, with a random persisted identifier as fallback) and, where a link leads to the App Store, writes a short random code to the iOS clipboard so the app can identify the originating link after install.

9.2. Data protection consequences. Reading or writing information on an End User's device — including the probabilistic matching in 9.1, reading the vendor-scoped device identifier, and writing the clipboard code — engages Article 5(3) ePrivacy and PECR regulation 6. Regulators treat this as requiring consent, and legitimate interests is not an available basis. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) confirm this applies to device fingerprinting and identifier access, not only to cookies.

9.3. App store consequences. Apple prohibits device fingerprinting irrespective of whether App Tracking Transparency permission has been granted (App Store Review Guideline 5.1.2 and the Apple Developer Program License Agreement). The probabilistic matching described in 9.1 falls within Apple's description of that practice. The absence of IDFA access does not cure this.

This is a risk to your app submission, not only to your privacy compliance, and you carry it. We state it here plainly rather than leaving you to discover it at review. Section 9.5 describes how to switch the behaviour off.

9.4. Your decision, your responsibility. You are responsible for determining whether these methods are lawful for your users and territories, for obtaining consent where required before the SDK collects any data, and for compliance with applicable app store policies.

9.5. Consent gating and controls available to you.

  • The SDK is consent-gated by default: no device data is collected until your app signals that the End User has consented. You can disable the gate in your SDK initialisation options, in which case collection begins when the app opens and obtaining consent beforehand becomes entirely your responsibility.
  • Probabilistic matching can be switched off, and the matching window changed, through the attribution settings for your workspace.
  • These controls operate at workspace level only. They cannot currently be set per app or per link, so a workspace containing several apps cannot disable matching for one of them alone. If you need per-app separation, use separate workspaces.

9.6. Our commitment. We will describe these methods accurately in this DPA, our Privacy Policy and our documentation; keep the controls in 9.5 available; and not misrepresent the SDK's default behaviour, the signals it compares, or the granularity of these controls. The version of this DPA previously published fell short of that commitment and this version corrects it.

10. Assistance to you

10.1. Data subject rights. Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures — including the dashboard and API functionality we provide — in fulfilling your obligation to respond to requests to exercise rights under Chapter III of the UK/EU GDPR.

10.2. Requests received directly. If an End User contacts us directly to exercise rights over Customer Personal Data, we will not respond substantively. We will promptly forward the request to you and confirm to the individual that we have done so, unless you have instructed otherwise.

10.3. Articles 32 to 36. We will provide reasonable assistance with your obligations on security, breach notification to supervisory authorities and data subjects, data protection impact assessments, and prior consultation — taking into account the nature of processing and the information available to us.

10.4. Charges. Assistance under this section is provided at no charge where the request is reasonable in scope and frequency. For assistance that is materially burdensome or repetitive, we may charge our reasonable costs, notified to you in advance.

11. Our own use of End User data

11.1. As disclosed in section 7.3 of the Agreement, we use End User data to develop and improve the Service — specifically to train and evaluate fraud detection models, and to produce aggregated statistics and benchmarks. For these purposes we act as a controller, not your processor.

11.2. For that processing we commit that: outputs do not identify you, your apps, or any individual End User; we do not sell End User data; we do not use it to build advertising or marketing profiles of End Users; and we do not disclose your data or metrics to other customers in identifiable form.

11.3. Our lawful basis for this processing is legitimate interests (Article 6(1)(f)) — operating a platform whose core promise is accurate, fraud-resistant attribution, which cannot be delivered from any single customer's data in isolation. We use the minimum data needed for the purpose. A balancing assessment is available on request at privacy@linktrail.io, and End Users may object as described in our Privacy Policy.

11.4. We also use processing data to diagnose faults, reproduce bugs, and develop the Service, on the same basis.

12. Personal Data Breach

12.1. We will notify you without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.

12.2. Our notification will describe, so far as known: the nature of the breach and the categories and approximate number of data subjects and records affected; the likely consequences; the measures taken or proposed; and a contact point for more information. Where we cannot provide all of this at once, we will provide it in phases without undue delay.

12.3. We will take reasonable steps to contain and remediate the breach and will cooperate with your investigation and any notification you must make to a supervisory authority or to data subjects.

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

13. Audits and information

13.1. We will make available the information reasonably necessary to demonstrate compliance with Article 28 and this DPA.

13.2. Documentation first. Your audit right is satisfied in the first instance by the information we publish or provide on request — including this DPA, Annex II, our sub-processor list, and any third-party audit reports or security documentation we hold. We do not currently hold an independent security certification or third-party audit report; Annex II is the primary documentation available.

13.3. On-site audits. Where that documentation is genuinely insufficient, or following a Personal Data Breach affecting your data, or where a supervisory authority requires it, you may audit us or appoint an independent auditor (not a competitor of ours, bound by confidentiality). Audits take place on reasonable prior notice of at least 30 days, during business hours, no more than once in any 12-month period except where required by a supervisory authority or following a breach, and must not unreasonably disrupt our operations.

13.4. You bear the costs of an audit you initiate, unless it reveals a material breach of this DPA by us, in which case we bear our own costs and yours.

14. Retention, return, and deletion

14.1. During the Agreement, we retain Customer Personal Data as described in Annex I, Part B.

14.2. On termination, at your choice, we will delete or return Customer Personal Data. Because we do not currently offer a self-serve export, you may request a copy in a commonly used machine-readable format by emailing privacy@linktrail.io before or within 30 days after termination, and we will provide it.

14.3. Deletion timetable. We delete Customer Personal Data from active production systems within 30 days of termination.

Residual copies remain in database backups and point-in-time recovery archives, which expire on a rolling basis up to 12 months. Those backups are held encrypted, are not used for any purpose other than disaster recovery, and are not searched, queried or restored to serve a deletion or access request. Deletion is therefore complete in production within 30 days, and complete across all copies once the relevant backup has expired.

14.4. Exception. We may retain data where law requires it. Where we do, we continue to protect it under this DPA and process it only for the purpose that requires retention.

14.5. Deletion certificates. We will certify deletion in writing on request. The certificate confirms deletion from active production systems and states the backup expiry position in 14.3; it does not certify that no copy exists in an unexpired backup, because that would not be true.

15. Liability, term, and general

15.1. Each party's liability under this DPA is subject to the limitations and exclusions in the Agreement, except where Data Protection Law does not permit that limitation.

15.2. This DPA takes effect when you accept the Agreement and continues while we process Customer Personal Data, with clauses that by their nature should survive (including sections 5, 8, 12, 14, and 15) surviving termination.

15.3. We may update this DPA to reflect changes in law, our Sub-processors, or our security measures. For material changes we will give at least 30 days' notice by email or in the dashboard. Sub-processor changes follow section 7.4.

15.4. This DPA is governed by the law of England and Wales, subject to section 8.3 for transfers governed by the SCCs.

15.5. Contacts. Data protection queries: privacy@linktrail.io. Security incidents: faizan@linktrail.io; security@linktrail.io reaches the same inbox and may be used instead. Legal notices: legal@linktrail.io, or LinkTrail Ltd, 66 Paul Street, London, EC2A 4NA, United Kingdom.

Annex I — Description of the processing

Part A: Details

Subject matter: Provision of the LinkTrail deep linking and attribution platform.

Duration: For the term of the Agreement, plus the deletion periods in section 14.3.

Nature and purpose of processing: Collecting, recording, storing, structuring, analysing, and transmitting End User data in order to route link clicks to the correct destination, deliver deferred deep link content after app install, attribute installs and events to marketing campaigns, detect click and install fraud, and present analytics to you.

Categories of data subjects: End users of your apps and of links you create — including people who click a LinkTrail link, and people who install or open an app containing our SDK.

Categories of personal data:

CategoryData
Click eventTimestamp, link identifier, workspace identifier, campaign identifier, channel identifier, referrer, routed destination, deferred click token
Device and environmentUser agent, device model, operating system and version, screen metrics, timezone, language and locale. These signals are stored and are compared for probabilistic matching as described in section 9.1
NetworkIP address, and the approximate location and network derived from it. Country is derived using a geolocation database held on our own servers, so IP addresses are not sent to any external geolocation service. IP addresses held in the application database are cleared once the attribution window for the relevant event closes; IP addresses in request and endpoint logs persist for the log retention window in Part B
Device identifiersiOS: identifier for vendor (IDFV), with a randomly generated persisted UUID as fallback where IDFV is unavailable. Android: App Set ID, with a randomly generated persisted UUID as fallback. Both are scoped to the app developer and are not shared across companies
Advertising identifiersNone. The SDK does not access the Apple IDFA at any point, with or without App Tracking Transparency permission, and does not read the Google Advertising ID
Clipboard (iOS)Where a link leads to the App Store, a short random code is written to the device clipboard so the app can identify the originating link after install. The code contains no information about the individual and is cleared by the app after reading. Writing it engages Article 5(3) ePrivacy — see section 9.2
App and install contextApplication bundle identifier, platform, deferred click token where present
Install and app eventsGoogle Play Install Referrer, install timestamp, first-open event
Post-install eventsEvents you choose to send us, such as signup or purchase value
DerivedAttribution match type, confidence score, fraud score
Deep link payloadThe deep link path and any custom data you attach to a link, which may contain personal data you choose to include

Special categories: None. Prohibited by section 4.5.

Frequency: Continuous, in real time as End Users interact with your links and apps.

Sub-processor processing: As set out in Annex III, for the duration of the Agreement.

Part B: Retention

CategoryRetention period
Raw click, install and event records, including device-level signals13 months from collection, then deleted by an automated purge job
Aggregated attribution reports (campaign-level counts, no device identifiers)3 years
Link endpoint, API and application request logs (including client IP address, request path, timestamp, user agent)The log retention window provided by our hosting platform under our workspace plan, currently up to 90 days. We do not extend that window by streaming logs to an external provider
Diagnostic and error data (stack traces and attached request context, which may include an IP address, a device identifier or deep link payload contents)Held in the same platform log stream and subject to the same window, and in Azure Application Insights per Annex III
Audit trail entries (actor, action, resource, before/after values, source IP)The source IP is cleared after 12 months. The remaining entry — actor, action, resource, and before/after values — is retained for the life of the account as an integrity record
Session and refresh token records (including issuing IP)Deleted shortly after token expiry
Aggregated statistics derived under section 11 (LinkTrail as controller)Retained on an ongoing basis in aggregate form only; no device identifiers

Backups: database backups and point-in-time recovery archives expire on a rolling basis up to 12 months. See section 14.3 and Annex II.

Earlier deletion on request: you may ask us to delete your data before these periods expire, and we delete it on termination as set out in section 14. Deletion from backups occurs on expiry, as described in section 14.3.

Note: the analytics history shown in the dashboard by plan tier is a product feature, not the retention period. The figures above are the operative ones.

Annex II — Technical and organisational security measures

These are the measures we have in place. We may update them over time provided the level of protection is not materially reduced.

Verification note. Rows marked *Verified* were confirmed against the running system in July 2026. Rows marked *Commitment* are organisational obligations rather than technical controls. The version of this annex previously published contained two inaccurate rows (request logging and backups), which are corrected here.

AreaMeasureStatus
Encryption in transitAll traffic is served over HTTPS. Plain HTTP requests to the API and to link domains are redirected to HTTPS by permanent (301) redirect; there is no HTTP fallback. HTTP Strict Transport Security is enabled with a max-age of 180 days including subdomains. We are not currently on the HSTS preload list.Verified
Encryption at restThe production database is encrypted at rest using AES-256, applied to primary and replica instances and to all backups, as provided by our hosting platform.Verified
Access controlProduction infrastructure and database access is limited to a small number of authorised personnel on a least-privilege basis. Multi-factor authentication is enforced at organisation level on our hosting, source control, and network providers, so it cannot be disabled by an individual member.Verified
Environment separationProduction, staging, and development are separate environments with separate credentials.Verified
Credential managementRole-scoped internal access, with application secrets held in the hosting platform's managed environment configuration and rotatable on demand. Secrets are not short-lived or automatically rotated. Configuration is validated at startup so the service fails to boot rather than running with a missing credential. Customer SDK API keys are stored only as SHA-256 hashes; the plaintext key is shown once at creation and is never retrievable afterwards, and individual keys can be revoked at any time.Verified
Audit loggingAn immutable, append-only audit trail records mutations made through the dashboard — actor, action, resource, before and after values, and source IP — and is available to customers through the audit API endpoint. Administrative actions on our hosting workspace are separately logged by our hosting provider and retained by them for at least 90 days.Verified
Request loggingApplication, API and link endpoint request logs do record client IP addresses, alongside request path, timestamp and user agent. Retention is the hosting platform's log-stream window under our workspace plan, currently up to 90 days, which we do not extend.Verified
BackupsDatabase backups and continuous point-in-time recovery archives are provided by our hosting platform, encrypted at rest under the AES-256 encryption above, and expire on a rolling basis up to 12 months. Backups are not searched, queried or restored other than for disaster recovery.Verified
Data minimisationIP addresses held in the application database are cleared once the attribution window for the relevant event closes. This minimisation does not extend to request logs, where IP addresses persist for the log retention window above.Verified
PersonnelEveryone with access to Customer Personal Data is bound by a written duty of confidentiality that survives the end of their engagement, as required by section 5.1.Commitment
Vulnerability managementAutomated dependency scanning is enabled on our source repositories, alerting us to known vulnerabilities in third-party dependencies, and we apply security updates on review. We do not operate scheduled independent penetration testing.Verified
CertificationsWe do not hold an independent security certification, and no certification audit is currently underway. We rely on the measures in this annex and on the certifications held by our infrastructure Sub-processors, which those providers publish.Verified
Breach responseSuspected security incidents can be reported to faizan@linktrail.io or security@linktrail.io, which reach the same inbox, monitored by a named individual responsible for investigation and for notifying affected customers within the timeframe in section 12.1.Commitment

Annex III — Sub-processors

Sub-processors that process Customer Personal Data:

Sub-processorPurposeProcessing locationEntity location / transfer note
Render (Render Services, Inc.)Cloud hosting — application and databaseEuropean UnionUS-parented; onward access under SCCs and UK Addendum
Cloudflare (Cloudflare, Inc.)CDN and edge delivery, DNS, securityEuropean UnionUS-parented; onward access under SCCs and UK Addendum
Microsoft (Microsoft Ireland Operations Ltd / Microsoft Corporation)Application performance and error monitoring (Azure Application Insights)European Union (West Europe)EU contracting entity; US-parented, onward access under SCCs and UK Addendum

*Microsoft was listed in the version of this annex previously published as a planned Sub-processor not yet receiving data. It is receiving data and has been moved to the table above. Notice under section 7.4 is being issued to customers; the objection right in 7.4 applies from the date of that notice.*

Planned Sub-processors, not yet receiving data. Disclosed in advance so you have notice before they go live. Each will move into the table above, and we will notify you under section 7.4, before it begins processing Customer Personal Data:

Planned Sub-processorPurposeProcessing location
Sentry (Functional Software, Inc.)SDK and application error monitoringEuropean Union

Not Sub-processors under this DPA. The following process data for which LinkTrail is the controller — our own customer, billing, website, and support data — and are disclosed in our Privacy Policy rather than here: Stripe (payments; Stripe is also an independent controller for its own fraud, AML, and regulatory purposes), Resend (transactional and marketing email), Titan via Hostinger (business email), Google (Google Analytics for Firebase and Ads conversion measurement, website only).

Integrations you configure — including ad networks and analytics platforms such as Meta, Google Ads, TikTok, Apple Search Ads, Amplitude, Mixpanel, Segment, Braze, Iterable, and BigQuery — are not our Sub-processors. See section 7.5.