Skip to content
Arc XP

User ID Guidance

Audience: Anyone sending behavioral events to, or reading recommendations from, Content Recommendations — regardless of collection path.

user_id is the key the model learns on. Every event you send and every recommendations request you make carries one, and personalization quality is a direct function of two properties you control: the ID is anonymized, and the ID is stable. This page is the single reference for those rules; other Content Recommendations guides link here instead of repeating them.

This page is the companion to the Item ID Guidance — user_id and item_id are the two halves of every interaction the model trains on.

TL;DR

  • Never send PII. user_id must be an anonymized token — not an email, name, phone number, or any directly identifying value. Hash or pseudonymize before sending. Arc XP does not sanitize user IDs on ingestion.
  • Same reader, same ID, every time. The same person must resolve to the same user_id across sessions — and across devices and collection paths where possible. Anonymous IDs are fine as long as they are stable.
  • A per-page-load random value is the worst case. It makes every event look like a brand-new user, so the model can never accumulate history.
  • Use the same raw value when sending events and when fetching recommendations. The write path and the read path pseudonymize user_id identically — if the two paths send different raw values, personalization silently breaks.

Anonymization

user_id may be an authenticated account ID or an ephemeral ID for anonymous readers, but it must be anonymized before it reaches Arc XP. Hash or pseudonymize on your side; the platform stores what you send.

This is a hard requirement, not a recommendation: user IDs surface in operational logs and internal data exports, and Arc XP performs no PII scrubbing on ingestion.

Stability

The model builds a per-reader interaction history keyed on user_id. Every place an ID can silently change is a place that history fragments:

  • Across sessions. A returning visitor must produce the same ID as their previous visit. A persistent first-party cookie or a CDP-assigned profile ID works; a session-scoped or per-page-load ID does not.
  • Across devices, where you can manage it. A stable, host-managed ID (for example, a hashed logged-in ID) is the only way one reader’s phone and laptop share a single history.
  • Across collection paths. If you run the Compass Web SDK for live web traffic and a forwarder for backfill or non-web surfaces, both must emit the same user_id for the same reader, or the model treats the two streams as unrelated people.
  • Between backfill and live traffic. Historical events replayed during onboarding must use the same anonymization scheme your production traffic will use, so pre-launch history attaches to the readers who show up on day one.

One value across write and read

The user_id you put on events must be the same raw value your recommendations requests use. Both paths pseudonymize identically, so a mismatch doesn’t error — it just returns recommendations for a reader with no history.

If you use the Compass Web SDK, read the value back with getUserId() and forward it verbatim to the read path. See Compass Web SDK: Consent & Identity.

Login transitions and identity stitching

When a visitor logs in, many event sources switch from a cookie or device ID to an account ID. Content Recommendations performs no identity stitching: the pre-login history stays attached to the old ID, and the account ID starts from zero.

Decide a strategy on your side and apply it consistently. The two workable patterns:

  • Keep emitting the pre-login ID as user_id even after login, or
  • Maintain your own mapping and always resolve a visitor to one canonical ID before sending.

Whichever you pick, apply it on both the event path and the recommendations read path.

What happens when you get it wrong

Unstable or inconsistent IDs don’t produce errors — they produce quietly bad results:

  • The model can’t accumulate history per reader, so results stay generic and popularity-based long after launch.
  • The same reader sees different personalization on different surfaces or devices.
  • Backfilled history never attaches to live readers, wasting the seeding work.

If recommendations look low-relevance, user_id consistency is one of the first things to audit — see the Troubleshooting section of the API Developer Guide.

New and anonymous readers

A reader with no history is expected, not a failure: Content Recommendations returns popularity-based results for them automatically, and results personalize progressively as their events accumulate. You don’t need special handling — you need their ID to stay stable so the accumulation happens.

See also