Читать книгу The Informed Company - Dave Fowler - Страница 22

Chapter One Starting with Source Data

When starting from scratch, keep in mind the potential for the data to grow and the usability needs of users in the future. In the beginning, sources are their own islands separated from each other. Data streams remain in their own “silo.” When a data team is small, a collection of sources is easy to maintain and monitor. For example, to support new data teams, many data sources have their own built‐in dashboards and reporting capabilities (see Salesforce, Heap, and so on).

While single‐source data isn't all that powerful, it's not at all useless. Some everyday use cases of solutions built from single‐source data include:

 Database queries that generate customer acquisition metrics.

 A dashboard that displays monthly sales featuring a downloadable spreadsheet.

 A custom web application that allows searching of referral traffic.

Siloed reporting does not yield the powerful data insights that more sophisticated teams need, but this is often where teams must start. The analyst's role becomes that of an instructor to stakeholders—the analyst must understand sources and support business stakeholders who read and interact with this limited data. An analyst may pull together numbers from separate comma‐separated value files (CSVs) and run manual analysis in Excel or with basic SQL queries.

As we explore data sources, remember that analysts can do much more for their teams than work with business intelligence tools, Excel, and simple queries. In time, they can build abstractions on top of the data that make data accessible to other colleagues and self‐servable (more on this in Stages 2 and 3).

Common Options for Analyzing Source Data

Data ends up in many different places, but the methods to analyze them boil down to application dashboards, Excel spreadsheets, SQL IDEs, cloud dashboarding tools, or business intelligence (BI). We proceed to touch on several common tools used for interacting with sources, giving a short judgment on when and how to use them (Figure 1.1).

Figure 1.1 Various methods for data analysis for data sources.

Get to Know Data with Application Dashboards

Many modern software as a service (SaaS) applications come built with a set of fixed dashboards and visualizations to showcase the data they are capturing (Figure 1.2). These charts are highly tuned to specific use cases and can be quite informative—and maybe meet all data needs. Some, like Salesforce, even have a customizable chart and dashboard creator built in to support ad‐hoc querying. Many have custom query languages, too. These can go a long way, especially when there is no need to see this data in combination with other data. An additional part of the value proposition underlying these tools is vendor support staff, who help answer questions or fulfill special data needs.

One word of caution: keep an eye out for how often single sources of data need combining with other sources. Perhaps you often fulfill queries like “tell me what lead type creates the most customer support tickets,” that is, business asks that require analysis across multiple sources. If your team finds themselves playing the part of “glue” between single sources all too often, it may be time to move to the Data Lake stage.

Figure 1.2 Example built in dashboard showing common metrics from Zendesk.

Source: “Zendesk”

Ask Interesting Questions with Excel

Most applications can export some of their data into CSV formatted files (Figure 1.3). Anyone with Excel or Google sheets can then import that data and analyze it. While this is an effective way to expand the questions that one can ask of data from applications, it is relatively manual and requires frequent updates to keep data current.

Figure 1.3 A basic export feature on a web services dashboard providing a CSV download.

Source: Microsoft

Query Databases with an SQLIDE

For data sources such as a production database, they can be queried directly from the command line, but this can get messy and hard to keep track of queries and results. We suggest setting up an integrated development environment (IDE) such as pgAdmin to better handle querying data within a schema (Figure 1.4). These tools have features that support writing queries (i.e. autocomplete), saving queries, and exporting data.

Figure 1.4 pgAdmin dashboard is a popular IDE for PostgreSQL.

Source: pgadmin.org

Visualize Data in the Office with Dashboards

Tools like Geckoboard or Grow receive data from cloud applications via APIs, then visualize that data in simple yet useful ways (Figure 1.5). These tools can provide data blended from multiple sources into a single dashboard.

These types of cloud dashboard tools often come with some helpful default dashboards and also look great on TVs around the office. They keep teams aware of what's going on. However, these solutions are very limited in their customizations.

Figure 1.5 Geckoboard like dashboard displaying standard sales metrics.

Toying Around with Analytics Products

Tools like Amplitude and Mixpanel (Figure 1.6) can help make product managers more self‐sufficient by removing the need to involve engineering to add tracking events. Product analytics provides templated analysis and a GUI so no code is needed to ask questions of the data. This appears to be a great solution, but we would advise caution with these sorts of tools.

Unfortunately these tools are typically expensive and for every new event tracked you have to wait a few months to get the data you need. These events are typically already tracked in the application database but may be named and stored in hard to understand ways. In addition, product analytics tools are limited to data from the application, meaning we can't see revenue or other business metrics that exist in other sources. Product Analytics do not really scale to serve the data needs companies have.

Figure 1.6 Mixpanel cohort analysis.

Source: Mixpanel

Look at Data Through a Business Intelligence Tool

For the most power in working with source data, use a flexible self‐service BI solution. For this stage, be sure to choose an agile product that supports direct SQL queries and ideally the ability to connect to and blend data from multiple sources.

The main benefits of adopting a BI solution with direct SQL capabilities include:

 Consistency of data access.

 Lower cost of operation.

 Portability of data to future systems such as data lakes.

When data sources aren't consolidated or cleaned and organized, these types of BI solutions are necessary but, on occasion, may require complex SQL queries. Tools like Looker and our very own Chartio support writing queries and managing custom dashboards (Figure 1.7).

Figure 1.7 Chartio Dashboard Executive Summary of Sales Metrics.

Source: CHARTIO