hextechnicalAPP-038

The Hex Data Analyst

#hex#data#notebooks#sql#python#analytics#collaboration

Aha Moment

“What was the moment this product clicked?” —

Identity

A data analyst or analytics engineer at a company with a modern data stack — dbt, Snowflake or BigQuery, and a growing demand from business stakeholders for self-service data access. They use Hex because Jupyter notebooks are hard to share and dashboards aren't flexible enough. Hex sits in the middle: code-first enough for real analysis, shareable enough that a PM can click through an interactive version without needing to run code. They build notebooks in Hex. Business people use the published apps. This is the workflow they've been trying to build for years.

Intention

What are they trying to do? —

Outcome

What do they produce? —

Goals

→Build analyses that colleagues can interact with without running code themselves
→Document the logic of an analysis alongside the code that produces it
→Move from SQL exploration to shareable insight in the same environment

Frustrations

—Computation time on large queries that breaks the exploration rhythm
—Version control that doesn't integrate with the Git workflow they use for everything else
—Stakeholders who use the published app and then ask questions the notebook already answers
—The line between "this should be a Hex notebook" and "this should be a dashboard"
—that isn't always clear until they've built the wrong one

Worldview

The analysis and the documentation of the analysis should live in the same place
Self-service data access only works if the access point is built by someone who
understands both the data and the audience
A chart without the SQL behind it is a number without a source — useful but unverifiable

Scenario

The CFO has asked for a weekly revenue reconciliation that finance can run themselves without filing a data request. The analyst is building this in Hex: SQL cells that pull from the data warehouse, Python cells for the reconciliation logic, and an app layer with date range pickers and export buttons. When they publish it, finance will have a self-service tool. The analyst will stop receiving this request every Monday. They're building that future right now.

Context

Uses Hex 3–5 days per week. Connects to Snowflake or BigQuery via Hex's data connections. Writes SQL primarily; uses Python for transformation and visualization. Has published 6–15 Hex apps that business stakeholders use as self-service tools. Uses Hex's scheduled runs for recurring analyses. Collaborates with 1–2 other analysts in shared notebooks. Has a personal notebook library organized by domain: revenue, product, marketing, operations. Uses Hex alongside dbt — Hex for exploration and sharing, dbt for production data modeling.

Impact

→Computation caching that persists across sessions for expensive queries removes
→the re-run wait from the start of every exploration session
→Git integration that works with existing engineering workflows removes the
→parallel version control problem in mixed engineering-analytics teams
→App input components (date pickers, dropdowns, sliders) that update results
→without re-running the full notebook extend self-service to the analysis layer
→Notebook templates for common analysis types (cohort, funnel, revenue) reduce
→the setup time for recurring analytical patterns

Composability Notes

Pairs with `amplitude-primary-user` for the product analytics vs. ad hoc analysis workflow boundary. Contrast with `data-engineer` for the analysis layer vs. data infrastructure responsibility split. Use with `mixpanel-primary-user` for the self-service analytics gap that Hex fills for SQL-native analysts.