Dynamic Tag Management and the Overnight Test

Dynamic Tag Management and the Overnight Test
Adobe Products Featured

This is a guest post from Cleve Young at Starwood Hotels. It’s a first look at how both practitioners and managers can benefit from dynamic tag management in different ways.

A big THANKS! to Cleve for contributing his time to create this post and share his experiences with all of us. Cleve is the Manager and Implementation Engineer at Starwood Hotels.

Business today has a relentless pace — we’re expected to do more, faster, and with fewer resources. It’s amazing that marketing and analytics teams accomplish this most of the time. But, more doesn’t always mean better.

People often reference time as being one of the most valuable commodities humans have; yet, we struggle and race to compress time, often losing track of the true value of our time. But, if you prioritize a brief timeout from the daily grind, you’ll realize more value than you ever thought possible.

Recently, I read an interesting article, “A Short Lesson in Perspective,” in which the writer discussed the “overnight test” — meaning, the author sleeps on his ideas overnight and reflects on them the next morning. This made me think about how I carry out my current job — analytics implementation and marketing technology integration. I’ve often fallen into the overnight-test methodology that allows for critical thinking. But, instead of using paper mockups, I use Adobe Dynamic Tag Management (DTM) as my sketchpad for testing ideas and thinking things through.

Tracking Needs Are Not Always Obvious (Sarcasm Ahead).
Many people — including some analysts — assume that digital analytics-tracking requirements are straightforward and obvious. And, in some cases, that’s true. However, most often, they become complicated quickly. For example, let’s say, the business folks want to know which webpage customers are logging on from. Sounds simple enough, right? Just fire a call when the user clicks submit on the login form. But, what happens when there’s a form error?

You need to account for that potential error, so simple click-tracking may not work. Next, you realize that certain types of errors may cause different page reactions: page reload vs. non-reload vs. different page destination. If you move pages after you get the error message, how will you track the page originally attempted? How will you know when a successful login has occurred? Do you need some value passed in from the server, or is there a frontend indicator?

And, of course, just as soon as the login-tracking request hits your desk, you know the next question will be about those login errors. Since you’re efficient, you should take the opportunity to set up error tracking at the same time as form tracking.

Oh, and don’t forget the different types of potential form errors that can trigger at different times. And, of course, once the information technology (IT) security team hears about “this whole tracking thing,” they will want to be briefed and involved, as legitimate concerns exist regarding exposing error codes to the public (who knew?!). So now, additional security restrictions deliver a bit more complexity. Finally, remember you must be diligent about server call volume and do your best to piggyback on the regular page-load call.

The above scenario is a common, straightforward tracking request. Now, let’s add a cold-water splash of reality: don’t forget that the business needs this tracking info ASAP because development has already begun. And, it must be right the first time, or you risk needing to wait for the next build cycle to begin in 1–2 (or 6) months before you can make any further adjustments. Add to that, the senior executives who need to have the reports for this tracking right after it goes live. And, to complicate things even further, you must always keep in mind just how much your boss truly loves to tell execs about how “We didn’t get it quite right, so you’ll have to wait a few months for accurate reports.” We all want to keep our jobs — the paychecks come in handy! As an added bonus, it’d be nice to also retain even a little of our sanity — what’s left of it, anyhow.

In the line of fire of analytics requests, we’re typically so busy scrambling to gather final specs that we rarely make time to give draft plans the overnight test. This is really just a matter of thinking about time — consciously and subconsciously. Remaining cognizant of time enables you to achieve deeper thought and make additional connections, allowing a different perspective when you look at it next. Call it what you want — hunch, intuition, connection, gut feeling, reasoning, magic, cosmic awareness. Whatever it is for you, it’s important, and so is following up with multiple drafts. DTM became my best friend for implementation work in this drafting and thinking process.

Think, Plan, and Then Go Live — Don’t Wait!
With DTM in my toolkit, I’m able to give developers basic instructions, quickly use DTM to sketch things out with several draft approaches, and then apply the overnight test. If things still make sense the next day, I can easily test different methods to see which is — and which isn’t — working well and better react to unexpected user experiences or code flows. Direct call rules are great examples; I find myself using them most often for these exact reasons. I sometimes tell the developers to just fire a direct call rule, and I’ll take care of the rest. Few things will make you faster friends with developers than telling them they don’t have to set up Adobe Analytics tracking. In the past, I would spend hours a day writing up specs for developers, testing and retesting their updates, writing emails about needed tweaks (and, usually, re-explaining how Adobe Analytics works), asking for more tweaks, and repeating. With DTM, I can now avoid that back and forth with the development team and use the time I save to conduct more strategic work and more comprehensive tracking.

Think, Test, Experiment.
Here’s another timesaver: I can test actual analytics tracking before IT or frontend development ever needs to be involved. Not all tracking requests are for new or updated functionalities. Sometimes, we just want to track stuff we have never had a chance to track. Maybe the business question was complex, and the analytics team didn’t have time to do the back and forth with development for implementation. As analysts, we’ve all learned to avoid asking for regular tweaks to the tracking code since it makes you rather unpopular with that group.

Now, I use DTM to experiment with things — grabbing different values, timing, using different combinations of eVars and events, saving values for later use in session Data Elements, and a multitude of other things. Sometimes, this can be more complex and require a higher level of programming skills; and often, this involves scraping data from the page, which is not ideal long-term. But, remember that, with DTM, it’s really your thinking time — time in which you can experiment, review, and discuss the results with others.

Once a solid approach is in place, you’re better prepared to discuss full requirements with the development team. With DTM, you will only need your development team to take care of limited things — for instance, place certain data into a data layer or trigger a Direct Call rule or custom event — while you retain the flexibility to make adjustments afterward. That is worlds away from the old days of hardcoding the tracking, pleading for tweaks, and repeating the cycle after reviewing results.

DTM offers a great deal of flexibility in using event-based rules, page-load rules, Direct Call rules, and even Data Elements in creative combinations. For more complex tracking, I’ve had a page-load rule add an event handler to an element and then had a developer trigger a Direct Call rule on an event, which ran a Data Element to store a value for the session. Then, I implemented a second page-load rule that checked for variables that were set using the previous rules and populated Adobe Analytics variables. That level of complexity is not the standard, but DTM’s flexibility opens possibilities for you to imagine when your mind has the time to think things through. Once again, I’ve come back to the concept of thinking-time, or the overnight test.

Dynamic tag management, by itself, is not a cure all — every system has quirks and limitations. You won’t totally eliminate the need for IT involvement in analytics. But, if you take some time to really learn the tool and understand how the pieces work together, you’ll be surprised what you can do with it. You’ll have more time to think through complex (and more valuable) questions and explore options. Less time will be wasted chasing IT for updates or fixes and waiting for accurate data to be delivered. And, you can better answer more business questions and highlight the value you bring to your team and company. Over the past two years — throughout which, I’ve been using DTM — I’ve learned how to use it to gain a much richer dataset for analysis and reporting, more consistent data quality, more long-term flexibility, and fewer annoyed IT and project-management people. And, just as important to me, it’s led to less stress and more peace of mind. I like having this time to think.

Recommended Articles