Designing a Unified Digital Identity Resolution Engine for Anonymous-to-Known Customer Journeys

How-To-Articles
1

Designing a Unified Digital Identity Resolution Engine for Anonymous-to-Known Customer Journeys

What This Guide Covers

  • Architecting a seamless identity transition pipeline in Genesys Cloud, allowing a customer to start an anonymous web chat and later merge that session into a fully authenticated CRM profile.
  • Utilizing Predictive Engagement tracking cookies, the External Contacts API, and secure Web Messaging Authentication (OAuth).
  • The end result is a contact center where agents never have to ask “Have you called us before?”, because the system automatically links the customer’s anonymous browsing history with their authenticated account profile the moment they log in.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 2 or 3 (Digital) with AI Experience (Predictive Engagement).
  • Permissions: External Contacts > Contact > Edit, Messaging > Integration > Edit, Journey > Session > View.
  • Infrastructure: A backend Identity Provider (IdP) supporting OpenID Connect (OIDC) or OAuth 2.0 (e.g., Auth0, Okta), and the Genesys Web Messaging widget.

The Implementation Deep-Dive

1. The Disconnected Digital Journey

Most digital customer journeys start anonymously. A user lands on your website, browses your pricing page, and initiates a Web Chat. The agent helps them. The next day, that same user logs into their account portal and initiates an authenticated Web Chat.

The Trap:
By default, these are treated as two completely separate humans. The agent handling the authenticated chat on Day 2 has no idea that the customer had a 30-minute chat on Day 1. The customer is forced to repeat their entire problem. This shatters the illusion of a premium “Omnichannel” experience.

2. Tracking the Anonymous Identity

The foundation of identity resolution is assigning a persistent identifier to the anonymous user before they ever log in.

Implementation Steps:

  1. Deploy journey.js: Ensure the Genesys Cloud Predictive Engagement snippet is deployed across all pages of your site (both the public pages and the authenticated portal).
  2. The Cookie: journey.js automatically drops a persistent tracking cookie (_actsc). This cookie links all anonymous page views and anonymous web chats to a single, anonymous cookieId.
  3. At this stage, Genesys Cloud knows that “Anonymous User 12345” looked at the pricing page and started a chat, but it doesn’t know their name.

3. The “Authentication Event” Handoff

When the user decides to log in to your website, you must inform Genesys Cloud that “Anonymous User 12345” is actually “John Doe (Account #999).”

Implementation Steps (Web Dev Team):

  1. When the user successfully authenticates against your backend system, your website must call the Genesys Cloud Journey plugin.
  2. Execute the ac('identify') method:
// Triggered immediately after a successful website login
ac('identify', {
  traits: {
    email: "john.doe@example.com",
    firstName: "John",
    lastName: "Doe",
    custom: {
      crm_account_id: "999888"
    }
  }
});
  1. The Stitching: When Genesys Cloud receives this identify event, its internal identity resolution engine immediately looks at the current cookieId. It searches the External Contacts database for a match on the email address or custom identifier.
  2. If a match is found, Genesys Cloud merges the anonymous journey session into the known External Contact profile.
  3. All previous anonymous page views and chat transcripts are now permanently attached to John Doe’s profile.

4. Authenticated Web Messaging (Secure Chat)

If John Doe starts a chat after logging in, you must ensure the chat is officially authenticated (not just tracked), allowing the agent to perform sensitive actions (like processing refunds) without asking security questions.

Implementation Steps:

  1. In Genesys Cloud, navigate to Admin > Message > Messenger Deployments. Enable Authentication.
  2. Configure an OpenID Connect (OIDC) integration mapping to your IdP (e.g., Okta).
  3. The Token Handoff: On your website, when initializing the Messenger widget, your frontend must pass an Auth Code (obtained from your IdP) into the Messenger plugin.
Genesys("command", "Auth.getAuthCode", {
  authCode: "token_from_your_idp",
  redirectUri: "https://yourwebsite.com/chat"
});
  1. Genesys Cloud validates the token against your IdP. If valid, the chat interaction arrives in the agent’s workspace flagged with a green “Authenticated” badge.
  2. Because the identity was stitched via Predictive Engagement and authenticated via OIDC, the agent sees the entire historical anonymous journey and knows with 100% cryptographic certainty that they are speaking to the account owner.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The Shared Device Conflict

  • The Failure Condition: A husband browses your website anonymously and looks at sports equipment. The wife then logs into her account on the same iPad and starts a chat. The agent sees the husband’s browsing history attached to the wife’s authenticated profile and asks if she needs help buying football cleats. The wife is confused.
  • The Root Cause: Tracking cookies are device-specific, not human-specific. The identify event stitched the shared cookie to the first person who logged in.
  • The Solution: Whenever a user explicitly logs out of your web portal, your web development team must explicitly clear the Journey cookie by calling ac('page', { clearCookie: true }) or completely re-initializing the SDK. This breaks the link and ensures the next user starts with a clean anonymous slate.

Edge Case 2: External Contact Duplication

  • The Failure Condition: A user logs in via the identify event, but instead of merging with their existing CRM profile, Genesys Cloud creates a duplicate External Contact named “John Doe”. Now you have two profiles for the same person.
  • The Root Cause: Genesys Cloud resolves identity based on strict matching rules (usually Email Address or Phone Number). If your CRM uses an obscure Account ID, but Genesys only has the Email, and the user provided a different email during login, the system will not find a match.
  • The Solution: Implement a robust Custom Identifier in External Contacts. In Admin > Directory > External Contacts > Custom Fields, create a unique field (e.g., Salesforce_ID). Ensure your ac('identify') payload always passes this exact ID, and configure your Genesys Cloud identity resolution settings to prioritize this custom ID over email addresses for merging.

Official References