In this video, we’ll explain what data elements are in tags, and how to create them for a property using the tags interface. As a system, tags is meant to sit on top of your digital properties to collect and leverage data for your marketing operations. Rather than integrating directly with your property using bespoke custom code, tags abstracts this data into its own set of contracts, so it can safely manipulate that data in isolation from the operations happening on your website, mobile app, or server. In tags, these abstractions of your data are referred to as data elements. Data elements are essentially building blocks that let you collect, abstract, and organize different kinds of data that are surfaced on your digital properties, from page view information, to product details, device info, customer identity information, and pretty much anything else you can think of. You create and manage data elements within the tags interface, giving you full control over how this data is organized and manipulated for your marketing use cases, without ever needing to touch your website’s code. And most importantly, data elements are referenceable. Whether you are creating conditions for a rule to fire, choosing data to send to a downstream destination, or even defining other data elements, you can invoke the names of existing data elements as references in tons of configuration options, making them a powerful, reusable tool to keep every decision made in your tags implementation a data-informed decision. So let’s hop into the tags interface and create some data elements. I’m starting here on my web property, so if you’re working with a mobile or edge property, keep in mind you’ll have access to different kinds of data elements than the ones you’ll see here, but they all generally work the same way in principle. Click Data Elements in the left nav, and here we’ll see a list of data elements we’ve made for this property previously. If you’re working with a new property, you won’t see anything listed here yet, but in either case, we’ll select Add Data Element and land in the creation dialog. The first thing we’re prompted to select is the extension. Every data element has a type, and every type is supplied by a particular extension. By default, this is set to the pre-installed core extension, and since we’re working with a web property, under the Data Element type we have a list of very common kinds of client-side data for websites, like JavaScript variables, DOM attributes, cookie values, and so on. If we switch the extension over to the Web SDK, you’ll see a different list here instead. So, whatever type of data element you want to create, make sure you have the right extension installed on your property. For this data element, we’ll stick with the core extension, and for the type, we’ll choose JavaScript variable. This is a really commonly used data element type, since you can invoke it in a rule to fetch a value from any globally accessible variable on the web page when that rule fires. For example, let’s say we’re working with Luma, and we want this data element to capture the name of the current page when it’s invoked in a firing rule. Ideally, this information would be surfaced in a data layer for the website, which Luma happens to have. Opening up the page’s HTML structure using my browser tools, I can search for the data layer by name, which happens to be digital data in camel case for Luma, but other websites may name it something different. As you can see, the data layer is just an object that’s available as a global variable on the client side of your website, containing data that dynamically changes based on the context of what’s happening on the page. And here’s our page name value, which has nested a few layers inside of this page object. So, to assign this to our data element, all we need to do is reference the field name the same way we would in JavaScript code. So for the value, I’ll start with digital data to reference the data layer object, and then drill down through page, then page info, and finally end with page name. And that’s basically all we need to do to set up a data element that uses this type, but we do have some additional options to choose from if we want to. For example, we can set a default value for the element if it’s not able to fetch one when it’s invoking your tag rules. It’s usually fine to leave this unchecked, but depending on the data you’re capturing, or how you want to use or test it, this can definitely be a useful setting. We can also set this data element to force a lowercase value, or use a clean text option to remove line breaks and spaces. Because your use case is particularly concerned with exact matches for strings, we recommend enabling both of these options to normalize the values of your data elements for easier matching. Finally, we can choose the storage duration of the data element. By default, this is set to None, which means when this data element fetches a value when it’s used in a rule, it will need to fetch that value again in the next rule that uses it, instead of using a cached value. In nearly all cases, your best option is leaving this at the default setting, but if your use case requires it, we do have some other choices available. Page view will let the data element persist as a variable until the next page loads, whereas session and visitor will store the value within the browser session storage and local storage, respectively. The last thing we need to do is name this data element. Like all things that you name in tags, we strongly encourage you to find a naming system that’s consistent, descriptive, and useful for your organization’s needs. In my case, I usually name the data element following the same dot notation reference as the client-side variable I’m using it to fetch, so for this one it would be page.pageInfo.pageName. When your property eventually has dozens if not hundreds of data elements listed, using a hierarchy like this in your naming scheme can make it easier for you and other tag developers to find the specific data elements they’re looking for. We’ll click save, and that’s it. That’s our first data element created. It’s a very simple data element, of course, but we can use that simple logic in more complicated data elements like conditional values. In fact, let’s make one of those right now. We’ll stick with the core extension again, and then pick conditional value for the type. This type of data element lets you compare two values and return another value based on the result. Both the values that are compared and the ones that are returned can be hardcoded, but you can also use other existing data elements to represent those values instead, making this a very powerful tool to use in your rules. For this use case, let’s create a data element that returns a simple welcome message if the user is currently on the homepage. We have a few options when it comes to configuring the conditional. By default, it’s set up to let us compare two values to see if they match, but clicking on operator we can see we have a bunch of comparison methods to choose from. Some checks, like isTrue, will change the number of inputs required if we select them, but for this one we’ll stick with the equals comparison. For this operator, we need to provide the two values, or operands, that we want this data element to compare. Since we want to check the current page name in this comparison, for the left operand I’ll select the data element icon and simply choose the page name element that we created earlier. This is what we mean by data elements being referenceable. We can use them virtually anywhere in tags where data inputs are expected. Whenever you see this icon next to an input field in tags, you can use any compatible data element for that setting. For the right operand, we could provide another data element if we want to compare two dynamic values, but for this situation we’ll just hardcode the name of Luma’s homepage as it appears in the data layer, which is content-luma-us-en. Alright, now we also have a return conditional value setting which, if checked, makes this data element return a certain value if the comparison resolves to be true. We can also choose a fallback value to return if the evaluation comes back as false. Since data elements are meant to return some kind of value when referenced, you’ll need at least one of these return options enabled to make use of the conditional. If you don’t need an explicit return value, and you just want to add some conditional logic to your tag rules, you’re much better off using condition components directly in the rules themselves, without needing to use a data element. For this element, we’ll hardcode a simple welcome message for the conditional return value, but note you can also provide another data element here if you want. We technically don’t need to provide a fallback value for our use case, but for debugging purposes it’s good practice to hardcode a generic value here so we don’t have to deal with mysterious undefined results when we’re trying to test our data element later. For the name, I’ll use the same dot notation format as before. For this one, something like text.homepagewelcomemessage would work, since it describes what kind of data this conditional value will return, if it returns anything at all that is. Click save, and now we have our second data element, which directly leverages our first data element. You can probably see how we can keep going from here, creating more data elements that leverage and manipulate these simpler data elements with increasing complexity. So, the next natural question is, how can we test whether these data elements are populating correctly when we run them on our site? Well, to answer that, let’s head back over to Luma. Once you’ve included a data element in a rule, added that rule to a library, and then built that library to an environment, you can verify whether that data element is working as expected directly in the browser. Open up the browser console and start typing satellite, preceded with an underscore. This will access the global satellite object that’s automatically set on every page running tags, and contains a bunch of useful functions we can invoke here. In this case, we want to use the getVar method, which will return the current value of any data element we specify. Let’s start with our pageName data element, which if you remember we named page.pageInfo.pageName. Run the command, and there’s our page name. So far, so good. Now, let’s pick a random product here and go to its details page, and then we’ll run the same command from here. Alright, looks like it’s updating correctly, so we know our storage duration is also good. Alright, now, same command again, but let’s try looking up our conditional value. And yep, we got our fallback value, which is what we’d expect since we’re not on the homepage. So, let’s actually go to the homepage, and then run it again. And there’s our message. We confirmed our data elements are working fine, and we can continue building out our logic from here. So, that was a basic introduction to data elements, including how to create them in the tags interface, and test them for a website. From here, you can keep creating your own data elements to capture dynamic information from your digital properties, and keep your tag rules the data-driven context they need to know when and how to act on customer-related events. Thanks for watching.