Data Element Assistant: Adobe Launch Extension Review

Hands up! This is the DEA!

Evolytics’ Data Element Assistant (DEA) is a collection of Data Element utilities built to keep your hands off of coding JavaScript. This sounds good in my book. Let’s take a look at each element and talk about how they behave! As a note, this is current as of v1.6.1.

The DEA has 4 different Data Elements: Calculate, Concatenate, Extract, and Sequence. Concise naming – I dig it. I’m going to skip over the Extension configuration screen and go straight into each Data Element. There’s no configuration necessary. They did create a tutorial in the configuration screen that pretty much repeats what’s in the UI. They could easily get away with consolidating this tutorial into tooltips… though the Adobe Exchange rules pretty much mandate tutorials.

Calculate

I think you can do the math on this one (GET IT?). It calculates stuff – 2 things, to be exact. Why would I want this? I can use this to add shipping to my unit price. I can calculate taxes or do other stuff that I’m used to doing with JavaScript. This is pretty useful. Its primary limitations are with the amount of stuff you can calculate. This was built for the Adobe Launch Extension Idol, so there was only SO MUCH one can build within the limited timeline. However, it would be nice to see the ability to calculate metrics similar to how they can be calculated in Adobe Analytics. There is a TON of opportunity here on the front-end. Even something as simple as a COUNT function that would let users count objects in an array.

Anyway, it’s useful as it is – but the use cases are limited to very basic operations. Let’s see them in action!

Integer + Integer

I set a Data Element of Custom Code Integer with the following code:

return 1;

I chose to add these together – so the function is 1 + 1 and forced 2 decimal places. This is a freebie.

Result: 2.00

Yay!

String + String

Let’s kick things up a notch and try adding 2 strings. If I add “foo” and “bar”, I expect the Data Element to return “foobar”. I used Jan Exner’s Constant Data Element extension to set these Data Elements. I set the decimal places to 0 to avoid contaminating the outcome.

Result: “”

Interesting! It first detects if the values are numeric – and if they aren’t, it falls back on the default value. This is actually what I should have expected. The concatenate Data Element in the DEA Extension should take care of concatenation like that. This works beautifully. Edit: Upon reviewing the code, it looks like there was supposed to be an error thrown with the string. I didn’t see one when I tested this, but I could be mis-remembering.

String + Integer

Now let’s see what happens if we mix strings and integers. I created a Data Element with the value of “1” as a string – and I’ll reuse the integer Data Element from the first example. Adding these together, I would expect an error. HOWEVER, it’s possible that this extension tries to convert the string to an integer! My expectation is that it won’t and it will fall back on the default value. Let’s see what happens.

Result: 2

WOW! It converted string to an integer! Very interesting. I don’t know what to think about this behavior. I think I like this. It leaves room for error by developers and eliminates the need for users to manually convert the value to an integer (or other numeric classification). They covered their bases on this one.

Divide by Zero

The mother of all tests. Let’s divide this thing by zero. I’m just going to type “0” into the box and see what happens. This should either fall back on the default value or return “Infinity”. I’m done predicting outcomes – I’ve been wrong each time.

Result: “” AND it throws a Notify error.

So it falls back on the default value. At least it doesn’t crash the page (kidding).

Other Notes

I recommend DEA expand the Calculate Data Element – there’s a TON of opportunity with this one. For instance, adding operators like Average, Count, or Mean. For instance, it would be nice to COUNT the length of an array. As it’s currently designed, we can only calculate something if there are 2 distinct values. It’s nice – but may require nesting of multiple Data Elements if your calculation gets any more complicated than simple division.

Okay, I think we get the gist of this Data Element. Moving on…

Concatenate

It’s sometimes nice to be able to easily modify values like a page name. The name may look something like this mysite:category:subcategory:product. Typing these in individually is a little tedious. I’m pretty hard-headed about the principle that almost all data we send in rules should be a Data Element. On the surface, the Concatenate Data Element seems a little unnecessary. That’s not because we don’t concatenate things – but instead because I can manually concatenate stuff. That page name? I can literally just type %Site Name%:%Category%:%Subcategory%:%Product Name%. Boom. Concatenated. Also unsustainable. If your structure, delimiter, or anything else changes – you’ll need to also update it everywhere it was manually typed.

The Concatenate Data Element does this for you so you only have to build this out in one place. Let’s give it a shot and see the output.

foobar

I’m going to start with a gimme. We’re going to try to produce the value foobar by concatenating foo and bar without a delimiter.

Result: foobar

mysite:category:subcategory

Result: mysite:category:subcategory

It works!

null and undefined

My expectation is that null and undefined values will show up as either “null” or “undefined” in the output – OR it will fall back on the default value. For each test, I used a string (“foo”) for the first input and the exception for the second input (with a colon delimiter). So let’s say undefined produced “undefined” – the result I would expect would be “foo:undefined”. Let’s go through each example.

