How SourceLoop stitches identities and deduplicates contacts

When a visitor lands on your site multiple times, from multiple devices, through multiple campaigns, and converts via multiple channels, SourceLoop has to decide: is this one person or several? The way it decides is identity stitching, and the by-product is contact deduplication, one row in the Contacts Hub per real human, not one row per session or form submission.

This article covers how stitching works, when merges happen, and what to do about the duplicates that occasionally slip through.

The model

SourceLoop maintains an identity graph per website. Each contact is one node. Every node can have:

• One or more anonymous identifiers — the cookie-based IDs the tracker assigns when a new browser lands on the site. One per device/browser usually.
• At most one canonical email — the primary contact email used for deduplication.
• At most one canonical phone — secondary identifier for phone-only conversions.
• Optional external IDs — your internal user ID, your CRM contact ID, your Stripe customer ID, etc., used to stitch across systems.

Two browser sessions that share any of those identifiers point to the same contact. Two sessions that share none are treated as two contacts.

How merging happens

A merge happens whenever a session emits an identifier (email, phone, or external ID) that’s already attached to an existing contact in your workspace.

Example: same person, two devices

1. Tuesday: Jane browses your pricing page from her laptop (Chrome). The tracker creates anonymous_id_A for her browser. Jane is anonymous, one row in your Visitors view.
2. Wednesday: Jane reads your blog from her phone (Safari). The tracker creates anonymous_id_B for that browser. Two anonymous visitors in your Visitors view now (laptop and phone, not yet linked).
3. Thursday: Jane submits a form from her phone with [email protected]. SourceLoop creates a contact with anonymous_id_B linked. One row in Leads, one row left in Visitors (the laptop, still anonymous).
4. Friday: Jane visits your pricing page from her laptop and logs into her account. Your app calls window.sourceloop.identify({email: "[email protected]"}). SourceLoop sees [email protected] already exists as a contact, and merges anonymous_id_A into that contact’s anonymous ID list. The laptop visitor disappears from Visitors. The contact in Leads now shows BOTH the laptop journey and the phone journey, every page view from both, every session from both, in chronological order.

Example: two different emails, one person

1. Jane submits a contact form with her work email [email protected]. Contact created.
2. Two months later, Jane signs up for the newsletter with her personal email [email protected]. Different email, different contact created.

These stay separate by default, because from SourceLoop’s view, they’re two distinct identifiers. If you want to merge them, mark one as a duplicate of the other in the lead detail drawer (see below) or have your CRM sync the merge so the next inbound sync from your CRM aligns the records.

How dedup happens within a single conversion path

Beyond cross-session merging, SourceLoop dedups single-conversion paths so a fast double-submit, a quick reload-and-resubmit, or a webhook retry doesn’t create two rows.

Path	Dedup signal	Window
Form submission (auto-captured by tracker)	Email address	A few minutes
Incoming webhook delivery	The chat_id field if you pass one, otherwise email	Workspace-wide, no time limit
Stripe / Lemon Squeezy / Paddle / Polar / Dodo Payments	Provider’s event id	Workspace-wide
CRM inbound sync	The CRM’s contact id	Workspace-wide
Manual contact creation	None, you can intentionally create two contacts with the same email; the system warns but allows it

If the same email submits the same form three times in 10 seconds (the visitor clicked submit too many times), SourceLoop produces one contact with one conversion event, not three.

The Mark as duplicate flag

When two real contacts represent the same human (different email addresses, accidental double-create by two team members, a CRM merge that didn’t propagate), the cleanest fix is the Is duplicate flag in the lead detail drawer:

1. Open the duplicate contact (the one you want to mark, not the canonical one).
2. In the Additional Information section, toggle Mark as duplicate.
3. Save.

What changes:

• The contact stays in the database with all its attribution intact (no data loss).
• The default Contacts Hub view hides duplicates; the Show duplicates filter shows them back.
• Outgoing webhooks for that contact include is_duplicate: true so downstream systems can filter accordingly.
• CRM sync respects the flag, the canonical contact gets the new updates and the duplicate is skipped.

If you’d rather merge two contacts entirely (combine their journeys, conversions, revenue), that’s a more involved operation. For now, contact [email protected] with the two contact IDs and we’ll do the merge manually.

Anonymous IDs in practice

The anonymous ID is a long random string the tracker assigns the first time a visitor lands on your site, stored in the visitor’s browser cookies / local storage. It persists across:

• Multiple page views on the same site
• Multiple sessions (the visitor returning days or weeks later)
• Browser restarts

It does NOT persist across:

• Different browsers on the same device (Chrome and Safari are two visitors)
• Different devices (laptop and phone are two visitors until they identify)
• Cleared cookies / incognito → normal browsing (a fresh anonymous ID gets assigned)

Where you see the anonymous ID:

• In the tracker’s debug output (?sl_debug=1 on any page)
• As the sourceloop_id field on every payment integration’s checkoutMetadata() call
• In the anonymous_id field on outgoing webhook payloads
• In the visitor’s URL query string when crossing into a cross-domain destination (the linker appends it as _sl=...)

Cross-domain stitching

If your visitor moves from yoursite.com to checkout.yoursite.com (subdomain stays within the same eTLD+1), the tracker handles stitching automatically; the cookies are shared.

If they move to a different domain (yoursite-checkout.com), you need to list that domain in window.SourceLoopConfig.crossDomains and have a tracker on the destination site too. The tracker then appends the anonymous ID to outbound URLs as a _sl=... parameter, and the destination tracker reads it on landing and continues the same visitor’s session.

See JavaScript SDK reference → cross-domain stitching for the config example.

Common pitfalls

Calling identify() with the wrong email. If a user has email A and your code accidentally calls identify({email: "...wrong-email..."}), SourceLoop creates a second contact for the wrong email or attaches the wrong identifier to the right contact. Always identify with the email the user actually owns.

Clearing cookies during testing. When QA testing, repeatedly clearing cookies creates a new anonymous ID each time, which makes the Contacts Hub look like it’s accumulating dozens of duplicates. Use incognito + a fresh email per test to isolate test data, then delete the test contacts when done.

Hoping the tracker fingerprints across devices without an identifier. It doesn’t, and it can’t without invasive techniques no one should be running in 2026. The only way to bridge devices is for the visitor to identify (log in, submit a form, complete a purchase) on each device.

Treating duplicate emails in the CRM as “SourceLoop’s bug”. If your CRM has two contacts for [email protected] and SourceLoop syncs both, you’ll see two contacts on the SourceLoop side too. Fix it in the CRM first, then let the next sync align.

What’s next

• See the contact view that this article describes: How to use the SourceLoop Contacts (Leads) table.
• Understand how sessions work alongside identities: How SourceLoop defines a session.
• Learn how the JavaScript SDK exposes identify and identifiers: JavaScript SDK reference.