Lessons Learned Adobe Web SDK

If you are currently involved in any way with Adobe Experience Cloud, then you have most certainly heard about the new Adobe Experience Platform Web SDK. It is the newest product in the Adobe Experience Cloud lineup for data collection. In addition to being the preferred method to sending data to Experience Platform, the Platform Web SDK contains a client-side JavaScript library that, by using the AEP Edge Network, a connection can be made with many of the Adobe Experience Cloud tools such as Adobe Analytics, Target, or Audience Manager. This change in implementation and deployment of the above-mentioned tools is the biggest change to data collection as Adobe Experience Platform Web SDK is intended to replace the existing libraries across the various Adobe Experience Cloud solutions.

To better understand this new offering, lets first compare a legacy implementation and an AEP Web SDK implementation.

Platform Web SDK vs Legacy Implementation

First, let’s clear this up quick: this is not a replacement for Tags (Formerly Adobe Launch), and it does not eliminate the need for a Tag Manager. Platform Web SDK is an extension for Tags that streamlines the implementation of “alloy.js”, the new JavaScript library that replaces existing Adobe applications libraries. A Tag Manager is still recommended to deploy alloy.js. On our maiden voyage, and the one being discussed in this blog, Tags was the tag manager of choice and Web SDK the extension used.

The Platform Web SDK houses “alloy.js”. the data collection library that will be utilized to inject web data into the Edge Servers and subsequently into the other Adobe Experience Cloud offerings (which will be discussed later). This is a complete rewrite of all existing libraries that were used by Adobe. Using the Web SDK is an entirely new way to implement the Experience Cloud.

This blog is going to better prepare you to make the decision or to begin the migration from any previous JavaScript libraries to the Platform Web SDK. Implementing a single library for all data collection comes with many benefits starting with faster page performance, reduced latency, and a single source of data to be used across the Adobe Experience Cloud. This minimizes data discrepancy as individual Adobe solutions will receive data server-side using the Adobe Edge Network.

Being in data collection for close to 10 years this is the biggest change in how it’s done I have ever seen. This was a learning experience to say the least. In this blog, we will discuss a few specific migration scenarios and how to address them:

• Schema Creation
• Data Collection
• Validate Data Collection

Schema Creation

Migrating to AEP Web SDK means creating XDM schemas that will hold our data. This must be done before even starting to think about data collection. So, this means before you get to the good stuff there is quite a bit of preparation required before you can start with data ingestion in AEP and/or Experience Cloud solutions. What you are doing with the XDM is building the container that will hold all your variables that will be used for tracking later. This step does require some understanding of how Platform works and the limitations. This is done in AEP -> Schemas -> Create schema -> XDM ExperienceEvent. Once generated you can add a set of field groups. We will start with the “AEP Web SDK ExperienceEvent Mixin” field group.

The pre-defined schema of this field group loads what Adobe estimates are the minimum and most common fields needed for web behavior measurement. However, without customization you will note you are presented with many limitations in data collection:

Once you arrive at this section my first lesson was learned. To begin forming real-time customer profiles, a schema must be enabled for Profile; and once a schema is enabled for Profile, it cannot be disabled or deleted. Also, fields can no longer be removed from a schema with Profile enabled. This was a step I was unaware of as our implementation was fluid. Fields were added that later, due to unforeseen changes in architecture, needed to be removed. Thelesson learned here was to always do the following:

1. Build out your dataset architecture
2. Collect some data into your datasets
3. Address any issues that arise during data collection
4. Enable your datasets and schemas for Profile
5. Collect new data

Data Collection

To make sure there is data consistency across Adobe solutions, Adobe Experience Platform Web SDK only supports sending data that has been structured to match the XDM schema (which is why the above is so important). Customers can leverage Tags within AEP Data Collection, which provides a new data element called XDM Object for mapping data to the XDM, and that will be passed within Rules to generate data. This is only necessary for the variables that are not auto-generated within your schema which can be found here.

The steps we created to capture data were as follows:

1. Create Data Elements by type
   1. Custom Code Data Elements
   2. Core Data Elements
   3. Data Layer Data Elements
   4. Mapping Table Data Elements
2. Create Rules
   1. Events
   2. Page Loads
3. Write processing rules for Adobe Analytics

This was also a point of learning as early on within the implementation specific events were generated for every single event that occurred on the site and every data element had to be specifically mapped to every single event. This led to an immense amount of work as I have yet to mention that your Rules and Data Elements are specific to the environment. This means that for each lower environment leading up to your production environment you: build a schema, create your data elements, configure your Tags rules, and configure processing rules in Adobe Analytics (discussed later). To help streamline this process we introduced the Adobe Mapping Table extension, by following this great blog post by Benedikt Wedenik (the creator of the extension) on scaling a Platform setup. This allows for you to set a source data element and define output associated to that data element. Then within Rules you can create a rule for Events and a rule for Page Views using the mapping table data elements only the populated variables will pass with that rule.

So that’s it right? We have built the data elements and we have written our rules. Data is coming in. Not anymore. With the AEP Web SDK you must take your XDM data and map that to Adobe Analytics variables. As of this writing, this is done by writing processing rules that convert your XDM data to props, eVars and events. Adobe has said that a new way of mapping Analytics variables will streamline this effort, but for now, our learnings. At first the processing rules were written for each event and then every prop or eVar that was associated to that event was written, this also caused a lot of additional work hours so the solution here was to build 3 types of processing rules:

1. Events – setting the context data event types set in your mapping tables to events in Adobe Analytics
2. eVars – one processing rule that sets all necessary XDM fields to equal the associated eVar in Adobe Analytics
3. Props – one processing rule that sets all necessary XDM fields to equal the associated props in Adobe Analytics

Validate Data Collection for Adobe Analytics AND Adobe Experience Platform

In our case we were implementing both Adobe Analytics and Experience Platform solutions. In this section, we will review how to validate that your data is getting to both. As said earlier, data collected from the page is sent via the Adobe Edge Network and then then can be routed to individual solutions such as Adobe Analytics and AEP. The data comes into Adobe Edge formatted in XDM from the data layer. While this approach creates a single avenue of data coming into the Adobe stack there are more points for failure. While you can validate in Analytics using Real Time reports, there are 3 others points of validation that need to be verified. Those steps are:

1. Data Layer
2. XDM Data
3. Processing Rules
4. Analysis Workspace

First to validate the data layer you will go directly to your website and within Developer Tools you can view the data layer within your console. From there you can view the data layer available for ingestion at both page load and events. This helps when you are building an event driven data layer, which for the Web SDK I strongly recommend.

Once you complete the data layer validation, using the Chrome extension Adobe Experience Platform Debugger you can view the XDM records being sent into the Adobe Edge Network and whether they are formatted properly or not. This is a necessary step to assure that your expected values are making it into AEP because AEP has strict formatting requirements. This was an issue we faced with return values being sent as strings when they needed to be sent as integers.

After you have validated the XDM records are being sent properly, a processing rule validation must take place for Analytics. For this we used the Adobe Experience Cloud product Project Griffon. In Platform Debugger you can start a Griffon session and review the output once the Analytics processing rules run in Project Griffon. This is a good step in validation as you can assure your processing rules have been set as needed.

The final step is to validate if the data is coming in correctly for that Analytics report suite. Using Adobe Analysis Workspace, you can build out a project to make sure that the XDM data from your schema has been sent to Adobe Analytics and available for user consumption.

As you can see with the new Adobe Experience Platform Web SDK Adobe has certainly changed the game when it comes to data collection. The expansion of how we collect and consume data provides many opportunities to enhance your ability to make data driven decisions within your organization.