What VisitLift is built to collect
VisitLift processes website page paths, supported campaign tags, referrer domains, coarse device information, timestamps, and approved custom event names. Page query strings and fragments are removed after supported campaign fields are extracted. Do not place personal information in page paths, tags, or event names.
Account access requires an email address. Workspace owners may invite members by email. Payment processing for your VisitLift subscription is handled by Stripe; VisitLift does not need your full card number.
Basic tracking and optional attribution
Basic tracking estimates visits using a site-specific daily hash from transient network and coarse browser information. Raw IP addresses and full user-agent strings are not intended to be retained in analytics storage or application logs. Hosting providers may process technical request metadata under their own policies.
Persistent attribution is optional. The browser creates a first-party random identifier when the visitor’s consent integration calls setConsent(true). The server uses that identifier for persistent attribution only when the workspace has enabled the feature. It has a fixed 30-day lifetime. Revoking consent removes the VisitLift identifier. Website operators are responsible for their notices, consent integration, and lawful use.
Payment data
Merchant revenue ingestion stores the minimum normalized Checkout facts needed for reports, attribution, and deduplication, including amounts, currency, timestamps, session/payment identifiers, and Stripe Customer IDs where provided. It is designed not to retain full webhook payloads or customer names, emails, and addresses from those payloads.
The merchant signing secret verifies webhook delivery and is stored encrypted server-side. The merchant revenue collector is separate from VisitLift subscription billing.
Retention and deletion
Active accounts retain up to 12 months of analytics. At trial expiry or the end of paid service, collection stops and analytics are retained for 30 additional days before deletion. Owner-requested workspace deletion is destructive. Operational backups and legally required billing records may follow different retention periods.
Retention cleanup must be configured and monitored by the production operator. A development instance is not evidence that production deletion jobs or provider-level backup deletion are operating.
Providers and deployment requirements
The reference deployment uses Vercel for application hosting, Supabase for authentication/database services, Stripe for subscriptions and payment webhooks, and Resend for transactional email. Providers process data to deliver their services. The final operator must publish the exact active providers, data regions, business identity, and a verified privacy contact before accepting production customer data.
This page describes the implemented product design. It does not claim a certification, a completed legal review, or a particular international transfer arrangement. Those commitments require the production operator’s verified configuration and agreements.
Requests and questions
This release does not include a self-service workspace export or workspace deletion workflow. The production operator must provide a verified privacy-request channel, business details, and a process for fulfilling access/deletion requests before general availability; this development build does not imply that a support inbox exists.
Visitors to a tracked website should first contact that website’s operator, who determines its tracking configuration and can identify the relevant workspace.