Skip to content
  • There are no suggestions because the search field is empty.

User Tracking: Understanding Soft IDs, Hard IDs & Raptor Identity Matching

How Raptor identifies users across devices, channels, and email.

Raptor identifies visitors via anonymous cookies (Soft IDs), which require tracking to be implemented on your site. To recognize known users across web, email, and devices, you must also send Hard IDs when available.

This article explains:

  • Soft ID vs Hard ID
  • UserId (Website ID)
  • RuId (Raptor Email Marketing ID)
  • ReaID (GDPR‑safe encrypted email ID)
  • When to set Hard IDs
  • How to choose your ID strategy
  • 3 supported ID scenarios

This is a conceptual guide, not an implementation guide. For “how to send” identifiers in tracking, see the Client‑Side, Server‑Side, GTM, and Hybrid tracking articles.

 

Soft ID vs Hard ID

Raptor uses two identity layers, combined to recognize users across sessions and devices.

Soft ID

These are anonymous IDs used to identify visitors:

  • CookieId — persistent user cookie (GUID - UUID v4)
  • SessionId — session cookie (GUID - UUID v4)

🔍 Note: For client-side implementations, Soft IDs are set automatically. Server-side implementations require manual configuration.

Used for:

  • Anonymous personalization
  • Browsing behavior
  • Product and content interest
  • Site search
  • Basket history

A single user may accumulate multiple Soft IDs (different devices or browsers).

Hard ID (sent by you)

Hard IDs identify known users across devices and channels. Most Hard IDs (including ReaId, and RuId) are stored as cookies once set and applied automatically on subsequent visits. UserId is an exception — it must always be passed explicitly with tracking events

Raptor supports two Hard IDs:

UserId (Website ID)

Internal identifier of a logged‑in user in your system.

Examples:

  • Email
  • GUID
  • CRM/ERP customer number
  • Authentication provider user ID

Used for:

  • Known user personalization on the website
  • CDP user stitching
  • Device linking
  • Persistent scoring and segmentation

RuId (Raptor Email Marketing ID)

Identifier used for email attribution and cross‑channel personalization.

Can be either:

  • Email
  • External Email Marketing ID (from your ESP)

Rules:

  • Must be Base64 encoded
  • Must be sent whenever known (login, checkout, signup, newsletter success, etc.)
  • Must always be passed in the tracking as RuId
  • Should NOT be mixed (email sometimes, external ID other times)

Used for:

  • Matching clicks from newsletters
  • Behavioral triggers
  • E-mail Recommendations

 

ReaID (Raptor Email Address ID)

A GDPR‑safe encrypted identifier representing the user’s email in URL redirects from your email system.

Why:

  • Email addresses cannot legally appear in URLs (GDPR)

How it works:

  1. Emails sent from Raptor include a ReaID in links
  2. When the user clicks an email, the ReaID appears in the landing page URL
  3. You must pass that same ReaID to Raptor in tracking
  4. Raptor internally converts it back to the original email

Used for:

  • Email → Web identity stitching
  • Trigger flows
  • Personalization upon landing

👀 Use case: ReaID should be used only when RuId = email.

Article on REAID synchronization.

Where Hard IDs Are Used in Raptor

UserId (Website ID)

Used in:

  • Website Recommendations
  • Website Personalization
  • Site Search
  • CDP / Profiles
  • CLV model (Audience Insights)

RuId (Raptor Email Marketing ID)

Used in:

  • E-mail Recommendations
  • Email Triggers
  • Behavioral triggers that involve email
  • Email → Web identity stitching
  • Cross‑channel personalization

ReaID

Used in:

  • Newsletter click attribution
  • Secure email → web identification
  • Trigger activation
  • Reconnecting email traffic to known users
 

When to send Hard IDs

To maximize recognition, send UserId and/or RuId at every point where the user can be identified.

