Adobe Web SDK scaffold for tracking to Adobe Analytics via the Adobe Client Data Layer (ACDL) using Adobe Experience Platform Tags (Adobe Launch)

[#1]

(Disclaimer: The following recommendation is based on my personal experience with actual client setups. It is not endorsed nor recommended by Adobe or any of its partners.)

I'm sharing this scaffold for using Adobe Web SDK to send events for Adobe Analytics to consume, with Adobe Client Data Layer (ACDL) as the data layer and Adobe Experience Platform Tags (a.k.a. Adobe Launch) as the tag management system.

The full gist is at https://gist.github.com/yuhui/0cb20fdcc21a03357c4a217edc58d63a. I've listed out the minimal set of:

• extensions
• data elements
• rules

that need to be set up in Adobe Launch to enable complete tracking of your website's usage data to Adobe Analytics via Web SDK + ACDL, i.e. your website with Adobe Launch -> ACDL -> Web SDK -> Analytics.

Hopefully, this scaffold is useful for those of you who are getting started with implementing Web SDK for Analytics, or migrating from Analytics' AppMeasurement to Web SDK.

If you find any errors or have any comments, please feel free to leave them here so that I can address them and/or correct myself.

(A "scaffold" is a software implementation term referring to a minimal setup that's needed for any software project to begin development. Reference: Wikipedia)

Yuhui | yuhui.sg | Analytics, A/B Testing, Development since 2006

[#2]

hi @yuhuisg ,

Thanks for sharing. The link  adobe-launch-web-sdk-extension-data-collection-on-before-send-event-callback-code-prevent-custom-lin.... is page 404. On the schema in your documentation, the json sample is it based on the Schema by Adobe existing templates or I need to have them script the way you shared? 

for this Data element: %event.message.event% , can you share the steps and do I need to add rules / link to something?

[#3]

@vinc112 , thanks for letting me know about the broken link. I've fixed it in my Github gist.

My JSON sample is based on the existing Adobe Analytics ExperienceEvent field group available in Schemas, with some modifications that I thought were suitable to have.

%event.message.event% is a special field available from the ACDL extension. It is not available as a data element itself, and you don't need to set it up. Instead, you reference it from within a Rule where you use the ACDL extension's "Data Pushed" event. To see it yourself:

1. Create a Rule that is triggered with the ACDL extension's "Data Pushed" event.
2. Add a custom code action: console.log(event);
3. Open your website and trigger that rule. In your browser console, you should see the contents of the ACDL event object.

[#4]

Hi @yuhuisg ,

Here's a scenario: 

Current website 

Adobe Launch - implement using Data elements and rules method (tag and triggers and AA extension) - no web sdk

Adobe Analytics - data is shared with multiple BUs but only 1 BU site is revamp. Other BUs using own evars in the report.

New website:

Adobe Launch - consideration to use old method based on new website as we don't want to migrate the other BUs tags which sits in other property on AL or create a new AL property with Web SDK linking to current AA report. What are the impact if we use Web sdk to setup on a new AL property? Or should we use back the old AL property creating tags the old method?

Adobe Analytics - we want to use the current Prod reports as we don't intend to create a new Prod report (as no migration of the other BUs). Currently have setup on Processing rules, evars and pros in the admin.

Do you have any thoughts on this?

Thanks in advance.

[#5]

@vinc112  I agree with your approach for the New website generally.

For your Adobe Launch approach, though, you might also want to verify that all of your existing Rule continue to work with the new website. I'm pretty sure that there will be some noticeable front-end changes and/or broken+new pages. That's a general tip when implementing for new/revamped websites, not strictly about Web SDK.

You can certainly configure Web SDK to send its data to your existing report suites. However, when migrating to Web SDK, there might be some things that you just can't get away from. For example, if you use Clear Variables a lot, then that's really not a thing any more with Web SDK, which means that you may need to rethink how you set certain variables in some Rules.

However, it helps that the Web SDK now has the Update Variable action to help you "build up" your XDM object over several Rules. If you use AA's Set Variables action, then this Web SDK action is similar to that. When I had developed my scaffold, there wasn't this Web SDK action, and so I had to "build up" my XDM object using a combination of events and custom code data elements.

[#6]

Hi @yuhuisg ,

If I used the "update variable" Rule, do I need to disable / do anything to the current rules on the old AL report? 

Also since the data will be going into the existing report, do I need to create processing rules?

Just to also check do I send the Actions for "Update variable"  before or after the AA - set variables. Below is an example of the setup:

current rule setup:

A click

Events: Core Direct

Action :

AA - set variables then AA - send beacon then AA clear variables.

Thanks.

[#7]

Web SDK's "Update Variable" is an action that you use inside Rules. It's like AA's "Set Variables" action in that you use that inside Rules too.

I think this discussion is moving beyond the scope of my article. I suggest that you:

• Try setting up Web SDK by following Adobe's tutorials/documentation together with my scaffold.
• Use Web SDK's "Update Variables" action where it makes sense, similar to how you'd use AA's "Set Variables".
• Test and observe what happens. This is one of the best ways to learn how tracking works.

[#8]

Nice and modular, @yuhuisg !

I like how you split everything into meaningful and manageable blocks and just merge the objects together in the final XDM.

A lot of code if not for everyone, but from my own experience, generating the _experience.analytics JSON with code makes it a lot easier to maintain the history e.g., by using a SCM tool.

[#9]

Thanks for the kind words, @bjoern__koth ! Yes, I agree that it is a lot of code, but I've tried to keep it as simple as possible. I should also update this scaffold one day by using the "Update variables" action in the Web SDK extension...