# Metric definition: one rule, one number

> How to write a metric definition so two people get the same number: qualifying event, unit, exclusions, time window and time zone, on a DAU example.

- Course: [Product Analytics: From Data to Decisions](https://productovi.com/courses/product-analytics.md)
- Module: What exactly are we measuring?
- Lesson 3/32, ~31 min
- Source: https://productovi.com/courses/product-analytics/metric-definitions

## Two DAU numbers for one Wednesday

**Alex Tutor:** At Halves, two teammates bring you the same question with different answers. You're the one who answers from the data.

**Maya:** Quick one for Thursday's update: how many active users did Halves have on Wednesday, 3 June? My dashboard says **6**.

**Theo:** Mine says **7**. Same app, same Wednesday. I'd like to know which one goes to the board.

**Sofia:** One of the queries must have a bug. Should I find out whose?

**Alex Tutor:** Probably neither. They answered two different questions that share a name. “Active users on Wednesday” sounds exact, but it's a label, not a metric definition.

**Alex Tutor:** Maya's dashboard counts anyone with any event on the UTC date. Theo's sheet counts app opens on each user's local date. Neither removes staff accounts.

![Two colleagues measure the same parcel side by side, one with a wooden ruler, the other with a tape, and look at each other puzzled.](https://productovi.com/courses/product-analytics/inline/metric-definitions-illustration-2.webp)

*Same label, different rules: two honest counts that can't match.*

**Sofia:** So before asking who's right, I ask what each of them counted.

> **Exercise:** “Active users on Wednesday” leaves several questions open. Which of these must a written definition answer? Select all that apply.

## What a metric definition contains: five parts

**Alex Tutor:** A **metric definition** that nobody can misread has five parts. It works the same for any product metric, from DAU to settlements. Each part hides a trap we've met in the Halves data.

**Alex Tutor:** **1. Qualifying action:** which event makes someone count. For “active”, take `app_opened`, not any event. Recurring bills are **server-side events**, so three users look active without touching their phones.

**Alex Tutor:** **2. Unit counted:** distinct users, groups or settlements. Both sides log a settle-up, so settlements are distinct `settlement_id` values, not rows.

**Alex Tutor:** **3. Exclusions:** staff, QA and test accounts. **4. Time window:** a day, seven days or a month, with its exact start and end. **5. Reporting time zone:** whose clock decides the date, UTC or the user's.

![A long receipt clipped to a board, with five small icons down its side: a tapping hand, a person, a crossed-out badge, an hourglass and a globe.](https://productovi.com/courses/product-analytics/inline/metric-definitions-illustration-3.webp)

*Five parts make a metric definition nobody can read two ways.*

**Sofia:** About staff: one QA account had an empty `is_internal`, didn't it?

**Alex Tutor:** Yes, u002. So the rule says how to find staff: `is_internal = true` **or** `acquisition_channel = staff`. A rule that trusts a half-filled flag is still vague.

> **A definition template**
>
> **Name:** daily active users (DAU)
>
> - **Qualifying action:** `app_opened`
> - **Unit counted:** distinct `user_id`
> - **Exclusions:** `is_internal = true` or `acquisition_channel = staff`
> - **Time window:** one calendar day, 00:00 to 23:59
> - **Reporting time zone:** UTC

> **Exercise:** Match each part of a metric definition to its example from Halves.

**Alex Tutor:** The time window looks like the easiest part, and it's the one teams get wrong most quietly. Try this one.

> **Exercise:** Maya wants weekly active users for the week of 1–7 June in Thursday's update. Which time window belongs in the definition?

## Recounting Wednesday in UTC

**Maya:** Fine, let's fix it. Real people, app opened, Wednesday 3 June. What's the number?

**Alex Tutor:** Two files. The users table has each person's time zone and staff markers. The event log runs from noon 2 June to noon 4 June UTC, which covers Wednesday in every time zone our users live in.

**Dataset (CSV):** [Halves users, first week of June](https://productovi.com/datasets/product-analytics/metric-definitions/halves-users-week-1.csv)

All 22 accounts that have any event in the week of 1–7 June 2026.

- `user_id`: User id
- `signup_date`: Sign-up date
- `platform`: ios or android
- `acquisition_channel`: Where the user came from; `staff` marks team accounts
- `timezone`: The user's time zone
- `is_internal`: Internal-account flag: true, false or empty (not always set)

**Dataset (CSV):** [Halves events, noon 2 June to noon 4 June (UTC)](https://productovi.com/datasets/product-analytics/metric-definitions/halves-events-2-4-june.csv)

42 events from the week's log. Times are UTC.

- `event_time`: When it happened, UTC
- `user_id`: Who did it
- `event`: Event name
- `platform`: ios, android or server
- `entry_method`: How an expense was entered
- `amount_usd`: Amount in USD
- `settlement_id`: Which settlement a settle-up belongs to

**Alex Tutor:** Start with UTC, the date exactly as written in `event_time`. Keep only `app_opened`, drop the two staff accounts and count distinct `user_id` on 2026-06-03.

**Sofia:** Distinct users, so someone who opened the app twice still counts once.

> **Exercise:** Every `app_opened` event Halves logged from 20:00 on 2 June to 04:00 on 4 June (UTC):
>
> | event_time (UTC) | user_id |
> |---|---|
> | 2026-06-02 20:50 | u020 |
> | 2026-06-02 23:10 | u012 |
> | 2026-06-02 23:14 | u010 |
> | 2026-06-03 02:30 | u011 |
> | 2026-06-03 07:14 | u002 |
> | 2026-06-03 07:53 | u019 |
> | 2026-06-03 09:19 | u002 |
> | 2026-06-03 09:37 | u019 |
> | 2026-06-03 10:02 | u004 |
> | 2026-06-03 15:46 | u018 |
> | 2026-06-03 16:39 | u021 |
> | 2026-06-04 01:40 | u017 |
> | 2026-06-04 02:31 | u008 |
>
> Two of these are staff accounts: u002 (`acquisition_channel = staff`, `is_internal` empty) and u019 (`is_internal = true`). How many real users (both staff accounts excluded) opened the app on 2026-06-03 by **UTC date**?

## The same Wednesday on the user's clock

**Theo:** My ads run per country, so I read days the way people live them. A New Yorker opening the app at 10 p.m. on Tuesday is a Tuesday user to me.

**Alex Tutor:** A fair choice. In June, New York is UTC−4, Lisbon UTC+1, Kyiv UTC+3 and Bangkok UTC+7. Add the offset to `event_time` and take the date from the result.

**Sofia:** So a late-evening UTC open in Bangkok is already the next morning there?

**Alex Tutor:** Yes, and an early-morning UTC open in New York is still the evening before. That's where this week's travelers slip from one day to another.

![A globe ringed by clocks at different hours, half in night shade; a traveller with a suitcase steps from the night side into the morning.](https://productovi.com/courses/product-analytics/inline/metric-definitions-illustration-4.webp)

*The same moment can fall on different dates on different clocks.*

> **Exercise:** Use the users file and the event log, exclude the staff accounts u002 and u019, and take the day as the **user's local date** (New York UTC−4, Lisbon UTC+1, Kyiv UTC+3, Bangkok UTC+7). How many real users opened the app on 3 June?

**Alex Tutor:** Before we blame anyone's query, reproduce Maya's 6 from the file. Start with what her dashboard actually scanned.

> **Exercise:** Maya's dashboard counts **any event**, by **UTC date**, with **nobody excluded**. How many event rows in the file are dated 2026-06-03 in UTC? (Her 6 users come from these rows.)

## UTC or local time: which DAU to report?

**Maya:** So it's 4 or 5. Which one goes in the update?

**Alex Tutor:** Either, if the rule is written next to the number and never changes quietly. Most teams report in UTC so every chart splits days the same way; local days suit questions about daily habits.

**Alex Tutor:** What breaks trust is 6 on one slide and 7 on the next. And both of those also counted the QA team.

**Theo:** Same story for the week, then. I've seen 22, 19, 18 and 17 weekly active users for 1–7 June.

**Alex Tutor:** Four definitions, four numbers. Only one is our DAU rule stretched to a week.

> **Exercise:** Theo has four weekly numbers for 1–7 June (UTC): 22, 19, 18 and 17. Which definition gives **17**, the agreed weekly active users?

**Alex Tutor:** One more trap, about time rather than counting: what happens when someone improves a definition halfway through a quarter?

> **Exercise:** **True or false:** Halves can switch DAU from UTC dates to local dates from 1 July, and the DAU chart for the year stays comparable, as long as the new rule is written in the definition.

## Where to document metric definitions

**Sofia:** Where should the definition live, so Maya doesn't have to ask us every Thursday?

**Alex Tutor:** Under the chart as a caption, and in the **tracking plan**, the document that lists what we log and why. That's the next lesson. The rule for today: no number without its written definition.

**Maya:** Then I want one for settling up. How many people actually settle their debts each week?

**Alex Tutor:** Good test. Write it with all five parts, and decide what happens when both sides log the same settle-up.

> **Exercise:** Write a complete definition of **weekly settling users** for Halves, in 3–6 lines. Cover the qualifying action, the unit counted, exclusions, the time window and the reporting time zone, and say what happens when both sides log the same settle-up.

**Alex Tutor:** So, Wednesday: 4 real users opened Halves by UTC date, 5 by local date. Both are correct. Only a number without a definition is useless.

- Previous lesson: [Totals, unique users and counting traps](https://productovi.com/courses/product-analytics/counting-traps.md)
- Next lesson: [A tracking plan for a new feature](https://productovi.com/courses/product-analytics/tracking-plan.md)

---
Productovi Learning. Free, no sign-up needed to read.