Product Usage Analytics Demo

Usage metrics that mean one thing

A small dashboard that validates raw event logs first, then turns them into daily activity, module usage and an ordered funnel, each with its definition written down.

My role
Requirements, edge cases and approvals; AI tools did the implementation
Built with
Python, pandas, Streamlit, Altair
Data
5,766 fictional event rows over 28 days
Source on GitHub

Raw clicks in. Clear answers out.

Before and after. Before: rows from the fictional event log, with time, user, module and action, fading into “5,766 rows like these”. After: a dashboard showing 175 users in scope, 1,520 sessions and 619 full-funnel sessions, with a September daily active users chart where weekends are shaded.
Redrawn from this project’s fictional event data; the rows and numbers are real, the layout is simplified.

The situation

“How many people use the product?” sounds like one question. Daily users, total events and funnel progress give three different answers, and a duplicated or malformed event can quietly change all of them.

This project explores that problem with 28 days of fictional events from an invented B2B web app.

Where this comes from

I expanded live administrator reporting for an industrial B2B business platform to track adoption by role and organization, weekly retention and storage growth, while distinguishing frontend reporting needs from backend data requirements.

Three decisions that shape it

  1. Validate the whole file before any filter.

    Exact duplicate events collapse to one, conflicting copies are quarantined and rows with missing or invalid fields are rejected, all before any date or module filter is applied. Changing the view never changes what counts as valid data.

    File-wide validation; every raw row gets exactly one outcome.

    Illustration: all modules for September 1–28 show 5,735 events and catalog for one week shows 480, but the 31 rows not counted stay the same under any filter, because validation runs on the whole file first.

  2. Write down every denominator.

    Daily active users are distinct people per day, not the sum of each module’s users, and module share is a share of events, not of people. Each chart states what it counts, and a rate shows N/A instead of a misleading zero when there is nothing to divide by.

    Distinct users, events and sessions kept separate; N/A for empty denominators.

  3. Count a funnel step only if it happens later.

    A session reaches the next step only when that action happens strictly after the previous one. Repeated clicks don’t count twice, and two actions in the same second don’t prove an order.

    Session = a (user, session) pair; strictly increasing timestamps.

The result

Of 5,766 raw rows, 5,735 are valid and every other row is accounted for: 10 duplicate copies collapsed, 8 quarantined and 13 rejected. In September, 1,357 sessions opened a page, 844 then searched and 619 then viewed a detail: 46% of the sessions that opened a page.

Fewer than half of page-opening sessions reach a detail view

Ordered session funnel for synthetic events: 1,357 page-view sessions, 844 sessions with a later search and 619 with a later detail view.
SYNTHETIC RESULT The funnel uses distinct (user_id, session_id) pairs and strictly increasing event timestamps. It is not a user-level conversion rate.

What I’d do next

Let users choose the funnel steps and add sessions based on inactivity, so the same definitions can answer more questions.

Technical notes

  • Every raw row has exactly one outcome: 5,766 raw = 5,735 valid + 10 collapsed + 8 quarantined + 13 rejected.
  • Timestamps must be YYYY-MM-DDTHH:MM:SSZ in UTC with ASCII digits; other offsets are rejected, not converted.
  • Date filters include the start date from midnight UTC and stop at midnight after the end date.
  • The metric code has no Streamlit dependency, so another interface could reuse the same definitions.
  • A seeded generator produces byte-identical data on every run; 44 pytest tests, including headless dashboard runs.

From raw events to defensible metrics

Synthetic telemetry pipeline diagram: 5,766 raw rows are validated file-wide; 5,735 valid events feed the usage metrics and 31 are excluded (10 identical copies collapsed, 8 conflicting, 13 invalid).
SYSTEM / MODEL File-wide validation precedes date and module filters; invalid or conflicting events do not enter the usage metrics.

Full definitions, tests and run instructions on GitHub

My role

I co-developed the original agent prompt kit for this project with AI assistance, and I provided the business context, project purpose and initial architecture outline. I set requirements, evaluation criteria, edge-case priorities and approval decisions.

I used a planner-and-builder AI workflow to produce the implementation and supporting documentation. AI tools performed the implementation work, while I remained responsible for the project's direction and final approvals.

During the first review round, I personally followed the project's run-and-check instructions in PowerShell and confirmed that the outputs matched the agents' reports. Later corrections and their regression results were verified by agents.

What I learned

I learned to connect a metric to the administrator's question before choosing a chart. Distinct users, event volume and funnel progression describe different aspects of activity. Clear populations, time windows, denominators and data-quality diagnostics help administrators interpret those numbers and decide what to investigate next.

How these were built

Academic connections

These are conceptual connections to the reasoning described in Applied Thinking. They do not claim formal implementation of every theory.