Web SDK Part 1: The elephant in the room…

[#1]

I have recently been through the process of migrating our Adobe Analytics implementation to Web SDK.  My intention is to write a series of blog posts detailing what my thought process was, how we got it done, and the things you need to be aware of when you take this on.  In other words, I've made the mistakes so hopefully you don't have to!

Why move to Web SDK?

Before we get on to any elephants, I wanted to take a moment to explain why I think you should migrate to using Web SDK for your Adobe Analytics data collection.

Support for First Party Device ID

This was our number one reason for moving.  On certain browsers the lifetime of an Adobe Analytics cookie is limited to seven days.  The impact of this is that you lose track of users, making your analytics data less accurate and reducing your ability to personalise experiences.

Using a First Party ID (which is only an option when using Web SDK) you can remove this limitation!

I hope to cover First Party Device IDs in a future blog post but for now you can find more information here:

https://experienceleague.adobe.com/docs/experience-platform/edge/identity/first-party-device-ids.htm...

Performance

Firstly, Web SDK should require less code as it replaces the multiple libraries you need to run Adobe Analytics and other Adobe capabilities.  Secondly, Web SDK potentially allows you to consolidate multiple calls from different solutions into a single call.  For example, you can transmit data to Adobe Analytics and Adobe Target, along with retrieving Adobe Target offer content - all in one go!

Future proofing

Deploying Web SDK is a foundational step that will make your life easier should you choose to use other Adobe products such as Customer Journey Analytics (CJA) in the future.  Web SDK is also where Adobe is most likely to invest in new capabilities and features (for instance, the previously mentioned First Party ID capability).

The elephant in the room

I'm a big fan of Web SDK and would strongly recommend using it.  However, if like us you are using Adobe Analytics and want to use Web SDK for your data collection, you need to address 'the elephant in the room'…  Web SDK was not primarily designed with Adobe Analytics in mind.  The Web SDK's focus is to support Adobe's new Experience Platform products such as their Real Time Customer Data Platform, Adobe Journey Optimizer (AJO) and Customer Journey Analytics (CJA).

For this reason, Web SDK takes a more modern approach than the data collection code that we are used to with Adobe Analytics; It acts as a single tag that collects a generic, flexible, extensible JSON data object from your website (Adobe's XDM data object) and transmits this data object back to Adobe's Edge Network where it is then consumed by these next generation Adobe products…

…meanwhile, we're still using Adobe Analytics which is expecting to receive old school s.props, s.eVars, s.events, s.products variables etc.

To make Web SDK work with Adobe Analytics we somehow have to join these two worlds of the old and new together, i.e. solving the problem of 'fitting a square peg in a round hole'.

In my view, understanding this upfront is key to making a success of your Web SDK/Adobe Analytics implementation as everything we have to do (and the small compromises we have to make) makes more sense in this context. And finally let's be clear, this is a good thing! Adobe could have left it's Adobe Analytics customers using appMeasurement.js etc. but instead we get to take advantage of their latest Web SDK!

How to fit a square peg in a round hole

The great news is Adobe have provided some good options to help you achieve this; the bad news is that you now need to work out which option to pick - hopefully I can help here!

Option 1 - Server-side Adobe Analytics Processing Rules

Adobe have built a capability that will automatically convert the generic XDM data object that is sent to the Edge Network into Adobe Analytics Context Data Variables (CDVs) and forward these on to Adobe Analytics.  The CDVs can then be mapped to props, eVars etc. using Adobe Analytics Processing Rules.

Pros:

This allows you to immediately start populating the XDM data object in a way that will likely be best for those next generation Adobe capabilities while still supporting Adobe Analytics.

Cons:

Although some variables will be automatically mapped, most variables (e.g. props, eVars etc.) will have to be manually mapped using processing rules (processing rules are a useful but older part of Adobe Analytics which can be more challenging to manage, and may not offer the flexibility required to process and transform the data).

More information on this approach can be found here:

https://experienceleague.adobe.com/docs/experience-platform/edge/data-collection/adobe-analytics/man...

Option 2 - Client-side mapping within the XDM data object

Hidden away in the XDM data object is a special part (" _experience.analytics") which when populated will automatically map values to the appropriate props, eVars etc.

Pros:

Mapping to props/eVars etc is done client-side so you retain the full flexibility of using client-side JavaScript to transform your data and avoid the need for managing server-side processing rules.  Also, when inspecting/debugging client-side with something like the Experience Platform Debugger, it is easier to see where things are going in Adobe Analytics.

Cons:

This approach requires a client-side set up which is more bespoke to Adobe Analytics and therefore is less suited to Adobe's next generation products so you will likely need to do more work in the future to support these products.

More information on this approach can be found here:

https://experienceleague.adobe.com/docs/experience-platform/xdm/field-groups/event/analytics-full-ex...

We opted for option 2 as we needed the flexibility of the client-side JavaScript.  Unless the implementation is very simple, I would always lean toward option 2 for this reason.

This brings me to the end of this first blog post.  My intention is to continue this series by next exploring how we approached the setup in 'Data Collection - Tags' (formally Adobe Launch) and some of the ways in which we had to completely change our way of thinking to achieve the best setup.

If you have found this useful, please consider following me on LinkedIn for updates.

Read other parts of this blog series:

• Web SDK Part 2: The missing map
• Web SDK Part 3: My biggest mistake... 
• Web SDK Part 4: Avoiding Banana Peels (and other thing that can trip you up!)

[#2]

Nice introductory post!

I am very interested in what approach you took to replacing the building of the tracker in multiple rules, do the lower flexibility of the "updateXDM".

So, for Adobe Analytics we build the tracker in multiple rules, depending on triggers and conditions, and then we fire a page view or an event at the end.

To do this in SDK, without the "set variables" action (Update XDM maps only to objects, without custom code) I could imagine making each rule having two actions

1. Set tmp data elements (one per evar!)

2. update XDM

This seems quite clunky and I would be interested if you had a more elegant solution. Potentially as you said, completely changing the way of thinking!

[#3]

very cool blog

[#4]

@Fishman22 yes - planning to get more into how we set this up in the next part!  (Hopefully posting part 2 next week)

[#5]

I'm looking forward to your experience with the First Party cookie implementation.

[#6]

Great overview @Andrew_Wathen_ and looks like will be a spot on blog that many will find useful.  Really wish this level and context was already part of the EL documentation - how most AA clients & users will be approaching this change.  Please post the rest rapidly!  Thx

[#7]

Thanks @markcol, literally working on part 2 at this very moment in time so hopefully you won't need to wait too long!  Aiming for one a week and I think it will be at least a 4 part series (we'll see how it goes!)

[#8]

I've just published part 2 of the blog series! You can check it out here: Web SDK Part 2: The missing map

[#9]

@Andrew_Wathen_ thanks for the info. A very useful post for someone who is planning to migrate to AEP!

Couple of questions:

1. appMeasurement.js is being replaced / removed, have you observed any issues with that ? For example: we have a page level tracking and we set the pageName = prop1 = eVar1; 
   pageName / prop1 - are used for entry / exit pages use case, while eVar1 is used for link tracking attribution (Adobe data collection servers strip pageName dimension from all link tracking image requests. In order for the pageName to appear in link tracking hits, an eVar needs to be used). If we use the option 2 and populate the web.webPageDetails.name, would we still need the eVar1 (for link tracking) ? Unsure how it works in alloy.js
2. Option 2 - we can't do any js manipulation in processing rules (option 1), therefore this option is the only viable solution for more complex implementations (from my point of view). For example if you have multiple data sources - data layer and on-page / document level events. Any thoughts on the above ? 

[#10]

@Franc_G I'm assuming you are looking to move to Web SDK but still using Adobe Analytics (i.e. not migrating to CJA at this stage).

Answer to Question 1:

As the tool receiving the data, Adobe Analytics will continue to work as it always has (e.g. stripping pageName from link tracking hits).

The web.webPageDetails.name automatically maps to pageName in Adobe Analytics (and will be stripped on link tracking hits).  Therefore, if you want to continue to support your other two use cases you would also need to map to the prop and the eVar using the following properties in the XDM Object:

• _experience.analytics.customDimensions.props.prop1
• _experience.analytics.customDimensions.eVars.eVar1

There are also some other differences between appMeasurement.js and Web SDK that can cause issues.  My upcoming post (part 4) is going to deal with these - so keep a look out for this!

Answer to Question 2:

Technically you can combine client-side JS manipulation with server-side processing rules (i.e. blending the 2 methods together).  However, I would question why you'd want to.  i.e. If you are already using JavaScript on the client to manipulate your data why not map it there and then and avoid the hassle of also having to deal with processing rules? Having said that, all implementations are different, so you may have some specific reason why you'd want to do this.

If you haven't already, it may also be worth checking out the other two parts to this series I've already published...

• Web SDK Part 2: The missing map
• Web SDK Part 3: My biggest mistake... 

Hope this helps.

Andrew

[#11]

@Andrew_Wathen_ I am just looking at the web sdk set up at the moment, although we are not using Adobe Launch, so there will be some differences. Currently, I am doing a quick POC with a couple of data sources (data layer and a document level event). Can't wait to see some data in adobe...

1. "stripping pageName from link tracking hits" - I have assumed that since we are getting rid of the appMeasurement.js the processing might change (as it is not longer the s.tl() call), but thanks for validating it. 
2. Agree, we are trying to avoid processing rules. For now we will stick with your suggested option 1.

Thanks for your answers to the questions above - very helpful. 

[#12]

@Franc_G No worries, glad to help - best of luck with it!

[#13]

@Andrew_Wathen_  Extremely useful content. We are planning to set up Adobe Target integration using websdk and this is going to come in handy.

[#14]

HI @Andrew_Wathen_ 

amazing post, especially about the use of the FPID. Are you aware of any other browsers than Safari's ITP that are already limiting the lifetime of "cloaked" analytics requests?

Or have you heard of any planning to do so? Firefox would surely be one of the first to do adapt that feature.

Cheers
Björn