Build tag rules

In this video, we’ll explain the concept of rules and tags, and how to build them in the tags interface. A rule is a set of instructions that tells your tags build how to respond to certain events and conditions on your digital property, whether that property is a website, mobile app, or server. Every rule is essentially an if-then statement. If a certain event happens, and certain conditions are true, then the rule will take certain actions in response. Rules lie at the heart of the capabilities offered by tags. Everything that you manage and configure in tags, from installing extensions, defining data elements, building and publishing libraries, and so on, ultimately revolves around creating, testing, and evolving different sets of rules that let you collect data from your digital properties in real time. In other words, rules are the tool that lets you control exactly what kinds of customer activities are tracked on your properties, and how data related to those events is handled. So let’s jump into the tags interface and see how these rules are set up. You can see that I’m working in a web property here, since I’m going to be setting up a rule that listens for a certain event on our website, and then sends data about that event to Adobe Experience Cloud. But keep in mind that the fundamentals we go over here work the same way in mobile properties, and for the most part event forwarding properties as well. We’ll start by selecting rules in the left navigation. If we created rules for this property previously, they’d appear here in a list, but as you can see, we’ve yet to make one for this property. So let’s go ahead and select Create New Rule. And here we are at the Rule Builder. This is where we’ll configure everything we need to build out the rules logic. Note that the canvas is neatly divided into two sections between if and then, so we can clearly see what will trigger the rule, and what it will do as a result, respectively. But obviously there’s nothing here yet, so let’s add some logic to this rule, starting with the if section. This is where we determine when we want the rule to fire. Specifically, we need to choose at least one kind of event that the rule should respond to, and optionally, we can also include further conditions on top of that event if we want to get more specific. Now, as an aside, keep in mind that for mobile properties, rules work the exact same way where we choose between events and conditions for the if section. But if we were working with an event forwarding property, we’d only be able to set conditions here. This is because event forwarding rules listen to all server-side events that stream through, and only certain conditions within those events can be used to differentiate when some rules fire and others don’t. Alright, so back to our web property. Let’s pick an event to start. Click Add under Events, and we’re taken to the Event Configuration view. So to begin, we need to pick what type of event we want our rule to respond to. But in order to do that, we need to confirm the extension for that event type first. All rule components are tied to an extension, so the available event types you can use depends on the extensions you have installed on your property. When I click the Extension dropdown, we can see I just had the Experience Platform Web SDK extension installed, in addition to the default core extension that comes pre-installed with every property. Clicking the Event Type dropdown below, you can see I have a ton of options for the kinds of events that can trigger the rule. These are the default events provided by the core extension, so this collection captures some very general, common events that happen on websites. These include programmatic events, like pages being rendered and media assets being loaded, as well as user-triggered events like clicks, key presses, form interactions, and so on. If I switch the extension over to the Web SDK, the event type list changes to include those specific to that extension. So in this example, I want to build a rule that fires whenever a page is loaded on our website, so we can send some simple data about the page view event to Adobe Experience Cloud. In this case, for my event, I’ll pick the core extension, and then select Library Loaded for the event type. Choosing this event type will cause the rule to fire as soon as the Tags library is loaded on the web page. I’ll click Keep Changes, and now our event is added to the canvas. Notice that we can keep adding events to this rule if we want to. Doing this will cause the rule to have multiple events that can potentially trigger it, and this can be useful if we want our tags implementation to take the same actions in response to different kinds of events. However, keep in mind that when adding multiple events to a rule, an OR relationship between each event is assumed. In other words, only one of the events you add needs to occur in order for the rule to be triggered. So if adding more event types doesn’t constrain the rule at all, what happens if we don’t want this rule to fire on every page load, but only on certain pages within the website? Well, in that case, we can add a condition. Click Add under Conditions, and we’re brought to the configuration view. Just like events, we need to pick the extension that provides the type of condition we want to use, and then pick the condition type itself from the dropdown below. For example, under the core extension, we can make conditions based on cookie values, the user’s device type, the current website path, and so on. However, we also have this additional logic type dropdown at the top, where we can choose between regular and exception. A regular condition must be evaluated as true in order for the rule to fire, whereas an exception condition is one that cannot be true for the rule to fire. You can think of a regular condition as an AND statement, whereas an exception would be a NOT statement. In this example here, you can see that I’ve added two conditions to the rule, and from the canvas it’s clear what kinds of conditions they are. The one preceded by NOT is an exception, and the one preceded by AND is a regular condition. If I switch the order of these around, you can see the semantics change to AND NOT for the exception when it comes after the regular condition. We’ll just get rid of these conditions for now, though. Since this rule is going to be tracking all page view events, we want this rule to fire on every page load without exception. That’s it for the IF section, so let’s move on to THEN. Now that our rule knows when to fire, we need to give it at least one action to take in response. So, just like before, we’ll click Add and land in the Action Configuration view. If I leave the extension on core, you can see that I only have a couple options to choose from when it comes to action types. The custom code action is worth noting, though, as this lets you write and execute any custom JavaScript code or HTML script as an action, so your rules are never limited to just the action types provided by other extensions. In our case, though, we’re going to use an action from the Web SDK, so we’ll switch over to that extension. The SDK has several very commonly used action types, but the one we’re interested in for this video is SendEvent. When we add this action, whenever this rule fires on our site, the SDK will send data about the triggering event to our Experience Cloud applications. You can see I have a ton of options here, but since we’re just introducing rules in this video, we won’t get too deep in the weeds when it comes to how to use this particular action from the Web SDK. We’ll just do the bare minimum here, which means providing a string to tell the SDK what kind of event this is. In this case, I’ll use the dropdown and select PageViews, since we know that’s what this rule is tracking, and then selecting the data that we want to send, which I happen to have here in a data element that I made previously. From there, I’ll keep changes, and here we basically have our rule logic complete. We have an event that will trigger the rule to fire, and an action for that rule to take when it executes. All we need to do now is give it a name. It’s best practice to name your rules descriptively and consistently, so others in your organization can see what each rule is doing at a glance without having to click into its details. We encourage you to find a naming scheme that works best for your organization, but in my case, I usually start with something that indicates where the rule will fire, in this case that will be All Pages, then follow it up with the event type that this rule will be triggered by, and the type of action it will take in response, which for this rule would be Library Loaded, Send Event. I’ll click Save, and now the rule has been added to the list, where it can now be included in the libraries that we build and publish on this property. Once you’ve added your rules to a library and published it as a build on your website, it’s easy to test which rules are firing and when using console logs to see if they’re working as expected. One way of doing this is by using Adobe Experience Platform Debugger. On your website, open the extension and select Tags in the left nav, followed by the Configuration tab. Check the Console Logging box and hit Save to enable the logging feature. Doing this causes the page to soft refresh, so when we switch over to logs in the left nav, we can see some rules here already. If I clear these and load the homepage again, I get new logs for these rules in real time. From the timestamps, we can confirm the order in which they’re triggered, as well as which ones fired and which ones didn’t fire due to conditions not being met, like this rule here that’s only meant to run on the website’s product pages. Alternatively, you can also view these logs using the browser console without needing to use the Debugger extension. Simply open the console while you’re on your site, and then start typing in satellite, which will bring up the client-side satellite object that’s automatically set when tags is running on your site. From here, we’ll invoke the setDebug method from that object and set it to true, and when we run it, our rules will start appearing directly in the browser console when they fire. You can see that we have all the same info here as we get in Debugger, including the timestamps for each rule trigger, and whether the rules’ expected conditions were met for it to fire. So that was a quick introduction to rules and tags, including how to create them in the tags interface, and how to test their behavior on a website. Keep in mind that there’s a ton we didn’t cover here, like how multiple rules can build off each other for more advanced use cases, so be sure to check out the documentation and our other videos for a deeper dive into rule capabilities. Thanks for watching!