SDI Toolkit: Adobe Launch Extension Review

SDI Toolkit: Adobe Launch Extension Review.

This week I dove into the SDI Toolkit by Search Discovery. While there isn’t configuration necessary in this extension, there is a tutorial baked into the configuration screen. Like most extensions, your mileage will vary with the tutorials. Sometimes they’re a bit long-winded, sometimes there needs to be more explanation… maybe in the form of tooltips?

SDI Toolkit

Data Elements

Launch Build Info

SDI Toolkit Launch Attribute

Conceptually, this is very straightforward. Build Date is a great way to understand when people are publishing things. Data suddenly looks weird? Check the build date to see if someone recently published a new Launch library. Environment returns development, staging, or production. This is nice because it tells you where the data comes from – and also lets you conditionally trigger rules based on the Launch library’s environment (less common use case).

You know what turbineVersion means, right? Right? Okay, maybe not. The first thing I wanted to see from these Data Elements is tooltips. There IS a description in the extension configuration, which is nice. However, it would be nice to have a tooltip by each item (again, I emphasized tooltip because they’re underutilized in extensions).

SDI Toolkit Launch Attribute Descriptors

Let’s also think about the audience on this one. Environment and build date make sense to me, but what are turbines? If I’m technical enough to know what a Turbine version is then I am also technical enough to know I can just add _satellite.buildInfo.turbineVersion or _satellite.buildInfo.turbineBuildDate as a Custom JavaScript Data Element. My point is that this stuff needs to be translated into terms for people who aren’t as deep into the technical weeds. For those who are NOT familiar with what Turbine is, this is how the npm project explains it:

Turbine is the orchestrator within a Launch JavaScript runtime library (the library deployed 
on a client website) which processes previously configured rules and delegates logic to 
extensions.

Basically it’s a thing that makes rules and extensions work. It has versions. This might be useful if something weird starts happening with your data and you notice that the Turbine version has changed. Maybe something happened to an extension.

Malformed URL Error

Malformed URL Error

This Data Element holds your media team accountable (it’s totally their fault, right?). This checks your query strings to see if things look weird. This data element runs checks on the 8 malformations from the list below the configuration. Let’s take a look at the output of these options. Note: Using the Data Element Viewer while writing this review saved me a ton of time.

JavaScript Array of Errors

Input: ?hello=?hello=world

Expected Output:

3 Errors:

  1. Multiple ?’s
  2. Missing value
  3. Duplicate keys

Actual Output: 2 errors

Malformed JavaScript Array

Returned an array of errors, as expected. However, I doubled-up on query string keys. My guess is that it checks for VALID duplicate query string keys. Using multiple ?’s in the query string probably prevented the keys from being parsed correctly. One could argue that this technically doesn’t represent duplicate keys, as they aren’t being parsed normally. As a user, I would still expect to see 3 errors.

I also want to test to see what determines the order in which it scans for errors, as this affects the rest of the Data Element types:

Input: ?hello=&?world==foo&&hello&=bar&foo=bar&foo=bar

Expected Output: All 8 errors in order of the list.

Actual Output: All 8 errors (yay)… BUT it wasn’t in the order of the above list:

Every Malformed URL Error

Without diving into the code, it’s tough to tell what the logic is… so let’s do just that.

Malformed URL Code

If you click to enlarge the image, you’ll see that it scans for the errors in the order it’s coded. Note that the Malformed URL & before ? error check is in a separate function. This isn’t a very big deal. This may make a difference to analysts who would want errors prioritized based on how critical they are. Each of these malformations suck, but some suck way more. For instance, & before ? could be routing users to 404’s. Missing a key or a value would break a tag. Repeating a query string? Meh. Typically less important. This will matter more in the “First Error Only” test.

Pipe Delimited List of Errors

Malformed Pipe Delimited

This takes the errors that were in that JavaScript array and join them with a pipe. This is good if you don’t want to have to manipulate arrays. Interestingly, the maximum length of this string is 257 characters, which is 2 bytes more than what an eVar allows. There is a 0.000000000001% chance that you’ll ever see all 8 URL malformations at once, so if I was in your shoes (I’m not) I would use this data element to pass the malformation into a conversion variable. You could also pass it into a list prop (limited to 100 bytes). I think the most concurrent errors one might expect to see would be 3.

