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)

Used for:

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

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
  
  

RuId and the Data Manager

When working in the Data Manager, the naming of user ID fields differs from what you see in tracking. This is expected behavior - the same data surfaces under different field names depending on the context.

The table below shows how identity fields map across contexts:

Context	Field name	Label
Tracking docs (input)	ruid	Raptor Email Marketing ID
Tracking docs (input)	reaId	reaId
Live Tracking Stream	RUID	Raptor Email Marketing ID
Live Tracking Stream	reaId	reaId
Data Manager (output)	ExternalUserId	Raptor Email Marketing ID

In the Data Manager, ruid and reaId are not exposed as separate fields. Instead, the value you send as ruid in tracking appears under the field ExternalUserId, labeled "Raptor Email Marketing ID."

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

Where Hard IDs Are Used in Raptor

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

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.

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