Adobe Experience Platform (AEP) Web SDK refers to a JavaScript library that can exchange data with the AEP Edge Network. It can replace your Adobe Analytics ‘AppMeasurement.js’ and Adobe Target ‘at.js’ implementations, while also sending data to AEP services like Real Time Customer Profile. But it doesn’t have to replace your existing set up either, even if there are benefits in doing so. If you are confused with AEP then I recommend reading Jim Gordon’s AEP Dictionary for some guidance on the terms that Adobe uses. AEP is a pretty broad term and is often used to describe several services.
Back to Web SDK. What’s the point of a new library and implementation? The short answer is that Web SDK is the next iteration for the Adobe stack of web measurement tools bundled together in one library. It’s a consolidation of the various Adobe libraries which manage identity, measurement, optimsation and personalisation. It works by exchanging data to/from the Edge Network, which Adobe describes as a distributed network of servers that enable a new methodology for deploying Adobe products. Web SDK sends data to an Edge Network server, which sends data onwards to destinations like AEP, Analytics and Target. These platforms can also reply, and send information back to the Edge Network which responds to the initial request made by Web SDK. This powers identity services, optimisation activities and more. This is done through one JavaScript library and one network request.
This article goes into implementing Web SDK to a site through Adobe Launch. In this first part I will walk through the set up required before actually sending any data.
But First… XDM Schemas
When you hear Web SDK and Adobe Experience Platform you will also hear about XDM schemas, and you might see images like this one.
Put simply XDM schemas are a format of data sent to the Edge Network – and luckily for us it’s essentially a JSON style format. Think of Adobe Analytics data collection using eVars and events to send custom variables and metrics. The eVar values are translated into parameters (v23, c64, etc) sent to Adobe Analytics. This is a very platform specific format of data, it’s only relevant to Adobe Analytics. The intent of XDM is to standardise data going into any Adobe platform (and some third party platforms too) to improve usability, maintenance, standards, governance, etc. You can define your own XDM schemas for your own use cases.
The first task for any Web SDK or AEP implementation is considering an XDM schema.
I could write a whole article on XDM schema creation, as there is a lot to learn. What you are doing by creating a schema is making a ‘solution design’ of sorts. An XDM schema is a structured collection of fields and groups of fields, each with specific types. This phase will take a big chunk of time because you need to ensure that you are setting yourself up for success in the future. The Adobe documentation is a handy reference here. For my examples I am going to set up a pretty basic schema to be used by Web SDK to send website events to AEP.
You can change your schema in the future, but generally it’s better to be additive. In other words once you create a field try and stick with it, and add new fields if required, rather than removing it. This is to ensure best compatibility into the future as your implementation develops.
XDM Schema = Class + Field Groups
Every schema starts with a “class” which defines the type of data the schema relates to. There are two default ‘core’ classes which can serve a great variety of cases, the XDM ExperienceEvent and XDM Individual Profile. XDM ExperienceEvent is a class to capture event data, such as website interactions, app events, log records, etc. XDM Individual Profile is a class used to capture data representing an individual person or entity. It’s not an event that happens at a particular time, rather it’s details about an individual.
For a Web SDK implementation I will start with a schema built on the XDM ExperienceEvent class. You will find the schema interface in Adobe Launch or Adobe Experience Platform.
Once there you will be able to create a new schema based on the XDM ExperienceEvent class. That will open the schema creation interface shown below.
The default fields for an ExperienceEvent are shown. You can now go ahead and add Field Groups to the schema. Field Groups are defined groups of fields by Adobe or by others that save you having to add common fields by yourself, though feel free to create your own Field Groups too. You may have heard the term “mixin” which is an old name for Field Groups. There is a Field Group titled “AEP Web SDK ExperienceEvent” made by Adobe to support some key fields used in most Web SDK implementations. I will add this to my schema.
As you can see above, adding a Field Group adds a bunch of fields for you to explore. In this case several objects were added such as the “web” object. Expanding this object reveals the fields inside. This particular Field Group is important for Web SDK implementations that intend to be used for Adobe Analytics data collection as some of these fields are mapped into Adobe Analytics fields automatically later in the process.
I’m not going to create any custom Field Groups or Data Types here and I’ll proceed with the simple schema above.
Another thing to do now is to create a Dataset based on your schema. A Dataset is only relevant to Adobe Experience Platform so if you don’t have AEP or don’t intend to use it, you can skip this step. It’s a place to store data to be used by various AEP services like Real Time Customer Profile, Customer Journey Analytics and Query Service.
Once you have a schema you can move to configure a Datastream.
Datastreams
Datastreams are basically configurations of the Adobe Edge Network. (In fact they were once named Edge Configurations.) You can find it on the side menu just like Adobe Launch properties and XDM schemas. When you create a new Datastream you will need to specify an XDM schema and then set up platforms, such as Adobe Experience Platform, Adobe Analytics, Adobe Target, etc. These tell the Edge Network what to communicate with after recieving data. In the example below I’ve set up a Datastream to talk to Adobe Experience Platform only. This means data sent from Web SDK will only go to my AEP Dataset for now.
The configuration options for Adobe Experience Platform allow you to specify the Dataset you created to store the data. There are some other options, which I will leave as default for now.
In this example I’ve only set up AEP as a connection to my Datastream. If I were to set up Adobe Analytics then I would need to specify a report suite. Sending data to Adobe Analytics via Web SDK means choosing a report suite and then mapping any eVars, props, and events from XDM in processing rules. There are nuances here and I will write a seperate post about this topic soon!
WebSDK and Adobe Launch (Data Collection)
Once you have a schema defined and a Dataset created you are ready to get into the tag manager. AEP Web SDK is ideally deployed through a tag manager for the same reason as any analytics library – a tag manager gives you flexibility and abstraction from development cycles of the website or application. Adobe Launch is a great choice since it integrates very easily with Web SDK. Adobe has made an extension which makes it simple.
Setting up this extension is quite fast, and a number of settings are set up automatically. Again the Web SDK extension Adobe docs are quite good here. You will need to specify a Datastream to connect to as this lets Web SDK know where to send event data. If you got this far then you can see the process boils down to creating an event schema > creating a datastream to communicate with various services > installing the extension. That’s the initial set up done – you are almost ready to actually send events!
In the next part I’ll actually send some events and test to make sure everything is working.