One of the funnest parts of any web analytics role is instrumentation: the tagging of the various parts of the site (Whee.). While what I mention below may not have happened to me, every one of them has happened to someone I’ve worked with:
- Having to tell one person that no, you can’t tag every AJAX event and URL link on the page, so pick the most important ones… while having someone tell you in the next meeting that “no, we don’t need any tracking on that page, no one goes there anyway.”
- Discovering a major ad campaign is breaking in 24 hours and not only are the ads not tagged, but the landing pages aren’t, either.
- Discovering that your tagging and cookie setup was designed for a different domain name, so all your stats have been beefing up the wrong section in your reports… and your cookies all appear to be 3rd party instead of 1st.
- Etc… you probably have some horror stories not fit for this kind and proper audience.
Yes, QA can catch some of this, but with new pages and new capabilities (AJAX pages, iPhone apps, widgets and in-page apps, etc.) and a gazillion new tags (ad networks, ad validators, 3rd party trackers like …
One of the funnest parts of any web analytics role is instrumentation: the tagging of the various parts of the site (Whee.). While what I mention below may not have happened to me, every one of them has happened to someone I’ve worked with:
- Having to tell one person that no, you can’t tag every AJAX event and URL link on the page, so pick the most important ones… while having someone tell you in the next meeting that “no, we don’t need any tracking on that page, no one goes there anyway.”
- Discovering a major ad campaign is breaking in 24 hours and not only are the ads not tagged, but the landing pages aren’t, either.
- Discovering that your tagging and cookie setup was designed for a different domain name, so all your stats have been beefing up the wrong section in your reports… and your cookies all appear to be 3rd party instead of 1st.
- Etc… you probably have some horror stories not fit for this kind and proper audience.
Yes, QA can catch some of this, but with new pages and new capabilities (AJAX pages, iPhone apps, widgets and in-page apps, etc.) and a gazillion new tags (ad networks, ad validators, 3rd party trackers like ComScore, social tracking, buzz tracking, etc.) coming to the market, it’s harder and harder to keep track of it all.
There are a couple of ways people are attacking it. One is the “piggybacking” approach, where one of your tags is “1st call” and it cascades the call down to other tags. So, your page really has only that one tag, and you plop the other tags on a management page at that vendor’s site. Not bad, but each vendor likes to say “Oh, we can have other tags piggyback on us, but our tag has to be first call”. This, of course, is a Prisoner’s Dilemma, and so gets us nowhere.
Another are 3rd parties which try to help out with the problem. Maxamine, now part of Accenture, is one company which can help you validate, organize, and manage your instrumentation and tagging. On the other end of the “company size” spectrum, smaller players like TagMan act as neutral tag aggregators, letting you load all your tags with them and then controlling which fire when. And tools like WASP can help you go through your site to verify that the tags are at least present; your vendor may also have similar tools.
But I wanted to point your attention to an interesting new idea, one that the amazing John Graham-Cummings is working with. If his name rings a bell, it’s because he wrote one of the early and best antispam filters called POPFile that really leveraged Bayesian approaches to spamfighting. So, anything he chooses to spend time with is probably worth looking at.
One of his latest projects is working with the JSHub open source tag consolidator approach. The site is fine, but his blog explains it much better: What is JSHub?. Basically, since so much of the tagging experience is the same (use JS to create an image call with data in the query string), he proposes consolidating all that duplicative stuff and use a standard approach to defining what data you need. After all the data is somewhat consistent from tag to tag; it’s what each vendor can do with it which is their real story.
I look forward to more vendors joining up into this fully open approach to allow more tag consolidation. This will make it easier on both the sites and the users: Sites will have more control and management over the tag forests sprouting up, and users will have better experiences controlling what’s tracking them and having faster page load times.
Liam Clancy and Fiann O’Hagan have a good idea with JSHub, and I encourage all of us who have to deal with tags on sites to take a look at it. It won’t solve everything, sure, but it’s a good step in the right direction.
