1. “Tracking tags will slow down our site.”

In my experience, tracking tags are often the first thing developers blame when sites load slowly. But even in the bad old days before asynchrony, tracking tags were rarely the real culprit. It’s even less likely now with tag management systems like Google Tag Manager and Tealium. So why does tagging get blamed instead of image formatting/sizing, java script minification, widgets, etc? Because IT is busy, and IT usually doesn’t own tagging. So, they kick the can to you. So, make sure the page tag is placed properly, prove through metrics that tag weight is negligible (it usually is), and kick the can back.

2. “We don’t have time to add tracking.”

IT departments in an agile development environment may classify tracking as an enhancement rather than a launch requirement. Remember, your IT buddies are graded on (a) coding and launching a digital asset on time, (b) adding enhancements and (c) making sure the asset continues to function well. Their bonuses do not depend on your ability to track. So take your favorite Finance Department buddy to lunch, sigh heavily, and opine about how much more efficient your budget could be if ONLY you could track right from launch. You’ve just gained political clout to move tracking from “nice-to-have” to “must-have”.

3. “Tracking tags can interfere with site functionality.”

Well, they could. But they won’t under your watch. Because you will make it your job to ensure tag library names are unique, and tracking is placed correctly on the page. Tags will be tested in the dev environment before going to production. Those are typically developer competencies, but your tags aren’t top-of-mind to your developer buddies. So help them help you. Once your developers reach a comfort level that your tags won’t break anything, the road ahead gets a lot smoother.

4. “It’s a waste of time to track all that stuff.”

Maybe so. That’s why you will have use cases – something like “If I knew “X”, I could do “Y”. For example:

“If I knew [which tools visitors from partner sites used], I could [optimize content to those visitors to increase engagement]”.

“If I knew [user article view sequence], I could [suggest ‘you-may-also-enjoy’ links for each article].”

Track what’s actionable now and in the future, and be prepared to justify each tag you add.

5. “Don’t tell me how to code.”

“Here’s what we’ve found works best” or “Here’s how other sites usually do it” can go a lot further than “Code it exactly the way we tell you.” I’ve found that patience, persistence and emotional intelligence can help Marketing and IT build a culture of measurement pretty quickly. At first, IT organizations may feel their autonomy is at risk when subtle code changes are needed to accommodate Marketing’s tracking. That happens. I knew we’d gotten past that hurdle the day a developer called me and said “Hey there’s no tag plan on this new functionality they just gave me to code – think we should we tag it?”

6. “Pssst…. hey, do you know how to do this web analytics stuff they’re talking about?”

Sometimes it’s because (a) they don’t know how to do it and (b) don’t want to admit to you they don’t know how to do it and (b) don’t think it ought to be part of their job to Google instructions on how to do it. This conversation may involve folks above your pay grade to get them to understand the importance of analytics and their role in it.  But have the conversation. Don’t give up.