How EngageTrack Tracks Revenue Without Cookies

Revenue tracking without cookies sounds like a contradiction. Cookies exist precisely to link a visit today to an action tomorrow — and revenue attribution depends on that link. If someone visits your site on Monday and pays on Thursday, how do you connect the payment to the traffic source without a persistent identifier stored in their browser?

This is the core technical challenge EngageTrack solves. This post explains the four-level attribution hierarchy in detail, shows the code for each approach, and is honest about the trade-offs compared to cookie-based and fingerprint-based tracking.

Why Cookies Were the Default for Attribution

Traditional analytics tools (Google Analytics, Mixpanel, Amplitude) set a cookie with a unique visitor ID. That cookie persists across sessions — when the visitor returns a week later, the tool reads the same cookie and links the new session to the original one.

For revenue attribution, this means: visitor arrives via Google Search on Monday (cookie set with ID abc123), starts a free trial on Wednesday (cookie still abc123), converts to paid on the following Monday (cookie still abc123). The payment gets attributed to Google Search because the cookie maintained the connection across all three visits.

The problem is that cookies require consent under GDPR and ePrivacy. Consent banners have 30-50% opt-out rates. Every visitor who declines cookies becomes invisible — not just for session tracking, but for revenue attribution too. You lose the ability to credit their payment to a traffic source.

Fingerprinting (canvas hashing, WebGL rendering, font enumeration) avoids cookies but introduces worse problems: it is explicitly banned under GDPR, blocked by most browsers, unreliable on mobile devices, and ethically questionable.

EngageTrack uses neither cookies nor fingerprinting. Instead, it combines four attribution methods that work without persistent browser-side identifiers.

The Four-Level Attribution Hierarchy

When a payment event arrives via webhook (from Stripe, LemonSqueezy, Paddle, or Polar), EngageTrack attempts to match it to a traffic source using these methods in priority order. The first successful match wins.

Level 1: Visitor ID in Payment Metadata

This is the most accurate method. It works across devices, across time gaps of any length, and does not depend on any browser state.

The idea is simple: when a visitor initiates checkout, your application reads the EngageTrack visitor ID and includes it in the payment metadata. When the webhook arrives, EngageTrack reads that ID and links directly to the session.

How the visitor ID works without cookies: EngageTrack generates a visitor ID per session using a daily-rotating hash of request attributes (IP address, User-Agent, and a server-side salt that changes every 24 hours). This ID is not stored in the browser — it exists only in memory during the page session and on the server. The same visitor on the same device the next day gets a different ID, which is why EngageTrack cannot track users across days by default. But if you capture the ID at a key moment (like checkout initiation) and embed it in the payment, the link survives indefinitely.

Stripe Checkout example:

// Client: capture visitor ID when user clicks "Subscribe"
const visitorId = engagetrack.getVisitorId();
 
const response = await fetch("/api/create-checkout", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    priceId: "price_xxx",
    engagetrackVisitorId: visitorId,
  }),
});

// Server (Node.js): include in Stripe metadata
const session = await stripe.checkout.sessions.create({
  mode: "subscription",
  line_items: [{ price: priceId, quantity: 1 }],
  metadata: {
    engagetrack_visitor_id: engagetrackVisitorId,
  },
  success_url: "https://yourapp.com/welcome",
  cancel_url: "https://yourapp.com/pricing",
});

LemonSqueezy example:

// Pass visitor ID as a custom field in the checkout URL
const visitorId = engagetrack.getVisitorId();
const checkoutUrl = `https://store.lemonsqueezy.com/checkout/buy/variant-id?checkout[custom][engagetrack_visitor_id]=${visitorId}`;
window.location.href = checkoutUrl;

Paddle example:

// Using Paddle.js overlay checkout
const visitorId = engagetrack.getVisitorId();
 
Paddle.Checkout.open({
  items: [{ priceId: "pri_xxx", quantity: 1 }],
  customData: {
    engagetrack_visitor_id: visitorId,
  },
});

When EngageTrack receives the webhook, it reads engagetrack_visitor_id from the metadata/custom data and looks up the session that generated that visitor ID. The traffic source of that session gets the revenue credit.

Level 2: Customer Email Match

If no visitor ID is present in the payment metadata, EngageTrack falls back to email matching.

This works when you use engagetrack.identify() somewhere in your application — typically after a user signs up or logs in:

// After user authenticates
engagetrack.identify(user.id, {
  email: user.email,
  name: user.name,
});

When a payment webhook arrives with a customer email (all payment providers include this), EngageTrack checks if that email was previously associated with a visitor session via identify(). If it was, the payment is attributed to that session's traffic source.

Trade-off: This only works if the user signed up and was identified before paying, and if the email matches exactly. It does not work for guest checkouts or when the payment email differs from the account email.

Level 3: Same-Session Attribution

If neither visitor ID nor email matching succeeds, EngageTrack checks whether the payment occurred during an active session. The visitor ID that EngageTrack generated for the current session is compared against recent sessions at the time the webhook arrives.

This handles the fast-converter case: someone lands on your site from a Twitter link, reads the landing page, and buys immediately. The checkout and the visit happen within the same session window, so the attribution is straightforward.

