Improved Visitor Identification using Adobe's First-Party Device ID

[#1]

By : Prachi Jain & Luc Forgeron

Introduction

Have you noticed your “Unique Visitor” counts increasing in your Analysis Workspace reports? Are you confident in the accuracy of your visitor identification reporting to personalize-at-scale? To set your mind at ease, Adobe, a leader in the digital marketing and customer experience domain, offers a powerful data collection tool known as the First Party Device ID (FPID), which empowers organizations to create stronger relationships with their customers. In this article, we will delve into the concept of Adobe's FPID and explore its benefits, applications, and best practices for effective visitor identification integration. 

Understanding Adobe's First Party Device ID 

The Adobe Experience Platform Web SDK assigns Adobe Experience Cloud IDs (ECIDs) to website visitors through the use of cookies, in order to track user behavior. The FPID can be used as a unique identifier to seed the ECID cookie, allowing businesses to collect and store user data securely within their own systems. In the past, if you were using a CNAME, your cookie was generated server-side, and the cookie lifetime was increased. However, with some browser policies limiting first-party cookies set using a CNAME, the lifetime is restricted to 7 days. To account for these cookie lifespan changes, you can opt to set and manage your own ECID device identifiers instead, which are referred to as FPID. 

Purpose

Organizations take the responsibility for setting and owning the FPID cookie server-side on their own website domain. The purpose of FPID is to seed the value of ECID to keep the persistence of a visitor ID due to browser restrictions on cookie lifespans.  

Support

FPID support is only available when sending data to the Edge Network via the Web SDK. The hybrid implementation of some pages on Web SDK along with some pages on legacy AppMeasurement.js is not supported.  

Benefits of Using Adobe's First Party ID 

1. More reliable Unique Visitor Count: Even with first-party cookies via CNAME (generated by Adobe), browsers still expire cookies after 7 days. Once the cookie is deleted, it results in inaccurate and inconsistent return visitor counts. The FPID solution allows organizations to have full control over their cookie lifetime spans and ensures more precise accuracy in creating and storing their real-time, streaming ECID service in Experience Platform. Even when a browser deletes the cookies after this extended period, it is possible to fall back upon the original seeded FPID value to renew that visitor’s session if the FPID cookie is present. 
2. Consistent visitor experience: The FPID solution will ensure customers can effectively identify site users over a reasonable amount of time and in a manner recommended by browsers. This enhances the ability to have a longer lookback window to understand customer behavior, leading to better personalization with one-to-one Target Offers and Experiences.. 
3. Stitching Data within Customer Journey Analytics (CJA) for authenticated and non-authenticated users using ECID: If the ECID is consistently generated from the FPID and is used as the "Person ID" in CJA reporting, it is now possible to tie authenticated and non-authenticated user behavior together across the full journey. 
4. Audience creation in RT-CDP: For stitching the anonymous profile to authenticated profile, you can create the segment in CJA by using ECID generated from FPID for authenticated and non-authenticated users. Once the segment is created, it is now possible to share it with AEP and RT-CDP to build your Audience. 

How to Generate UUID   

• Generate cookies using server-side scripting languages and not using client-side code. Cookies created client-side via a common programming language such as JavaScript using the document.cookie method will almost never be protected from browser policies that restrict cookie durations. 
• Only UUIDv4 format is supported. Generate a UUIDv4 and write UUIDv4 value to a cookie. 

How to set the FPID cookie 

• For any browser, the FPID cookie should be available before your Tags script is loaded on the page. 
• Having first-party domain (CNAME) enabled is required. If you already have a CNAME for Adobe Analytics, you should use that one. 
• The FPID cookie should be added to all the Edge Network calls on the page. 
• With a 2-year expiration, FPID cookie for every visit should be refreshed on subsequent visits 

Steps to Implement First-Party ID Client-Side Vs Server-Side 

 There are two ways you can implement the FPID Cookie: 

Client-Side (Inside Data Collection) 

 By passing the identity as a part of IdentityMap of your XDM payload. Steps to implement: 

• Create a Data Element using the “Adobe Experience Platform Web SDK” Extension, Type as “Identity map”. 
• Set the namespace as “FPID” and pass in the ID and authenticated state. Mark the ID as the Primary Identity.  It is not necessary to create a corresponding FPID namespace in Platform and the FPID values will be dropped and is not stored at the Edge Network.  

• Map your Identity Map (Web SDK) Data Element to your Page View/Load call which has the object identityMap. Once mapped, each Page View call will have the identity added in the XDM payload. 

 Server-Side (Inside Datastream) 

• It is not necessary to pass the FPID namespace as part of IdentityMap. For Datastream configuration under section “First Party ID Cookie Name,” enable the toggle button and include the First party ID cookie name as per your cookie set by your organization. 
• ECID will be created as a deterministic value derived from First party ID at the server. 

Validation: Reference Example 

Additional Use Cases for validation 

1.  Cross-domain scenario using first-party ID as primary identifier: FPID is not designed to solve for cross-domain tracking. For alternatives, refer to Cross Domain Documentation and Google related website documentation. 
2.  Consent scenario using first-party ID as primary identifier: If an existing visitor has opted-out of data collection when FPID is already implemented, the visitor will maintain the same existing ECID and FPID once they opt back in upon future visits. 
3.  AMCV cookie takes precedence over FPID: If your implementation has subdomains using multiple Data Collection Tags Properties within the same IMS Org. when the ECID cookie is already present, it will take precedence over the FPID being set. 

Common Questions About Implementation 

1. What happens when you migrate ECID from Visitor API checked box to the Web SDK?

• If you are migrating from a legacy implementation (AppMeasurement.js) to Web SDK, you should check the checkbox to migrate you're existing ECID to Web SDK. At this point, the identifier used to identify the visitor will be ECID contained in the AMCV cookie. 

2. What happens when both AppMeasurement.js and Web SDK are loaded on the page with FPID implemented?

• It is not recommended to implement FPID if both VisitorAPI.js and Web SDK are loaded on the same page. The existing ECID cookie present on the pages will take precedence.
• If some pages have AppMeasurement.js while others have Web SDK, depending on how user navigates on the sets of pages back and forth, we may break the identifier to seed the ECID value from FPID if ECID cookie is present. The recommendation is to implement FPID only if all the pages are on Web SDK. 

3. What happens when you have “third-party cookie” checked in the WebSDK extension? 

• The setting should be unchecked. If you are still using a third-party cookie then you should migrate completely to first party cookies to leverage FPID. In the demdex use case, there is no option to migrate to a first party cookie - you can only disable the third-party cookie. 

4. Can we pass the FPID value in the data layer? 

• Yes, you can pass the consistent FPID value to persist in the data layer. The data layer should be loaded with the FPID value before any Adobe solutions are loaded on all pages. If the FPID value is set in the data layer, the only way we can implement FPID will be a client-side implementation. 

5. Can we write the logic client-side to set FPID value in cookie?

• Yes, you can write the logic client-side to set FPID value in a cookie. However, cookies set using JavaScript’s document.cookie method will almost never be protected from browser policies that restrict cookie durations. It is recommended to generate cookies using server-side scripting languages. 

6. Can we implement FPID in Mobile Applications? 

• FPID is not supported for Mobile SDK. In the AEP Mobile SDK, the ECID is generated at the device-level while the Web SDK ECID is created on the server-side. With the Mobile SDK, we do not currently have any restrictions in terms of ECID lifetime.  

Conclusion   

By giving you and your organization the power to more accurately identify your website visitors, FPID serves as the foundation for better understanding your customers, giving you a unified view of their interactions with your brand, and enabling you to drive more personalized engagement while building long-term relationships.