Introduction to Analytics & BI

What analytics practitioners actually do

Analytics is the bridge between data and business decisions. The work isn't about building models or engineering pipelines. It's about understanding what the data says and communicating it in a way that helps people act. Here are the main roles:

Business Analyst. Answers questions from the business. "Why did revenue drop last quarter?" "Which customer segment is growing fastest?" "What happened after we changed the pricing?" Works with SQL, dashboards, and spreadsheets to find and present answers.

Product Analyst. Focuses on how users interact with a product. Funnel analysis, feature adoption, retention, conversion. Designs and reads A/B tests. Works closely with product managers and engineers.

Data Analyst. The broadest title. Combines elements of business and product analysis. Builds dashboards, writes reports, defines metrics, runs ad-hoc analyses. At many companies, this is the entry-level analytics role.

Analytics Engineer. Sits between data engineering and analytics. Builds the data models (in dbt, typically) that analysts query. Defines metrics in a semantic layer so everyone uses the same numbers. A newer role that's growing fast.

These roles overlap. At a small company, one analyst does all of it. The underlying workflow is the same.

The professional loop

Every analytics project, whether it's a dashboard, an ad-hoc analysis, or an A/B test readout, moves through the same cycle:

1. Stakeholder problem and question framing. What does the business need to know? The hardest part of analytics isn't the SQL. It's understanding what the stakeholder actually needs, which is often different from what they asked for. "Can you pull the revenue numbers?" might really mean "I need to know whether the pricing change is working."

2. Metric definition and alignment. What are we measuring, and does everyone agree on how? "Revenue" can mean gross, net, recognized, or booked, and different teams often use different definitions without realizing it. Getting metrics right before doing analysis prevents the worst kind of error: a correct analysis of the wrong number.

3. Data acquisition and quality assessment. Where does the data come from? Is it complete? Is it trustworthy? A dashboard built on incomplete data is worse than no dashboard. It creates false confidence.

4. Exploratory analysis. What patterns exist? What's surprising? What deserves a closer look? This is insight discovery, finding the story in the data before formalizing it.

5. Visualization and dashboard design. How do you present what you found? Information hierarchy, chart selection, drill-downs, accessibility. A good dashboard answers the stakeholder's question at a glance. A bad one requires a 30-minute walkthrough.

6. Narrative and recommendation delivery. Translate findings into something the stakeholder can act on. Executive summaries, slide decks, written reports. Communicating uncertainty honestly, saying "we're 80% confident" rather than presenting estimates as facts.

7. Experimentation and impact measurement. Did the change work? A/B tests, pre/post analysis, impact measurement. This is where analytics proves (or disproves) whether a decision had the intended effect.

You'll run this loop in every project. What changes is the complexity: early projects give you clean data and a clear question. Later projects give you conflicting stakeholder needs, messy data, and metrics that nobody has defined yet.

What you'll work on

Each project is built for a client with a specific problem. You'll direct AI to query data, build dashboards, define metrics, and run analyses, then verify whether the numbers are right and the presentation is honest. Here's a sample:

• A dashboard that shows a client their key business metrics at a glance
• A metric definition project that gets multiple teams on the same numbers
• An ad-hoc analysis that explains why a KPI changed unexpectedly
• A visualization that communicates a complex finding without misleading
• An A/B test readout that determines whether a change had a real effect
• A stakeholder presentation that translates technical findings into business recommendations

The projects get harder in specific ways. The questions get vaguer. The data gets messier. The stakeholders start disagreeing about what to measure. You move from answering questions to framing them. And throughout, AI is your primary tool, capable at writing SQL and building charts, but prone to subtle analytical mistakes that you'll learn to catch.

Core tools

These are the tools analytics practitioners use daily. You'll set up the core ones in the track setup; the rest are introduced as projects need them.

Terminal. Your command line. Everything runs through it.

Claude Code. Your AI coding agent. You'll direct it to write SQL, build analyses, create visualizations, and produce reports. It's strong at generating queries, and it makes specific, predictable mistakes with aggregation and metric logic that you'll learn to catch.

Git and GitHub. Version control. Every project lives in a repository.

Python. Used for analysis, statistical testing, and scripting. Not as central as in ML or data science, but present throughout.

DuckDB. A fast, local SQL database. You'll run queries against it directly, no server setup needed. The standard analytical database for this track.

Jupyter notebooks. Interactive documents for exploration and analysis.

pandas. Data manipulation in Python. Loading, cleaning, transforming.

matplotlib, seaborn, and plotly. Visualization libraries. Static charts (matplotlib/seaborn) and interactive charts (plotly).

Metabase. An open-source BI platform. You'll build dashboards and reports in it. The hands-on tool for learning dashboard design.

scipy and statsmodels. Statistical testing. Used for A/B test analysis, significance testing, and experimentation.

You'll install additional tools as the track progresses: dbt for data modeling, GrowthBook for experimentation, Tableau for industry exposure, and others. Each project tells you what's needed.