A timeline that does not stop at the property boundary
Every event this person has generated, newest first, labelled with the property it happened on. Somebody who read the blog in March, tried the product in April and came back through a newsletter in June is one story here, not three disconnected visitor records.
Which of your products they have actually used
The question a portfolio owner asks constantly and almost no analytics tool answers: has this person touched anything else of mine? Each property they have used, with first seen, last seen and event volume.
Identity, and how it was established
Person ids are derived deterministically at collection, with no database round-trip in the request path. When somebody identifies themselves, a single small insert re-attributes their entire history with no rewrite of stored events, and the merge is recorded so a wrong one can be reversed from its own audit snapshot.
- Same identify() id on two properties resolves to one person
- A click-through between two of your own domains stitches the anonymous visitor
- Every merge is logged with a snapshot, and can be undone
- Anonymous visitors are never joined across domains you do not own
Every referrer that ever sent them
Not just the last one. The acquisition chain records each referrer and campaign across the person's whole history, with first touch frozen at the point it happened so a later visit cannot rewrite where they originally came from.
Interests, scored rather than listed
A background job scores the topics a person engages with, weighted by rarity and decayed over time, so a page everybody reads counts for less than a page almost nobody does, and last year's interest fades rather than sitting at the top forever.
The company behind the network, without touching personal data
B2B identification is done from the autonomous system the request came through, mapped to an organisation. Consumer ISPs and hosting providers are filtered out, so a visitor at home is never mislabelled with their broadband provider's name, and no personal data leaves the collector to do it.
How it works, precisely
- Identity signals
- Device id, identify() id, cross-domain link token
- Merge cost
- One insert; stored events are never rewritten
- Reversibility
- Every merge keeps a snapshot and can be unmerged
- Company data
- Derived from ASN, with consumer and hosting networks excluded
Person profiles: the usual questions
Is this cross-site tracking?
No, and it deliberately cannot become it. Identity resolves only on first-party signals from properties you operate: the same identify() id on both, or a click through a decorated link between two of your own domains. Anonymous visitors are never joined across domains, and there are no third-party cookies, no fingerprinting and no purchased data anywhere in the system.
What happens when someone asks to be erased?
A GDPR erasure cascades through both stores and tombstones the profile so a later event cannot resurrect it. Export produces the full profile and event history. Both run as background jobs rather than blocking a request.
Do you store IP addresses?
Never. The IP is hashed at the collector with a daily-rotating salt and the original is discarded in the same function. Hashes are scoped per project and per day, so they cannot be joined across tenants or across days.
Next, most people read
Run it yourself this afternoon
Clone the repository, bring up the stack with Docker Compose, paste one script tag. The data never leaves your machines.