Live is a recent activity estimate
Open Live visitors at /app/live and select a website. Use the Country filter to narrow the view. The dashboard refreshes every 10 seconds while its tab is visible.
A visible tracked page sends a presence heartbeat every 20 seconds. A presence entry expires after 60 seconds without an update, so a closed tab or lost connection can remain visible briefly. Hidden tabs do not continue heartbeats. Presence heartbeats do not count toward event usage. This is a recent-activity estimate, not a count of people watching the page at this exact instant.
Anonymous presence uses a temporary tab identifier kept in memory and the site’s approximate daily identity. It does not create a persistent anonymous cookie. Shared networks, multiple tabs, blockers, and daily resets can affect the count.
Country and unknown locations
Country comes from the hosting provider’s country header; it is not inferred from form fields or precise browser location. Missing country information stays Unknown. VPNs, proxies, and shared networks can affect the result; do not use country as proof of a visitor’s identity.
Read a journey without inventing an identity
Open Visitor journeys at /app/journeys, select a website, choose From, To, and Country, then select Apply filters. Find on this page searches only the loaded page; use Previous and Next for more visitors. Open a visitor to read its ordered visit timeline of pages, named clicks, and linked payments. Detail history is also paginated; a loaded batch is not the visitor’s complete history. A new inferred visit begins after 30 minutes of inactivity; the timeline does not prove when someone exited.
A journey orders the accepted pageviews and named interactions that VisitLift can connect. General page navigation already records the pathname; click collection adds selected interactions on that path. It does not record a video, DOM snapshot, mouse movement, form value, or keystroke.
Anonymous daily identity is approximate and cannot reliably connect activity across dates. A returning-browser label uses a consented first-party identifier with a fixed 30-day lifetime and website attribution enabled. Optional server-signed account references can connect multiple consented browsers that your application identifies as the same account. That is account continuity, not person verification or automatic cross-device recognition. Cookie deletion or missing consent is not repaired by guessing an email.
Open the signed customer profile
After implementing /docs/identity, open a linked browser journey and select View customer journey. The profile groups only matching, unexpired, site-scoped signed account references and their consented activity. A raw account ID or email does not come from the browser tracker.
A signing key is created or revealed only by an explicit owner action, then installed only on the merchant server. Assertions expire after five minutes and consume a browser-bound challenge once. Reset on logout or account change; revocation and reset cancel pending identity work. Previously permitted history follows retention.
Signed customer links are retained for up to one year; the browser cookie remains limited to 30 days. Different browsers require their own consent and authenticated signed link. One account may be shared by multiple people, so these rows are not an identity check on a person.
Track a named call to action
Give a deliberate public CTA a stable, non-personal label with data-visitlift-click. Labels start with a lowercase letter and use lowercase letters, numbers, underscores, or hyphens, up to 48 characters. Use a label such as pricing_cta; never put an email, account ID, token, or customer name in it. Sensitive labels are rejected. Each accepted click counts as one event toward your allowance. The tracker does not copy the button’s text or full destination URL.
Automatic collection accepts fragment-only links such as href="#pricing", href="#features", and href="#faq" when they resolve to the current origin, pathname, and query. It uses an exact approved section-label list; full destination links and arbitrary hashes are not automatically collected. Use an explicit safe CTA label only for a deliberate public interaction. Ordinary navigation to another page is measured by that page’s pageview rather than a captured destination URL.
Add data-visitlift-ignore to an element or enclosing container to suppress click collection there. Keep private areas excluded from page tracking as well; click opt-out does not replace path exclusions.
<!-- Automatic public section anchor. -->
<a href="#pricing">Pricing</a>
<!-- Deliberately named public CTA. -->
<a href="/pricing" data-visitlift-click="pricing_cta">See pricing</a>
<button type="button" data-visitlift-click="demo_cta">Open demo</button>
<!-- Suppress clicks within this container. -->
<div data-visitlift-ignore>...</div>Connect a Checkout customer
Checkout linking requires the signed merchant Stripe webhook and a valid site/attribution-token link. Follow the Stripe Checkout guide to send visitlift_site_id and the consented attribution token from your server. An email typed into a page is not a visitor identity.
The workspace owner can view a linked customer email received from the verified Checkout event. It is stored encrypted, not read from the website DOM or sent by the browser tracker. Members receive redacted customer details. Without a valid link, revenue remains explicitly unattributed or unassigned; an email alone does not join separate journeys.
Verify the data you expect
Use a published, registered domain. Check a public pageview, one eligible section anchor, and one deliberately marked CTA. Confirm the expected labels in the journey. Leave a tab visible for a heartbeat, then hide it and allow the 60-second presence window to expire.
Test returning recognition only after your consent integration has activated attribution. Verify Checkout linking in Stripe test mode using a correctly signed event and valid metadata. Keep test/live reports separate, and verify that a member cannot view the owner-only email.
For a full signed account journey, verify accepted consented activity, a server-signed account link, and a positive paid Checkout matched to that same site and browser in the installation guide. Use Purchase journeys in Funnels to measure completion across return visits in a 7-day or 30-day window. Keep Within one visit for the existing visit-based comparison.