Build tag rules

Last update: 2024-02-23
  • Topics:
  • Tags
    View more on this topic
  • Created for:
  • Beginner

Learn how to create rules so you can execute commands in tags. Events and conditions determine when to do stuff while actions determine what to do. For more information, see the rules documentation.


Hello and welcome to this training video, building rules for launch. My name is Mike Mineer and I’m a technical training instructor here at Adobe. Now let’s talk a little bit about the rule builder. Rules are the foundational tool for setting up the triggers, conditions and actions for recording when something happens on the page. For example, I want this code to execute so I can track these data points and send them to these various data collection sources. A key point of this rule is the simple; if this, then that format. And this is beneficial because Launch is a rule-based system. It looks for user interaction and associated data. When the criteria outlined in your rules are met, the rule triggers the extensions, script, or client-side code that you have identified. Let’s go ahead and go on a system and take a look. So we have here our rules tab in Launch. At this point we don’t have any rules in here but we have already created some data elements, we’ve added some extensions, and we even have some multiple environments. So let’s go ahead first and take a look at the different options we have available to us in the rules tab. And then we’ll go ahead and create three rules to show you how you can use those different events, conditions and actions. We’ll go ahead and click on create new rule. First thing officially you need to do is give it a name and we’ll talk a little bit more about that in just a minute. But first let’s talk about events. Events use dozens of pre-built events like form submission, clicks, page views and history change to deliver great experience. In fact if we click here and we do a dropdown on the event type, you can see all the different types of events that are available for you to use. And I would like to make one specific call-out of the direct call event. In the past there’s been a tab array section specifically for direct calls. And there’s also been another one specifically for page load events. All events are now in this one single location. And you simply need to determine which event you want to be the trigger for your different actions.

Now if we come out of there and we look at conditions, you see like events there are dozens of pre-built options and conditions that you can use. Things such as; new visitor traffic source, data range, or sampling to fine tune the experience. You can see all these different options. And we’ll setup a rule later that has a condition so you can see it in use. In the final option are the actions. Now we get different actions based on the different extensions that we’re using. If we keep the extension as core, you’ll see that we get custom code. If we change the extension to analytics, you’ll see that we get three unique options to analytics. So each of the extensions that we’ve added has it’s own actions that we can do. So let’s go ahead and setup three different rules to show you some of the different functionality that is available. The first rule we want to setup is to fire the Experience Cloud ID service on our site. So we’re just going to call it ECID. It’s important to have a good naming convention for your rules cause over time you’re going to end up with dozens if not hundreds of different rules. So having a good naming convention will help you to keep them organized and to be able to easily find them later on. So with our ECID service the first thing we need to do is set an event. What is the trigger that we’re going to use? And for this we want to come down to the bottom to our page load and say; library loaded or page top. This is the first thing we want to have happen. So that also affects the order, since we don’t want anything to fire before this, we’re going to change the order to one. And we’ll go ahead and keep those changes. So now no matter what other rules we had, this is going to be the first thing triggered. We’re going to skip conditions in this particular rule. And we’re going to come down to our actions and go ahead and click add. Now we’re going to change the extension from core to the Experience Cloud ID service.

And there’s only one action we have available and that is to set the customer IDs.

Now the integration code would have been setup using a different tool, but we’re just going to go ahead and put cust ID here knowing that we’ve previously set that up. And the value is going to be pulled in from our customer ID data element that we previously setup. Our authentication state is going to their authenticator or logged in. And we’re going to go ahead and hash this for security purposes. Now we’ll go ahead and keep those changes. And we have set up our ECID or Experience Cloud ID service rule to fire on each page.

Let’s go ahead and use a different extension and setup two rules based on the analytics extension so we can see how multiple rules can work together. So first let’s go ahead and click add a rule. And we’re going to simply call this our AA page load rule, or our Adobe Analytics page load. We’re going to have this fire on every single page of our website to pass some basic information. So the first thing that we need to do is set an event. We’ll come in here and-- Events are always based on the core. We’re going to change the event type to our page bottom and we’re going to keep the order as 50. And you’ll see we’re going to change that in our next analytics rule. We’ll go ahead and keep changes. We still don’t have a condition for this cause we just want it to fire on every single page. If we wanted to, since we’ve set up multiple websites that are being tracked by this, we could come in and set something like a domain and it’ll let us say; we only want this particular rule to fire on We.Travel, and then we could setup another rule for We.Retail if we want. But for this rule we’re not going to set any conditions, we’re just going to tell is to fire everywhere. And the next thing we’re going to do is set an action. Now with analytics there are three different actions we need to do, the first thing is we need to set variables. Setting variables is the basic part of analytics, it’s how we pass information into analytics. And if we scroll down a little bit there are some default ones liker page name. So we’ll go ahead and set our page name to be based on our data element, call it page name. We’ll set our channel to be our primary category cause that’s what channel is meant to do. But we also want to track our channel or our category in eVar6, so we’re going to pass that same value of primary category into eVar6. And we’re going to set prop6. We’re going to go ahead and duplicate that from eVar6. So we’re just simply passing that category into each of those. And then we have a unique counter event, event10 that we’re going to go ahead and set here also. We’ll go ahead and keep those changes. And now we’ve set some variables. However, Launch is different than what we’ve had in the past with DTM. Simply because this still won’t fire an analytics beacon. We need to go ahead and click plus and add the action of send beacon. So a very simple action, there’s only two things we can choose; an s, dot t call which is a page view and that’s what we’re going to choose. Or we could do link tracking which is an s, dot tl. But in this case we’re just going to stick with the s, dot t. Go ahead and say keep changes. And there’s one more action we can do which is a best practice. And that is; we want to clear variables. Nothing more we need to do, simply after that beacon is sent, all variables that are currently set will be cleared. Which is fine cause we can use rules to set them on the next call that we want to make. We’ll go ahead and keep changes.

And then we’ll go ahead and save that. Now we’ve set up two rules. Now let’s set up one more final rule that will add additional variables to that page load rule.

We’re going to click add a new rule, and we’re going to call this our Adobe Analytics or AA search results page rule. This is designed so that we can now use a condition for certain pages or a certain page to add additional information. So we’re going to come into our events and just like our analytics page load rule, we’re going to say page bottom. But we’re going to change the order here to 40. We want this rule to be triggered before our page load rule cause what we’re going to do next in the conditions and in the actions; we want that to happen before the page load rule. So we’ll go ahead and keep changes. Now we’re going to set a condition. And the condition that we’re going to set is down here towards the bottom. We’re going to use the path without a query string, we don’t need it to look at the query string. And we’re going to simply look at a certain port of the URL of the search page, which is search, dash results, dot HTML. We’ll go ahead and keep those changes. So now this rule will only fire if that specific path is met.

And the action we’re going to set; we’re going to come into it and change the extension to Adobe Analytics, we’re going to set variables. And then on this one we want our eVar3 to equal our internal search term. And to follow what we did previously, we’re going to duplicate our prop from our eVar. And we also have a custom event. Event20, which we want to fire every time there’s a search done. Now we’ll go ahead and click keep changes. Now I want to point out here, we do not need the action to send a beacon or to clear variables. Because this rule is simply designed to add additional information into that general page load rule that we had for analytics. We’ll go ahead and click save. And we’ve now created our three rules. -

On this page