Use doPlugins and implementation plug-ins in Experience Platform tags

Transcript

In this video, I’ll review using the Do Plugins function along with implementation plugins using Experience Platform tags. This is what I’ll cover. I’ll start by explaining what the Do Plugins function and implementation plugins are used for. I’ll show you where to grab the code from documentation, where to add it in the analytics extension and tags, and finish with an example including testing the code on a website. The Do Plugins function is automatically called as part of every analytics call, whether for a page view, custom link, exit link, or download link. It’s the ideal place to set variables that you want to capture for all analytics hits, again regardless of type, as well as setting variables from implementation plugins. Now implementation plugins are code blocks that extend the capabilities of the analytics app measurement code. If you’ve worked with Adobe Consulting, chances are you’ve seen a few already. These plugins perform functions like getting the query string parameter value from a URL, formatting time values, appending a variable to a hit, and many more. In my browser, I’m displaying the documentation for implementation plugins. This is found in the analytics implementation guide. The left rail contains links to specific plugins, which I’ll be showing you more of coming up. I’ll start with Do Plugins because this is the starting point. Now to reiterate, this function runs right before the image beacon is sent to Adobe servers for any type of image request. This code isn’t automatically included in app measurement, so you do have to add it manually, and this is what we’re going to be doing next. I have a tags property open here. I’ll open the analytics extension configuration. Now I’ll open the custom code section further down, and I’ll have a look at the contents in the editor. To start with, I have a single line of code that outputs a log statement to the browser’s console. Now I’ll go to the Adobe website, and I’ll open the browser’s developer tools. I have debug statements turned on, and that’s done by typing in underscore satellite set debug true in parentheses, but I’ve already done that. I can see which rules are firing. The all pages rule right here fires for every page view. I also see the logger statement included in the custom code editor I just showed you. At the bottom of this page, there’s a link to Facebook in the footer. This opens Adobe’s Facebook page in another tab. This is considered an exit link. Now it doesn’t fire the all pages rule because it’s an exit link, and also it doesn’t fire the logger statement I added in my custom code in the analytics extension. Again, this is expected because we need to add the do plugins function plus any code we want to execute within it for all image request types, including links. All right, I’m going to go back to the documentation for do plugins, and I’m going to copy and paste the do plugins function from this page. It’s the block of code under sdo plugins in app measurement and custom code. There’s a copy command in the right corner. Now going back to tags, I’ll paste that code into the custom code editor in the analytics extension configuration. Okay, now there’s another variable I need to add above this function. It’s mentioned at the top of the documentation right here. If use plugins is enabled. I’ll click on the link and pop it open in a new tab. It explains right here that the variable needs to be enabled. This means I need to set that variable to true because it’s initialized to false by default. Now I’ll hit the copy link here. I’ll go back to tags, and I’ll paste it into the custom code editor right above the do plugins function. Now that my do plugins code shell is in place, I’ll talk about next steps. I want to set a variable on every image request. This is going to be for both page views and any sort of link. For demonstration, I’ll set prop four with the beacon type sent to Adobe servers. All right, so I already have that code that accomplishes that task, and I’m going to add it to the editor now. I’m going to put it within, of course, the do plugins function. And basically this logic sets prop four with the link type if the variable link type is not undefined. Otherwise it’s a page view beacon. Now this code alone won’t set prop four for link beacons. That’s because the variables you want to send with links must be included in the link track bars variable. So I need to use another block of code called an implementation plugin to append prop four to the request. All right, now let’s look at the help documentation for implementation plugins. In the left navigation area, you’ll see the plugins listed. I’m going to scroll up to the top to find the APL plugin, which is the one I’m going to be using for my example. This plugin allows you to add new listed limited variables like events, link track bars, and lists. There’s also a set of conditions for adding variables in the bulleted list. I’ll also mention that these plugins were created by Adobe Consulting and that customer care doesn’t provide support for these. So just be aware of that in case you need further help with them. Below it provides instructions for using the plugin in the Adobe analytics extension and tags. This is what I’ll be showing you. And then further down there’s a section for copying the plugin code. Now back in tags, I’m going to copy this plugin to my code. I don’t want the plugin code to execute until it’s called. So notice that I’m putting it outside of and below the do plugins function. All right, so last I need to call the plugin. I’ll go back to the documentation to see how to do this. Now the arguments are listed below the plugin code. The first two are required. The LV argument is the variable that contains a delimited list of new values that you want to add. So in my case, it’s s.linktrapvars because that’s the one specific to link begins. Next, the VTA argument should pass the value or values you want to add to the value of the LV argument. And then the last three are optional, but I won’t be using any of these in my code. Further down below the arguments are examples for calling the function. Now coincidentally, I’m setting Prop4 in my example, but I’ll be using slightly different arguments than you see here. All right, now back to the custom code editor. I’m going to add the call to the APL plugin to my custom code, and then I’m going to save the code. Now I’ll save and build it to my current library. All right, now that my library is built, let’s get this code tested on the Adobe site. I’ll refresh the page and in the image beacon for the page view, here I see C4, which is Prop4 set to PV, which is what I’d expect. Now I’ll scroll down to the exit link for Facebook at the bottom. Looking at the beacon fire from that click, I see C4 set to E for exit link. And again, that’s what I’d expect. All right, let me go back to the code and review the logic again. Here I’m setting Prop4 to the link type if the beacon is in fact a link. Otherwise I’m setting Prop4 to PV, which is the only other type of beacon. And then last, in order to append the value of Prop4 to the link beacon, I’m calling the APL, which is Append to List, implementation plugin. The logic to set Prop4 is included in the do plugins function because I need it to execute for all analytics beacons. This concludes using the analytics do plugins function and implementation plugins and tags. You should now feel comfortable adding this code to the Adobe Analytics extension. Good luck.