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?
Launch Build Info
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).
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
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.
- Multiple ?’s
- Missing value
- Duplicate keys
Actual Output: 2 errors
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:
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:
Without diving into the code, it’s tough to tell what the logic is… so let’s do just that.
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
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
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.
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.
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.
These actions all have a similar theme – store and retrieve information.
Cookie Setter and Remover
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
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: