Data Collection

A detailed breakdown of exactly what data Pipetrace collects and how it's used.

Browser data points

Page Information

FieldExamplePurpose
URL/blog/my-postIdentify which pages are visited
TitleMy Blog PostDisplay readable page names
Referrergoogle.comUnderstand traffic sources

Device Information

FieldExamplePurpose
Device TypemobileOptimize for device types
BrowserChrome 120Browser compatibility insights
OSmacOS 14OS usage statistics
Screen Size1920x1080Design optimization

Engagement Metrics

FieldExamplePurpose
Time on Page45 secondsMeasure content engagement
Scroll Depth75%Understand reading behavior
Bouncetrue/falseSingle-page visit indicator

Performance Metrics (Web Vitals)

FieldExamplePurpose
LCP2.5sLargest Contentful Paint
FID100msFirst Input Delay
CLS0.1Cumulative Layout Shift
INP200msInteraction to Next Paint

Identifiers and Browser Storage

Data TypeStatusReason
IP AddressProcessed by the APIUsed for geolocation and an IP/user-agent/site recovery hash
First-party cookieUsedPersists the visitor identifier
Local Storage and IndexedDBUsedPersist visitor identifiers; localStorage also holds consent and retry data
Visitor, session, and supplied user IDsStored with events when suppliedVisitor/session counting and the optional identify API
Visitor recovery hashStored by the APICombines IP address, user agent, and site ID to recover visitor identifiers

Session & Visitor Counting

Visitor and session identifiers connect events across pageviews:

  1. The visitor identifier persists in localStorage, a first-party cookie, and IndexedDB.
  2. The session identifier and page count are stored in sessionStorage.
  3. Visitor and session identifiers are transmitted with events and stored by the API.
  4. If browser storage is empty, the API can recover a visitor identifier from its recovery hash.
  5. 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.