Experience Cloud ID – and other user IDs

This article will focus on the Experience Cloud ID service, what it is for, how does it work and the possible configuration you can have with it. This article will also cover the different method you can use to link your system with the Adobe ID that is being generated from the Experience Cloud ID service.

What is the ECID and why it exists ?

The Experience Cloud ID (ECID) is the global identifier for the Adobe solutions.
Adobe Analytics, Target or Audience Manager were different solutions in the past and they had their own way of creating a visitor id cookie.

Each solution was using its own server and that made it impossible to create a global registry of unique visitors. This lack of communication was creating different way to address the visitor with the different tools and therefore avoid any global user experience.

Adobe Ecosystem

Soon Adobe realizes that it would make things so much easier if the solutions were able to see the visitors the same way. This would enable the Adobe solutions to communicate between each other.

As Adobe Audience Manager was the solution closest to have this kind of setup because of his cross browser id generation service (AAM UUID), it has probably been decided to use that server, who is actually already in use for that kind of process.

Therefore the ECID is using the demdex domain for the generation of the ID. This domain is attached to Audience Manager, thus, on some plugins you can see that Audience Manager is used on your domain even if you have never bought this solution.

To make things a bit more difficult for the clients to understand, the ECID hasn’t always been named that way.
At first, Adobe tried to apply this solution to Adobe Analytics (as a test maybe?) and they called it Marketing Cloud ID, aka MCID (because it was used with Audience Manager : Marketing purpose). it was also named MID because of Marketing ID.

Thereafter, it has been extended to all the solutions and “marketing” wasn’t really meaningful, also it could brings possible suspicions even if you didn’t use that for Audience Manager (the Marketing activities of the Adobe Solution at the moment).

However, you may still face this naming (MCID) on some of the documentation or tools.

Implications of ECID

Having the ECID implemented brings lots of implication and the most famous one is the ability to use the different Adobe solutions and use a single mean of identification for the users.

With this solution, Adobe Analytics is able to understand when you are doing a Target Experience and you can share segments between Analytics, Target and Audience Manager. Actually, I believe that this process is misnamed, you are actually assigning a name on an audience bucket. The segments you have created is calculating the ECIDs that match the conditions set and create a pool of users, this pool of users (or ECIDs) is then share with the different solutions.

The other implication of the ECID, as it is implemented by default, is the ability to have a cross-domain identification. For a long time, the visitor ID was set and calculated on the domain of the website it is run. The ECID service, by using the demdex domain, is able to have single identifier for all of your domain.

Contrary to the believe, the ECID is not unique to the user, it is unique the user client. It turns out that the ECID genereation is unique for each Experience Cloud client, because it takes your Organization ID as component for its generation. In other words, the same user will have different ECID for different organization.
On the other hand, the demdex ID, which is used by Audience Manger for sharing audiences to partners is a unique identifier across brands, organization and domains.

Another implication of the ECID is that you need to run this service quite high on your website implementation strategy. As it servers as your identification service, it needs to run before your Adobe solution so the Experience Cloud ID is either recognized or generated before the adobe solutions run.

It is generally not a problem when you run Analytics and / or Audience Manager but it can be quite a challenge for Target. Target is usually also quite high on your load priority, within the asynchronous worlds where we live in, it may turns out to be difficult.
If you are using Launch for your implementation, you don’t have to worry though, Launch inner mechanism make sure that the Experience Cloud ID service extension is ran before any other extension.

Last but not least : Analytics implication

And the last implication I will discuss is about the analytics visitor ID. Last but not least I would say.
Analytics is now preferably using the ECID as its method of identification HOWEVER it is not the one that is used by default on Analytics. The reference is quite hidden but here is the link.
The Analytics servers will first look for the s.visitor to be used as identification, then the s_vi, the legacy, domain-bound id and only after it is looking to the ECID.

Therefore it is a must that you are not setting the s.visitor if you want to take advantage of the Experience Cloud ID for other solutions. If you do so, Analytics will then use your s.visitor value as user identification and will not be able to connect to other solutions such as Target or Audience Manager.
The s.visitor was a good intention so that companies could use their own ID for doing cross-device identification but it ran short for the compatibility of this method with other tool.
Important to know; if you set the s.visitor in the middle of a user session, it will split that user session in 2. Data before and after the s.visitor is set are independent from each other because they are attached to different Unique Visitors.

The legacy s_vi ID is a default mechanism that Analytics used when the Experience Cloud ID is not available. Therefore, make sure you have it in place, because if Analytics doesn’t find it, the s_visitor ID is used and create a new Unique Visitor on your session.

If you want to check that you are using the mid within the analytics requests, you can open your network tab in the developer console and check if the mid key-value pair is filled.

How to use the ECID with other IDs

OK, so far we understood why the ECID has been used and how it is connected with Analytics, for user identification. If you are not sure how it is reflected, here is the direct view on your reports :
Number of Unique Visitors = Number of different user ID collected.

I didn’t put Number of ECID collected because you may use a mix of ECID, s.visitor and / or s_vi IDs. I hope you don’t but it may happen for very specific reason that you need to do that. E.g. : Using mparticle for your mobile application, their direct integration with Analytics works with setting the s.visitor to the Mobile Device ID. Which is a clean solution but it is not compatible with other Adobe solutions.

If you are a bit of a critic (critic can be good and bad), you may be think that it is kind of chain that you are creating. At the end, you may want to use your own ID for the analysis and you don’t want to be bound to Adobe ID service.

If you want to use the full power of the Adobe solutions, you will need to be bound at some point. It will also make your life a lot easier when / if you are expanding solutions in the future. However, it is possible to use your own ID with the different Adobe solutions (Analytics, Target and Audience Manager).

I already described the way you can do it for Analytics and Target mostly, it is done by what is call the setCustomerIDs. This will set a secondary ID to the users and you can then upload the data that you have with your customer ID to what is called Customer Attributes, here is the link to my article on customer attributes and on how to use them.

For the ones that are familiar with Analytics, the customer attributes process is similar to the classification. An attributes is a classification value attached to a user.
The advantage of customer attributes over classification, because you could track the customer id into a prop or eVar and classify them, is that it is faster and it is not limited by the low-traffic limitation.

The best practice is that you upload segments qualification into user so you can use your internal segmentation on Target or on Analytics analysis.

Adobe Experience Platform & ECID

The future of Adobe is Adobe Experirence Platform, you may have heard of it. This solution will be the base of most of the current solutions being used at the moment.
With this new solution the Experience Cloud ID will still be used but will not be the only one you can use.

As we have seen during this article, the ECID is, at the moment, the main (and kind of unique) identification service that you can use in order to link your users within the different Adobe solutions.

In the future, the ECID will be one of your identifying key for your users but he won’t hold any particular place within your user identification process. When you are extracting your data, you can also use your own key to realize ID stitching.
It will be helped by the Identity Service that Adobe Experience Platform will use but mainly you would need to declare it on your schema (see XDM schema)