How Adobe Client Data Layer messes up Tags' (Launch's) rule ordering

[#1]

TL;DR If you're using Adobe Client Data Layer (ACDL) in Tags (Launch) and ordering of Rules is important to your setup, then setup your ACDL Events to listen to "All Events" only.

Preface / Legend

For the rest of this post, I'm going to use specific upper- and lowercase spellings to distinguish various items.

• Uppercase "Event", "Condition", "Action": these refer to the Events, Conditions and Actions in Tags that come from extensions. For example, the ACDL extension has an Event called "Data Pushed".
• Uppercase "Rule": this refers to Rules that are setup in Tags. A Rule can contain 1 or more Events (where each Event doesn't have to come from the same extension), 1 or more Conditions, and 1 or more Actions.
• Lowercase "event": any other event that occurs during your web page's runtime, i.e. when it is loaded and interacted with in the user's browser.
• "ACDL event": an event that got pushed into ACDL / adobeDataLayer.

Background

Tags, or Launch as is more commonly known, has a fantastic feature that allows you to specify and order that your Rules' Events are supposed to run. For example, if you have the following setup:

• Rule A: Click with default order 50
  • Event: Core extension > Click event type, order 50.
  • Action: Adobe Analytics extension > Send Beacon.
• Rule B: Click with order 10
  • Event: Core extension > Click event type, order 10.
  • Action: Adobe Analytics extension > Set Variables.

Then, you can safely assume that your Adobe Analytics (AA) variables will be set first via "Rule B: Click with order 10", before the beacon is sent to AA via "Rule A: Click with default order 50".

Meanwhile, it is generally good practice to use an event-driven digital layer to allow your web pages to provide data for the pupose of marketing analytics. And in the Adobe world, the Adobe Client Data Layer (ACDL) is probably the #1 choice to be that data layer.

Problem

However, it is worth noting that ACDL Is not a required data layer to operate in Tags. Likewise, Tags can function perfectly well without a data layer, whether its ACDL or other technology. As a result, there isn't any tight coupling between Tags and ACDL (unlike what happens in the Google world, where Google Tag Manager has a very strong dependency on dataLayer).

But that means that if you are using ACDL with Tags and you want to ensure that your Events from the ACDL extension are triggered in a particular order, then you will need to understand how ACDL works with Tags, so that you can sort your Rules' Events properly.

Example

I'll use the following example to illustrate how Tags' Rule ordering doesn't work the way you would expect it to when working with ACDL. Let's say you have the following Rules:

• Rule 1: Do something with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 1
• Rule 2: Do something else with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 10
• Rule 3: Do something with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "Specific Event", register for ACDL event "foo", order 50
• Rule 4: 😧😧Do another thing with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "Specific Event", register for ACDL event "foo", order 60
• Rule 5: Do something finally with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 90
• Rule 6: Do something lastly with all ACDL data changes
  • Event: ACDL extension > Data Pushed, listen to "All Data Changes", order 99

You might then expect the Rules to run in the following order:

1. Rule 1: Do something with all ACDL events
2. Rule 2: Do something else with all ACDL events
3. Rule 3: Do something with ACDL event "foo"
4. Rule 4: 😧😧Do another thing with ACDL event "foo"
5. Rule 5: Do something finally with all ACDL events
6. Rule 6: Do something lastly with all ACDL data changes

But no!

What actually happens

When your web page runs the Tags script, Tags sorts all of its Rules' Events by their orders. For the above example, Tags ends up with this sorted list:

1. Rule 1: Do something with all ACDL events
2. Rule 2: Do something else with all ACDL events
3. Rule 3: Do something with ACDL event "foo"
4. Rule 4: 😧😧Do another thing with ACDL event "foo"
5. Rule 5: Do something finally with all ACDL events
6. Rule 6: Do something lastly with all ACDL data changes

This is all well and good, and in line with how we expect Rule ordering to work in Tags.

Tags then runs the code contained in the extensions, including the ACDL extension's code. Now, what the ACDL extension does is that it loads a callback handler for each of the extension's Event types. (A callback handler is basically the JavaScript code that responds to signals so as to do something. In this case, ACDL's callback handlers listen for the ACDL events so as to trigger Tags to run its Actions.) So, ACDL sets up three calback handlers:

• Listen for all ACDL data changes.
• Listen for all ACDL events.
• Listen for specific ACDL events.

Then, it groups the Rules' Events from Tags by these 3 handlers. In our example, ACDL effectively ends up with this:

• Listen for all ACDL data changes.
  1. Rule 6: Do something lastly with all ACDL data changes
• Listen for all ACDL events.
  1. Rule 1: Do something with all ACDL events
  2. Rule 2: Do something else with all ACDL events
  3. Rule 5: Do something finally with all ACDL events
• Listen for specific ACDL events.
  1. Rule 3: Do something with ACDL event "foo"
  2. Rule 4: 😧😧Do another thing with ACDL event "foo"

Notice how the Rules are still sorted, but per callback handler.

But ACDL is not done yet! ACDL has its own priorities for each of the callback handlers. The priority is: "All Events" first, then "All Data Changes", then finally "Specific Event". Now, our list of ACDL callback handlers-with-Rule-Events becomes this:

1. Listen for all ACDL events.
   1. Rule 1: Do something with all ACDL events
   2. Rule 2: Do something else with all ACDL events
   3. Rule 5: Do something finally with all ACDL events
2. Listen for all ACDL data changes.
   1. Rule 6: Do something lastly with all ACDL data changes
3. Listen for specific ACDL events.
   1. Rule 3: Do something with ACDL event "foo"
   2. Rule 4: 😧😧Do another thing with ACDL event "foo"

Notice the numbering. That is exactly the order that the Rules' Events will get triggered!

Let's say your web page now runs this:

adobeDataLayer.push({
  event: "foo",
  bar: "baz"
});

 ACDL is then going to cause the Rules to be triggered in this order:

1. Rule 1: Do something with all ACDL events
2. Rule 2: Do something else with all ACDL events
3. Rule 5: Do something finally with all ACDL events
4. Rule 6: Do something lastly with all ACDL data changes
5. Rule 3: Do something with ACDL event "foo"
6. Rule 4: 😧😧Do another thing with ACDL event "foo"

Oh no! The order that you had expected is no longer the order that you get!

Here's an example of a consequence. Let's say you set your AA variables with Rules 1, 2, 3 and 4, then send your beacon with Rule 5. What's going to happen is that you will set your variables with Rules 1 and 2, then send the beacon with Rule 5, then set your variables with Rules 3 and 4. Consequently, whatever variables you had set with Rules 3 and 4 won't get sent to AA because they were set after the beacon had already been sent!

Solution

Given how ACDL prioritises "All Events", "All Data Changes" and "Specific Event", and if you absolutely, positively need your Rules to run in a specific order, then you only have 1 solution:

• All of ACDL extension's Events must listen to "All Events".
• All of adobeDataLayer pushes must contain an "event" key.

That will ensure that your Rules are triggered in the order that you expect when working with ACDL. So in our example, Rule 6 will need to be changed as follows:

• Rule 6: Do something lastly with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 99

But that leaves us with the problem of how to trigger Rules with specific ACDL events. The solution is to use a "Value Comparison" Condition. In our example, Rules 3 and 4 will become this:

• Rule 3: Do something with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 50
  • Condition: Core extension > Value Comparison, %event.message.event% equals foo
• Rule 4: 😧😧Do another thing with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 60
  • Condition: Core extension > Value Comparison, %event.message.event% equals foo

(%event.message.event% is a special data element to get the pushed event that got pushed into adobeDataLayer, i.e. "foo" in this example.)

After all of the changes to accommodate Rule ordering, our example will be like this:

• Rule 1: Do something with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 1
• Rule 2: Do something else with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 10
• Rule 3: Do something with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 50
  • Condition: Core extension > Value Comparison, %event.message.event% equals foo
• Rule 4: 😧😧Do another thing with ACDL event "foo"
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 60
  • Condition: Core extension > Value Comparison, %event.message.event% equals foo
• Rule 5: Do something finally with all ACDL events
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 90
• Rule 6: Do something lastly with all ACDL data changes
  • Event: ACDL extension > Data Pushed, listen to "All Events", order 99

And ACDL's list of callback handlers-with-Rule-Events becomes this:

1. Listen for all ACDL events.
   1. Rule 1: Do something with all ACDL events
   2. Rule 2: Do something else with all ACDL events
   3. Rule 3: Do something with ACDL event "foo"
   4. Rule 4: 😧😧Do another thing with ACDL event "foo"
   5. Rule 5: Do something finally with all ACDL events
   6. Rule 6: Do something lastly with all ACDL data changes
2. Listen for all ACDL data changes.
3. Listen for specific ACDL events.

Now, all of the Rules will run in their expected order. Consequently, the AA variables that need to be set will get set before the beacon is fired.

Summary

Rule ordering in Tags is a powerful feature for ensuring that things get done in a specific arrangement. But when used with ACDL, then we need to do the following:

• All of ACDL extension's Events must listen to "All Events".
• All of adobeDataLayer pushes must contain an "event" key.