[cs_content][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][x_image type=”none” src=”https://taginspector.com/wp-content/uploads/2017/06/Screenshot-2017-06-30-07.38.09.png” alt=”Tag Management for eCommerce Enterprises” link=”false” href=”#” title=”” target=”” info=”none” info_place=”top” info_trigger=”hover” info_content=””][/cs_column][/cs_row][/cs_section][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][x_blockquote cite=”Lucas Long, Product Manager for Tag Inspector” type=”left”]“Any large initiative related to tagging should follow the same path.”[/x_blockquote][/cs_column][/cs_row][/cs_section][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][cs_text]When it comes to Tag Management for eCommerce Enterprise, it is crucial we understand how tags affect the performance and data quality across multiple websites.
On June 21st, Lucas Long hosted a fantastic webinar that focused on the tag lifecycle and our Tag Management Methodology. We focused on information that would make an eCommerce marketers/developers/analysts life easier by discussing ways to maximize performance through in depth understanding of eCommerce Tag Management.
Did you miss the webinar? Don’t worry! We know announcements get lost in the cracks of a business schedule. That’s why we have included the webinar recap at the end of this blog.
After watching this recap, you will:
- Be able to explain how tags affect data quality, performance and – if left unmaintained – conversions
- Feel ready to create a tag management process that will bring structure to the organization’s digital initiatives
- Understand the importance of ongoing monitoring and know how to choose an automated solution
[/cs_text][/cs_column][/cs_row][/cs_section][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][x_video_embed no_container=”true” type=”16:9″][/x_video_embed][/cs_column][/cs_row][/cs_section][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][cs_text]
Click here to download the presentation and follow along!
[/cs_text][/cs_column][/cs_row][/cs_section][cs_section parallax=”false” separator_top_type=”none” separator_top_height=”50px” separator_top_angle_point=”50″ separator_bottom_type=”none” separator_bottom_height=”50px” separator_bottom_angle_point=”50″ style=”margin: 0px;padding: 15px 0px;”][cs_row inner_container=”true” marginless_columns=”false” style=”margin: 0px auto;padding: 0px;”][cs_column fade=”false” fade_animation=”in” fade_animation_offset=”45px” fade_duration=”750″ type=”1/1″ style=”padding: 0px;”][x_accordion][x_accordion_item title=”Click Here for the Transcript!” open=”false”]Lucas:
Alright. It is now 11:00 AM Eastern Time. We’ll go ahead and get started.
I just want to thank everyone for joining. I know there’s still a few people joining. I want to thank everyone for joining today. We’ll be going through our Tag Management for eCommerce Enterprises Webinar. Some of the things that we’ll cover here today just in terms of what goes into a solid tag management foundation, going through the process of building out that foundation, building out a solid architecture. Then how to maintain what the things are that you need to keep in mind for maintaining that architecture moving forward, maintaining good and sound tag management. Some of the standards need to have in place and then as well as testing an ongoing monitoring on the back end to make sure everything is still working as expected.
To start just to get through some general housekeeping items.
As always, this webinar is brought to you by Tag Inspector. As many of you are familiar, Tag Inspector is a product of InfoTrust, LLC.
On the InfoTrust side of things, we do web analytics consulting work, tag management consulting work, and then also obviously develop products, one of which is Tag Inspector. About your presenter today, I am Lucas. I’m the product manager for Tag Inspector, as well as I handle a lot of tag management consulting and tag management work for a number of clients.
To get started and why this is important, why we wanted to dedicate a tag management process and guide webinar specifically to ecommerce sites is because they’re different.
What makes different ecommerce sites?
What makes them different? What makes this whole process a little bit more difficult one, but also rewarding and necessary on the back end? The first thing is the different types of page types. When you think about it on ecommerce site, not only do you have general content pages. I mean in many cases, you might have articles or things like that, or a blog, or something like that about your products, or about some topics that are relevant to your customers; but you also have general home pages, landing pages.
There might be pages specific to an individual campaign or a product for a category that you’re running. You have category list pages for different products. You have product pages, in many cases, there might be virtual page views for pop ups for an individual product coming off of a list page. Then most importantly, you have your cart checkout funnel, and then an order confirmation page. There’s a lot of complexity there. A lot of different areas where you might have tags, and it need to be able to conditionally execute and conditionally fire tags in each of those areas, as well as conditionally capture different data points in each place.
In addition to the complexity of the site in general, you’re also typically going to be working with many more tag types. It’s not just analytics. You’re also working with advertising platforms and other advertising tags to one serve dynamic content on your site in order to maybe remind a user of an abandoned item that they had on their cart previously, or make similar recommendations. You might be using a recommendation engine. You’re going to be firing tags for remarketing both display as well as search. You need to be firing tags in order to evaluate the effectiveness of the different advertising campaigns that you’re running.
There’s a lot of different marketing advertising technologies that are going to be used on the site. It’s going to then translate to a lot of different tags that need to be on the site. That leads to additional data requirements. It’s not just specific to Google Analytics or Adobe Analytics. You have to also factor in and layer in the requirements for other platforms, both conditions for where they need to be as well as the conditions for that data that needs to be captured, and events, or interactions that needs to be evaluated on the website.
Outside of just the site complexity, you also have internally different teams, different request, different goals as it relates to the website. You have your performance and development team, that they’re being judged based upon how well is the site performing, uptime, how fast are different pages loading. You also have marketing folks who are interested in how many people are we attracting to the website? What is the conversion rate for people once they get to the site, going all the way through that funnel? Running different campaigns, trying to leverage different technologies in order to improve those; and a lot of times those teams, the KPIs, or their goals are going to clash.
Marketing would love to throw every single different platform under the sun that might be able to increase conversions, or increase visitors to the website. Whereas performance are saying, “Hey, slow down. Let’s keep this clean, and let’s keep the performance up.” There’s some complexity there, which leads to that last point, security and performance on an ecommerce site, not only just in your check out process, or you kept collecting payment information for users, but also because you’re doing behavioral types of advertising. In many cases, there’s additional restrictions and security that needs to be accounted for, and then also performance of the website. One second slowing down of an individual page load can affect your conversions by more than 10%. That has to be at the forefront, and that has to be a consideration as you’re building out your architecture and managing tags.
What do we do about it?
That’s what I really want to get into here, going through the agenda of what we’ll cover.
Number one is the process. How do we need to think about one, implementation of tags, and the overall architecture and how we’re building out our tag management process; but also that process and how it plays in, what we need to be doing for new tag requests? What we need to be doing for monitoring and how that works? Some of you might be familiar with our tag management process or methodology. We’ll quickly go through that.
Then I want to go through with the foundation. What a solid tag management architecture looks like? What are the considerations that go into architecting that and building that? A couple touch points for implementation and how we can ease that process, and then getting into ongoing maintenance, ongoing addition, and ongoing monitoring. As always, if there’s any questions at all as I’m going through here, please don’t hesitate to drop those questions in. Happy to answer them as we go through. We’ll use it as an hour of free consulting here. Happy to help out, and please, please let me know any questions that come up.
To get started, and some of you might be familiar if you’ve been watching a lot of our webinars of what this tag management process is or tag management methodology.
There’s different steps in, a different mental framework for how you can think about progressing through the process. Step one, just defining the goals, understanding what it is. What’s the end goal of the project? Is it implementing a new analytics platform? Is it implementing a new tag management system and really getting everything into that tag management system and building this foundation for future growth? Is it just the implementation of a new advertising tool, or maybe an audit? Know what the goal is going in. That’s going to dictate some of the information and the things that we really want to spend more time on as we go through the audit and the policy process.
Step two is that audit, you have to understand what the current architecture. What’s currently on the website? What is the current tag behavior? What data points are available? How are we capturing those data points and how are we pulling them into the technologies? For that, we need an audit. We need to understand where we are now so that we can put together that plan to get to where we want to be.
Step three is a policy. This is key for ecommerce sites going back to what I’ve mentioned for the complexities of security and performance. We need to have a solid, solid policy in place that defines what tags, what technology should be on the website. How should they be being loaded? How are they allowed to be loaded, and then also what data points are necessary and required for each?
Without this, that’s when your website becomes the Wild West; where anyone and on any team is able to just add in new technologies. The websites get bloated. They get way too many tags, way too many requests trying to be sent, slows the website down. It’s going to make it difficult even to do basic things like basic analytics tracking because of a lot of that different activity that’s going to be going on there.
Step four is the actual architecture. Taking what we’ve learned in the policy, factoring in what the goal is, and then building out that architecture and really mapping everything. What does the data layer look like? What does the actual setup of the tags look like? How are we managing each of these tags? Where are they? Are you managing them through essential tag management system? Or they may be being loaded through another container like your DMP or data management platform, or floodlights, things like that for different purposes.
Steps five, six, and seven here are the adjust, the validate, and alert. This is the ongoing monitoring, ongoing testing process that we should always be doing just to make sure that everything is working as expected. We don’t want yourself or your analytics team running into a situation where they’re pulling reports for the executive team to show effectiveness, and they just don’t have data for an entire week; or situations where you have unauthorized, unknown tags loading and affecting other security, and violating your privacy policy, or to affecting the performance of the website. This is how we need to think about in the prism through which we need to really look at the process that we’re going to be moving through.
Now, the first step here is really building the foundation. Again for an ecommerce site, because everything is so dynamic, you’re going to be working with new technologies. You’re going to need to be removing old technologies. We have to have a sustainable architecture, a sustainable foundation from which we can build everything else upon. Thinking about this through the prism of our tag management process to that methodology, we’re going to start out … and our goal here just so you know, not neglect step one. Our goal here is going to be building out this entire architecture and this entire foundation.
Imagine that either it’s A: Your sites a mess and we need to really clean everything up and get it into a sustainable format, or B: Starting from nothing. I need to implement a tag management system, migrate my tags to it, and how the heck am I going to go about this on maybe a new site. Number one is an audit. The audit here as mentions here, assessing the current landscape. The things you need to know coming out of an audit. What tags are present on the website? Where are those tags? How is each one loading? Is it loading from the source? Is it loading through a tag management system? Is it piggybacking off of some other third party tag? That’s going to be our overall behavior. What’s on the site? How is it getting there? Where are they?
The next thing is more granular context for each tag. I need to know how is each one performing. Do I have a standard latency figure? On average, this tag its requests are going to take 200 milliseconds to fully execute. How much resources are being taken by each of the different tags? It’s going to be important as we move through and really architect what tags are allowed in our policy, because if we have something that’s not delivering a whole lot of business value, but yet it’s taking a lot of our different browser resources, CPU resources, potentially affecting the performance of the website; we need to start looking for a different platform in order to accomplish that same goal.
The next thing is what data is being collected both from a requirement’s standpoint, which you’re going to get like your devguide or implementation guide for the tag; as well as what’s being collected now. It’s not just about what’s possible, but what in practice is being collected? Do I have all these different events set up for Facebook, or is just the standard pics on all pages in order to be able to build retargeting audiences? Understanding in this audit what data is actually being collected, what function these tags are actually doing on the website, it’s going to help inform how are we going to treat each platform moving forward. The final thing here is the deployment method for each specific tag, that goes back to how it’s being loaded.
One thing I always encourage with the tag audit. Go to multiphase approach, high to low level. By high level, that’s identifying it first. Just overall, what tags are there? Get an inventory of the tags, understand everything that’s loading for each of those, then understand where they are. Is it something that’s only on a couple of my landing pages, or is it something that’s across the entire site? Then, how is it getting here? Is it loading through the source, through my tag management system, or piggybacking off of another tag? From there, from that high level look, that inventory look, that’s when you get more granular into each individual tag. I always encourage people, start with the things that are most important. Your analytics platform, any advertising tags or campaign conversion types of tags that you’re really leading on, and really investing a lot within those platforms.
Here’s an example. When I mention that really high level, so what’s that inventory looks like? As mentioned, identifying what tags are on the site, the behavior of each, and then the business requirements and means. Why is this platform on the website? This is crucial because it really feeds into the next stage, which is our policy. Identifying what needs to stay there, what needs to be removed, and then what maybe needs to be adjusted in some way. In this inventory, again high level information. What is the tag name? What is the platform? What is the category? What is a subcategory in case you need to … You don’t know what it is, which I would say about 80% of the time we go through this exercise with clients. There’s going to be at least two to three, sometimes even more things that you’ve never even heard of that are going to show up loading on your website.
Category, subcategory, important there. Initiating tag or locations, that’s what it’s loading in that tag. That’s that how is this tag loading, and then again where it is. These two blank columns at the end here, Business Owner and Agency Partner, that’s really an internal sort of thing. There’s nothing that we can pull out via Tag Inspector or a scan from the technical standpoint; but that helps in understanding who is responsible for each of these platforms. Who do I need to contact to see, is it actually necessary, and who do I need to contact in case anything is breaking due to this tag? Or if the tag breaks for whatever reason, who’s going to be able to put me in contact with that particular vendor, or that platform, to get the implementation documentation that I’m going to need.
Here’s just a quick look at what this looks like when you’re pulling out of a Tag Inspector report.
Obviously, I mention that can feed everything there for that tag inventory. You can see that hierarchy there on the left, which is going to show you all the tags that are there. How each is being loaded in? Then on the right, they’re just a list of tags; how many pages there on, how many pages were scanned. That’s that high level. Inventories of that high level, now we’re wanting to get into for each individual tag, the tag data. These are additional contextual information that I need to understand and I need to know as a part of this audit for each platform. Again, this is going to inform both my tag policy and then down the road, my actually architecture for the data layer, for the tag management system the whole nine. Critical right here to collect this information for each tag.
Number one, business context for each platform. How is the platform used? Why is it on site? Who owns it? Who uses it? How much is it being leveraged? The goal as we’re working through this audience, we want to identify things that we can remove. If there’s an old legacy platform or something that we’re really not investing. We’re not really not running campaigns through this particular platform anymore, there’s no reason for that tag to be on there. It needs to come off the site.
One, it’s going to have potentially a performance improvement impact; but two, from a security standpoint, it’s one less piece of JavaScript on the website that could potentially open up a window for other things to be loaded in on the site. Business context, who owns it? Why is it there? Then getting into the technical tag data in order to … Once push comes to shove, there’s going to be a number of handful platform that you’re able to just remove. “Hey, this isn’t used anymore,” but the next step is really pitting one against each other. We’ll be … sometimes call it like the tag Thunderdome.
Identifying, okay we’re using two different remarketing platforms, getting about the same utility from each, from the business perspective. Which one has less of an impact from the performance standpoint? Which one do we not have to worry about as much for data being collected? What data is being collected? Because again, that’s going to inform how we’re architecting it and building out that data layer. We need to understand technical performance. Information, how is it actually performing on the website? What data is being collected ideally against the standard? You can just in one fell swoop see if something is broken or needs to be optimized.
What is the loading behavior of each tag? How is that specific tag loading? Then if you have those requirements at this stage, it’s helpful to do just that gap analysis to understand. Okay, this is what should be happening for this particular tag. This is what actually is as we are building out our data layer. Maybe we need to add additional data points, or just from a configuration standpoint. Something that’s broken within the script, it needs to be fixed. It needs to be optimized.
Here’s a look when I’m talking about the technical requirements in mapping that out.
This is actually for Google Analytics here. Here on the right side, so purchase confirmation page. This is just an example of what it could look like. Here we have the different variables. These are the things that would be being collected by Google Universal Analytics. On the right, here is the value. What’s actually being sent up in that request by that tag? Then here, I’m able to see when I’m talking about like the gap analysis. What’s not being collected? In this case, a couple of critical items around transaction ID, transaction revenue, tax, shipping. Either one, the things aren’t available on my page, which I would hope that my transaction ID, my transaction revenue on a confirmation would be either in a data layer. If I don’t have a data layer yet, it will be scraped from there. Right now in this particular instance, Google Analytics, it looks like is not collecting those different values.
On the left here, I hope we’ll do understand, what needs to be, what should be being collected? One, to understand what’s not as we are in this case; but also to understand how can we better architect this. These values are easily accessible by this particular tag or by all tags. We’ll get to that here in a minute, that is the data there. Technical requirements for each tag, granular what’s necessary. Going through that audit process, and now that we … In our methodology and in that process we have theoretically at this point. We’ve gone through the audit. We understand what’s there. How it’s getting there? Where it is, what’s necessary, and required for each?
Not we get into the tag policy. Now we need to formalize and really understand, “Okay, what is allowed? What’s not allowed? What’s required?” First thing to think about here is from that inventory of tags. What tags should be here? What tags need to be removed? What tags need to be … The loading behavior need to be migrated or moved to be loading in a different manner. In many cases, this might be tags that are loading directly from the source of your page, being migrated into a tag management system.
Now I know in a lot of ecommerce sites, you might be using a back ends, ecommerce platform such as like a Demandware or a Magento. It’s fairly easy. In a lot of cases, to be able to deploy tags via that configuration, I still always recommend deploying them instead if it’s possible, as long as it’s loading asynchronously, not messing or adjusting anything with on page content. If it’s just a tracking tag analytics, Facebook things like that, still load it and manage it through your tag management system makes it so much easier. One, you’re able to leverage via that your central data layer, which you can and we’ll get to. Two, you’re able to manage everything in one place. Permissions become a lot easier, ongoing maintenance becomes easier, and just over our cleanliness becomes easier. Identify what those tags are. What’s allowed, not allowed? How it should be loading and then where it should be?
Another really important piece here that you need to consider as an ecommerce site is put standards around tags, just in general. It doesn’t have to be for each individual tag but for performance. The latency of an individual platform shouldn’t be over, you name it, 400 milliseconds, 500 milliseconds. Have a standard. When new platforms, new tags are being requested to be added to the website, you have something to really compare it against. Does this meet our standard for our website? Is it potentially going to affect or act detrimentally to one user experience, and also the functionality of any other tags or platforms that I’m running?
Next thing, privacy and compliance, really important around what is the privacy policy say on your website
.
What data points are allowed to be captured both for many regulations in the industry you might be in, as well as this is from your own personal site standards? Make sure that all those things are documented and in place so that you have again, something to compare against; and you have a standard moving forward. Also, having standards for the implementation process, which we’ll get to, and then ownership.
Ownership is key for the tags. Who owns implementation? Who owns ongoing management? Who owns this platform? If there is ever any type of an issue who can I go to, as the manager of the tag in order to be able to get updated one implementation steps, or two, approach with any issues that might be being caused by this tag. “Hey, is it still needed? Hey, we need to adjust X, Y, Z. You can expect A, B, C to happen.” We need to know who exactly it is that we need to be able to approach with those different items. That’s the tag policy.
The next step after that high level tag policy, what’s allowed, what’s not allowed? What are our standards? Is it getting into the architecture? When I talk about architecture, I talk about that foundation. It’s the technical setup of the site in the tags. This includes the configuration and management of tags within your tag management system to have some examples for data layer implementation. What goes into What’s necessary to include? What that looks like? Then some important considerations for really building that out, as well any events in data requirements breach. Events, those would be user interactions on the website when they click on a particular product, when they view a particular product, or when they view an advertisement or recommendation on the website. Those would be your events or interactions. Then what’s necessary to be collected by each tag. What’s necessary for Facebook? What’s necessary for Analytics? What’s necessary for Criteo or other marketing platform. We need to really understand that, or walk through the process for how to make sure that everything’s covered.
Number one, critical data points. Things that need to be within your data layer. For those of you … I feel like everyone should be pretty familiar with the data layer. I know we had a webinar with the DeepDive just a couple of weeks ago. To take a quick step back, the data layer is going to be that central object that you’re pulling information from your back end systems and then pushing it to on the website. It’s not viewable by the users on your website. It’s something that’s sitting just under the surface that you need to organize all the different data points potentially necessary to be collected by each tag that you have on the website. It all needs to be in one place. It all needs to be in the standard structure.
As I go through these critical data points, these are the things that by and large for an ecommerce site, you need to have in there. Number one, page information. Why do you need page information if it’s not content? Primarily, for the ability to conditionally load tags. Oftentimes especially with media tags, you double click floodlights. You might have like … Any other of those different types of platforms, you’re running a campaign for a specific product. You’re going to be pointing that traffic from your display ads, or from your search ads to an individual landing page, or individual product page.
Having the page information allows you to use those data points as conditional firing rules, or conditional triggers for when to execute those tags. Now, why is that important? It allows you to only fire tags and only execute tags when they’re necessary. On pages where page traffic is not going to, you don’t need to execute that tag and take a browser resources, a CPU resources, network resources and potentially affect performance. This allows you to really optimize where tags are by including this page information; so page type, page name, user type, user status. Then optional in many cases, you probably will need these things for different platforms. Things like a hashed email, or just user email, the user ID, and then geolocation of different users on the website. These things are going to get you that page information again. It’s going to make firing tags conditionally a lot easier.
In addition to the page information, obviously on the ecommerce site, you need the product information. This is going to be some standard critical product data points that needs to be adjusted by different tags. One, analytics; and then two, any media or advertising tags from the website. Things like your product name, product category and subcategory if you have it, a unique product skew, product price, brand. Any additional product information that you might have available is also helpful to put in here. The more product information you have here, the more you can ingest and to namely your analytics platform; so the more granular and more segmentation you can do.
In addition, this product information is helpful for your advertising platforms. Just use say Facebook is a pretty pervasive as an example. By collecting product information on product pages, or you would do a viewed content event for the product page, it should be like a product view like collecting things like the skew, the name, you can then set up an outside product catalog feed. Now, you can dynamically remarket and dynamically target users on Facebook with the products that they viewed. Same can be said for many other media or advertising platforms. That’s why this information is so critical outside of just analytics.
Finally here, when we talk about critical data points events. Again, events are what is the user doing? What are those interactions? Automatic timing events potentially for the video view or a scroll type view on the website as you can get impression information. What products were actually viewed on our listing page? Obviously product view events, we need to know when someone is looking at or is viewing a particular product impressions. Then purchase events critical; being able to identify and measure when conversions take place.
We’ll walk through here, what does looks like as you’re building it out, as you’re trying to document this architecture. It’s going to start here with your tag requirements, and that goes back to the audit. We know four … This list of five tags say, just to keep it simple. These are all the data points that are needed. These would be the unique data points that are needed and we can then list that out here. On the purchase confirmation page, I need all of these different types of data points. They’re going to be adjusted by the different tags, the different platforms around my website. These here on the right hand side are just example values.
I then translate those tag requirements that again I’ve gotten from my audit standpoint. I translate that to what would this look like in the data there? Now, the structure here and it’s not just the straight list in column A, because the structure’s going to be dictated based upon some of the tags that you’re using. For example if you’re using say Google Analytics, and you’re using there, enhanced ecommerce functionality. If you put the different data points in the specific defined structure configuration of the tag, all you need to do is enable that functionality within either your script or within the template tag depending upon the tag management system that you’re using; and it’s going to automatically grab those data points.
If you’re using GA as your web analytics platform, it just makes sense both from an ease of implementation, as well as the troubleshooting and monitoring standpoint to just set it up in that particular structure in order to be able to save you a lot of time in that implementation. The requirements of those different tags, which again you’re going to be able to find within your implementation, documentation, that you would have gathered during that audit phase. It’s going to dictate if there is a particular structure that you need to use for the data layer.
We translate those tag requirements that we have listed out into … This is what’s going to go into the data layer. This is the structure that it needs to be. Once we have them, we can then cross reference with our requirements. We can then put it into what does this need to look like from an implementation standpoint? This would be like a development guide. You could put this together and this is just example script, but you could give this to your development agency, or your internal development team.
It’s going to lay out, “Okay, this is exactly what the different variables of the data points that I need. These are what the values are.” You can even define on a more granular level where they would get that from. It’s always going to be an end point in back end system, be at the content management system. Be at the back end ecommerce system whatever it is, but this outlines what are those key value pairs. What is the structure that it exactly needs to be in? Then they can translate that into actual code on the website with the result being a nice, clean, well-structured data layer on the website.
I cannot stress enough how important this is for the overall tag management process to have a full, robust, clean, data layer in order to be able to manage all the different tags off of. The data layer is what’s going to make ongoing and sustainable tag management possible. Again, it houses all the different data points that are necessary and required to be consumed by each platform; as well as makes things like conditional firing, timing all possible.
We have the data layer architected.
That’s up there. It’s running on the website. We have everything we need being surfaced. Now, comes actual configuration of tags and ideally your tag management system. The examples that I’m going to give here is high level and they’re all coming from Google Tag Manager, from feedback from some of our prior webinars. It seems as though that is what is most commonly used by a lot of clients and a lot of people that are joining these. Pull the examples from there, but you can configure. Again, even taking a step back, we’ve already defined what are the tags that should be on the website, which one should be, need to be loaded via our tag management system, as well as the data points that are required.
Now, I need to configure for all those that I’m managing within my tag management system. I need to configure the container and configure the TMS in order to be able to read from the data layer; and then be able to put those variables into my different tag scripts in order to be able to feed those platforms, and those data requirements. Step one is defining all those different variables; so I can create variables, referencing my data layer to be able to pull out the required data points I need, so product name. You’re going to reference the data layer within that ecommerce object that we’ve already defined and already has been in that devguide, in order to be able to pull out product name on any product page.
From there, if you can figure what my triggers or my firing rules are going to be for these different tags. Some common ones is going to be obviously set up for any events that you have configured, as well as different page categories or page types. Configuring triggers in order to be able to fire tags conditionally in each of these different cases, you can go through and do that. Then finally actually configuring the tags. Now this example here, just the custom HTML script for a new product event within Facebook. As you can see here, it’s configured simple, clean, fire that event whenever a user views a product page within Facebook, and send up my different variables or my different values for my product ID, product name, product category, and value. Something as simple as this, is going to allow you to then dynamically remarket advertisements for specific products on Facebook.
This is just a quick screenshot of what TMS or a GTM container can look like. These are all the different tags that are listed here. Then there are different firing rules or their triggers, so what they’re actually going to be executing on. Now, I included this just to be able to really double down on the point that I made earlier. This is why you want to manage your tags within a tag management system. You can manage everything from one interphase, one simple place. You have all the different platforms. You have all your different events. All in one area, so they can share and they can leverage the same variables and the same macros that you have set up. Again, pulling directly from the data layer that can share different firing rules that you have set up or different triggers that you have set up. Then you’re able to make any adjustments in one place. It’s simple. You only need to manage one snippet of code on the website, and then manage that data layer. You can manage everything else in a separate interphase in one place.
Now, we’ve gone through what that foundation looks like, what that architecture looks like in the process for setting that up, as well as implementation.
It’s now extremely important to quickly cover just what is new tag addition and what does maintenance look like.
All too often, we fall into the trap. We go through in the audit. We get everything cleaned up. Everything looks great, awesome, but then we fall back into the bad habits. We have different teams requesting all kinds of different tags. We just willy-nilly, add them to the website. Things get dirty. Things get bogged down. We start scraping pages. It’s just going to slow down everything. It’s just not sustainable and it gets out of control.
A new addition, an implementation process is critical here. This is an example I use, just a pretty basic implementation request document that I’ve shared with a lot of our clients. This first page here is just defining what exactly is being requested and what is the business need? What is the business case? Why are we putting this tag on the website? Then also, some check boxes to make sure that it has been approved and has been vetted, both by a development team for a performance, as well as by our security and legal team for and make sure it follows a privacy policy in any standards that are in place.
Critical information here, just what is the name of this platform? Who owns it? If we are working with an agency, who is the agency partner? They would be working within this platform, business description for why it should be on here. Then, a tag life cycle. It’s always important to put an end date on this. We need to be reviewing the tags that we have on the website. I typically recommend between 12 and 18 months for a couple of different reasons. One, if something is no longer new, it needs to be removed. The only way that we’re going to know in a proactive fashion if something is no longer new is if we’re checking. Every 12 months, 18 months, we need to check if it’s still in use. If it is, great. We can then extend this period for another 12 months.
Number two, a lot of these different platforms and different technologies, they’re always improving; and a part of that is they’re also changing their tag script in order to enable and allow for additional new functionality within the platform. It’s always great to go back, double check, be proactive. “Hey, is this still, the script is still up to date? Do I need to migrate to a new version of a code, or change what the script looks like in order to make my marketers, my media teams more capable, and more able to do and accomplish their goals?”
The second piece here is the technical requirements. Your tag name, what pages, what sections of the site is this particular tag or this platform required to be on? What are those firing conditions, those firing triggers that need to be applied to that tag? Where does it need to fire? On what event does it need to fire? That sort of information, which is going to help really ease the implementation process as well as what is the actual script look like. Again, eases the implementation process, gives you one central repository where you can find all the different tags and platforms on your website.
What are the data attributes that are required, so I can cross reference and make sure that, yes, they are already available within my data layer. They’re already configured as variables within the tag management system, or if it’s something that you need to add in. Then any instructions for implementing the tag or the pixel that it’s just going to ease development effort and implementation effort. Also, important is just to attach or include with a request document like this, the actual implementation guide that most platforms are able to provide. That way, you have that always on record in case anything ever breaks with that tag; and anything’s ever flagged and or monitored in process, which I’ll show you here in a minute. You know exactly what everything should look like so you can go back and fix those different items.
Also, important in ongoing management is our tag policy maintenance. Having that tag policy document that we put together already in that second step, but monitoring against that. Making sure no new unauthorized tags or unauthorized platforms have shown up on the website. Make sure that everything that is on the website is still approved, is still required, is still allowed. Make sure everything is still loading in a manner in which it should be.
Just because DoubleClick floodlight is approved or allowed on the website, if it is allowed on the websites and we’re managing it via GTM. All of a sudden, we see it piggybacking off of some other tag, that’s not an instance that would be allowed. We need to have visibility into that. We need to be able to fly any of those instances. The only way to identify some unauthorized activity is if we know what the authorized and allowed activity is. That’s what this tag policy maintenance comes in.
The final thing I want to cover here is just with the testing and then ongoing monitoring.
It’s great to have the standards. It’s great to have everything in place, but if it’s way too much effort to actually monitor and make sure that everything is happening as expected, never going to, never going to happen. What’s really critical here, and I’m just using Tag Inspector for these examples; but to be able to put an ongoing monitoring process and an automated process in place. Number one, tag policy. How can we in an automated fashion make sure that our tag policy is being followed? Well, we can do so within a tool. An automated scanning tool such as Tag Inspector.
Translating what that policy is into its rule, these are the things that are allowed. These are the things that are required. This is how each of these things should be loading. Letting a tool like Tag Inspector go through just scan the website, identifying instances of that allowed or required activity not happening, and then being alerted to it. We need to constantly be monitoring in order to be able to ward against any unauthorized tags that are showing up, or anything that’s critical on the website no longer functioning as expected.
That leads us into the next piece, which is going to be monitoring and validating for the different data requirements.
It’s not enough just that a tag is executing. A great Adobe Analytics is firing on mine confirmation page, recording a page view for that; but if it’s not collecting transaction information, I don’t have the ecommerce reports that I need for reporting for optimization. Making sure that granular data points are always being collected for really high leverage, really important interactions on the website is critical.
Now, you can do this in a couple ways. You can put in place a manual monitoring or manual testing process where you have someone walk through all the different interactions, and different pages on new releases and things of that nature; or again, you can use an automated tool just to find what data points are necessary on what interaction, and make sure that that’s happening. It’s just always on, always monitoring. Again, I have an example here from Tag Inspector looking for individual parameters on a confirmation page being sent by Google Analytics tag.
The final piece here just that proactive monitoring. Again, the point is to always be on top of and always be proactive, so that when issues arise, we know we can go in. We can fix them before there is an outage of data or reports don’t have the information that our marketing team needs, or before a major performance impact has had on a website and our conversions drop; just because user experience is really suffering because of an unauthorized tag that’s been introduced. We need to always be proactive. We need to always have visibility into this process, so that we can take the steps necessary to remediate any issues as soon as they arise.
Again, this goes back to and just a quick review as we’re looking at the journey and looking at it through that prism of our tag management process and methodology. One really important thing to note here is that the process is ongoing. Any large initiative that’s related to tag, it should follow the same path. If it’s a new tag that’s being implemented, we’re going to go through step one, defining the goals. Let’s get this thing up and running. Step two, audit. Is everything there in our data layer? Is everything there within our tag management system that’s necessary for this tag?
Policy, we need to get this particular platform approved. If it’s not, we need to vet and evaluate the potential effects of this platform, adding data requirements to that tag policy. Add that into the architecture. How does it factor in? Where is it being loaded? How is it being loaded? What’s being referenced? Then actually implementing, adjusting, testing, validating, and getting that new tag or that new platform into our ongoing monitoring process. That’s one example. Anything again, is going to follow through the same process, the same methodology.
With that, that’s all we have here for today.
Any questions at all? We have about 10 minutes, so happy to answer anything that might have come up.
It doesn’t look like anything is… Oh [nevermind] We do have a question here.
Question, just if we will share the slides afterwards? Yup, absolutely. All of our webinars are recorded. The slides as well as the recording will go up on the website. All that will be sent out as well. You’ll have access to slides, as well as the recording. Yeah, shortly.
There’s no other questions. I’ll go ahead and wrap it up. Again as always, let me know if anything does come up, if we can help out in any way, any projects you’re working on. Also, a quick call out, we’ll be having another webinar next week. That will actually be myself, one of the owners of InfoTrust, as well as a senior analyst from Forrester. We’ll be discussing the ROI of good tag management, and good sound analytics and data collection. What is the business impact? Why should we be focused on some of these different items? That will be really interesting. Please be sure to join us for that. Thank you all. Have a great rest of the day. Again, let me know if I can help out in any way; and we’ll hope to see you on a webinar again next week. Thanks.
[/x_accordion_item][/x_accordion][/cs_column][/cs_row][/cs_section][/cs_content]
