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.