The Problem With Self-Serve Analytics

Because security officers like Rafae see themselves as being responsible for security outcomes, not just inputs.

Rafae didnt just give me the information I needed – he followed up to make sure the decision I made was the right one.

Now, imagine this parallel scenario: Our head of marketing is evaluating which of our marketing campaigns need more investment and which need to be cut.

She has a few questions about how each one is performing.

While shes familiar with our marketing programs and goals, shes not an expert in analytics or our data stack.

She wants to make the right decision, so she asks an analyst for help.

A typical response from an analyst would be to point her to a marketing dashboard or a tool for accessing campaign data, and leave her to make the decision on her own.

This hands-off approach would seem reckless for questions about security.

And yet that approach is not just the norm for analytical questions in most organizations; its often the ideal.

Many analytics teams aspire to enable as much “self-serve” as possible – in other words, to remove themselves from as many decision-making processes as they can.

And many vendors hold this up as the promised land: build a dashboard or report, hand it off to the marketer or product manager to “self-serve” their data, and step away.

This approach often develops for understandable reasons.

Companies have to make a lot of decisions, and analysts cant be involved in all of them.

Self serve seems like the only way to scale.

But as data scientists, we should be clear-eyed about our primary responsibility: to turn data into insight, and insight into action.

Attempting to hand off these problems doesnt change that.

Providing a tool to someone to get the data doesnt offload that responsibility.

If the data is easily misunderstood, or if the person making the decision hasnt been trained to interpret it, its on us for creating that situation.

To put it another way, the only things self-serve helps scale is SQL code and a general understanding of business logic.

But knowing how to write a query, or how our company defines a new customer, isnt what makes an analyst.

Were analysts because, when there are problems, we know which rocks to look under, how to question what we find, and how to distinguish between what weve learned and what we havent.

The more we focus our role on delivering data access and remove ourselves from delivering outcomes, the more we waste this skill – and the worse off our organizations will be.

Original.

Reposted with permission.

Bio: Ben Stancil is the Founder of Analytics @ Mode.

Resources:Related: var disqus_shortname = kdnuggets; (function() { var dsq = document.

createElement(script); dsq.

type = text/javascript; dsq.

async = true; dsq.

src = https://kdnuggets.

disqus.

com/embed.

js; (document.

getElementsByTagName(head)[0] || document.

getElementsByTagName(body)[0]).

appendChild(dsq); })();.

. More details

Leave a Reply