Usermaven
Dark mode

How Event Sources matches events to people

Why this matters: an offline conversion is only as valuable as the person it lands on. Get the identity fields right and every imported sale connects to the ad click, the campaign, and the browsing history that earned it. Get them wrong and you have revenue totals with no story behind them.

Every event source, webhook or CSV can carry three identity fields. They are not interchangeable, and each one unlocks a different level of stitching. This guide explains exactly what each field does, so you can decide what to send.

The three identity fields

Priority

Field

What it unlocks

1

user_id

The full person: the event joins their profile, their history, and person-level attribution, including the web activity already stitched to that ID

2

anonymous_id

The visitor's pre-signup story: ties the event to the browsing session and campaign that led to the conversion

3

email

A fallback match: reliable when exactly one person has that email, honest when it can't be sure

Send as many as you have, they're preserved together on the event. When multiple identity fields are provided, Usermaven uses them together to resolve the event. A stable User ID provides the strongest deterministic match.

image.png

Send the same user ID your website uses in its usermaven('id', …) call (usually the ID from your own database or CRM). This is the single most important field, because of how stitching works end to end:

  • When a visitor signs up or logs in on your site, Usermaven links their earlier anonymous browsing to their user_id. From that point on, their whole history lives under that ID.

  • An event-source event carrying the same user_id therefore lands on the complete person, profile, web activity, first-touch attribution, everything.

  • This works retroactively in one important way: a backdated event (say, a CSV import of last quarter's sales) joins the person at its real timestamp. Backdated events are recorded at their original event time and added to the matched person’s history.

The honest caveat: sending a user_id does not, by itself, claim a visitor's still-anonymous browsing. The anonymous-to-identified merge happens when your website identifies the visitor, a server-side event never triggers it. So if someone browsed your site but never signed up or logged in, an offline event with a user_id creates or updates that person, but their anonymous sessions stay unconnected until your site identifies them.

2. anonymous_id the link to the pre-signup story

The anonymous ID is the identifier the Usermaven pixel assigns to every visitor before you know who they are. It is the field designed to connect an Event Source event to the anonymous visitor who was browsing your website.

Send it whenever the converting person may not have an account yet:

  • Embedded forms and checkouts, capture the anonymous ID on the parent page and pass it through with the submission (see Track embedded forms and checkouts for the handoff pattern).

  • Vendor-hosted flows where the visitor converts off-site minutes after browsing your site.

This is also your safety net for identity: if the submitted email happens to match several people, the event's campaign and session context is still preserved through the anonymous ID you supplied independently.

The honest caveat: passing anonymous_id together with a user_id or email tags that event with the visitor's lineage, it does not merge the anonymous visitor's whole history into the person, the way a website identify() call does. If you want the full merge, make sure your site identifies the user when they sign up; the event source then benefits automatically because both carry the same user_id.

3. email the dependable fallback

When there's no ID to send, a webinar registration, a deal closed in WhatsApp, email works, with predictable rules:

  • Exactly one person matches → the event attaches to them.

  • No one matches → Usermaven creates a new person for that email, so the conversion is never orphaned.

  • Multiple people match →The event remains counted, but it is not assigned to a specific person at the time it is processed. Usermaven never guesses between people, and this outcome is permanent for that event, which is why sending an ID alongside the email is worth it.

The honest caveat: To improve matching across systems, send the same stable User ID from your website, CRM, and Event Sources whenever possible. The fix is upstream: whenever your CRM or tool knows the customer's real user ID, send it.

What stitching does and doesn't do

Worth having crisply, because it's where expectations most often drift from reality:


Happens

Doesn't happen

Person

The event is recorded at its supplied event time and added to the matched person’s activity, revenue, goals, and reports.

A server-side event never merges an anonymous visitor into a person; only your website's identify call does

Attribution

Person-level attribution (first touch, campaigns) includes the event; mapped ad click IDs can be used by supported attribution and Conversion Sync workflows.

An identity-unresolved event is not assigned to a specific person. Any available event-level attribution data is still preserved according to the fields provided.

Sessions

An event containing the correct Anonymous ID can be associated with the visitor’s existing browsing context.

Event-source events never create sessions, and backdated events never synthesize historical ones

What to send, by scenario

  • SaaS or any product with login → user_id (the same one your site uses) plus email for readability. This is the gold standard.

  • Embedded form or checkout, visitor may be anonymous → anonymous_id captured from the parent page, plus email if the form collects it.

  • Webinars, offline sales, CRM deals → email, plus user_id whenever your CRM has it. The more consistently your tools share one customer ID, the better every report gets.

  • Everything → a stable external_id (order/deal ID). It's not an identity field, it's your duplicate protection, but it belongs in every payload.


Was this article helpful?