DataFast integration — see the session behind every conversion

DataFast: 🎉 New conversion — $49/mo, source: twitter, campaign: launch-week

You open UserTapes, filter Tapes → Conversions, click the matching session:

  0:00  landed on /pricing from twitter.com
  0:14  scrolled past the FAQ without reading it
  0:19  hovered the annual toggle, switched back to monthly
  0:31  click "Start free trial"
  0:33  ⚠ rage click ×3 — coupon field flashed an error, then cleared itself
  0:41  retried, coupon applied, checkout completed

Pricing copy is landing. The coupon field has a bug worth fixing before it
costs you a sale that doesn't retry.

DataFast is good at one thing on purpose: it tells indie founders which channel, campaign, or landing page made them money. By design, it stops there — no heatmaps, no session recordings, no behavioral detail.

Which leaves a real question unanswered every time someone converts: not which channel worked, but why. What did that customer actually read, hesitate over, or almost bounce from before they paid?

The gap DataFast leaves on purpose

Right now, closing it means installing a second, unrelated session-replay tool, cross-referencing visitor data by hand, and keeping two dashboards open at once. Most founders never do this — so they keep optimizing based on which channel converts, without ever learning why.

UserTapes closes it the way it should be closed: automatically, using data you’re already collecting. Install both script tags, connect a DataFast Website API key (see Setup below), and each DataFast conversion gets matched to the UserTapes recording of the visitor who made it, whenever a recording of that visitor exists — no new privacy conversation, no new tool for anyone to evaluate from scratch.

What you actually get

A tag, not a separate dashboard. A converted session gets a Paid signal right on the tape shelf, next to the Rage and Err tags you already scan for. Filter tapes by it, or just glance at the shelf — a converting session and a frustrated one live in the same list, because they should.

The exact path, not an aggregate number. DataFast can tell you Product Hunt converts at half the rate of Google. It can’t tell you why. Pull up a handful of Product Hunt session replays and you might find every one of them bouncing at the same broken signup field — the kind of detail no aggregate number surfaces on its own.

Evidence you can act on before you change anything. Before rewriting pricing copy, watch the last five converting sessions on the pricing page. See what visitors actually read, hover over, or scroll straight past — replacing a guess about what’s working with direct behavioral evidence.

Something worth sharing. A real, consented, anonymized recording of an actual conversion is stronger proof for a launch post or cold outreach than another stats screenshot.

How the matching works

UserTapes’ tracker reads the same visitor id DataFast’s script already sets — a cookie on their default script, or a rotating server-hashed value on their cookieless one — and stores it alongside the session recording. When a DataFast payment fires, a background job matches the two by that id, inside whichever window that id stays trustworthy for.

On their cookieless script that’s about a day, and it’s a hard ceiling: the id is a server-side hash whose salt rotates roughly every 24 hours, so past that the same string probably belongs to somebody else. Neither tool can extend it.

On their default script it’s about a month. That one is our choice, not theirs — their cookie actually lasts a year, but a year-old recording is rarely the session that explains a purchase, and matching that far back buys more false confidence than insight.

No visitor id, no match, no silent guess: an unmatched conversion still shows up, tagged plainly as unmatched rather than dropped or misattributed.

If you take payments through Stripe Checkout

This is the step most people miss, and it’s the difference between “some conversions match” and “no conversions arrive at all.”

Add session_id={CHECKOUT_SESSION_ID} to your Checkout session’s success_url. DataFast’s script reads that parameter off the page the customer lands on after paying and turns it into a payment event linked to the real Stripe session — the actual amount, the actual currency:

Stripe::Checkout::Session.create(
  # ...
  success_url: "https://yourapp.com/welcome?session_id={CHECKOUT_SESSION_ID}"
)

Two things make this the method worth reaching for first:

• It’s the only Stripe-native method that works cookieless. DataFast’s other Stripe method passes their visitor cookie through as Checkout metadata. Their cookieless script never sets that cookie — it keeps its ids in sessionStorage instead — so on a cookieless site that method silently passes nothing, forever, with no error anywhere. (The email event below also works without cookies, but it matches on an address DataFast already knows rather than on the payment itself.)
• It’s safe to double up. DataFast dedupes payment events, and their script also guards per session id in sessionStorage, so a customer refreshing the success page can’t double-count your revenue.

