Lookup Tables: Adobe Launch Extension Review

We’re going to do something a little different for this review. There are 2 extensions that are currently on the Adobe Launch marketplace that have the same utility. One is named Lookup Table Utility by Blast Analytics & Marketing v. The other is part of the SDI Toolkit by Search Discovery v1.0.3. Full disclosure: I have no horse in this race and I have good relationships with folks at each company. As with all of these reviews, the purpose isn’t to criticize but instead to try to understand the differences and compare the functionality of each tool so you can make the best decision for your implementation.

Lookup Tables Extensions

For starters, these both already have excellent write-ups (see links above). Neither extension has functionality on their configuration screen. The SDI Toolkit has an explanation of what’s included in the toolkit, as the extension includes more than just a lookup table.

If you haven’t already looked at the links I posted above, let’s quickly go into use cases for a lookup table for the uninitiated. For starters, a lookup table lets you match a key to yield a value. if you’ve ever used classifications in Adobe Analytics – this is very similar. In this example, let’s say every time I yield a value of “foo” I want to return “bar”.

Lookup Value: foo

Key Value
foo bar
baz qux

Resultant: bar

More practically, let’s say I want to send an eVar to Adobe Analytics that identifies when a user is logged in vs. logged out. We’re using a Data Element Login Status that checks a cookie named “loginStatus” that returns “true” or “false”. “True” means the user is logged in, false means the user is not logged in. We want to send something more user-friendly than “True” or “False”.

Lookup Value: %Login Status%

Key Value
true Logged In
false Not Logged In

If the user is logged in, the %Login Status% Data Element will equal “true” – and the resultant of the lookup table will be “Logged In”.

 

Data Elements – Form

SDI Toolkit Interface

SDI Lookup Table

What I first noticed here was that it’s not actually called a Lookup Table in the Toolkit, but instead a Data Element Translator (see the shelf on the left). It isn’t nomenclature that I might expect if I want a lookup table. This interface uses more native’ish Launch design patterns, which is nice.

Lookup Table Utility Interface

Blast Lookup Table

The name of this Data Element type (on the left-hand side) is much more straightforward. I think the design patterns here take another second or two to figure out. + Add Row makes sense, but + Data Element makes me wonder whether I’m adding another Data Element or if I’m picking from the list. I’d change it to the database icon for consistency.

Data Elements – Function

This section is what really matters. We’ll run the exact same tests between each utility and see if there are any differences.

SDI Toolkit

Test 1

We’re trying to match a value of “1” with any of the Inputs as a string or as an integer. This will let us know whether incoming values are treated as strings or their original type.

Test 1 - SDI

Test 1A

Data Element value: 1 (string)

Expected Output: 20

Actual Output: 20

Test 1B

Data Element value: 1 (integer)

Expected Output: 20

Actual Output: Not Found (default value)

Test 1 Findings

In the first test, we learned that the SDI Toolkit’s lookup table treats each input as a string and leaves the Data Element as its original type. Therefore, comparing an integer to a string will return false.

 

Test 2

For this test we’re using dynamic values in the lookup table. We’re using a Data Element (with a value of “foo”) to match %An Input% (with a value of “foo”) and retrieve an output of %An Output% (with a value of “bar”). With this, we’ll find out if the %% syntax is converted into a string.

Test 2 - SDI

Data Element value: foo

Expected Output: bar

Actual Output: bar

Test 2 Findings

Data Elements work in the Input/Output section.

 

Lookup Table Utility

Test 1

We’re trying to match a value of “1” with any of the Inputs as a string or as an integer. This will let us know whether incoming values are treated as strings or their original type.

Test 1 - Blast

Test 1A

Data Element value: 1 (string)

Expected Output: 20

Actual Output: 20

Test 1B

Data Element value: 1 (integer)

Expected Output: 20

Actual Output: 20

Test 1 Findings

It seems Blast’s Lookup Table Utility converts all values from data elements into a string before comparing the value with each row.

 

Test 2

For this test we’re using dynamic values in the lookup table. We’re using a Data Element (with a value of “foo”) to match %An Input% (with a value of “foo”) and retrieve an output of %An Output% (with a value of “bar”). With this, we’ll find out if the %% syntax is converted into a string.

Test 2 - Blast

Data Element value: foo

Expected Output: bar

Actual Output: bar

Test 2 Findings

Data Elements work in the Input/Output section.

 

Final Thoughts

From a design perspective, they both have tutorials within the Data Element configuration that take up entirely too much space. It’s very clear which extensions are produced by a vendor versus which ones are native. Vendors seem to overcompensate with tutorials. Branding and credit is a good thing, but make the tutorials easier to ignore. After adding a few rows with each of these I’m already scrolling.

Functionally, both work and have the same features. The key differentiation is that Blast’s tool converts all data to a string (I tested with Boolean, as well). Given I don’t have the option to toggle string vs. non-string, I think this makes more sense because it normalizes the data that’s being compared. On the flip side, I might prefer my data to be compared in its raw form because it’s more intentional. Similar to my recommendation in the Constant Data Element review, it might be worth exploring a toggle that lets a user force each value into a string. One last MINOR difference is that the Blast tool lets you input JavaScript variables in addition to Data Elements. Your JS variables should be stored as Data Elements so this doesn’t really change anything.

The last thing on my wish list is to add in the ability to upload a CSV document. That’s a totally different level of effort, though.

1 thought on “Lookup Tables: Adobe Launch Extension Review”

  1. Thanks for the review Jim! I love the notes you have in here for our extension. This was the first one our team built so there are definitely some things we will want to change. We’ll look into updating the UI, the DB icon, and possibly add functionality for the toggle of string vs original data type. I know when we first released this we discussed allowing a CSV to be uploaded so this may be something we look into adding as well. Again, thanks for the great review!

    Reply

Leave a Comment