Why you should use the Constant Data Element more often in Adobe Launch

Adobe Experience Platform Dynamic Data Collection Tags, by Adobe Launch is the most prevalent Tag Management System for Adobe Experience Cloud customers. It is nicely integrated with the available Adobe Solutions and is offered completely for free to those customers. But while it is best enjoyed to fuel other solutions, it is a beast of its own with some unique features and mechanics.

I’ve already written a few posts about Adobe Launch’s particular features, like the ability to use call traces between rules or how rules can be executed exactly once. Today I want to focus on a specific Data Element, called the Constant Data Element Type. It has first been created by Jan Exner as a dedicated Launch Extension but has (thankfully!) later been built into the Core Extension.

I’m going to show you three of my favorite use cases for this, in my opinion, shamefully overlooked gem. You may already have read my previous post about configuration management through Launch, which also featured it, but I will also give some more examples for this specific and two more use cases. Make sure to read them all, as the third one is actually my favorite. Let’s get started!

Use case 1: What the name says

The first use case is basically what I’ve already described before plus some internal configuration applications. Whenever I want to use a value in the frontend or within other Rules, the Constant Data Element is my go-to solution. We can, for example, define a simple string value like this:

On the page, we can then use _satellite.getVar() to access this constant value:

So far, so expected. The string we define in Launch can now be used on the website directly. But another awesome way we can use this is in other Launch rules. For example, we can put it into our Custom Code Actions like this:

The above Custom Code Action prints the value to the console as expected:

There are a bunch of instances where I always like to use Constant Data Elements in this way. For example, you could:

• Use this to manage IDs of ad accounts used in marketing pixels
• Configure your consent management container ID
• Set configuration parameters for other scripts

As Jim has pointed out correctly, using numbers in this Data Element can be a bit tricky. The same is true for other non-string data types. In the interface, there is nothing stopping us from putting a number into the value field:

But when we access this “number” in the frontend, we can witness some of the fun surprises Javascript’s dynamic typing has in store for us:

Besides the urge to leave the industry and start a new life on a remote farm without internet, I also want to mention one (admittedly overly complicated) way to return actual numbers through this Data Element type. To start, we need a Custom Code Data Element returning the desired number:

We can then reference this Custom Code Data Element in another Constant Data Element, which will inherit the referenced data type:

Accessing this Constant Data Element in the frontend now returns a number:

So, if you want to return an actual numerical value (or objects, boolean, etc.) directly from Launch, this is a way to do it. Of course, just using the Custom Code Data Element would be much more straight forward in this case. But now that we’ve already touched on the option to reference other Data Elements, let’s jump into our second use case…

Use case 2: Concatenate strings and Data Elements

Since we have already learned that we can reference other Data Elements without issues, it’s super easy to create combined Data Elements using the %% expressions. Using the Data Elements we defined above, we can create a combined Data Element like this:

Using this in the frontend works flawlessly:

We can use this composite value in other Rules in Launch as well. One thing I use myself and frequently see others do is putting information about the Launch environment into an Adobe Analytics eVar. Using the rather new Runtime Environment Data Elements and a Constant Data Element, we can create a value like “%Config | Environment Name% | %Environment | Launch Property Name%: %Environment | Launch Environment Type% (%Environment | Launch Build Date%)” to pull a lot of information into the Adobe Analytics Extension:

How neat! If we want to use a complex value like this in multiple places, we can just define a Constant Data Element and use it everywhere! If you are good with the Launch API, this would even allow you to roll out changes across multiple Launch Properties. Now, onto my favorite use case!

Use case 3: Accessing Launch’s internal variables

This use case is super, super cool! To fully appreciate it, we need to first understand a bit about how Launch uses information provided from Events internally. When using an Event for your Rules, like Page Top or an Event from the Adobe Client Data Layer Extension, those Events can attach information about the event to components in the following Rule components. For example, you could access the name of a clicked element on a page from the Click Event when sending out Analytics calls.

Adobe Launch does this by writing the information into a variable called “event”. You can see what it contains by printing it to your browser console in a Rule like through this Custom Code action:

Depending on what Event you use the payload can be quite different. Here are two examples, one for the Click Event from the Core Extension and one for events pushed to the Adobe Client Data Layer Extension:

That’s quite a lot of information! Now, if we want to access this information, we can use the familiar %% notation with the path of the desired information. For the Adobe Client Data Layer Extension’s message, we could use something like %event.message.foo% for the example above.

Doesn’t that syntax look familiar from the previous use case? It should! Using the amazing Constant Data Element, we can pull information like the key from the Adobe Client Data Layer event into a Data Element like this:

By using %event.message.key% here, we will pull the corresponding value from the Adobe Client Data Layer Event into our Data Element when the Rule fires. We can then use this Data Element in any Rule we want, like for naming a custom link when firing an Adobe Analytics call.

But wait a second: If we can use the same %event.message.key% syntax in, for example, the Adobe Analytics Extension directly, why should we even wrap it into this Data Element? Isn’t that just unnecessarily complex again? The answer is simple: manageability!

Websites change quite drastically over time and data layers often change with them. New developments may require you to change where information within the pushed events is found. If you use those pieces of information in a couple of places, you will suddenly need to touch many existing rules to apply the correct location of the information. If you put it into a Constant Data Element instead, you will only need to change it in one place! Thinking about democratization and accessibility, using clearly named Data Elements can help you to make your Launch setup much more readable to anyone who is not familiar with the intricacies of your data layer. Managing information like this has saved me hours of work in my job already.

Conclusion

I hope you found this post useful. The Constant Data Element should, at least in my opinion, be a well-understood tool in the belt of anyone who manages implementations through Adobe Launch. It is a great way to make your setup easier and better to understand. Thank you Jan Exner for creating it and making it part of the Core Launch Extension!

As always, let me know if you found this post useful. Have a great rest of your day!

Frederik Werner

German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.

2021&2022 Adobe Analytics Champion

EMEA Adobe Analytics User Group Lead

www.frederikwerner.de/