Make sure the page your success_url lands on actually has the DataFast script on it. A success page rendered from a bare layout without the tag is the other common way this quietly does nothing.

If you’re on Stripe Elements, a payment link, or a third-party processor, DataFast’s email-based event is the fallback: window.datafast("payment", { email: buyerEmail }).

Cookieless sites: identify your users

If you run DataFast’s cookieless script, their visitor id is a server-side hash whose salt rotates roughly every 24 hours. That’s why the cookieless match window is about a day — past it, the same id string probably belongs to a different person.

You can’t extend that window, but you can stop it mattering as much. Once someone signs in, tell DataFast who they are:

window.datafast("identify", { user_id: user.id, email: user.email });

That pins a stable identity to whatever rotating visitor id is current, so DataFast keeps attributing later revenue to the original acquisition channel instead of starting over each day. It doesn’t widen the replay match window — a recording still only knows the rotating id — but it does mean your revenue numbers stop fragmenting across rotations.

If your site has a Content-Security-Policy, both snippets are inline scripts and need a nonce, and datafa.st needs to be allowed in connect-src as well as script-src. The cookieless script POSTs to https://datafa.st/api/events and reads the visitor id back out of that response — block that call and no visitor id ever reaches UserTapes, with nothing in the UI to say why.

Ask instead of dig

UserTapes already speaks MCP — DataFast does too. Once both are connected, your coding agent can answer “who converted this week, and what did they actually do” in one conversation, citing timestamps you can click through to, without either dashboard ever opening. list_conversion_sessions and get_session_replay are the two tools that do it; connect_datafast_site is the one that sets it up, so an agent with DataFast’s own MCP already connected can generate a scoped key and wire the whole integration up itself.

Setup

1. Install both script tags — DataFast’s, and UserTapes’ (from your site’s Setup page, once you’ve created a free account). Put them on every page you want matched, including whatever page customers land on after paying.
2. Connect a DataFast Website API key (the df_ one, from DataFast → Website settings → Developer) on your site’s Integrations page — paste one in, or hand your agent the prompt there if it already has DataFast connected. An account token (dft_) won’t work. We check the key against DataFast before saving it, so a wrong or revoked key tells you immediately instead of failing quietly in the background.
3. If you use Stripe Checkout, add session_id={CHECKOUT_SESSION_ID} to your success_url — see the Stripe section above. Skip this and cookieless sites record no payments at all.
4. Done. Matching runs in the background every 15 minutes; converted sessions start showing up tagged Paid shortly after DataFast reports them.

If conversions aren’t showing up

Almost every “it’s not working” case is one of these, and none of them surface an error on their own:

• The success page has no DataFast tag, or the success_url is missing session_id={CHECKOUT_SESSION_ID}. Start here — it’s the most common one.
• localStorage.datafast_ignore is set to "true" in the browser you’re testing with. DataFast’s script honours that flag and drops everything, silently. Easy to set while testing and forget about.
• You’re testing with a headless browser or a script. DataFast drops events from anything that looks automated — navigator.webdriver, or a user-agent containing curl, python, node.js, postman. A real browser is the only way to verify this end to end.
• A CSP or an ad blocker is blocking datafa.st. Check both script-src and connect-src, and check the browser console for the script’s own log lines — it reports what it’s doing.
• The visitor id rotated. On cookieless sites a recording older than about a day can’t be matched to a payment. The conversion still appears, tagged unmatched — that’s the honest answer, not a bug.

You: who converted this week?

▸ datafast list_visitors(isCustomer: true, startAt: "7d")
  ← 3 customers · $147 total · top source: twitter

You: show me what the highest-value one actually did

▸ usertapes list_conversion_sessions(site_id: "...", min_amount: 40)
  ← 1 conversion · $49 · matched tape 3e7128f8
▸ usertapes read_transcript(3e7128f8)
  ← 0:00 landed on /pricing · 0:31 click "Start free trial" · 0:33 ⚠ rage click …

Neither dashboard ever opened.