One visitor, one journey

Tiny Funnel identifies a visitor with a random first-party id in that browser's localStorage. No cookies, no fingerprinting. That id names a browser on a domain, so on its own it would lose the thread in three ordinary places: a second domain, a link opened on a different device, and a Safari visitor who stays away for a week.

It does not, because journeys are stitched back together server side. Most of that happens with nothing to set up, and two small additions cover the rest.

What already works

Links between your own domains. When a visitor clicks from one of your funnel's allowed domains to another, the script carries the id across in the URL (a tf_v parameter, stripped from the address bar on arrival) and the destination page continues the same visitor. The domains are the ones already listed in your Install panel, and a link to anyone else's site is never touched.

For links your own code builds, tf.link(url) returns the same URL with the id attached:

window.location = tf.link("https://app.example.io/signup");

Events from your backend find their visitor. A server event is matched on external_id if you send one, then the visitor token, then the IP address it arrived from. The IP match is cross-checked against the delivery's operating-system family, so a Windows conversion is never attached to an iPhone's journey, and an event that cannot be placed with confidence is recorded as a drop on your Install panel rather than guessed at.

Two rows for one person get merged. However the connection is made, the journeys combine: steps reached are pooled, the earlier visit keeps the entry page and referrer, and your funnel counts one person rather than two.

Two things worth adding

Tell us who your signed-in visitors are

The strongest stitch is the one only you can make. Once someone signs in, hand over your own id for them, either with a meta tag in your layout:

<meta name="tf-user" content="42">

or from code, whenever your app learns who the user is:

tf.identify("42");

Use a stable id you already key your users by. A database id is perfect; an email address is not, since this id shows up in your own dashboard and should mean something to you without being personal data on our side. The meta tag costs one beacon per identity change rather than one per page, so it is safe on every signed-in page.

This is also the fix for a journey that spans a phone and a laptop: same id, one visitor.

Carry the id into emailed links

The script cannot decorate a link inside an email, but your backend can. On the page that requests the email, read the id and send it along:

<input type="hidden" name="tf_visitor" id="tf_visitor">
<script>
  addEventListener("load", function () {
    if (window.tf) document.getElementById("tf_visitor").value = tf.visitor();
  });
</script>

Then append it to the link you email:

https://example.com/session/confirm?token=abc123&tf_v=THE_VISITOR_ID

The click can land in any browser, on any device, and the journey picks up where it left off.

Logging out and shared browsers

When someone logs out, or one account signs out and another signs in on the same browser, call:

tf.reset();

Everything after that belongs to a new visitor. Without it the browser keeps writing to the signed-out person's journey. If your users never share a browser this matters little; if they can (support teams, agencies, families), put it in your logout handler.

What this is not

None of this tracks anyone across sites that are not yours, and none of it uses a cookie. The handoff parameter only ever carries an id your own funnel minted, between domains you listed yourself. identify only ever stores an id your own system already holds. Everything expires: the id in the browser after six months idle, the visitor record after eighteen.