I am happy to present a guest post by my colleague Ben Wedenik, who, following a not so old, but very good tradition, writes about keeping implementations ridiculously simple.

What does a lean and scalable Web SDK implementation look like?
How to stay flexible while still having a powerful tag manager setup?
I'm going to share my insights with you in this post.

Introduction

Some time ago, I've written about how a lean Analytics setup with the Adobe Client Data Layer (ACDL) could look like. As time went on, Adobe introduced the Experience Platform and the Web SDK. Now it's time to learn how to use some of my favorite technologies to build a scalable and flexible setup to fit your needs.

I'm assuming that you are already familiar with those technologies, if not I'd highly suggest you check them out before continuing: Data layer, ACDL, Web SDK

In a modern and up-to-date web setup, the data layer is one of the most essential parts. You'll struggle frequently with a bad one and will have a good time with a decent one. Thus, one mandatory ingredient for this setup to work is a clean and well-defined data layer, specifically the ACDL.
Number two in this trio is the Web SDK, which allows us to efficiently collect data and send it to Adobe's edge network.
The third ingredient helps us to glue everything together and establish a setup where we don't have to rely on much custom JavaScript: the Mapping Table.

Whenever there is an interaction on the page, an event should be pushed into the ACDL, filled with context information about what exactly just happened. That way, we have achieved a decoupling between "what is going on" and "how and what should be tracked". Let's assume we have the following events we want to track:
• Pageload
• CTA
• App Download
• Video Start

Of course, this list will be longer in your real implementation, but it should be sufficient to illustrate the underlying concepts.

Final State

Before going into the details, let me show you what we are trying to achieve by the end of this post.

We want:
• Low complexity
• High flexibility
• High scalability
• Track arbitrary events
• Populate standard and custom XDM fields
• User-friendly maintenance

Let's have a look what this could look like when performing a page load:

[screenshot]
Pushing a pageLoad Event

The ACDL push triggers Launch to set the right values in our XDM and executes the sendEvent command. Observe how the pageViews value is set to 1 while the linkClicks are 0.

The CTA event contains less data, thus we want to leverage the ACDL state to still capture fields like the page name, section etc.

[screenshot]
Pushing a CTA Event

The same is true for app downloads:

[screenshot]
Pushing an appDownload Event

Notice, how the linkClicks is here set to 1 while the pageViews are reset to 0 for non-pageload events. In addition, the eventInfo values are used to populate fields like the webInteraction type.

Of course, this is a very simplified tracking setup with just a few variables, but it nicely allows us to abstract and focus on the concept and the lean setup behind it.

Setup

Now that we have seen what we want to achieve, let's start by inspecting each component of this setup in detail.

To make our life as easy as possible, we are going to use the following carefully selected extensions:

[screenshot]
Core and the Golden Trinity of Extensions

Then we can create the one and only rule we need:

[screenshot]
One Rule, to -uhm- rule them all

Yes, with a decent data layer, there is no need for dozens of rules. I personally really like this simplicity a lot!

[screenshot]
Definition of the Rule

The rule itself listens to all the ACDL events we defined above.
Adding a new tracking event, e.g. videoEnd, only takes a few clicks with an ACDL listener.

The rule events are very simple and look like this:

[screenshot]
Event setup

The one and only action we need is the AEP Web SDK – Send Event, which we'll have a closer look at now.

[screenshot]
Action setup

As you can see, in this example, we're just using two data elements to configure the Send Event action. Of course, this could be extended, e.g., setting an optional merge ID when needed, but for now, let's focus on the essentials, which are the "XDM data" and the "Type".

Data Elements

The "Type" is a predefined enumeration, thus we need to map our ACDL events to one of those values.
I'm going to use my beloved Mapping Table extension for that task:

[screenshot]
Mapping the Event Type

For pageload events, we are setting the value to web.webpagedetails.pageViews for everything else (the regular expression .* matches any string) the value shall be web.webinteraction.linkClicks.

Again, this table can easily and visually be customized to fit your needs.
Now we are coming to the core piece of this setup. The actual XDM data element:

[screenshot]
The XDM Date Element

Depending on your XDM Schema, you will see different fields here.

In my example, I'm using the Experience Event Web Details, which provides a structure for fields such as interaction, page details, and referrer.
For the sake of simplicity, I'm only populating some values of the "web" object here.

One detail we should pay close attention to is the value we are using for the web.webPageDetails.pageView.value. As you can see, this is a number. Populating the field with a string or "undefined" will cause your request to fail, thus we need to actually provide a JavaScript number.

In our example, we want this value to be 1 for all pageload events and 0 otherwise. Vice versa, the logic is defined for web.webInteraction.linkClicks.value.

Let's have a look at the respective data element "mappingPageviewValue":

[screenshot]
Mapping XDM for Page View

Notice that the structure is equal to the event type data element. The only difference is that we want to return a number (not a string). Thus, we need to be a bit creative and return just another data element, which will provide us with a JavaScript number:

[screenshot]
int0 Setup

 

[screenshot]
int0 Code

In the same fashion, the "int1" data element is defined.

Alright, back to our XDM data element.
We've used the Mapping Table to populate web.webpagedetails.pageViews with a number successfully. Now we can do the same for web.webinteraction.linkClicks with another mapping table and the inverse logic.

Next, we can use the eventInfo payload to populate some more fields, like the webInteraction type:

[screenshot]
XDM webInteraction type

As you can see, we don't even need a dedicated data element for this, but can directly refer to the ACDL event payload.
In case the respective values in eventInfo are not set, Launch will replace it with undefined. This allows us to map all fields for all events directly, without having to worry which ones are actually going to be populated.

In the same fashion, we can leverage the state of the ACDL to populate fields like the page name:

[screenshot]
XDM webPageDetails name

In the same way, we can use the rest of the ACDL payload to set our other XDM fields.

Putting it all together, we end up with those six data elements:

[screenshot]
Six Data Elements

Not that much, right?

Do it yourself

If you've followed the steps, feel free to go ahead and actually build a library and give it a try.
For your convenience, here are the ACDL pushes I've used at the beginning of this post:

  adobeDataLayer.push({      event: "pageload",      eventInfo: {},      page: {          name: "homepage",          section: "home"      },      view: {          name: "home"      },      referrer: {          type: "internal"      }  });    adobeDataLayer.push({      event: "cta",      eventInfo: {          type: "other",          targetURL: "https://www.wedenik.com"      }  });    adobeDataLayer.push({      event: "appDownload",      eventInfo: {          type: "download",          targetURL: "https://play.google.com/store/apps/details?id=com.wedenik"      }  });

Conclusion

We've built a lean, scalable and flexible setup which allows us to build a robust and extensive tracking framework.

A clean and well-defined data layer allows us to be minimalist in our setup. If this is the case, there is no need for a lot of complexity in the tag manager any more. And that's the philosophy I'm sharing with all my clients.
One rule and six data elements already cover a lot of use cases, without having to mess with much custom JavaScript code. From this point on, it is straight forward to add new ACDL events and to populate additional XDM fields.

I hope you enjoy this simplicity and elegance just as much as I do, and am curious what you are thinking of this approach.

This is the powerful trio you should rely on for a successful setup:
• ACDL - The event driven approach and the well-defined structure decouples the website from the tag manager.
• Web SDK - Adobe's new library provides us with all the functionality to build an extremely flexible tracking setup.
• Mapping Table - By leveraging multiple matching options and nesting, we can build arbitrarily complex if-else structures without writing a single line of code.