Pseudonymous does not mean anonymous
The tracker uses a consent-gated random browser visitor identifier in session storage. It does not fingerprint a device, and it does not automatically read form values or page text. A visitor identifier is still pseudonymous data: a site can associate it with a checkout. Do not describe individual journeys as anonymous.
Explicit page labels, source campaigns, event names and enum values must not contain personal data or secrets. Syntax checks and enum allowlists reduce accidental collection but do not prove that a label is anonymous. The project owner controls those labels. Country and person identity are not inferred.
Grant and withdraw consent deliberately
Call reylin.consent(true) only after your own consent process permits this collection. The tracker never makes that decision for you. Consent is not inferred from a click, an account login or a purchase. Denied and preload tracking queues are discarded rather than saved for later replay.
Calling reylin.consent(false) disconnects view observers, clears the browser visitor ID and aborts pending requests where supported. A request already received by the server cannot be recalled by aborting the browser request. Withdrawal stops future tracking in that browser; it does not erase existing server records or already accepted emails.
// Connect these calls to your own consent manager.
reylin.consent(true); // only after permission
reylin.consent(false); // withdrawal: stops future collectionWhat the project export includes
The project JSON export is an analytics-record export: project collection settings, consented event records, payment ledger records and refunds. It includes an explicit scope manifest. It is not a complete account export and does not include passwords, session credentials, API token secrets or encrypted provider credentials.
Companion-store notes, saved reports, notification delivery records, provider inbox/retry history, Google cached rows and receipt tombstones are outside that export. A Viewer with project access can export project analytics; only an owner can delete or change collection settings. Keep downloaded exports private and remove copies when they are no longer needed.
Section-by-section account export
The Data export panel separately inventories locally stored account and companion sections. It can export supported sections in bounded JSON pages, including private workspace configuration, report delivery records, cached search rows, subscription snapshots and selected integration metadata. Only the signed-in owner can use this account route; Viewer roles and read-only API tokens cannot.
Every page includes coverage and an explicit exclusion list. A missing or schema-incompatible database is unavailable, not silently reported as an empty section. Passwords, credential hashes, token secrets, encrypted provider credentials, worker internals and physical backups are excluded. User-authored notes and labels can themselves contain personal information, so protect downloaded files.
This is a scoped local export, not a universal legal-completeness certification. Pages are generated separately while writes may continue, not as an atomic multi-database snapshot. Download each page, preserve its coverage and timestamp, and use the offline backup process only when an operator needs a restorable system snapshot.
Retention and deletion are different operations
Plan retention and the manual retention action remove old event JSON. They do not remove financial ledger records or every receipt: event IDs, ingestion receipt times and content hashes can remain to preserve idempotency and prevent duplicate usage. This is not a promise that all pseudonymous data expires at the event-retention boundary.
Project deletion removes the local project records and integrated companion data after active-worker checks. Account deletion requires password verification and provider/billing cleanup prerequisites. Provider-side data, downloaded exports, previously accepted emails and backups require their own cleanup. A separate owner-only visitor cleanup workflow coordinates bounded local stores; do not substitute consent withdrawal for it or interpret its completion as physical or universal erasure.
Coordinated local visitor cleanup
A verified project owner can request cleanup of one exact pseudonymous visitor ID. The request is not person identification. It persists a project-scoped SHA-256 suppression digest, not the raw target ID, to prevent known-ID replay and payment relinking. The digest is still pseudonymous data, not encryption or anonymization; someone with candidate IDs may test guesses.
The project temporarily pauses new collection and financial reconciliation. Transaction-local fences let existing workers settle before bounded batches remove matching events and linked receipt/stream records, clear payment visitor linkage, scrub normalized provider-inbox visitor fields and cancel pending project notifications. Monetary amounts, currencies, financial IDs, timestamps, aggregate quota usage and frozen attribution labels are preserved.
Cleanup is resumable after interruption. A job may wait for an active or uncertain email send; accepted messages cannot be recalled, and abandoned uncertain sends require controlled operator review rather than automatic re-sending. Other projects can continue.
Completion describes this specified local scope only. Already-purged legacy receipts without a visitor index may remain. Owner-authored notes, personal information accidentally encoded in attribution labels, provider-side copies, downloaded exports, SQLite free pages/WAL and backups need separate review. New browser identifiers cannot be recognized as the same person without identity tracking, which this workflow does not add.
Email reports and external providers
Reports target only the verified owner email. Sending is separately disabled by default, including when an email adapter exists. The interface distinguishes queued and provider-accepted messages; acceptance is not proof of inbox delivery. Disabling reports cancels queued work but cannot recall a message already accepted by the provider. Never-attempted reports expire after 24 hours. Terminal queue records are eligible for logical cleanup after 30 days, in bounded background batches; delivery-limit reservations expire after 32 days. A stopped or overloaded scheduler can delay physical row removal, but stale reports cannot be newly sent.
Stripe payment processing and Reylin’s own SaaS subscription billing are separate integrations and data flows. Disconnecting an integration prevents future local reads but is not proof of deletion from the provider. Google Search Console uses an explicitly authorized property and reports provider search data, not observed keyword-level revenue.
Before collecting real customer data
Publish an accurate operator privacy notice and consent experience for the actual deployment, naming the operator, contact route, purposes, applicable providers, retention and request-handling process. No operator identity, jurisdiction, legal basis or support contact has been invented here. This technical guide is not a reviewed legal policy or a compliance certification.
Verify production access controls, deployed provider settings, backup retention, restore behavior and deletion procedures. Logical SQLite deletion does not establish physical erasure from WAL files, free pages, snapshots or external systems. The deployment operator must establish and test those lifecycle controls.