What does it mean to build a self-service analytics infrastructure?

When I joined Human Interest in 2019, I was tasked with building a Data team that could empower everyone else in the company to make smarter, data-driven decisions. One way to disseminate knowledge across your business is to make data science products into self-service analytics assets that less technical employees can use to make better decisions.

I immediately set out to hire a small team that could make an outsized impact on the business by building “self-service” analytics products. This post outlines our journey to self-service, and highlights the benefits we’re seeing from self-service analytics.

❓ What do we actually mean by ‘self-service’ analytics?

I think about “self-service” as the process by which more technical users asynchronously augment the abilities of less technical users. A classic example of this is enabling non-technical users to pull data or access an analytical insight without needing to write SQL.

Any component of analytics can, in theory, be made self-service. At Human Interest, we want non-data scientists to be able to leverage frameworks and models built by data scientists. But it takes time and energy to make data products self-service, so it doesn’t make sense to do so for all of the frameworks and models that our data science team creates. Complex, one-off analyses don’t need to be made into self-service products. However, a root cause analysis that feeds team-level KPIs on an ongoing basis would be a great self-service analytics product.

Here’s a rule of thumb you can apply when determining which projects are worth converting into a self-service asset:

If a less technical person is repeatedly asking for the same insight or data product from an expert data scientist or other technical resource, it’s probably worth making it into a self-service analytics asset.

🧭 How do we get to the self-service holy grail?

Make tooling and assets easy to find

Self-service tooling needs to be easy to find and fit the mental models for search that people have. For example, do your users prefer directory structures or search functionality? The answer to this question should affect the self-service tooling you use, and how you set up access to it.

At Human Interest, we also try to organize information according to its business area or team which aligns with the way our people look for information.

Keep it simple

Simplicity ensures that general users can autonomously use the self-service app. Documentation is important here, whether embedded in the app or linked out. Ensuring consistent naming conventions is also important, and should be applied throughout the data stack, from the tables, columns and schemas to the names of metrics.

The most successful form of self-service is one where we can onboard new employees and they can access and leverage the data they need for their day-to-day without interfacing with the data organization whatsoever.

Most importantly, meet users where they are

The most useful guiding principle for enabling self-service is to try and limit the degree to which users need to learn tooling. You need to package up the component that is useful to the other person in a shape and form that they can use.

For example, some of our stakeholders at Human Interest would rather use spreadsheets than interactive BI dashboards, so we try to deliver self-service products in this format. For other business stakeholders, this means returning tables or simple data visuals.

Likewise, we want analysts to be able to use code written by data scientists. Most analysts don’t know how to manage their Python environments, so we work to abstract package management. We also try to confine functionality to SQL and simple Python for our analysts. This is where Hex comes into play.

💪 At Human Interest, non-technical stakeholders self serve using Hex

Hex has been a core part of our infrastructure that’s powering self-service analytics here at Human Interest. We leverage user inputs in Hex to generate SQL that pulls reports for stakeholders. For instance, we might have filters corresponding to useful segments that end users can use to pull down a swath of data to analyze in Excel.

We also use Hex to make the output of data science models accessible to business stakeholders. For example:

• Our operational teams use Hex to identify customers likely to churn so they can proactively reach out and see whether there’s an opportunity to improve their experience.

• Our finance team uses models built in Hex to attribute revenue changes between periods.

• Our product managers enjoy their ability to easily filter, sort, and pull data to answer simple questions independently, without taking up an analyst's time.

And we maintain shared code that is accessible through Hex, which abstracts complex Python functionality for analysts. This allows analysts to up-level their own skills and take on more complex data science work, like building feature engineering frameworks, auto binning functions, or writing into the data warehouse. Those who are familiar with the use cases can do advanced work, even if they aren’t advanced programmers.

Out of the box, Hex comes with charting and database connections which saves us from having to teach those skills to analysts. As a shared environment, it also allows analysts to look at the code of more technical resources, learn and work from it.

🛤️ It’s a journey, not a destination

Driving the adoption of self-service can empower both stakeholders and analysts. Specifically with Hex, our users appreciate the speed at which analysis can be delivered (as opposed to Tableau) and the ability to interact with analyses without having to learn to code it.

Our ability to move towards self-service allows analysts to spend more time working with specific stakeholders. This can help the team feel more connected to their work. They are becoming more consultative with stakeholders as they’ve started working with a more concise group. They have also gained more context within a business domain which provides them the context necessary to collaborate and make sure they’re working to answer the most important questions.

If you’re leading your organization’s effort to create a self-service analytics environment, dedicate careful thought and structure to the initiative. You need to understand the types of analytical functionality that will be useful to the people in your organization. Then, determine how they can most easily access and engage with that functionality.

It’s important to think about self-service as a process rather than something you implement. It requires constant learning and adjustments along the way. For instance, as we are learning more about what is working, we are adapting our Jira space and process to better fit the needs of these partnerships between data scientists, analysts, and stakeholders.

At the end of the day, it's about the people you are trying to support and the team you are trying to build. Whether whatever route you choose, it's a journey defined by iteration.