This article will try to introduce the Experience Platform Web SDK that is coming from Adobe. The Experience Platform Web SDK is also known as Alloy.js (following its github name) or Experience Edge.
Explanation on how this is coming from and what are the expectation of this tag are important for understanding when to use that new tagging system and what are the implication of that usage.
I will try to not copy / paste the, already, important documentation existing on this library and that you can find here. But I will try to highlight what is newly coming, what to expect and what will be the implication on Adobe solution
By the way, what I want to do or would love to be able to do on my blog posts is something like what Aaron Hardy did on his presentation of the AEP Web SDK.
So if you don’t like to read stuff and prefer watching a really cool video, you can go here : https://youtu.be/kvqXSrzJMQ0
Why a new library ?
If you are still here and didn’t give up because of the video, we can start.
First of all, we need to understand the reason of this new Web SDK for Experience Platform.
As I already explained on my previous articles, there is a new solution coming for Adobe. This is called Adobe Experience Platform (introduction here) and this solution is planned to be the “mother” application for most of the Experience Cloud Solutions from Adobe.
What I mean is that all of the current solutions that you are using at the moment from Adobe are going to be applications of Platform.
Analytics or Target data will actually consume data coming from Platform in the (far away) future and won’t own their data collection anymore.
This sounds like a huge deal and it is ! I announce that (own opinion here):
The shift we will see in our implementation logic for Adobe solutions will change not only the JS in place but how we think about data.
This seems either scary or exciting if you feel prepared or comfortable with data collection and manipulation.
Web Analyst will become real data analyst following this, the whole data collection happening on the web will become more holistic and better integrate to the whole company data structure (CRM data, NoSQL, etc…).
This will require upgrade of your skills, obviously technical skills but also business skills. Increasing the power of Web data will create an important overlap the other data teams within your companies.
As the data, that lived independently, will be able to flow seamlessly and complement each other, insights will become more powerful and platform agnostic.
Important. I want to add that this is the path that AEP will create but don’t worry, Adobe Analytics or Adobe Target won’t be discontinue, they will still exist as products and you will be able to use them without having Platform. They won’t disappear but a possible deeper integration will exist.
Nevertheless, as more and more cool things will come from that deep integration, I believe that more and more companies will want to use that integration.
What is different with Experience Edge ?
The AEP Web SDK is going to replace the following libraries:
- ECID (Experience Cloud ID Service)
- Audience Manager
- Target
- Analytics
And at the same time, serve as the JS library to capture data for Platform. It could be web application of course, but IoT is also targeted as several type of SDK will exist.
Everything will be unified into one Library so you can imagine that most of things attached to that library will change.
I will list the big differences that exist with Alloy and the different element that you have:
Endpoints
Yes, this is obvious but the endpoints that you have used before ( omtrdc.net, demdex, tt.omtrdc.net) will change, you will have only one endpoint at the end.
This endpoint will receive all of the data and then distribute it to the applications you have subscribed with Adobe, be it Analytics, Target or anything else…(more on that in another post about Launch Server Side).
You will have to realize some intermediary steps for the data to be completely fitting the old application data structure but we will come to that on a latter point.
CNAME
CNAME is not an option anymore, it is a pre-requisite for the implementation of that solution. You will have to set this CNAME for your website, thanksfully the process to create a CNAME with Adobe hasn’t been made easier over the years.
It is a best practice to set first party cookie and Adobe puts the CNAME as prerequisite in order to ensure consistent data.
You can find the explanation set for the Experience Cloud Service here : https://docs.adobe.com/content/help/en/core-services/interface/ec-cookies/cookies-first-party.html
Adobe has created a Managed Certificate Program that allows you to delegate the creation of the CNAME SSL certificate to Adobe.
At the anniversary date of the CNAME SSL certificate creation, Adobe will just contact you to ask if you want to continue this program.
PRO TIP: Give a team email or create one with multiple respondents. I have seen many times that either the contact person was gone or absent for a long period of time and program is turned off and crisis mode is fired on client side as no data are collected anymore.
Data Model
This one is going to be harder to accept as it will create a lot more work for the companies. As I already explained the big condition to use Experience Platform correctly is to have understood and applied the Experience Data Model Schema.
The Experience Data Model is a schema annotation that is compatible with Microsoft and SAP schema. That will facilitate the transfer of data between these platforms. It is definitely the counterpart of Google. 3 companies are big enough that other players of industry cannot ignore this schema composition, and you neither.
It will really help that you try to fit your internal data schema into a XDM at some point.
You may not want to transform all of your data to that schema, it may actually be useful to start scoping what you want to extract from your database and transform that data into a XDM schema.
But on the website, you will also need to plan your implementation following the schema structure (Pathing & Typing) and for the people I know working with JS, it is not common for them to have such constraint.
In my humble opinion, it would be the perfect time for you to set a TypeScript process on your company as TypeScript is a static typed JS, you could validate your schema usage while implementing it.
At the same time, if you are using Launch and Data Elements, because data elements can return anything, and it cannot be forced to return a specific type of dimension, using TypeScript wouldn’t really help there.
I created a blog post on how to think of your Data Model with Platform. I would recommend a read it if you are totally oblivious to this.
In any case, the possibility to work with (possibly unlimited) key value pair is something that has been wished for a looong time by the Industry and that should satisfy lots of people. (In comparison, Analytics is working with number dimension (eVar1,eVar2, prop1, etc…)).
Promise architecture
Alloy will use the JS promise to send data. It will mean that you could chain more and more things from the different instance of Alloy that you will create.
This change will finally shift the web tracking methods to the XXI century. If you are not familiar with promises, I will encourage you to read about it. You don’t have to be a master of JS to use or understand them but it is better as you can better grasp what will be possible.
At the moment, to not over-hyped this functionality too much (maybe too late), the main use case is to catch when there is an error on your data insertion. You can then define to do something when the promise return an error.
However, you could imagine the amount of things if Platform is starting to communicate information back to you on real time. There is no time wasted to act on data anymore. At the moment, you could at best some on page optimization based on Target Offer or Audience Manager cookie destination.
We used to dream of the possibility to realize everything (tracking, analyzing, rendering decision) into one call/request and Platform makes it technically possible from the get go.
Still time is required in order for the Product team to deliver this use case but this looks super promising.
And if you think this functionality is nice, let see what comes next.
Event Merge ID
The Adobe Experience Platform Web SDK would be pretty cool if you would have the different elements already presented before but it has “just one more thing“. I think of this as the “killer app”, the thing that makes you want to switch from your legacy implementation.
The killer app is the Event Merge ID. This feature will allow you to merge data (event) a posteriori. How cool is that ?
Github page on this : https://www.adobe.io/apis/experienceplatform/home/services/web-sdk.html#!api-specification/markdown/narrative/edge/fundamentals/merging-event-data.md
I know lots of customers that are sending multiple requests within one page and would be very happy to learn that they could merge this information into one request after everything is done.
Lots of unknown are still there for this feature because the possibility offer by it are quite huge. At the moment, I believe that these merge ID will only work for some minutes maximum when you are using Alloy.
So you could not merge completely 2 different events but it is technically possible and I believe that Adobe product team is working on a way to make it possible and also accessible for everyone.
The main obstacle is that the eventMergeId is a key that you are defining and possibly you can create 2 times the same key (by mistake), let’s say in the last 2 years. You don’t want these data to be merged obviously, but you don’t want to track all of the eventMergeID that you have created neither.
You could work with hash functionality and live with the risk of hash collision but I believe that there is a way that could satisfy everyone on how to deal with it and make it accessible.
When and How to use Experience Platform Web SDK?
First of all, you should get an access to Adobe Experience Platform. At some point all of the Adobe clients will probably have access to some core functionalities but that is the first requirement to be able to use the Experience Edge script for the moment.
Also, as described, it would be required to have a CNAME in place for your implementation. This will help setup first party cookie on your domain and avoid many of the pitfalls that 3rd party cookies will create.
As I explained above with the Data Model, a schema is also required .
You can create a schema by following these steps : Tutorial on Schema creation with Platform.
The schema that you will create will retrieve the different elements that you can track on the pages. On this step, there are some mixins that are already setup to track the web information. I already explained (in different blog posts) that it is better to create and use your own mixin but Experience Edge (EE) or Alloy is expecting some fields in place with specific path. At that points, it would be better to integrate the mixins directly so you are sure to create the correct expected paths.
- Consumer ExperienceEvent mixin
This mixin contains lots of different types that can be useful on a web implementation.- application information (crash, installs, upgrades, etc…)
- channel (content Type, media Type, etc..)
- commerce (checkout, order, cart addition, etc…)
- dataSource (tags)
- device (colorDepth, manufacturer, etc…)
- environment (ISP, carrier, connectionType)
- marketing (trackingCode)
- media (impressions, progress, timePlayed)
- placeContext (latitude, longitude)
- productListItmes (prodID, name, price, etc…)
- search (keyword, position, etc…)
- segmentMembership
- web (pageName, referrer, etc…)
- ExperienceEvent implementation details
This is supposed to be tracking the name and the version of your tracking.
All of this will probably evolves because as exhaustive as it gets, it doesn’t bring much flexibility so far.
I would advise you to create your own additional mixin to track the thing that is specific of your applications. And don’t forget about creating your own Identity mixin.
Once that schema has been created, you can use it to create a Dataset that is going to be the receiver of the data. The dataset will receive all data matching the schema notation.
Once you have your schema and dataset, you will be able to get a configuration ID. At the moment of this writing, this is something that can only be done by Adobe internally.
The configuration ID will tell Platform where this Schema data should go to.
In the future, I am sure that this process will be self-managed by the customers.
Once you have all of that, you can use alloy.js or Experience Edge to track your elements.
As you have probably realized when reading this blog post, this will give you some advantages :
- Lighter : only one library to manage is reducing code duplication and therefore the weight.
- Faster : This comes on par with the lighter element
- Real Time Ingestion : Data ingested by platform will be available on real time for activation.
The Adobe Experience Platform Web SDK can be implemented in different way on your website.
As with every Adobe solution you can do it yourself (using the github repo) or rely on the extension provided in Adobe Launch.
I hope this post made it clearer what the Adobe Experience Platform Web SDK, Experience Edge or Alloy is. In the future, I will try to create more blog posts on the best practices that Adobe recommend on the usage of that library but I think you can already start be excited about it.