learntodriveai.dev/Analytics & BI/Product Performance: Multi-Source Analysis
Analytics & BI·Project 02·5 units

Product Performance: Multi-Source Analysis.

**Track:** Analytics & BI

§ Brief

You're building a multi-source product performance analysis for an organic tea company in Kota Kinabalu, Malaysia — reconciling data from three systems, defining profitability metrics, and identifying which products and channels are actually making money.

The discipline skills: authoring metric definitions from scratch (deciding what "revenue" and "profit" mean for this business), cleaning and reconciling data across three sources with inconsistent product names, iterative exploratory analysis where each finding leads to the next question, and documenting every cleaning decision and its downstream consequences.

The AI-direction lesson: longer sessions can drift, and decisions you set early in a chat may not still be holding twenty turns later. The other lesson is task-sizing: asking AI to "analyze the data and produce a report" gets worse results than focused, sequential requests — profile first, then define metrics, then compute, then chart. The order matters because profiling reveals quality issues that affect every step after it.

Your Role

You're picking up this analysis. Same tools as last time — Claude Code, DuckDB, Jupyter, the analytics stack. Your job is still to direct AI through the work and verify what comes back.

What's different: nobody is telling you what the metrics should be. You write the definitions before any analysis starts. AI handles the computation. You handle the definitions, the cleaning decisions, and the investigation. When AI says it cleaned the data, you check what it actually did — how many rows it dropped and why.

What's New

Last time, everything was provided: analysis spec, metric definitions, chart specs, verification targets, prompts. You focused on the loop itself — profile, compute, chart, verify, communicate.

This time, the brief is clear but the plan is yours. No analysis spec. No metric definitions. No chart types specified. You decide what to define, what to clean, what to compute, and what to show Farid. The data comes from three systems that don't agree on what the products are called, and one of them stores items as free text instead of structured data.

The hard part is the definitions. When you write "channel revenue equals total invoiced amount minus refunds for completed orders," every number in the analysis inherits that decision. If you define it differently, the numbers change and Farid gets a different picture. AI will produce a definition if you ask — syntactically complete and missing the edge cases that matter.

Tools

  • Python 3.11+ (via Miniconda, "analytics" environment)
  • DuckDB
  • Jupyter Notebook
  • pandas
  • matplotlib / seaborn
  • Claude Code
  • Git / GitHub

Materials

  • Three data files — retail sales (POS export), online orders (Shopify export), and wholesale invoices (operations manager's spreadsheet). Each has different columns, different date formats, and different product names.
  • Product catalog — standard product names and cost-per-unit. This is the authoritative reference for reconciling names across the three sources.
  • CLAUDE.md — project governance file with the client context, tech stack, work breakdown, and verification approach.