Web SDK Part 3: My biggest mistake...

[#1]

In part 2 of this series I gave you a basic technical guide on how to get Adobe Analytics working with Web SDK. In this article, I will expand out more details of my recommended approach, particularly around how to efficiently populate the XDM Object.

However, before we get on to what to do, I'm going to start with what not to do and my biggest mistake!

Mental model

Prior to using the Adobe Web SDK, based on years of successful deployments(!), I had a very strong mental model of how Data Collection - Tags should be set up to support Adobe Analytics.  My basic mental model went like this:

1. Set a data layer in the website
2. Read the data layer into Data Elements, normally on a one-to-one basis
3. Use rules (which contain most of the logic) to:
   • apply conditions to our data processing
   • concatenate Data Elements together
   • map Data Elements to Adobe Analytics variables
   • send data back to Adobe Analytics

My biggest mistake was initially sticking rigidly to this mental model and trying to impose this on Web SDK.  While an early attempt to use a fair amount of custom code to enable us to continue as we always had technically worked, it resulted in a complex setup and moved us away from Adobe's intended approach - don't make the same mistake!

In fact, most of my preconceptions about the relationship between Data Elements and Rules were wrong in the context of Web SDK.  It was necessary to make a big shift between what takes place in Data Elements and what takes place in Rules. To make it work efficiently, the following needs to be moved to the earlier Data Element stage:

• applying conditions to our data processing
• concatenating data layer properties together
• mapping Data Elements to Adobe Analytics variables

There are two impacts of this:

• It requires a bit more coding within Data Elements.  This is because some wizard driven utilities available in Rules (such as the ability to add conditions) are not available within Data Elements.
• Rules are massively simplified - theoretically, you could have a single rule that is just there to send the data (in reality, we've ended up with a few more)

A new mental model...

The new approach looks something like this:

1. Set a data layer in the website
2. Read in the data layer and use Data Elements to assemble a fully formed XDM object with all Adobe Analytics variables mapped and ready to be sent
3. Use a rule to send the XDM Object to Adobe

The key aspect I want to focus on in this article is how to assemble a fully formed XDM object.

A more elegant approach to the XDM Object

In part 2 of this series, I showed the basics of populating the XDM Object within Data Elements. However, there is a more elegant way to structure the building of the XDM Object.

So how do you do this?

Forget everything you know about Data Elements!

OK, this might be a bit of hyperbole, but the point is, I've really had to change the way I think about data elements as I've adapted to Web SDK and populating the XDM Object.

Potentially, the most interesting aspect is the use of the "Merged Objects" Data Element Type.  This is provided by the "Core" extension and is available even if you are not using Web SDK, but like me, you may never have realised it was there, or had cause to use it.

I think "Merged Objects" is key to a successful setup because it allows you to take a modular approach to building the XDM object.

To create that modular approach, the other big change I had to get used to, was the fact that Data Elements becomes a multi-stage process, comprising of the following three steps:

1. Create a set of Data Elements that have a one-to-one relationship with the Adobe Analytics variables you want to populate (props, eVars, events etc.)
2. Create multiple "XDM Object" Data Elements that collate together modular groups of Data Elements created in step 1
3. Use the "Merged Objects" Data Element to stick together the modular groups to build a complete XDM Object for each required scenario

For our implementation, we settled on three groupings of Data Elements:

• Global Data Elements that we want to transmit every time we send data
• Page View Data Elements that will only be transmitted when a page view occurs
• Link Tracking Data Elements that will only be transmitted when custom link tracking

We then merge the global variables with both the page view variables and the link tracking variables to create two complete XDM objects ready to be sent.  The output of this is two Data Elements, one contains the complete XDM Object for a page view, the other contains the complete XDM Object for link tracking.

The benefits of this approach...

By arranging things this way, you are avoiding duplicating areas of your XDM Object, which makes it easier to maintain.  For example, if you want to add a new variable to be sent on both page views and link tracking, you simply add this to the global XDM object Data Element, rather than having to do this in multiple places. 

How to use the 'Merged Objects' Data Element

It is easy to use the 'Merged Objects' Data Element.  Simply reference the 'XDM Object' Data Elements that you want to merge as shown below:

Then with the 'Send Event' Rule, you can reference the 'Merged Objects' Data Element that you've created:

Final thoughts...

When implementing new technology, the need to stay flexible and not be bound by how we have done things in the past, is a lesson we can all learn from - and is one that particularly applies to implementing Web SDK!

I'm looking forward to writing Part 4 of this series as I will be looking at some of the 'quirks' that can trip up even the most experienced professional.  Beyond that I'm thinking about First Party IDs and possibly touching on Adobe Target.  However, if you have any areas that you would like to see me cover, leave a comment below.

Thanks for reading, and if you want updates on when these posts go live please follow me on LinkedIn.

Read other parts of this blog series:

• Web SDK Part 1: The elephant in the room…
• Web SDK Part 2: The missing map
• Web SDK Part 4: Avoiding Banana Peels (and other thing that can trip you up!)

[#2]

@Andrew_Wathen_ 

It would be good to find out how did it go with the following:

1. SPA pages;
2. Adobe Target implementation & AT on SPA pages;
3. First Party IDs;

Have managed to capture pageView & basic custom link tracking in adobe. Your article have saved me a lot of time, thank you very much for that!
Franc

[#3]

@Franc_G Thanks Franc, Definitely planning on covering First Party IDs (pencilled in for part 5 if all goes according to plan).  I'd not considered doing anything specific on SPA based websites, although I do have experience of this so could potentially cover this.

Out of interest, was there a particular aspect that you were struggling with or was it more of a general overview that you were looking for?

[#4]

@Andrew_Wathen_ 

Well, in our case SPAs proven to be a bit tricky when it comes down to the AT implementation. Sometimes our dataLayer is being populated quite late and it is a bit tricky to send any parameters to the AT. But this is quite a unique case and it might not be of interest to most of the community. For me personally, it would be interesting to see a general overview of SPAs and whether migration to alloy made any impact on the AT performance. Looking forward to part 5 - First Party IDs  

[#5]

@Andrew_Wathen_ , This is awesome! Very useful.