Visitor identity & payment matching

Enable only when needed#

Persistent mode creates a project-scoped visitor ID after analytics consent, with a 30-day stored identity lifetime. Cookieless mode does not supply that persistent browser ID. Identification additionally needs the site's identity feature enabled, data-identification="true", and separate visitor purpose consent.

Identify after authentication#

// Run only after the tracker is ready and the visitor opted into identification.
window.weeveo.identify("customer_123", { email: "customer@example.com" });

Use an opaque stable ID of 1–128 letters, digits, underscores or hyphens. Email is optional, validated and normalized. Other profile properties are not an open-ended identity database. Never use credentials, payment card data or sensitive profile details.

Link permitted visitor context to checkout#

Read getSession().visitorId only when available, and pass the provider-supported visitor context through your own trusted checkout creation. Provider field mappings differ. Follow the fields shown by your integration and verify the resulting customer journey rather than assuming every provider accepts the same metadata.

Why a payment may be unattributed#

Consent may have been refused, the visitor may have used a different device, persistent identity may have expired, metadata may be absent, or the payment may predate tracking. A provider transaction remains valid revenue even when no browser journey matches it. Do not fabricate a visitor ID to force a match.

Withdrawing permission#

Analytics revocation clears the local persistent identity and stops collection. Historical data requires the separate visitor privacy workflow; clearing local storage is not a historical erasure request.