Wrong Person, Right Device: Solve Shared Device Profile Mix-Ups with Launch

[#1]

RTCDP profile collapse due to shared devices represent some of the most complex challenges in the fields of Analytics and Personalization. Virtually every business leveraging digital platforms for personalization had to confront this issue at some stage.

In simple terms, profile collapse occurs when two different users share the same device to browse a website—for example, family members at home or colleagues on a common office computer. Since both sessions generate the same ECID, the RTCDP identity graph links their profiles together. As a result, personalization content meant for one user may be incorrectly shown to the other.

Here are a few examples of how profile mix-ups can lead to the wrong content being shown to users:

• A wife sees credit card offers meant for her husband.
• You start seeing hotel deals for a destination your colleague booked a flight to.

      

Adobe has introduced few workarounds to address this challenge, though each comes with its own set of advantages and limitations. In this white paper, we present another potential workaround using Launch + WebSDK - along with its implementation approach, and a detailed review of its pros and cons.

Implementation Approach

This solution can be implemented through Adobe Launch, though the same approach can also be applied on the server side. It is best suited for businesses that require users to log in—ideally at the beginning of their journey.

Once a user logs in to website, their UserID (encrypted) is stored in a cookie or in local storage. Local storage is the preferred option, but if the website is designed to clear it frequently (for example, after logout), cookies are the better choice.

The stored value remains until another user logs in on the same device. On each page view, the system checks whether a UserID is present and compares it with the stored value. If it matches, the cookie’s expiry time is extended to a future date. If there is a mismatch, the stored UserID is replaced with the new one.

This process will continue every time new user login to the website.

 

Below is a sample snippet that can be placed within the pageview event. This ensures the UserID is checked against the stored value in a cookie, updated if necessary, and the cookie storage expiry is extended appropriately. Same approach can be used with local storage as well.

try {
  function getCookie(name) {
    const cookies = document.cookie.split(';');
    for (let cookie of cookies) {
         cookie = cookie.trim();
         if (cookie.startsWith(name + '=')) {
            return cookie.substring(name.length + 1);
         }
    }
   return null;
}

function delete_cookie(name) {
    document.cookie = name + '=;expires=Thu, 01 Jan 1970 00:00:00 UTC;path=/;domain=.abc.com';
  }

  //Setting User ID into local storage when User ID is available in the cookie
  if (_satellite.getVar("User  ID") !== undefined && _satellite.getVar(''User  ID") != "" && _satellite.getVar(''User  ID") != null && (getCookie("UserID") == null || getCookie("UserID") == "" || getCookie("User ID") === undefined)) {
    document.cookie = "UserID=" + _satellite.getVar(''User  ID”\ ") + "; expires=Thu, 18 Dec 2050 12:00:00 UTC; path=/;domain=.abc.com";
  }

  // Checking cookie User ID and Local Storage is same or different AND if User ID is available in local storage
  if (_satellite.getVar(''User ID") !== undefined && _satellite.getVar( "User ID") != "" && _satellite.getVar("User ID") != null && getCookie("UserID") != null && getCookie("UserID") != "" && getCookie("UserID") !== undefined) {
    if (_satellite.getVar("User ID") != getCookie("UserID")) {
      delete_cookie('AMCVS_XXXXXXXXXXXXX%40AdobeOrg');
      delete_cookie('AMCV_ XXXXXXXXXXXXX%40AdobeOrg');
      delete_cookie('kndctr_ XXXXXXXXXXXXX_AdobeOrg_cluster');
      delete_cookie('kndctr_ XXXXXXXXXXXXX_AdobeOrg_identity');
      delete_cookie('kndctr_ XXXXXXXXXXXXX_AdobeOrg_validation_token');
      document.cookie = "UserID=" + _satellite.getVar("User ID") + "; expires=Thu, 18 Dec 2050 12:00:00 UTC; path=/;domain=.abc.com";
    }
  }
} catch (error) {
  console.log("Tracking error pageview rule" + error.message);
}

Key considerations:

• In the WebSDK extension of Launch, “Use third party cookies” checkbox should be disabled. If this option is enabled then system will generate the same ECID using demdex cookie even if we delete the AMCV or Kndctr cookie.
• If there are multiple websites with different launch properties with in the same org, then ensure you are using same tracking code/CNAME across all the launch properties. Also thorough validation is required across all the websites.
• Resetting the ECID often will lead to multiple ECID linked to same profile in AEP. But this should be a problem as all the ECID’s belong to the same user ID.
• Identity Service will apply a “first-in, first-out” mechanism and deletes the oldest identity to make space for the newest identity in the identity graph.

Impact of the Proposed Solution on Analytics, RTCDP and CJA

• User ID & ECID Mapping
  Each User ID will now be mapped to a unique ECID, eliminating profile merges that occur when multiple User IDs are linked to the same ECID
• Personalization Accuracy
  Personalized offers will be delivered to the correct segment of users, eliminating the risk of mis-targeting caused by profile overlap.
• Unique Visitors (Adobe Analytics)
  Because new ECIDs are generated, the ECID count—and therefore the Unique Visitors metric in Adobe Analytics will appear inflated. However, reporting in Customer Journey Analytics (CJA) will remain largely unaffected.
• Profile Count (AEP)
  Delinking shared-device profiles will increase profile counts in AEP; careful planning around edge guardrails and the resulting licensing/cost implications is vital here.
• Return Visits / Visitors
  Frequent resetting of ECID breaks continuity of the original visit, resulting in lower return visit and return visitor counts
• Server Calls
  No impact—Analytics server call volumes remain unchanged.
• Attribution (Adobe Analytics)
  Attribution logic in Adobe Analytics for will be impacted, specifically for campaigns and marketing channels. Earlier, attribution spanned all user IDs linked to a single ECID. With the proposed approach, attribution will be limited to the ECID associated with the most recently logged-in user ID

Conclusion

The proposed solution, strengthens personalization accuracy, ensures cleaner identity stitching, and reduces the risk of mis-targeting. At the same time, it introduces side effects such as inflated unique visitor counts and potential impacts on attribution in analytics. This solution is best suited for the organizations which are planning to decommission AA and migrating to CJA. Because unlike AA, CJA will use user ID for person metrics calculations, instead of ECID.

Ultimately, addressing profile collapse is less about finding a perfect fix and more about adopting the most balanced strategy for the business context. Organizations must therefore weigh the benefits against these reporting considerations, while also planning for licensing and cost implications in AEP.

[#2]

@archanasnarayana Nice Article. Thanks for sharing!