If analytics thrives on accuracy and storytelling, maybe borrowing a time honored method from journalism will help us improve both. Instead of treating an analytics business requirement or ad hoc request as a cut and dry task to execute, what if we investigate the story that drives it?
Mix in a couple Radical Analytics principals from Stéphane Hamel, and you end up with a pretty good way of looking at how to best help our users with their requests.
Why – Understand It Like It Was Your Own
As the requirement recipient, you are the bridge between the person that understands the problem, and the orgâs analytics resources. That means you need to understand the problem, and what your org can do with analytics. The good news is that youâll build an ever greater understanding of your team, resources, and tools by virtue of working with them.
The even better news is that the user request side of things will be a never ending series of often totally unforeseen and fascinating topics that will keep your work interesting. Itâs crucial to your performance that you understand what users are after – specifically what people want to do and why. Unforeseen questions can often be handled by someone that gets the âwhyâ of a request without having to make that round trip to the original user.
Asking why is a very powerful business tool, even formalized in the 5 Why method, which you might want to consider using. Getting people to talk about why they are doing something gets them away from talking about what they want you to do, and focuses the conversation on their activities and goals. That leaves room for you and your team to add value by considering solutions the user wouldnât know about. More on this in the next section.
What – Never Ask, Alway Propose
People might try to tell you what analytics solutions they think they need, or even how to do what they think they need, instead of telling you what they are trying to accomplish. Remember that you and the analytics team can figure out how to track, report, and analyze just about anything, but you can only do a good job of that if you know what the analytics user is trying to do, and why.
Depending on the ask, goal, and need, the solution might be obvious to both of you. If itâs not, present some options you can discuss. The point is to get people talking about solutions without inviting them, let alone forcing them, to think of a solution without your help. You are the one that knows about using analytics to help people succeed at marketing – donât rely on your users to take the lead.
This principle comes from the Never Ask, Always Propose, part of the Radical Analytics series by StĂ©phane Hamel. The series is a fantastic look at things that are wrong with our industry, and what we can do about it. I enjoy doing analytics more now that Iâm applying it.
Note that you donât have to come up with great options on the spot. You can let someone know youâll get back to them and give yourself a chance to do some research or talk to your team. If you are just spitballing ideas on the spot, make sure you tell people that, and avoid promising something you arenât sure you can deliver.
Who – The Good, The Bad, and The Ugly
We arenât going to categorize user requests with those three terms, and certainly not the users making them! They are just to break down reasons itâs important to consider and pass along who is asking for the analytics work.
The Good
Understanding who is asking is often the first step to understanding why they want to do something, and a crucial part of scoping a question. The quality of communication you have with a person is greatly influenced by how well you know them. Sometimes, someone on your team will have a relationship with the asker, or at least experience working with them, and can leverage to find a better solution. Of course, in a larger org, youâll need to keep track of this just so you remember who to tell when something is done.
The Bad
Who do you reach out to if thereâs something to clear up, or a deadline that will be missed? Perhaps more importantly, who does whoever is working on that ticket reach out to when they get your auto-repsonder about recovering from surgery for the next couple weeks?
The Ugly
Different people in your org have different levels of ability and inclination to make you and the rest of the analytics team happy or miserable. As much as it can hurt people like us, who value transparency and accuracy, it is in your interest to take this into account when prioritizing whoâs stuff gets done first, and how to frame your response. Faking report results to humour a CxO is unethical. Doing something you donât think is the best technical solution, use of resources, methodology, etc, once your politely but clearly disclosed objections are noted, overruled, or ignored, is part of working with others.
Before you run off to get the âc-suite buy-inâ often presented as a silver bullet to every analytics problem, StĂ©phaneâs Radical Analytics lets some of the air out of that myth, and presents a great, sustainable strategy for analytics pros to grow influence in an organization.
Where – Online Is a Big Place
Make sure you clearly understand the scope and targeting that are called for. Very often, people (including me) with decades of experience working in places that have dozens of websites, a bunch of social media accounts, several agency partners, and huge numbers of campaigns, will refer to whichever piece of the puzzle they happen to be thinking of as âthe site/account/agency/campaign.â
Are the new content and forms we need to track going up on all the properties? Or just on the English part of the US site for now? Or itâs actually going on a new subdomain?
Itâs incredibly easy for someone working hard on something to leave out a detail that is obvious to them, but unknown outside the people really tucked in to that project. Help avoid misunderstandings by double checking on context.
A standard request form or ticket format can help make sure this is clear in every case. Donât use it as an excuse to avoid a conversation though: itâs there to make sure all the important stuff is covered, not to allow the important stuff to be glossed over and assumed.
When – Preferably Before the Campaign Ends
People are usually pretty good about letting you know when they need something. Unfortunately, depending on resources and culture, not every ask will get done, and it can take a lot of diplomacy to help users understand when their needs canât be the priority. Try not to leave people empty handed: if new interactive dashboards arenât in the cards for this quarter, can you at least get the data into a custom report to tide them over?
A lot less thought and discussion goes into how long something will be needed, which is almost as important. Tags that only needs to be around for a short campaign or promotional event donât require the same degree of thinking about maintenance consequences. It might get added in a faster, simpler way than if the team has to worry about how the tags will have to behave as the site and analytics solution evolve.
Something needed now that doesnât need to last a long time is usually ok, and something that needs to last a long time but isnât needed right now is usually ok. Trying to get something that requires long term planning done in a hurry is where you run into problems.
Consider a phased approach if the priority and timelines justify it, particularly if your org or team use Agile. Get a temporary and easily reversible solution in place quickly, then make a new request out of making a long term solution.
Sometimes, itâs a lot easier to wait and do something as part of a larger update or new build. Sometimes, when you go back and ask the stakeholder how things are working out and if thereâs anything they want tweaked while you set up the long term solution, you find out that the campaign was a bust and they donât need the tracking anymore.
Either way, the user got what they needed while your analytics team judiciously conserved resources, and kept the tag container from turning into martechâs answer to the Mutter Museum of Medical Oddities.
How – Thatâs 6 Questions and You Donât Start with W
Youâre right, weâre done! How is a different thing entirely, in that itâs not up to business to figure out how you are going to implement their requirements for you. That doesnât mean you should be dismissive if they mention something technical: the last thing you want is a culture where people donât tell you stuff because they are worried youâll be frustrated with their lack of understanding.
With less analytics knowledge, they are even less able to determine what is obvious to everyone and what has to be mentioned. And itâs not like weâre 100% accurate when we are deciding what to assume and what to ask. Youâll usually fair better in an environment where people freely mention their concerns and donât get a bunch of eye rolling in response.
Be reassuring about stuff that is obvious, and be thankful when people give you info that turns on a light bulb. Outright tell them how that info is useful and changes things, without getting technical. Over time, youâll build a shared concept of what is par for the course and doesnât need discussion, vs what might be out of left field and require some extra notes.
Let me know in the comments if you have any questions about how this could work in your organization, or if you have some tips to share about how you better understand your usersâ requirements.