I’m speaking at the Marketing Analytics Summit about marTech tracking and how to keep tags from causing problems on your site. In true Jenn fashion, I have way more that I want to convey than I can possibly cram into my 30-minute presentation, so I have a series of blog posts to store all the practical takeaways:
If there is one thing I hope folks take from my presentation, it’s to do something now. You don’t have to wait until you have a ton of resources to do a full audit and clean up. Do what you can, when you can. Implement standards for tagging going forward. Even if it only helps a few tags, your future self will thank you.
If you’re here in Vegas for the Marketing Analytics Summit this week, let me know, I’d love to meet up!
How you name your rules, events/triggers, tags and actions can have a big impact on the health of your TMS. You want to prevent duplicated conditions and logic as much as possible, to keep things simple, lighter, and less error-prone. You want to make things easier to find and easier to put into context.
Launch Rules, Events, Conditions, Data Elements, and ACTIONS
Let’s face it, the internal search functionality in Launch isn’t great. But there is much you can do to make navigation within Launch easier and cut down on duplicated logic.
For rule names, I often follow a format with some combination of the following:
category[: sub category] | trigger | [type (analytics or marketing)] | what the rule does/marketing vendor | load order | consent management category
add to basket | “add to basket” event | analytics | s.tl | #50 | C0008
search: search results | “page view” event | analytics | set vars | #50 | C0008
Of course, it usually differs for every client depending on their needs. For me, the important thing is for rules with similar events/conditions to be together (all my search rules start with “search:”), to know what triggers it (page bottom? direct call rule?), and to have an idea of what’s inside. Here’s a simpler version:
Having it arranged this way already shows me for this property…. I have a lot of rules firing on that page view event. I could probably consolidate some of those into a single rule. I also see some inconsistency… one “page view” is lacking quotes, which makes the editor in me twitch a bit, and in that top one I didn’t specify s.t or s.tl beacon. But you know what? I can navigate this property pretty easily. And if I see an inconsistency, I can fix it as I go along. Some order is better than none.
Sometimes I only include the event order (eg, #50) if it’s something other than the default of 50. Sometimes we have analytics and marketing in the same rules so the standard has to adapt.
For events, I only change the name from the default if I had to customize it- page bottom is always just “Core – Page Bottom” (unless I changed the order, in which case I’d probably name it “Core – Page Bottom #1” or somesuch), but a direct call rule or something based on a CSS selector should always include that info in the name. For instance “click on .pdf links”, “DCR page view #25” or “payment modal enters viewport”. I won’t even be picky about following a standard… just keep it informative. If you changed the order (from #50 to, say, #1), then do note that. It makes troubleshooting so much easier.
Conditions should always have custom names. “Core – Value Comparison” is just not helpful… but “pageType of ‘search results'” is. Again, I’m not picky about following a standard… just make it so I don’t have to click into the condition to have an idea of what it is.
Action naming… this is where I get excited. Folks don’t take advantage of Action names nearly enough. Action names should include the marketing tag name and the scope. Within a rule, it might look redundant with the rule name (how many times do you see “All pages/Page Top” here) :
But if you search for a tag in the Launch’s search tool, those action names make a world of difference. Let’s say I’m searching for eVar63… this:
…is not helpful (by the way, please go upvote this feature request for better search functionality). I’d have to click in to each of those to find out what the context is to know which one I want to make my change to. But if I’ve added a bit of information to the action name, I can know exactly where it is taking me:
It’s a minor inconvenience when setting rules up, but if you have a complex implementation, it can make life so much easier.
For data elements, I tend to go much simpler. Some sort of categorization, then some sort of detail. If it suits the implementation, I might add more information about the source of the data. For example:
search: term | QP
search: number of results | DL
content id: page name
I tend to always keep it lower case, since you have to have to right case when referencing a data element.
Don’t stop with good names, add even more info!
As I mentioned in my post on governance, it can be extremely helpful to include information about the tag within the tag itself, along these lines:
This means that “https://www.googletagmanager.com/gtag/js” file loads twice. It’s a 40 KB file, with no benefit for loading multiple times.
This code accomplishes the same thing, minus 40 KB of dead weight:
I’ve seen folks shave 200KB off their site by merely getting rid of extra gtag/js files. You can take it a step further and consolidate events, too- I don’t need to fire a conversion event twice, I can just add multiple destinations to my send_to variable:
This tip isn’t specific to gtag, though that is one of the tags that I see duplicated the most. Anytime you are deploying two tags from the same vendor on a page, odds are there is some part of that code that doesn’t need to be repeated.
Many tag vendors will tell you in their documentation that a tag must be placed as high as possible. This ensures that that vendor gets credit for every possible conversion, gets every possible data point.
It’s great for their data accuracy, and they may not really care if it has an impact on your page speed. But we do.
You have to find your balance:
Do you put the tag as high as possible, knowing it may negatively affect user experience by slowing down the page load?
Do you put the tag as low as possible, knowing that if users leave the page quickly, you may never get data about their experience?
Some tags actually DO need to be placed higher. Things that alter the user experience, like Optimization tools, need to have access to the HTML as it is loading. But conversion tags? Are they really worth a potentially slower user experience? It may not matter for one tag here or there, but it adds up!
I don’t think I’ve ever had someone ask me to move the tag up, no matter what the documentation always says. You are the ultimate decision-maker about what tags get deployed, where.
This is a question I get asked a lot: should I use my Tag Management System’s Extensions (or Plugins, or Tag Templates, depending on which TMS), or should I just copy-and-paste tags as custom code? The true consultant answer is: it depends.
Extensions do have some inherent weight. In GTM, adding a single AdWords conversion event using the Tag Template can add 10-20KB to the weight of my container. Extensions can be heavier than a simple code deployment, but lighter than a messy code deployment.
Extensions are less flexible. If you have conditions around your tags, such as “in the US, add these variables to our Doubleclick conversion event, but in the UK, leave those out”, that can be really hard to implement using an extension, but fairly simple in code.
Extensions are less likely to cause JS errors. They get load order correct (eg, Launch’s Target extension ensures the Target script has loaded before it add params, which it does before it fires an mbox). They’re more likely to stay updated, which means they’ll work best in current browsers and be more compliant with regulations.
The main thing I want folks to think about is what they’d be willing to give up in order to avoid code. A lot of companies set forth with the goal of having a code-free implementation, thinking that that is the best practice worth achieving. But in many cases, that goal isn’t worth the cost. Vendors/agencies often send their tag requests AS CODE, intended to be copied-and-pasted:
So someone is going to have to interpret that code into the friendly UI of the extension, which does introduce room for error… perhaps more error than merely copying-and-pasting.
I know code can be scary if you don’t have a lot of technical resources working on your implementation. Do what you think you can sustain. But don’t assume that code-free is the ideal you must fight to achieve.
A server-side TMS still has that client-side component- it still needs to gather information in the user’s browser. But instead of sending that information to third parties using scripts, pixels and iframes, it sends all the info in one big batch to a server, where you can then divvy it up and send to third parties using APIs.
This is a wonderful technology that will be used more and more in the future. Tealium has long had a server-side option, and now Google has GTM Server-Side and Adobe has Event Forwarding. But server-side tag management does have some limitations:
This technology is fairly new. It can be hard to find documentation and expertise. And frankly, some of the tools still feel a little “beta”.
Not all tags have a server-side option. Facebook is pushing it really hard with their Conversions API, but Bing doesn’t even have a way to send data through APIs yet. In my example image above, you can see that Bing has had to stay client-side while other tags moved out. Some tags will always need a client-side component: anything that changes the user experience needs access TO that experience as it loads. So scripts for optimization, personalization, recommendations, voice of customer… they may always need to have some part of it maintained on the client-side. Maintaining a server-side container and a client-side container does complicate things, but for now it’s the only way forward for most folks.
The client-side component of server-side tracking still needs a way to identify the user as they move from page to page, and for the foreseeable future this will be done using cookies. GTM Server-Side can actually help a little with this, as you can use it to deploy HTTPS cookies that will make browsers like Safari happier. It can do this because you run the container on your own server, which does have a cost, but it also allows you to do first-party things. Adobe (and Tealium, as far as I can gather) host the server-side container themselves, which is less complicated for you to set up, but makes it so they can’t really help with the whole make-happier-cookies thing (though they certainly don’t hurt either).
I’m not saying folks shouldn’t move part of their implementation server-side- I’m actually very excited to see this technology roll out more. We just need to approach it realistically and be as well-informed as possible before making decisions about it.
Regardless of how much effort you can put into cleaning up current tags on your site, there are relatively simple things you can do, starting now, that will improve the future health of your marTech implementation.
Keep information ABOUT the tag WITHIN the tag
Within each tag, include info about the tag:
Who requested the tag (include any contact info for the agency, vendor support, internal sponsor)
The date the tag was deployed or updated or confirmed to be in use (and if known, date to remove)
Who deployed the tag
However you do it, keeping this information directly with the tag makes it so easy for everyone to have context around the tag and makes it easy to keep your TMS set up healthy and current.
Use a Tag Request Intake Process
We’ve helped a lot of our clients implement a formal MarTech Tracking Request Intake process. When someone comes to you asking for a new tag to be deployed, you can have them fill out key information such as contact info, go-live date, tag vendor/account ID… This information can help in a few ways:
It cuts down on the back-and-forth between the implementor and the tag requester (I’ve had some email threads go 20 replies deep, trying to make sure we were all on the same page about the tag. You’d be amazed how often I get Facebook tags without an account ID, for example.)
It gives you a chance to set expectations with the tag requester, like the fact you need 2 weeks of turnaround time, or that you’ll follow up with them on a certain date to see if the tag is still in use or needs updates.
It builds an audit trail and can feed directly into documentation, like for the Tag Inventory you should be keeping.
I have an example in my my governance workbook download, but it doesn’t have to be a spreadsheet. It can be a google form, a JIRA template, or just a something you paste into an email.
Keep a “pixel menu”
I’ve found it can be a huge help to have a standard list of what user actions you usually have tags on, and what dimensions are available at those times.
At bare minimum, this can be a great internal resource for the implementors and, say, a Center of Excellence. Sometimes it can be helpful to show vendors/agencies to get on the same page about what’s worth tracking…. just be warned, sometimes if an agency sees such a list, they’ll just say they want all of it. Which brings me to my next suggestion:
Consider having some restrictions on what you deploy
It’s ok to push back on Tag Requests. Consider:
Do you only deploy certain types of tags? Maybe things that you already have a set up for, or that have passed a security review.
Do you only deploy on certain user actions (do they have to “stick to your list” in the pixel menu)? If they ask for a tag on both the click of the search button and the load of the search results page, ask them WHY. Sometimes they’ll have a reason, but much of the time they’ll say that the button click was just a nice-to-have, and they’ll tell you what items are actually a priority. Pro tip: mention to them “our turnaround time can be pretty quick if we stick to these particular user actions, but if you need something custom, that might slow things down. Maybe we can move forward with the priority tags for now, and circle back to your more custom requirements later?”
Do you ask them to justify the business value of the added weight and complexity that their tag brings? Some of the most complicated tags I’ve deployed turned out to be for something not providing a lot of value. Much of the time, the data a tag is supposed to be delivering can already be found other ways (like with an analytics tool).
Establish a follow-up cadence
Set up a calendar for your TMS. Each time you publish a tag, add a reminder one year out to followup:
It takes very little effort or commitment in the here-and-now, and makes it easy to followup without it being part of a massive clean up effort.
Just… do something
Don’t wait until you can get it perfect. Do what you can, when you can. Make a commitment for the little things you can do going forward that your future self will thank you for.
I have a template as part of my governance workbook download, but it’s not hard to get started on your own: create a spreadsheet with one row per tag/vendor account, with columns for at least the following:
Vendor (Facebook, Doubleclick, etc)
Account Number- your key to the audit*
Date of last update to tag
Internal Owner/Agency Contact Info
Next Steps (investigate, keep, remove)
*That account number can become a useful tool for finding more information about the tag. If I look in my email box for the word “Adwords”, the results would be hard to wade through. But If I search for my Adwords account number, “AW-123456”, it will take me directly to correspondence about that tag. This also helps when using your TMS’s internal search functionality, or to use as a filter in the network tab:
It’s ok if this sheet is a work in progress- in fact, I guarantee it almost always will be. It’s ok if the sheet only has information in three rows, or just has the first two columns filled out. It is better to have a blank workbook so you can at least have a place to store info as it becomes available, or to add new tags to, than to have nothing at all. Just fill in what you can, when you can.
Use Tools Like Observepoint
Observepoint has a free chrome extension that you can run to see which known marTech tags are on any page you access:
If you want a more comprehensive scan of your site, the paid Observepoint App does just that- it crawls your site and gives you a full report of everything it finds. You may need to teach it how to get to parts of the site that require interactions (like logging in, or entering credit card information) but with Observepoint, the more time you can invest in it up front, the more value you will get out of the tool.
The nice thing about the paid app is it has an under-appreciated “Tag Initiators” tool that shows you which tags are loading other tags, which is invaluable for helping figure out where your less-obvious tags are coming from.
A quick note: Observepoint may not recognize and catch some of the more obscure tags- I did come across a few that the extension didn’t pick up (though I have no doubts they have a drastically more comprehensive list than I do). I don’t think this is a shortcoming of theirs, but just the nature of the beast: there are almost 10,000 marTech vendors now, and many of them use multiple domains for tracking. But just in case, you may still want to run the webpagetest.org domains report and analysis I talked about in my post on marTech impact, and may need to supplement their mapping with information from our vendor/domain mapping database, or you may have to do some research on your own. I’ve found better.fyi to be a great resource for this type of research.
Use TMS Container Export tools
There are free tools for both Adobe Launch and GTM to help you see all your different tags (and help you get a sense of the health of your TMS set up).
For Adobe Launch, Tagtician by Jim Gordon is still one of the handiest things out there. It’s a chrome extension you can use to download an entire Launch library- toggle the library option at the top:
Potential Last Date Updated (or Date Implemented)
I turn it into a table and organize by Extension, add columns for Vendor, Account Id, event (What the tag does), date of last update, notes, etc… and then just start at the top and work my way down:
Sometimes, the tag is directly in the exported file in “action detail”, but much of the time custom code resides in external JS files and frankly, I haven’t found an easier way to get at the code than to just open Launch and go looking for it.
Urs Boller also has a great tool for Launch: the Launch Parser. It makes it easy to see the relationships between the different components (what data element is getting used where, etc) and also helps spot problems and make recommendations.
For GTM, Simo Ahava has a great tool for showing all the different components (tags, triggers, variables, containers) and their relationships to each other. Then if you want to dive deeper, you can export your container directly from the GTM Admin console:
Do what you can
I know an audit sounds like a lot of work. At the bare minimum, set up that Tag Inventory and just start documenting things going forward, then audit past stuff when you can. I recommend just taking on one vendor at a time (eg, all your Facebook tags at once). Apply a new naming convention/meta data standard as you go to keep track of what you’ve updated/inventoried and what you haven’t.
It’s better to have something in place, even if it’s imperfect.
This is part of a series of blog posts on keeping marTech tags from becoming a problem on your site. See the preceding post (which serves as the “table of contents”) or following post on the impact that marTech has on your site.
The health of your website depends on the health of your marTech ecosystem, which is decided by a combination of the following:
The number of tags on your site. I’d say most companies I work with have between a dozen and 150 tags on their site, though I have seen it go as high as 1500. Each additional tag adds a little to the weight and complexity of your marTech implementation.
The age of the tags on your site. This matters both because you want the most updated versions of tags, which play best with modern browsers and current regulations, but also because the older the tag, the less likely there is someone out there still getting value out of it. A few weeks ago I came across an Adwords gtag from 2018. No one had any record of it, or any idea who might be using it. And instead of that meaning they could safely delete it, it meant they didn’t know who to ask permission of to delete it, so they left in place “for now” and just keep piling tags on top. It adds up.
The complexity of your Tag Management System. Duplicate rule triggers/conditions, repeated logic, poor naming, unnecessary complexity… these all can make an ecosystem unmaintainable. We’ve seen good technical employees leave companies because they felt they were spending all their time deploying tags that weren’t providing value, or worse yet, felt they were tasked with keeping a sinking ship afloat. These issues can all make a TMS library unnecessarily heavy (in another post, I show how one site I looked at had 15% of its site weight come just from the TMS library… not the tags, but the library itself… you know, the part that has to load on every page.)
Documentation. Every site has quirks, workarounds, edge cases, and places where the implementation had to do something unanticipated. And every implementor has their own way of doing things. If you don’t have documentation, then every small change to your implementation has the potential to bring the whole thing tumbling down.
Resource Turnover. This goes hand-in-hand with documentation. The more fingers you have in the pie (or cooks in the kitchen… whichever metaphor resonates), the higher the possibility of conflicts. The messiest implementations I see are the ones that have changed hands many times.
And these problems build on themselves: if you don’t have a place to put documentation, no one is going to document things. If someone new goes into your TMS to put a new tag on purchase confirmation, and they see eight rules that look like they could all be for purchase confirmation, they may very well make a ninth rule that they know is what they need. The whole ecosystem can slowly spiral out of control until it’s no longer sustainable.
Why ecosystem health matters: Security
Some tags inherently carry a bit of risk. Anything that allows a third party to change the code on your site has the potential for trouble. For a while a few years back, Doubleclick for Publishers had a known cross-site scripting vulnerability that could allow malicious parties to inject script onto a site. Even now, agencies can (and do) use Google Ad Manager to deploy tracking scripts.
Why ecosystem health matters: Fragility
Why ecosystem health matters: Consumer Trust
An ever-increasing amount of (negative, fear-mongering) attention is being paid to cookies, data sharing, retargeting, and third-party tracking scripts. For instance, if a user is using Safari on their desktop, they’ll see this shield next to the URL bar, which shows them all the “bad, scary” trackers that Safari is “saving” them from:
It doesn’t add any nuance, of “this tag is monetizing you and will follow you around the internet with targeted ads that you’ll think are creepy” vs “that tag is used for first-party analytics, which improves your user experience without any harm to you at all”. Users ARE paying attention to who you are sharing their data with (even if they don’t really know what they’re afraid of.)
Why ecosystem health matters: Privacy Regulation Compliance
Privacy regulations such as the CCPA (California Consumer Privacy Act), which is a pretty good representative of various laws in the US, and the General Data Protection Regulation (GDPR) in the EU, are constantly changing (or at least, they way they are interpreted and enforced is constantly changing). For instance, if you’re in the EU and have users in Austria, and Austria suddenly decides that Google tracking is no longer GDPR-compliant (and therefore “illegal”), how quickly could you disable or update all of your Google tags so you could be compliant with confidence? Many companies would really struggle with that.
Why ecosystem health matters: Site Speed
The main thing folks think of when they think of Tag Bloat is the effect on site speed. There is an incredible amount of data out there showing that site speed affects conversion rates. I had a hard time choosing between studies, because there are just so many that have found things like:
Mobify found that decreasing their homepage’s load time by 100 milliseconds resulted in a 1.11% uptick in session-based conversion
Retailer AutoAnything experienced a 12-13% increase in sales after cutting page load time in half
Walmart discovered that improving page load time by one second increased conversions by 2%
Site speed is also a direct ranking factor in SEO (and an indirect ranking factor, if users bounce or spend less time on your site because of the slow user experience).
Folks often discount the impact that marTech tracking has on site speed. It’s ironic that the technology we use to measure site success can actually decrease site success. Every now and then the SEO team or IT may come to the Analytics and Marketing folks and say “that TMS library is too heavy and causes all our problems”, and there may be some cleanup, and usually some back and forth, before it’s ultimately decided “sorry, we HAVE to have tracking. Leadership gave us their stamp of approval”. And that may be true, but that doesn’t mean we shouldn’t minimize the impact, because (as I discuss in my next post), it does have an impact…
1. Impact to Page Performance. TMS files and extensions/tag templates do have some inherent weight to them- code that must be run on every page so that the TMS knows what other code to bring in. An empty GTM container with no tags, triggers, or variables in it, is around 33 KB. If you add a single Google Adwords conversion pixel using the Adwords Tag Template, that adds another 20 KB. An entirely empty Adobe Launch library is nearly 10KB. Once you start adding rules and tags, a TMS can easily become one of the single heaviest assets on many sites.
2. Loss of Control. Let’s say you notice a “clarity.js” file throwing an error on your site, but to your knowledge you aren’t deploying anything called clarity.js. If you’re spread between two Tag Management containers, it can be hard enough to establish that no one is deploying that tag directly. Once you track down that that file is being deployed by Bing, you need to find all the Bing tags and disable or modify them, and you need to do it quickly to get rid of that error. That kind of agility and knowledge of your own ecosystem becomes very difficult if you’re spread between tools. You should have one point of entry for tags to your site, and you should watch that entry point carefully.
Sometimes, adding a second tag container is unavoidable, but it should never be done without thinking about the risks.
Folks often take for granted that they “must” have analytics and martech tracking and tools on their site. And that may be true, but that doesn’t mean we shouldn’t try to minimize the impact… because it DOES have an impact. I looked at the home pages of 5 brands from the top of the Fortune 500, and found that:
On average, 35% of the page weight was for MarTech. (Note, this does include stuff beyond just conversion pixels… it’s tag managers, optimization tools, analytics, consent management… some of which may improve the user experience, but none of which is required for the site to function.) For the Telecom site, literally half of the site weight was marTech!
Tag Manager Containers alone can carry a lot of weight- for the Energy site I looked at, it was 15% of the site’s total weight! I mention this in my post about TMS Best Practices, but an EMPTY Google Tag Manager container weighs 30-40 kilobytes (not to compare, because weight-when-empty isn’t the most useful measure, but an empty Adobe Launch library is 9 KB). If you add a single Google Adwords Conversion tag using GTM’s Tag Template, that adds another 20 KB. That’s more than any script on my site, including the whole jQuery library. A “full” TMS library can easily be the “heaviest” single asset on a page.
All that marTech tagging also means a lot of different domains are contributing something as the page loads. The Media site I looked at had almost 200 different third-party domains adding their script, pixels or iframes to the page.
MarTech DOES impact page speed in a way that. That media site had a speed index of 13.2 seconds for a mobile device (meaning it took about 13 seconds before the majority of VISIBLE content on the site was loaded.)
See the impact of your TMS on YOUR site with Chrome Developer Tools
If you want to get a quick sense of the impact marTech has on your site, there is an easy way to do it using the Chrome Developer console. I find the easiest way to get to the Dev Console is to right-click anywhere on a page and choose “inspect” (you can also do Ctrl+Shift+J on Windows or Ctrl+Option+J on a Mac). Once in there, go to the network tab (#1) and find your main TMS container file. You can use a filter (#2) to get to it quickly: adobedtm.com or launch for Launch, googletagmanager.com or gtm for GTM, or utag for Tealium. Right click on the first file that matches that filter (#3), and select “Block Request URL” (#4):
This essentially gives you an “ON/OFF” switch for your TMS:
You can load any page on your site with your TMS “on”, as it is for all your users, then turn your TMS “off” and see the difference in load times and amount of files and weight on your site. The “DOMContentLoaded” and “Load” numbers at the bottom of the network window are good ones to watch, since they show the amount of time for the main structure of your site to be built, and the time for images and other content to load.
Do make sure you’re comparing apples to apples- either use a fresh incognito window for each load, or click the “Disable Cache” checkbox in the network tab (#5 in the graphic above).
For example, with the TMS in place, this particular site I tested took 3.5 seconds to load, and had 54 files (“requests”) with a total weight of 3.2 MB. (I tend to ignore the “KB transferred” and “Finish” numbers for reasons not worth going into).
After I “blocked” the TMS, those DOMContentLoaded and Load times went down considerably:
This isn’t a perfect science- every time a user loads a page they’ll get slightly different times depending on device, bandwidth, server response times, and caching- but it can give you a quick sense of how much your marTech and analytics scripts have on your site. If you want to take it a step further, you can use this “Request Blocking” trick while running a lighthouse test directly in your dev console:
Get deeper insight on the impact on your site with webpagetest.org and my marTech Governance and Impact template
Deeper instructions are in the template itself, but at a high level: run a webpagetest.org scan of a page on your site- for instance, I ran a scan on marketingAnalyticsSummit.com. Once the scan has run, grab the URL and paste it in to cell B1, just for safekeeping (you can always refer back to it later). The “good stuff” is on the Domain tab, but if you’re interesting in overall metrics on the main page, you can throw this script in your developer console:
document.querySelectorAll("#tableResults tr").remove() //clean up the table so we can copy the whole table but get only the row we care about
copy(document.getElementById("tableResults")) //copy the table to your clipboard
document.location.href=document.location.href //refresh the page so you get the full table back
Then paste into cell A4 in the template (it’s bright yellow) to fill out this handy little table:
Next go to the domains portion of the scan:
In general, you can use the process of elimination to figure out what is from a marTech vendor… in most cases, if it isn’t a domain you own, it’s marTech (not always, but… often enough). Figuring out which marTech vendor can be a bit trickier. I mean, www.linkedin.com is pretty obvious, but LinkedIn also fires resources from licdn.com.
Then paste the result into cell A12 of the excel template (it’s red), which will fill out the table and allow it to check if domains match our list of known domain/vendor mappings, then summarize what it finds:
For instance, here we find that marketinganalyticssummit.com’s home page weight is 26% marTech (and 8% TMS). It’s a very light site to begin with, so 26% of not much is…. not much. But it’s interesting to see how much is going on behind the scenes, even on “light” pages.
Now that you’ve established a high-level view of marTech’s impact on your site, you may want to dive deeper and do a tag audit… I’ve got tips and tricks for how!