Data Collection
A detailed breakdown of what data Pipetrace collects and how it is used. What is kept depends on the privacy tier: the browser data points below are recorded only at tier 3 (consented analytics). For tiers 1 and 2, see anonymous counts and anonymous sessions.
Browser data points (consented analytics)
Page Information
| Field | Example | Purpose |
|---|---|---|
| URL | /blog/my-post | Identify which pages are visited |
| Title | My Blog Post | Display readable page names |
| Referrer | google.com | Understand traffic sources |
Device Information
| Field | Example | Purpose |
|---|---|---|
| Device Type | mobile | Optimize for device types |
| Browser | Chrome 120 | Browser compatibility insights |
| OS | macOS 14 | OS usage statistics |
| Screen Size | 1920x1080 | Design optimization |
Engagement Metrics
| Field | Example | Purpose |
|---|---|---|
| Time on Page | 45 seconds | Measure content engagement |
| Scroll Depth | 75% | Understand reading behavior |
| Bounce | true/false | Single-page visit indicator |
Performance Metrics (Web Vitals)
| Field | Example | Purpose |
|---|---|---|
| LCP | 2.5s | Largest Contentful Paint |
| FID | 100ms | First Input Delay |
| CLS | 0.1 | Cumulative Layout Shift |
| INP | 200ms | Interaction to Next Paint |
Identifiers and Browser Storage
| Data Type | Status | Reason |
|---|---|---|
| IP Address | Processed by the API |
|
| First-party cookie | Tier 3 (Consented analytics) only | Persists the visitor identifier (_pt_vid); see its lifetime below the table |
| Local Storage and IndexedDB | Tier 3 (Consented analytics) only | Persist visitor identifiers; localStorage also holds consent and retry data |
| Visitor, session, and supplied user IDs | Stored with events when supplied | Visitor/session counting and the optional identify API |
| Visitor recovery hash | Stored by the API | HMAC of IP address and user agent, keyed with a per-site secret that changes every UTC day and is deleted after it. It can only match visits on the same UTC day, is deleted about 24 hours after it was last used, and cannot be recomputed once its secret is deleted, except from operator-held database backups, which follow their own retention. |
| Retention | Set per site, 1 to 25 months (25 by default) | Events, hourly statistics, and visitor aliases and archetype memberships whose visitor has no remaining events are deleted after the site's retention period, by a job that runs every 6 hours |
| Daily secret key (salt) | Kept until 01:00 UTC the next day | One random key per site per UTC day, for the tier 2 visitor code and the same-day recovery hash. A cleanup every 15 minutes deletes it together with that day's open-session records. |
Tier 3 stores a random visitor ID in the first-party cookie _pt_vid, which expires 730 days (about 2 years) after it was last set (the tracker sets it again on every tier 3 page load), and in localStorage and IndexedDB, which have no expiry; it keeps a per-tab session ID in sessionStorage.
Tier 3 runs without asking on legacy sites and, in regional mode, for visitors outside the consent regions.
Before consent: anonymous counts and anonymous sessions
When a site's policy requires consent and a visitor has not given it, or has refused, the script runs in a minimal mode. At tiers 1 and 2, the tracker stores nothing in the visitor's browser. It reads one thing, and only before switching to tier 3: an opt-out saved in localStorage (_pt_consent) by the older optOut() call. If it finds one and the visitor has not accepted, it stays at tier 1.
In minimal mode the script sends only page views and named custom events or goals, with the page path, the URL with standard UTM tags only, and the referring site's origin. The server adds the country, device type, browser family and primary language from the request. The site owner chooses what the server keeps:
| Pre-consent setting | What is kept | Limits |
|---|---|---|
| Off | Nothing. | The tracker may still contact the server on each page; the server stores nothing from those requests. |
| Anonymous counts | Each page view or event on its own, with no visitor or session ID, timed to the minute. | No visitors, sessions or journeys. |
| Anonymous sessions | The same fields, plus a visitor ID derived on the server from the IP address and user agent with a per-site secret that changes every UTC day, a random session ID, the page number and entry page of the session, and the time of each page. The ID is pseudonymous within a UTC day: it cannot be recomputed once that day's secret is deleted, shortly after the day ends, except from operator-held database backups, which follow their own retention. The table of open sessions is deleted with the secret; the events follow the site's retention period. | People who share an IP address and an identical user agent (the same browser, version and operating system, for example in one office) count as one visitor. So does everyone with the same user agent behind a proxy that does not pass on the visitor's IP address. A visitor whose IP address changes (a mobile network switch, IPv6 privacy addresses, iCloud Private Relay or a VPN) becomes a new visitor with a new session. A session that crosses midnight UTC counts as two visits, and the same person on two days counts as two visitors. No time on page, scrolling, bounce, performance, errors or forms. |
- In anonymous sessions, visitor IDs are pseudonymous within a UTC day. A session ends after 30 minutes without activity.
- Nothing recorded at tier 1 or tier 2 is linked to a tier 3 visitor. When a visitor accepts on the same page, that page's tier 1 or tier 2 page view is deleted and replaced by its tier 3 page view. Nothing is copied from it; for a tier 2 page view, the server only checks whether its session has other page views, to decide whether the tier 3 page view continues a visit.
- The pre-consent setting also applies to visitors who click Reject. With consent required in consent regions, a visitor outside those regions who refuses is still recorded as anonymous counts, whatever the pre-consent setting, including Off: the tracker stops using cookies and identifiers but keeps counting page views. Pipetrace does not remember the visitor's choice. Your consent tool must store it and load the script with data-consent="denied" on every later page; otherwise, in regional mode, a visitor outside the consent regions who refused gets tier 3 again on the next page, and so does a visitor on a legacy site.
- Sites that have never saved privacy settings (legacy) do not ask first: a script tag without data-consent, or with data-consent="granted", records tier 3, and data-consent="pending" or "denied" records anonymous counts.
- Do Not Track keeps the visitor at tier 1 at most, even after the visitor accepts. With Do Not Track and the pre-consent setting Off, nothing is stored before the visitor accepts if the visitor must be asked first (consent required everywhere, or a visitor in a consent region). A Do Not Track visitor who is not asked first (outside the consent regions in regional mode, or on a legacy site) is stored as Anonymous counts.
- Global Privacy Control stops all collection: nothing is stored from a request that carries it.
Whether measurement before consent is allowed depends on the site owner's jurisdiction and its own assessment; this page describes what the software does, not a legal basis. See the jurisdiction guidance and privacy tiers.
Session & Visitor Counting
With consented analytics, visitor and session identifiers connect events across pageviews:
- The visitor identifier persists in localStorage, a first-party cookie, and IndexedDB.
- The session identifier and page count are stored in sessionStorage.
- Visitor and session identifiers are transmitted with events and stored by the API.
- If browser storage is empty, the API can recover a visitor identifier seen earlier the same UTC day, using its salted recovery hash.
- The optional identify API sends a supplied user ID and traits with an event.
Backend data and redaction
Backend exporters send operation names, trace/span IDs, exact timestamps, parent relationships, status and exception events, service/resource/scope metadata, caller-supplied logs and typed attributes, and metric observations including counts, distributions and exemplars. Automatic HTTP/Pino capture depends on instrumentation and application configuration; console output is not automatically bridged. Explicit confirmed outcomes are stored separately from browser events and span success.
With first-party correlation enabled, recorded site, session, page and request trace/span references link browser evidence to backend operations. A linked browser identity is not a verified person. Background operations need no visitor. Browser opt-out disables further tracker collection and association; it does not turn off an independently configured backend SDK.
The receiver recursively redacts declared secret attribute/map keys, including authorization, cookies, passwords, secrets, tokens and API keys. This is a fixed key list, not free-text content scanning: log messages, exception messages, URLs, SQL strings and other caller-supplied text can still contain sensitive data. Configure capture at the application and avoid sending secrets or personal values.
See the backend API and SDK support matrix and separate retention/deletion behavior.
Access and deployment security
Backend queries require current project membership. Ingest keys and scoped MCP/query tokens have distinct purposes; one-time secrets are stored as hashes. Network TLS, disk encryption and backup protection depend on the operator's deployment. This source qualification does not establish TLS 1.3 everywhere, AES-256 storage encryption, regular independent security audits or a privacy certification.
Access to recorded data
Use the documented authenticated APIs and reports within their result and retention limits. This documentation does not promise an implemented all-data Settings export. Operators must describe export, access requests and contact procedures in their published policy.