undefined

Result: foo: AND it throws a Notify error (Adobe Launch built-in error check)

null

Result: foo:default

Falls back on the default value. I think the notable outcome of this falls in Adobe’s court. An undefined value should probably fall back on the default value. It would be nice to have a check on Concatenate’s end… but as an extension developer I would trust the function of Data Elements to protect against values failing. There’s probably a reason undefined returns as a valid Data Element (and someone has probably told me in the past), but I don’t think this is Evolytics’ problem.

Other Notes

It would be nice to automatically populate the previous delimiter when a new input row is added. That would save a little bit of time. Additionally – why do people have to click on “Generate Sample Output” to see a sample output? This is a great reference that can be shown in realtime! So show the sample output by default and update it on keypress. I would also keep the %% Data Element values in the sample output. Removing %’s will cause confusion. Here’s an example where I might think the tool is broken:

In the sample output, it shows home:video viewed:25. In practice,it actually shows the %:

I think it’s safe to assume that users will know that the %Data Element% will turn into whatever that value normally evaluates to.

Okay, we’ve beat this one to death. NEXT!

Extract

Array

I love this one. This takes arrays and grabs specific values from it based on its position in the array. When would I use something like this? Let’s say I have an event-driven data layer and you need to pull the last event that was pushed into an events array. I would do this because I want to know the last action our user took. In the example below, the last action the user took was clicking on the footer:

digitalData = {
  events:[
    {event:"click", action:"submit"},
    {event:"click", action:"menu"},
    {event:"click", action:"footer"}
  ]
}

If we’re adding a new event each time someone takes an action on the site, we would traditionally need to create a Data Element that looks something like this:

//Get the events object
var eventObject = digitalData.events

//Grab the size of the array and subtract 1 to correct the index
var objectSize = eventObject.length - 1;

//Return the last object in the array
return eventObject[objectSize];

Gross. The Extract function grabs a specific object from that array. I see this mostly being used to get the first or last value of an array. I tested it… it works. It also throws an error when you try to grab an array value from something that isn’t an array. I don’t anticipate the “Index” function of Extract being very useful, as this can be set as a JS Variable Data Element type… meaning this functionality is pretty redundant. Perhaps use a “Custom” parameter for this so I can select an index via a Data Element?

Nested

When I first saw this feature, I thought it was just a JS Variable clone. I was wrong. This is actually a super slick addition to Adobe Launch. Without this feature in the Extract Data Element, I can’t easily set a Data Element as an object and refer to other objects inside of it. Here’s how you currently have to do it with code:

//Set a variable as the Data Element object...
var dataElementObject = _satellite.getVar("Data Element Object");

//Refer to the specific object you want to extract
return dataElementObject.someValue[0].someOtherValue;

This is annoying… and it’s code. Ew. Let’s see what this looks like in the Extract interface:

Easy peasy… AND an added bonus is it mimics the syntax of the Code JS Variable Data Element. That’s a good thing.

Sequence

The purpose of sequence is to create a hierarchy of Data Elements. It picks the first Data Element that is defined*. We’ve all run into situations where we might be trying to grab something like a page title or product name – where we say “If a product name doesn’t exist, set the page name as the page title.” This is a very rudimentary example of how this might be used. I’ve run into these exact use cases before.

* There is a specific definition of “defined”.

To be completely honest, I’m not crazy about this Data Element. The reason is that it forces other Data Elements to conform to its unique IF statement evaluation method. This is by design – but also out of necessity. There’s no signal from Adobe Launch that a Data Element has resorted to the fallback Default value so it’s impossible to tell when a Launch didn’t find a value… UNLESS you leave the field blank.

In the Evolytics documentation, it says if the value is null or empty it will fall back to the next element. In practice, only the latter works because a null value will fall back to the default value (which can’t be null). This is the specific definition of “not defined” – the resultant has to be an empty string. In practice, this isn’t always preferable because you’ll often have some kind of default value. I’m NOT a fan of dependencies like this and would prefer to just write code as opposed to using conditional statements built into the UI.

THAT SAID… I think adding custom fields could fix this. For instance “If %Data Element% = ‘foo'”… and allow regular expressions. As it is, I don’t anticipate using this one.

Final Thoughts

On the whole, I was pleasantly surprised by this extension. Concatenate and Extract anchor this extension very well. I wouldn’t change anything about those two (except for automatically generating the preview). Calculate and Sequence have some opportunity. With Calculate, adding functions that can COUNT, AVERAGE, or other similar expressions will drastically improve its mileage. It would also be nice to do more than just basic operations with 2 values. This is a rabbit hole, though. At what point are you just coding an entire calculator? Sequence is a great idea that’s held back by built-in Launch constraints. Having to ensure other Data Elements are tailored to work with the Sequence Data Element impedes its utility, in my opinion. Adding some customization to this is another rabbit hole.