This week I dove into the SDI Toolkit by Search Discovery. If you recall, I already reviewed the lookup table. The extension has since been updated to v1.0.4. We’ll look at the other features included in this utility. 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?
Table of Contents
Data Elements
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).
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
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:
- 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:
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:
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
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
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
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
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
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
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
While writing this, I began to question the concept of utility bundles. To use 1 utility, I don’t want to have to buy a bundle of 12. I made that assumption based on gut feeling, so I decided to see how large these Data Element utility bundles are out-of-the-box (installed, but not used). As it turns out, the SDI Toolkit is 146 bytes. The DEA is only 168 bytes. The Adobe Target Toolkit is 163 bytes. That’s negligible. To contrast, the Constant Data Element is 165 bytes (still negligible). The various Adobe Analytics product string builders out there are around 200 bytes. In other words, it might make more sense to bundle utilities than it does to install individual ones (from a size perspective).
On the other hand, it’s not immediately clear to me what’s included in utility bundles. It’s immediately clear what I’m getting when I see Constant Data Element. These are the 2 things that will keep these utility bundles from becoming more mainstream.
- People think it will bloat the library (it won’t)
- People don’t know what’s in them and don’t have time to sift through documentation
That said, 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.
As with most of these bundles. The good utilities are really good. The others? Well, maybe I’m just not giving them enough credit. If you think you might use 1 utility but not all of them, don’t shy away from installing this extension. You can afford 146 bytes.