Hey everybody, this is Doug. In this video I wanna talk about the global variables section of the Analytics extension in Launch. So, when you are configuring the Analytics extension one of the things you have available to you is this global variables section. Now, if I expand that and we look in it, you’ll see that I can set eVars and props and hierarchies and page names and all these different variables in here, and generally speaking, we start with that, generally speaking, this is a place where you can set global variables. Where you can set the variables that are going to be used on every hit, okay? So you might notice that I didn’t say on every page. It would be on every page load hit, as well as, every custom link hit, or s.tl, the track link hit as well. So that’s kind of a clue as to your best practices here on using global variables. You’ll see that I have a few in here that I’ve put in a page name into eVar4 as well as, putting the page name into the page name variable et cetera, by using a data element. But in any case, yeah that’s kind of the situation is that if you want these variables to go in on every hit, then, this is an okay place to put them. Now you will find that when you talk to some Analytics and Launch specialists, some consultants etcetera, they prefer to use a different location for most of their global stuff. And that is in a rule. But in any case, I just wanted to show you that this is available to you and you can set these variables and they will get set onto that s object, which is the normal default tracking object, when the extension loads and the object instantiates etcetera. So you will have these variables, in this case eVar4 and prop 10, and page name and these other ones that I’m setting. You’ll have those in there and they will be assigned to that tracking object, but they don’t get sent in unless, we send in a beacon, and that is done through a rule. So, if we did want to set these at a global level, we could set them here, and then we would need to go into the rules and create a rule that would send in a beacon again, either in s.t for a page load beacon, or an s.tl for a custom link beacon. Now as I mentioned, some experts prefer to actually do global type things in the rules. And I’ll click over here to the rules section. Yeah, discard any changes. And I’m gonna go into an all-pages DOM ready rule here. So you can create a rule that fires, for example, on DOM Ready, and has no conditions. And so, it will fire this event whenever the page comes up and is DOM Ready. And again, because we have more control over when this fires, again, here whether, it’s a page top, or DOM Ready or page bottom etcetera, and because we can also set the order here. So, if we have different rules that are firing when the page is DOM Ready, then, we can also select which order they fire in. And so this amount of control is a really nice thing to have when you are setting variables et cetera. Especially, if you might run into a race condition, you’ll want to have more control over when things are set, and when things are sent in et cetera. And so again, for that reason, and just to kinda have everything in one rule instead of spread out throughout the system. That’s the couple of main reasons why a lot of our experts actually suggest, that you create a global rule like this, instead of using that global area inside of the analytics extension itself. Okay, let me cancel this right here. But I do wanna show you again, that if you have that event set up to, for example DOM Ready Which is kind of best practice for a page load event. Then, down here you can set some more variables and this is a place where you could go in and set those variables. If you’re gonna set the page name variable, this would be a great place for it. Or maybe a channel, which is a site section that it’s in. Or setting other things, like maybe the page name into an eVars. So for example we had eVar4 set as the page name, and again, I can use a data element, and easily, put that right in there. So this is basically a global area itself. Because I haven’t set any limitations on the pages that this loads on. And so, this is basically a global load. Then, and I’ll just cancel this for now. But then once you set the variables, then, you’ll want to send the beacon. Because nothing is really going in, unless you actually send a beacon. And I’ll click on that and we can see that I’ve selected to send in an s.t which is a page view beacon here, and that goes in etcetera. So, that’s kinda your best practices there. Probably, instead of the extension itself, is to use a page load beacon and a page load rule, to send in your page based things, and that way you have more control over what goes in and when. But once again, if you like to go to the extension and the configuration area, and to the global variables, you can set any of these, keeping in mind that they’re gonna go in on an s.t or an s.tl, and you’ll want to be sure that that is what you want it to do. And then, in another video, we’ll talk about the configure tracker using custom code area where we can put our plugins and those kinds of things. And so, even if we don’t actually set some variables in these fields up here in this global variables section, we can always use plugins in the area below to set variables etcetera, and we’ll talk about that on another video. Anyway, hopefully that was helpful and good luck.