Stack tag rules

Transcript

In this video, we’ll go over the concept of rule stacking and tags, which allows you to create dynamic modular rule sets that adapt to different variations of similar events that occur on your digital properties. To demonstrate this, we’ll be building out a simple use case and tags within one of our web properties. We’re going to set up three rules that are all triggered by the same type of event and perform different actions in sequence. Specifically, these rules will trigger for every page load event on our website, where they’ll then perform the following actions. The first rule sets some global variables that are present on every page of our site. The second sets additional variables when the user is on our product page, and the third rule sends that data to downstream Adobe Experience Cloud Applications. To follow along with this tutorial. You’ll need to have a web property with the experience platform web SDK extension installed, including the required data streams, schemas and data sets. The SDK installation is out of scope for this demo, so if you need more information on setting this up, please refer to the Web SDK documentation. If you’re not using web SDK yet, this rule stacking technique is still very useful if you implement the older Adobe Analytics or Adobe Target extensions. You’ll also need to set up three specific data elements before you can fully build the rules. One of them using the variable type from the web SDK and the other two being simple JavaScript variables from the core extension will quickly cover the details of these data elements to start before moving on to the rules themselves. So let’s jump into our web property and click into data elements on the left now. We’ll go through these data elements one by one, and if they’re intended purpose seems vague right now, that’s okay. It’ll make much more sense when we work them into our rules later on. For now, all that matters is their composition. So first up is actually a variable content data element, which is the most complex of the three. This uses the variable data element type from the web SDK extension, which means this data element is formatted as a JSON object that we can populate as a structured variable. More importantly, though, this object conforms to an experienced data model or idms schema axiom schemas are natively understood by the SDK and experience cloud in general. So by constraining our data element to a next team structure, we can ensure that we populate it in a way that’s immediately actionable by our downstream applications. You can see us selected the Luma Web event schema in our production sandbox, which was set up when we first installed the Web SDK. If you ever want to see the structure of the schema for a variable type data element, simply hop over to the data collection interface. Select schemas on the left NAV and look up the schema name from there. The other two data elements are much simpler by comparison, and they both use a JavaScript variable type from the core extension. Clicking into this page name element, you can see it’s referencing digital data, which is the variable name for the global JavaScript object that serves as the data layer for a Lumos website. And within that object you can see we’re drilling down a few layers to pull out the name of the current page. This data layer attribute is made available on every page of the site for the other data element. It’s basically doing the same thing, accessing the data layer object and grabbing a value to use as a variable. In this case, this one’s fetching the title of a product. Unlike the page name attribute, product titles are only available in the data layer when the user is on a product page. The zero here indicates this element expects to access an array and will fetch from the first object within it. As that’s how Lumos data layer happens to surface product info on their respective pages. If we are trying to access the product titles from what the user has on their shopping cart, that would take on a different structure in the data layer and we’d have to capture that path in a separate data element. Every data layer’s name is structured differently, so always make sure you understand the one you’re working with and adjust the paths for your data elements accordingly. All right, we’ve covered our data elements, so let’s head over to the rule builder and start creating some logic for most web implementations. One of the first, if not the first rule you want to fire with the page loads is one that grabs relevant, globally available information from the data layer to populate some standard attributes. You can think of this as your baseline data collection rule, representing the bare minimum amount of data you want to capture whenever tags loads on your site, regardless of location and context. This will include things like page, name, the user’s current login status, and so on. Start by adding an event. And since we know LUMA as data layer is completely loaded before tags will select the library loaded event and the core extension for the type on your website, you may need to use a different event like bottom of page or a custom event to ensure your data layer is available before your rules start firing. Now, if we were making a standalone role here, we would just say this event and move on. But since we’re going to be making a rule stack, the order attribute for the event becomes very important when using multiple rules that are triggered by the same event type. This value controls the order in which they’re fired, which is critical if one rule builds off the output of another rule when multiple rules are triggered by the same event. They will fire based on their order number from lowest to highest. Since we know we want this rule to fire before all others will set this to one. Before keeping changes. We don’t need any conditions for the rule since we want it to fire on all pages. So we’ll jump straight to adding an action for the extension. We’ll use the platform web SDK and for the type to update variable. This is a really powerful action that lets you flexibly populate an EDM object based on the context of the event and your rule object. What’s more, with rule stacking, you can have multiple rules. Use this action to all update the same variable with different sets of attributes for different conditions and use cases. Adding and overriding values as necessary before we eventually send the completed object to experience cloud. To configure the action, we need to choose the variable type data element that we want to populate as part of the rule. Since our content data element is the only one of this type created on our property, it’s auto selected for us here and below. We have the full axiom structure available for us to explore. Keep in mind that this is just the schema for the variables. Object structure and the variable itself will only contain fields that are actually populated with data when we invoke it or send it downstream. Several fields of asterisks next to them, meaning these will automatically populate if we use the web SDK to send this event to the edge network, like the timestamp for the event in the web page URL. As for the rest of these fields, we can populate them using our rule logic. For the first rule, we’ll just populate two fields the event type and the page name. So we’ll click the event type field and all heart code. The value for a page view as recognized by standard actually M you can provide your own string value here to represent a page view if you want, but best practice to support downstream users is to stick with a predefined value for an event type if one is available. Note that when we populate this field, its icon in the schema structure changes to indicate this. Next up is the page name. And for that I’ll click into the web object. Then web page details the name. Now we could hard code another value here if we wanted to, but since we want this to dynamically fetch the current page name, we’ll use the data element icon to select the JavaScript variable element from earlier like before the icon for the field updates to show it’s populated. But since this is a nested object, the icons for its two parent fields also update to show that they’re partially populated. We’ll keep changes. And now we have a rule that will populate our variable with the page name. Whenever a page is loaded on our site for the name, we’ll call this all pages library loaded global variables so we know where this rule will fire, what event will trigger it, and what it’ll do in response. I’ll also tack on the order number or reassign to the event for this rule, so it’s easy to see at a glance when we’re expecting this rule to fire compared to other rules responding to the same event. Well, let’s save. And that’s our first rule done. Now that we have a rule that sets some global variables on every page, let’s make another rule that adds more information to our variable object. When the user lands on our product page, hopping back into the rule builder once again, we’ll select the library loaded event. And since we want to make sure that this rule fires after our global variables rule, we’ll set the order value to 20. We could set this to two if we wanted to, but it’s usually good practice to leave gaps in the order numbers. In case you want to add more rules of between later. Next, we need to add a condition since we only want this rule to fire when the user is on our product page. Under the core extension, select the path without query string condition type for the path itself will enter in products wrapped in slashes and enable the option so that this condition will return true for all pages where the product’s namespace is contained in the URL. Make sure to keep the logic type to regular since we only want this rule to fire when this condition returns. True, you keep changes for the action. We’re going to use update variable once again. Keep in mind that we’re setting this rule to always fire after the set global variables rule finishes, meaning that by the time that this action fires, the content variable will already be populated with the page name and the event type will be set to page view. And here’s where this action type really shines. Since this rule only fires in the context of a product page, we can use that context to refine our variable with more specific information for our downstream solutions to act on. For one thing, on product pages, we want to update the event type to a product view event instead of the baseline page view event. Just like before. We simply hardcoded the product view string and the event type field. So whenever this action fires, it will replace the existing event type value when stacking rules in this way, it’s best practice to set the order so that rules for more general situations fire first, followed by those that fire under increasingly restrictive or rare circumstances, so that you’re always adding context to your collected event data rather than taking it away. We also want this action to add the name of the currently view product to the variable. So we’ll go product list items, item one name, and then set this field to the product title data element that we showed earlier. Cool. Let’s keep changes and name this rule. Same pattern as before. This time we’re indicating that this is only firing on product pages and it’s collecting the commerce related variables instead. Don’t forget to add that order number to add save. And now we have two rules that directly build off of each other to populate a variable. In other words, we’ve just made a rule stack that acts as a single algorithm executing in sequence. We can keep changing rules like this together as long as we’re careful to order them in a way that makes sense. In many implementations, you can see lots of these stack rules, but for this demo, we’ll just make one more rule that’ll fire up to the previous two to send or populate a variable to the platform edge network. Just like our first rule, we want this to fire on every page without exception. So we just need to add the library loaded event with no conditions. Make sure to set the order number higher than all the other rules, since we want those to finish populating our variable before this rule sends it to the edge network. In my case, I’ll use 50. Moving on to add the action will pick the web SDK extension once again, but this time will pick send event for the action type. When it comes to picking the data we want to send, it’s as simple as clicking the icon next to extreme and choosing our content data elements on the list. That’s it. Despite the complex constraints that team enforces on the data you send to experience cloud using update variable actions in your rules combined with variable type data elements makes it easy to ensure that your data is structured the right way. Every time we’ll keep changes and we’ll wrap up by naming this rule. Same schemas before hit Save. And there we go. A simple little rule stack that will take a next variable, populate it with some baseline data for every page load event, followed with some more specific data under certain predefined conditions. And finally, sending that dynamically populated data object to the edge network for downstream processing. All we need to do now is add these rules to a library and build it to one of our development environments to see how it runs on our site. So let’s jump ahead a bit and see what that looks like. All right. So we’ve built our library and now we’re here. And Luma, I’m using an experience platform debugger. What console logs enabled. And I’ve also used the configuration tab to switch the embed code to our development environment, where we’ve built a test library that contains the new rules we’ve just built. So let’s see how they do. I’ll click to the home page and let these logs populate. You can see there’s a mix of logs coming from tags on the web SDK, but we’ll scroll down until we start seeing rules. And there’s our global variables rule firing going first just like we want it to. Below that, we can see our second rule didn’t fire because the condition wasn’t met, and that’s also what we want to see because we’re not on our product page. And right below that we have a log from the Web SDK that shows the completed HCM object. It was given for the Send event action expanding the so we can see that we have the event types that the page views and the page name is also populated. Keep scrolling down and there’s our last rule mark desired indicating that the send event action completed successfully. Keep in mind that a rule fired log isn’t posted when the rule in question is initially triggered, but rather after it’s finished processing Looks good so far. So let’s clear these logs and head over to our product page and see if our commerce rule is working correctly. We’ll also use the search bar to narrow down the list of logs when they come in searching for the rule itself. First, we can see that our commerce variable rule fired when it was supposed to. We’ll adjust our search terms so we can pull up the time object that was sent and ever expanding it. We can confirm that the event type and product name were updated correctly. So that’s how you stack order and test tag rules to dynamically collect client side data from your digital properties. The use case we covered here was specific to using one of the platform SDK is for a web property, but these concepts can be applied to all property types for a ton of advanced marketing use cases using virtually any combination of extensions, data types and rules. We look forward to seeing the creative ways you leverage TAC rules to get the most out of your client side data collection capabilities. Thanks for watching.