Tag Archives: code

A Marketer’s Guide to Agile Development – When Your IT Department Pushes Back on Digital Tracking Tags

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.

A Marketer’s Guide to Agile Development – Top Five Reasons Agile Teams Hate Marketers

In a previous column, we reviewed some reasons why some marketers give Agile the stink-eye. Let’s review why developers may be sending that stink-eye right back at ’em.

They’re annoyed – by short attention span theatre.
Marketing is all about the art of the possible. Brighter, shinier, cooler possibilities assail marketer’s brains constantly – it’s relentless. Those deep thoughts surface at inopportune times – like when their original, slightly less cool vision is in testing phase. Intellectually, they may know the enhancement should wait for the next sprint. But emotionally, this new cooler version becomes their vision of the finished project. So they become serial badgerers, imploring the PM and the developers to make “this one little change” here, “a small tweak” there. Hey marketers – a little discipline please. If you catch yourself uttering a sentence that begins with “keep it exactly the same, except….”, snap the elastic on your wrist and go back to your desk.

Sure, some marketers argue that Agile environments are supposed to welcome changing requirements. They do, in theory. The GOP welcomes healthy bipartisan debate in theory too. Theories are like that. Unlike the GOP, Agile doesn’t filibuster – it simply pushes the change to backlog. Or depending on the rank and title of the badgerer, stays late and does it, and harbors resentment.

They’re misunderstood – most marketers are clueless about sprint process.
Many marketers do actually think that if their request is not yet in production, they can still make changes, even if it’s 3 in the afternoon and the release is at 5:30. They’re not really trying to be jerks, they simply don’t know better. But they should. Responsible marketers, with the help of the project manager and/or scrum manager, learn the rhythms of the development organization that brings their ideas to life. When they do, they understand that recalcitrance isn’t the only reason behind a refusal to accept a change. But development teams take notice – once a marketer has taken the time to understand and honor your process, you’ll have to stick by your process too. No more blue smoke and mirrors.

They’re resentful – they’re the ones staying til 8:30 on Friday night.
Let’s just say it. Marketers have a reputation of not working very hard. Full disclosure, I’m in Marketing. That Dilbert cartoon with the sign that says “Marketing – 2 Drink Mininum” hangs on my wall. But trust me, most of us work our share of nights and weekends – usually individually instead of communally. Maybe because we’re not visibly toiling away night after night as a department, development teams can sometimes assume that they’re doing all the heavy lifting while Marketing lounges on divans eating bon bons while watching Oprah. That’s a myth. We only eat bon bons if the mailhouse vendor sends them at Christmas. And we only watch Oprah when we’re home sick. Some of us not even then.

They’re apprehensive – Marketing can declare all their work a failure.
A pet peeve of mine is when I’m in a meeting where someone justifies a decision with “well, I think users would want…” I just want to cut off that sentence with an air horn. Good marketers test. Good marketers declare success metrics for their initiatives, and Agile teams should abide by the same set of metrics. In my experience, when Agile teams reject Marketing’s analytics in favor of their own metrics, usually their own analytics tell them they don’t need to change their code. Objective, dispassionate measurement makes continuous improvement possible. It doesn’t matter if a developer missed his high school reunion to code the new product page, or the Angel Gabriel handed the style guide down from the sky to the CMO on an iPad. If Marketing Analytics results show that it’s decreasing rather than improving conversions, that page is going bye bye until they figure out why.

They’re jealous – Marketing gets all the cool swag.
The new branding campaign launches. Marketing gets the leather bomber jackets with the new logo on the sleeve. The developers get logo coffee mugs that can’t go in the dishwasher. Marketing celebrates the launch at Le Chateau Tres Cher. The developers stay back at the office with a Quizno’s platter to code the hot fixes. This dynamic is actually changing in some organizations. Marketing budgets aren’t what they used to be. And IT executives can order swag too.