ECID Migration with AEP Web SDK

[#1]

Author: JB Creusat

The Adobe Experience Platform Web SDK (AEP Web SDK) is now available and brings significant performance improvements but also changes in terms of data collection. One of the first questions is whether Visitor identification will be impacted. In this article, we will explain how the migration to the AEP Web SDK works and how to plan.

While the different libraries required by Adobe Analytics, Target and Audience Manager are being replaced by a single SDK, the Experience Cloud ID (ECID) remains as the way to identify your visitors. The VisitorAPI.js is no more longer required when you are using the AEP Web SDK. If you are using Adobe Launch, you will simply remove the ECID Extension and check the box for the ECID migration in your AEP Web SDK Extension.

One pre-requisite for this simple migration is that your implementation is fully on the ECID. If you are not sure, a first test is to compare Unique Visitors against Visitors with Experience Cloud ID. With Adobe Launch as a tag manager on all your pages, you control your code delivery and you can update your implementation. If Launch is not yet fully deployed, this should be your priority.

When migrating to the AEP Web SDK, there are several considerations other than the ECID. This article is focusing only on the ECID migration. Also note that you don’t need to deploy the Web SDK on all your pages: you can phase the deployment and deploy the AEP Web SDK first on a section of your site.

The process is as follows:

1. Confirm you are only using ECID (usually the case when using Adobe Launch)
2. Update your Launch implementation (enable the Web SDK and remove the legacy libraries)
3. Update your set Customer ID rules
4. Deploy additional processing rules to collect ecidECID, AppMeasurement Code version, Page Domain
5. Validate your processing rules
6. Push your code in production
7. Monitor

Important : if you are still on Grace period or if you are still using the legacy visitor identification, you will have first to fully move to the ECID. Otherwise, you will have what we call visitor cliffing. To test this on your site, Cclear your cookies and cache, then check your image requests:

• If you have a “mid” AND an “aid” parameter, you are on Grace period
• If you don’t have a “mid” parameter, you are still using the “s_vi” cookie

At this point, the AEP Web SDK doesn’t handle the “aid” parameter. But also bear in mind that one of the main use cases or reasons to migrate to the Web SDK is to simplify your implementation around A4T: one of the key requirements to use A4T is to be fully deployed on ECID.

Phasing the deployment of the Web SDK

As mentioned, you can deploy the AEP Web SDK only on some parts of your site. If you are using the Launch Extension, this is the “Migrate ECID from VisitorAPI to Alloy to prevent visitor cliffing” in the Identity option. If directly using the AEP Web SDK, this is done by setting “idMigrationEnabled” to true.

Per Adobe documentation: “if true, the SDK reads and sets old AMCV cookies. This option helps with transitioning to using Adobe Experience Platform Web SDK while some parts of the site might still use Visitor.js. If Visitor API is defined on the page, the SDK queries Visitor API for the ECID. This option enables you to dual-tag pages with the Adobe Experience Platform Web SDK and still have the same ECID.”

Unlike the Grace period that was used when transitioning from legacy s_vi cookie to Visitor.js, this doesn’t require any involvement of Client Care to apply a configuration on our servers. You simply configure this at the AEP Web SDK level, and if you are using Launch, once all your pages are using the AEP Web SDK, you can disable this option.

Validation and monitoring

When deploying with the AEP Web SDK, you will assign values through processing rules. You don’t assign anymore directly props and eVars. If you want to monitor in real time that your visitor ID remains the same with your new code, one option is to leverage Real Time reports.

In your legacy implementation, collect the “mid” in a context data variable:

s.contextData['ecid.mid'] = (typeof(Visitor) != "undefined" ? s.visitor.getMarketingCloudVisitorID() : "not set");

You can then create processing rules to collect your “mid”, both on the legacy implementation and in the new implementation. In this case, I am using prop35:

The context data using the Web SDK is provided out of the box: a.x.identitymap.ecid.0.id

Configure a Real Time report. I recommend “mid”, “AppMeasurement Code Version” and “Page Domain” (these two dimensions can be set directly in processing rules if you are not already collecting them).

Next, visit pages with the legacy and new implementation. You will notice that the data coming from the Web SDK (“O-ally-2.4.0” being the version used in the example below) comes way faster since there is no extra processing introduced when you have the Target “sdid” in your data collection.

For Console debugging, you can view the ECID by calling the following function directly in the Console

alloy(“getIdentity”)
    .then(function(result) {
    // The command succeeded.
    console.log(“ECID:”, result.identity.ECID);
    console.log(“RegionId:”, result.edge.regionId);
    })
    .catch(function(error) {
    // The command failed.
    // “error” will be an error object with additional information.
    });

Migrating your set Customer IDs

If you are using Customer Attributes or Audience Manager, you will need to update your rules. Let say you had the following action:

You would need to pass your integration code and value into the identityMap. You can either set this directly in your data layer or use the Web SDK Extension.

"identityMap": {
    "userid": [ // Replace by your integration code
        {
        "id": "1234",
        "authenticatedState": "authenticated",
        "primary": false
        }
    ]
    }

Additional considerations

• Data feed: there is no impact on data feed. Visitors are counted the same way. But once again, make sure that all your visitors are on ECID before migrating as otherwise you will cliff visitors.
• Visitor deduplication: we’re only talking about ECID migration, not changing to a custom ID etc. For merging visitors and advanced attribution, you need to evaluate CJA and Real Time CDP for activation.

Originally published: Jun 28, 2021