Send Hard IDs at these moments:

  • User logs in
  • User completes checkout
  • User creates an account
  • User signs up for a newsletter
  • User enters an email (e.g., in a form)
  • User clicks in a newsletter (ReaID must be synced)
  • User updates profile information

Why this matters

Personalization quality heavily depends on how often Hard IDs are sent.
The more places you identify the user, the more cross‑device accuracy Raptor achieves.

 

How to choose your ID strategy

Raptor supports three clear scenarios.
Choose one and apply it consistently.

 

Scenario 1 — Email = RuId, Website ID = UserId (MOST COMMON)

You have two different hard IDs:

  • UserId (Website ID): internal login ID
  • RuId: email address

Use when:

  • Your users log in with one ID
  • Email marketing uses email
  • You want full email → web attribution
  • You support multiple devices per user

You must:

  • Send UserId whenever they log in
  • Send email as RuId whenever it appears
  • Enable ReaID sync so email clicks resolve to the right user

Scenario 2 — External Marketing ID = RuId, Website ID = UserId

You still have two Hard IDs, but:

  • The e-mail system uses a non‑email user ID (e.g., ESP‑provided contact ID)
  • You choose NOT to send email as RuId

Use when:

  • Your ESP uses stable, non-email identifiers
  • You don’t want to send email addresses into Raptor
  • ReaID sync is not needed

You must:

  • Send UserId on login
  • Send the ESP ID as RuId
  • Use consistent casing when encrypting
  • Never mix ESP IDs and emails as RuId

⚠️ Risk: Recognition is worse unless users log in often, because ESP IDs can only be matched when a newsletter click happens.


Scenario 3 — One global ID for both web & email

You use the same Hard ID everywhere:

  • The user’s website login ID
  • The user’s ESP ID
  • The ID used by your CRM/CDP

“Single Identity Strategy.”

Use when:

  • All your systems agree on one stable ID
  • This ID exists both online and in email
  • You want maximum consistency

You must:

  • Send the ID as UserId
  • Send the same ID as RuId
  • Do NOT enable ReaID sync (not needed)
  • If your global ID is an email, enable ReaID sync to ensure GDPR‑safe email → web recognition

Benefits:

  • Best user stitching
  • Cleanest CDP profiles
  • Most future‑proof

Best Practices & Warnings

✔ Use consistent casing for IDs

To avoid mismatches, keep all IDs lowercase unless your ESP requires case sensitivity.

✔ Never mix RuId formats

Either use:

  • Email OR
  • External Marketing ID
    but never both — switching breaks user recognition history.

✔ Always encode RuId

Always send RuId as Base64 (email or ESP ID).

✔ ReaID sync required only when RuId = email

Do not enable it for external ESP IDs.

✔ Recognize user as early and often as possible

Login, checkout, newsletter submit, email click — all are good places.

✔ CookieId must always be a GUID (UUID v4)

Required for visitor stitching.

✔ Hard IDs must be available to all systems calling Raptor

If your ESP cannot fetch the ID, do not select it as RuId.

⚠️ Warning: Do Not Switch RuId Format

Raptor treats the RuId as the user’s permanent Hard ID for all email-based personalization.

If you change the RuId format in your tracking (for example, from email → external ESP ID or the opposite):

❌ Previously recognized users will no longer match

❌ User history cannot be merged

❌ All users will appear “new” from the point of change

❌ Email → web journeys will break

❌ Trigger performance will degrade

You must choose ONE RuId strategy and keep it permanently.


Summary

Raptor uses Soft IDs (cookies) to track anonymous visitors.
Hard IDs (UserId, RuId, ReaID) allow Raptor to connect behavior across:

  • devices
  • browsers
  • web & email
  • sessions
  • channels
  • time

Choosing the right ID strategy (Scenario 1–3) and sending Hard IDs consistently is crucial for:

  • personalization accuracy
  • e-mail recommendation relevance
  • trigger performance
  • cross-device identity stitching
  • CDP profiling
  • lifetime value modeling

💡If you are in doubt, Scenario 1 is the most effective and widely used.