11/18/19 Update: The Constant Data Element extension is now part of the Core Launch extension!
Welcome to the first Adobe Launch extension review. The purpose of this series is to get hands-on with extensions that have been created by the community. My goal isn’t to rate these extensions, but instead to learn about them and share my thoughts. While I will state my opinion, keep in mind that this is coming from someone looking from the outside in. The first extension we’re going to look at is the Constant Data Element (v1.0.2) by Jan Exner. Here it is in the marketplace:
This one will be super simple, as this extension does one very basic thing. It lets you define a constant value as a Data Element. There’s no Extension configuration screen – and there doesn’t need to be. This extension solves the problem of there not being a template to define constants in Adobe Launch. Normally, you would have to either write a string directly in the rule OR use a Custom Code Data Element to return a string (I never do this).
So why would someone want to use a Constant Data Element? There are lots of reasons. One is that I’ve constructed page names in Adobe Analytics using partial strings that I’ve manually typed into the interface – several times. While these values aren’t regularly changing and they aren’t dynamically set by a data layer, I still want consistency (typos CAN happen) and realistically… it will eventually change. While you can use Tagtician to track down each individual rule where you’ve manually set these values – that’s a waste of time. As simple as it is, having something handy like this extension in Adobe Launch might encourage you to think about your implementation differently… and that’s a good thing.
Data Elements
Let’s break down the interface and see what the output looks like. This should be pretty straightforward.
Concise. For this example, I will type “Hello, world!” where you see “Put a value here”. My expectation is when I check the Data Element it will return Hello, world!
Input: Hello, world!
Output: Hello, world! (string)
Now let’s try with an integer!
Input: 42
Output: 42 (string)
Interesting! So if you’re thinking about using this to do mathy stuff, remember that all outputs are strings (as of v1.0.2).
Final Thoughts
This will probably one of the most under-utilized extensions out there. In my opinion, it should be part of the Core extension. As practitioners, we need to continuously evolve the way we think about our work. CSS evolved into the Sass syntax because we learned that typing the same thing over and over again didn’t make sense. Even if we only set the value once when we stand up the Launch implementation… in 6 months, you’ll start seeing redundancies. In 12 months, you’ll wish you had used the Constant Data Element extension. In terms of where I would improve… I think it would make sense to have a checkbox to “force as a string”. I would want to be able to leverage a Boolean or integer. Other than that, this is a super nifty and straightforward extension! Great stuff as always, Jan.
Hey Jim, thanks for the great content you put out. How has the recent release of the cross-property Copy feature impacted the usefulness of an extension like this one? Since that release I have just set up a “template” property with all the string values in their places and copy those values from that template to the new property. Thanks again :)
Hey Clark – Great question! I didn’t even think about that! If anything, it makes this extension even more necessary. Let’s say I have a page naming schema set up for Adobe Analytics where I’m pulling in a few static values – let’s say all my page names look something like this “jimalytics:blog:some post”. In Adobe Launch, that may look like this:
jimalytics:%Section ID%:%Page ID%
I might be manually setting this page name in several locations. By copying my rules over to another web property, that means I have to find each instance and replace “jimalytics”! That’s a pain. Instead, I would use the Constant Data Element to just change the Data Element instead of each instance.
So I guess where we net out is that it depends on your use case and how your implementation is structured. I wasn’t even thinking about something of that scale when I wrote it – so I’d say that for my use case, web property scaling just made it more powerful! However, in other contexts I can see how this would be less necessary. It all depends on how you build your implementation.
Re this Extension being part of Core, see https://github.com/adobe/reactor-extension-core/pull/1