First Error Only

This grabs the first error in the array of errors. Using the examples from above, it would pull in Multiple ?’s in query string.

This is more of a binary check to see if something is screwed up. It’s more informative than a Boolean, but serves a similar purpose. In most cases, there will be only one thing wrong with a URL.

True / False String

This checks to see if there are more than zero errors in the list of errors. If there are, then it returns True. Otherwise, it returns False. This is a nice way to consolidate line items or conditionally trigger a rule based on whether there is a malformed URL.

One Way Hash

One Way Hash

The One Way Hash is a good way to ensure you aren’t passing PII (Personally Identifiable Information) into your analytics tool when setting consistent IDs. This is good if I want to use a consistent identifier without using a personal identifier. Jim Gordon will always equal 6485fb2ef39a035ff304123c7b4e6b2e1621583a416cef7d31995d90c37450a6 regardless of where/when I use this hash. It uses an algorithm called SHA256 which doesn’t mean a whole lot to me, but unless you have stored every combination of every letter/word then it’s nearly impossible to decrypt. I was able to decrypt my first name, which is why this should probably be used for stuff that’s more than a certain character length.

Events

Swipe Gestures

Swipe Events

These events are designed to trigger rules anytime someone swipes in a direction (or all directions). I might want to use this for a photo gallery where I can swipe between pictures. I don’t think this takes much more of an explanation, but its use cases are very limited.

Conditions

Malformed URL

Malformed URL Condition

This lets you trigger a rule (or not trigger a rule) based on whether the URL is malformed. This saves you some time if you don’t want to actually create a Data Element. This is convenient, but I would prefer to use the Boolean Malformed URL Data Element and then just evaluate using Value Comparison to check for True/False. It would slightly reduce extension bloat.

Actions

These actions all have a similar theme – store and retrieve information.

Cookie Setter and Remover

Cookie Setter Action

The Cookie Setter is nice if you want to retain data without reevaluating it like a Data Element would. It’s a cookie. You get the idea. In DTM, you use the _satellite.setCookie() and _satellite.readCookie() functions. In Adobe Launch, you use _satellite.cookie.set() and _satellite.cookie.get(). This adds a UI around those functions. I ran several tests with this action and it behaves exactly as the baked-in function does (it uses _satellite.cookie.set()).

Leaving the Domain field blank returns your URL just as though you typed document.cookie=“foo=bar”. Just as a tip, if you want the cookie to persist between subdomains, use .domain.com instead of just domain.com. Cookie remover uses _satellite.cookie.remove(). There are a few more options you can toggle if you need to specify whether the cookie only applies to the specific page/domain. Most cases you’ll just put the Cookie Key in the box (in our above example: foo) and it’ll remove it without any trouble.

From an interface perspective, this makes sense. It’s easier than using code. I would recommend flagging fields like Domain, Path, and Expiration as optional. The default expiration is at the end of the session – that’s nice to know, but isn’t clear.

Web Storage Setter and Remover

Web Storage Action

Session/Local Storage is much simpler, depending on how sensitive you are about your website’s Privacy Policy. This behaves just like cookies, but uses sessionStorage/localStorage. Session Storage expires when a user closes their browser. Local Storage sticks around for a very long time.

Final Thoughts

The SDI Toolkit adds a really nice UI around things that normally require code. I think the Malformed URL and One Way Hash (along with the look-up table) are the true stand-outs of this extension. The Malformed URL Data Element would make a beautiful automated report showing URL errors. The One Way Hash is critical to obfuscating PII. Cookies, Local Storage, Launch Build Info, and the Malformed URL Condition make easy stuff just a little easier. If I’m being totally honest, I think the Malformed URL custom condition should be removed from the extension. I get why it’s there, but we can create the Boolean with a Data Element and use Value Comparison. The Swipe Gestures are definitely good events to have in Launch (should be part of Core) but their use cases are limited.

Need help with Digital Analytics? Get in touch: