Where your data runs, and who touches it
The OnTracks site and dashboard are hosted on Vercel; the data lives in a managed Postgres database at Neon; the API is exposed through a Cloudflare tunnel. Authentication runs on Clerk, payment on Stripe, transactional email on Resend. Access to your Tag Manager container, your Analytics property and your Search Console is delegated through OAuth, with narrow scopes you can revoke at any time. We do not have a published data processing agreement yet — the drafting is with a lawyer, and we will tell you where it stands if you ask. No certification badge appears on this page, because we hold none — this is what is actually in place, as of the review date at the bottom.
Sub-processors
Three pieces make up the platform: a Next.js front end (the public site and the operator dashboard) on Vercel, an API server reachable at api.ontracks.net through a Cloudflare tunnel, and a managed Postgres database at Neon. Everything else in the table below is a service one of those three calls.
| Provider | Role | What it receives |
|---|---|---|
| Vercel | Hosting for the public site and the operator dashboard | Web traffic and dashboard sessions |
| Vercel Blob | Storage for the screenshots taken while a site is crawled | Screenshots of the public pages analysed |
| Neon | Managed Postgres database | All workspace data: tracking plans, runs, tracking sessions |
| Cloudflare | Network exposure of the API (tunnel and DNS for api.ontracks.net) | HTTPS traffic between the dashboard and the API |
| Clerk | Authentication of operator accounts | Account email and identity. No password is stored on our side. |
| Stripe | Payment and billing | Billing identity. Card details are entered on Stripe-hosted pages and never pass through our servers. |
| Resend | Transactional email (account and activation notifications) | Recipient email address and the content of the notification |
| OAuth-delegated access to Tag Manager, Analytics and Search Console | Whatever the scopes listed below allow, on the properties you connect | |
| Microsoft | Read-only delegated access to Bing Webmaster Tools | Search data for the site you connect |
| Content-analysis provider (United States) | Analysis of page content while a tracking plan is drafted and verified, and writing a session brief when you ask for one | The public content of the pages crawled, and the plan metadata. For a session brief: the full session row — including captured identity, where capture is switched on — and that session's event timeline. |
| Meta, LinkedIn (United States) | Server-side conversions and segment exports as custom audiences, on your own accounts with your own tokens | The conversion events you map. For a segment export: the email and phone of the visitors in that segment, SHA-256 hashed before they leave our servers. |
| ip-api.com (fallbacks: ipinfo.io, ipapi.co, ipwho.is, get.geojs.io) | Resolving country, region and city from an IP address | The IP address of a tracking session. This call is made over plain HTTP, which is what the provider's free tier allows. |
Several of these providers are established in the United States, so data leaves the EU by construction. Hosting regions are the providers' own; we do not offer a guaranteed EU data residency today. The table above is the sub-processor list — it is maintained here, on this page, and carries the review date at the bottom.
What the tracking SDK collects, and what it drops
The SDK reads your site's dataLayer to detect the business moments a tracking plan describes: a page view, a product view, a form submission, a purchase.
- dataLayer keys that look like identity — email, phone, first and last name, address, postcode, date of birth, customer identifiers — are dropped in the browser, before anything is sent. The filter matches the usual key names: it lowers the risk, it does not remove it, and it is no substitute for not pushing identity into the dataLayer in the first place.
- The analytics_storage consent signal emitted by your consent platform is read and followed: a mid-session revocation stops the relay.
- Identity a visitor deliberately submits through a form (name, email, phone) can be recorded, for the workspaces where that capture is switched on. In the dashboard those fields are masked by default, and every reveal is logged: who, when, which session, which fields.
- A session's IP address is stored and sent to a geolocation provider to derive country, region and city.
What the Google and Bing connections can do
Connecting Tag Manager, Analytics or Search Console goes through Google's own OAuth screen. The scopes requested are exactly these, and nothing else:
- tagmanager.edit.containers — create and edit the variables, triggers and tags of the container you designate.
- tagmanager.edit.containerversions — create a version of that container.
- tagmanager.publish — publish a version live (only when you ask for a one-click deploy).
- analytics.edit — set up the GA4 configuration the plan needs.
- webmasters.readonly — read-only Search Console data.
- openid and email — record which Google account granted the consent, for the audit trail.
- Bing Webmaster Tools is a separate, read-only connection, stored apart from the Google grants.
Tenant isolation and access
- Every query carries the account it belongs to, and the API refuses to return another account's data. That isolation is enforced by the application layer.
- The matching database-level lock — Postgres row-level security — is written and provisioned, but not yet switched on in production. We would rather say so than let you assume a second barrier that is not standing today.
- The API verifies the authentication token on every dashboard call, independently of the dashboard itself. A short, fixed list of public routes — tracking ingestion, the SDK bundle, health checks — is exempt by design and authenticates with its own per-workspace key instead.
- Reveals of captured identity in the dashboard are written to an append-only audit table.
- OAuth grants are revocable at any time from your own Google or Microsoft account, without going through us.
What we do not claim
- No certification: no SOC 2, no ISO 27001, no external audit. We do not display a badge we do not hold.
- No guaranteed EU data residency at this stage — see the note under the table.
- No compliance guarantee. Whether a given site complies with the GDPR, or with Morocco's law 09-08, depends on what its own data controller puts in place; OnTracks is not a consent management platform.
- Phase 1 alpha: what this page describes can change. That is why it carries a review date.
Reporting a vulnerability
Email roadmap@ontracks.net with "security" in the subject line. There is no bug bounty programme. You get an answer from the person who wrote the code, a fix, and a note when the fix is live.
Data processing agreement
We do not have a published DPA — the Article 28 GDPR processing agreement between OnTracks and your company — yet. It is being drafted and is under legal review. Write to us and we will tell you exactly where it stands, rather than send you a template we have not had checked.
In the meantime, the table above is the sub-processor list, and this page describes an architecture rather than a contractual commitment. Once a DPA is signed, it is that document that counts.
Ask where the DPA stands — roadmap@ontracks.net