Trade-off: This does not work for longer sales cycles. If someone visits today and pays next week, the session has expired and the daily-rotating hash produces a different visitor ID. Same-session attribution only covers purchases that happen during or very shortly after the originating visit.

Level 4: First-Touch Fallback

If none of the above methods produce a match, EngageTrack attributes the revenue to the first known session for that customer — typically identified by email address across historical data.

This is the least precise method but ensures that revenue is never left unattributed. It biases toward top-of-funnel channels (organic search, social media) which is defensible: those channels did introduce the customer to your product, even if the final conversion path is unclear.

Accuracy Comparison: Cookies vs. Fingerprinting vs. EngageTrack

The key insight: cookie-based tools have higher baseline accuracy for session linking but lose 30-50% of their data to consent opt-outs. EngageTrack has lower baseline cross-session accuracy but loses zero data to consent. When you factor in the visitor ID passthrough for revenue events — the moments that actually matter — EngageTrack's attribution accuracy for revenue matches or exceeds cookie-based tools.

The Trade-Offs: What You Give Up

Being honest about what cookieless tracking cannot do:

Cross-day visitor counting is approximate. Because the visitor hash rotates daily, a person who visits Monday and Tuesday is counted as two unique visitors. This means your "unique visitor" count will be slightly inflated compared to cookie-based tools. For most SaaS businesses, this does not materially affect decision-making — you care about trends and channel comparisons, not exact unique counts.

Multi-touch attribution requires the visitor ID passthrough. Without passing the visitor ID in payment metadata, you are limited to same-session and email-based attribution. For products with trial periods longer than a day, implementing the visitor ID passthrough is strongly recommended.

No retargeting or ad platform integration. EngageTrack does not set cookies that ad platforms can read. You cannot use it for Google Ads remarketing or Facebook Custom Audiences. If you rely on retargeting, you still need those platforms' pixels (with consent).

Why This Is Better Than Fingerprinting

Browser fingerprinting attempts to create a unique identifier by combining dozens of browser attributes: canvas rendering, WebGL capabilities, installed fonts, screen resolution, timezone, language, and more. It seems like a clever cookie alternative, but it fails on multiple levels:

It is illegal. GDPR Article 5(1)(a) and the ePrivacy Directive treat fingerprinting as equivalent to cookie tracking. The French CNIL and Austrian DPA have both issued guidance explicitly prohibiting it without consent.

It is inaccurate. Fingerprints change when users update their browser, OS, or display settings. Mobile devices share near-identical fingerprints within the same model. Studies show fingerprint stability degrades to under 50% after 30 days.

Browsers actively block it. Firefox, Safari, and Brave all implement anti-fingerprinting measures that randomize canvas output, limit font enumeration, and reduce available entropy.

EngageTrack's approach is fundamentally different: instead of trying to covertly identify returning visitors, it relies on explicit data (visitor IDs passed at checkout, emails from identify calls) and statistical matching (same-session, first-touch). No covert tracking, no legal risk, no browser arms race.

FAQ

What if a customer pays from a different device?

If you pass the visitor ID in payment metadata, cross-device attribution works perfectly — the visitor ID links the payment to the session regardless of device. Without the visitor ID, EngageTrack falls back to email matching (if the customer was identified via engagetrack.identify() on both devices) or first-touch fallback. For SaaS products where users are logged in, email matching handles most cross-device cases.

How accurate is same-session attribution?

Very accurate when it applies — the challenge is coverage, not precision. If the checkout happens during the same browser session as the visit, the attribution is correct. The limitation is that same-session attribution only covers fast converters. For products with free trials or long consideration periods, you need Level 1 (visitor ID) or Level 2 (email match) to maintain accuracy.

Does this work for long trial periods?

Yes, with the visitor ID passthrough. Capture the visitor ID when the user starts the trial (Level 1) or identify them by email at signup (Level 2). When they convert to paid 14 or 30 days later, the payment is still attributed to the original traffic source. Without either of these, attribution falls back to first-touch, which is less precise but still directionally useful.

Can I verify which attribution level was used for a specific payment?

Yes. In the EngageTrack dashboard, individual revenue events show the attribution method used: visitor ID match, email match, same-session, or first-touch fallback. This lets you audit attribution quality and identify where adding visitor ID passthrough would improve accuracy.

Does the daily-rotating hash use IP addresses? Is that a privacy concern?

The hash uses the IP address as an input but never stores the raw IP. The hash function is one-way (the IP cannot be recovered from the hash) and the salt rotates daily (yesterday's hash cannot be recomputed). The CNIL and other European DPAs have reviewed this approach — hashing with rotation is considered pseudonymization that does not require consent under GDPR, provided the raw IP is never stored.

EngageTrack proves that you do not need cookies or fingerprinting to attribute revenue to traffic sources. The four-level hierarchy — visitor ID, email match, same-session, first-touch — covers the full range of conversion timelines while respecting user privacy. Start your free 14-day trial and see revenue attribution in action.

For implementation details, see the revenue attribution overview and Stripe Checkout integration guide.