Create data elements

Learn how to create data elements to store values pulled from your data layer and make them available to rules and extensions in your tag property. For more information, see the data elements documentation.

Transcript
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 constructs 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 and use cases without ever needing to touch your website’s code. And most importantly, data elements or references. Whether you’re 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 a references and tons of configuration options, making them a powerful reusable tool to keep every decision made in your tag’s implementation in a data informed decision. So let’s hop into the tags interface and create some data elements. I’m starting here in 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 will 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 will 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 will 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 will be surfaced in the data layer for the website, which Luma happens to have opening up the pages 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 is 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, we’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 lower case value or use a clean text option to remove line breaks and spaces unless your use case is particularly concerned with exact patches 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 such as 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 cash value. In nearly all cases, your best option is leaving this at the default setting. But if your use case requires that we do have some other choices available page view all of the data element persist as a variable until the next page loads where a 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 and 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 that would be page page info dump page name 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 are looking for. We’ll click Save and that’s it. That’s our first data element created. It’s a very simple dead element, of course, but we can use that simple logic in more complicated. Did elements like conditional values inside? 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 home page, 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 is true will change the number of inputs required if we select them, or 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, 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 references. Well, we can use them virtually anywhere in tags where data inputs are expected. Whenever you see this icon next to an input field and 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 to dynamic values, but for this situation we’ll just hard code The name of Loomis Home page as it appears on the data layer, which is content. Luma use n All right. 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 in reference, 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. Well, hard code 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 hardcoded 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 home page welcome message 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 date element. You can probably see how we can keep going from here, creating more data elements that leverage and manipulate the 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 we’ve included a data element and a rule out of 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 get var method, which will return the current value of any data element we specify. Let’s start with our page name Data element, which if you remember, we named page Stop page invoked page name, run the command and there’s our page name so far so good. Now let’s pick a random product here and go to what’s details page and then we’ll run the scene command from here. All right. Looks like it’s updating correctly so we know our storage duration is also good. All right. Now same command again. But let’s try looking up a conditional value.
And yet we got our fallback value, which is what we’d expect since we’re not on the home page. So let’s actually go to the home page 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. Include your tag rules, the data driven context. They need to know when and how to act on customer related events. Thanks for watching.
recommendation-more-help
9cc2b5f3-7a2d-451f-950c-f8f7136b6390