What is a daily active user?

A daily active user is a distinct user who performs a defined qualifying activity within a defined reporting day. Before counting, specify the user identifier, activity, timezone and exclusions. There is no universal rule that every pageview represents an active user.

For this exercise, an active user is an identified account with at least one qualifying product event. The input rows have already been filtered to that event definition. These are synthetic records, not traffic from a real business. This warehouse metric should not be assumed to equal GA4’s product-specific active-user metric.

Why a US dashboard needs a timezone rule

At 00:30 UTC on September 18, it is still September 17 in New York. A dashboard grouped by the UTC date and a dashboard grouped by the New York date can both execute correctly while answering different questions.

Choose one reporting timezone for a shared business dashboard, or explicitly define a user-local-day metric. Do not silently mix local dates across users and call that the same measure. A New York reporting day also does not imply that every user in the report lives in New York.

Store event instants with an unambiguous offset or UTC representation and convert them for reporting. Use named zones such as America/New_York instead of subtracting five hours throughout the year. Offsets can change with daylight saving time. See the PostgreSQL date/time documentation for the distinction between timestamps and timezone handling.

Four events, two users, two reporting days

The exercise contains four events. User u1 generates events at 00:30 and 03:30 UTC on September 18; both fall on September 17 in New York. User u2 generates an event at 04:30 UTC, and u1 returns at 15:00 UTC; those fall on September 18 locally.

• September 17, New York: one distinct active user, u1.
• September 18, New York: two distinct active users, u1 and u2.
• Across both local days: two distinct users, not three.

Adding daily counts produces three user-days. It does not produce a deduplicated two-day audience because u1 appears on both days. Conversely, dividing two weekly unique users by seven would not calculate average DAU.

Run the Python example

This example uses Python 3.9 or later and an available IANA timezone database. Python’s zoneinfo documentation explains the system database and the first-party tzdata fallback. If your environment lacks timezone data, install that dependency through your normal package workflow.

from collections import defaultdict
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

events = [
    ("u1", "2026-09-18T00:30:00+00:00"),
    ("u1", "2026-09-18T03:30:00+00:00"),
    ("u2", "2026-09-18T04:30:00+00:00"),
    ("u1", "2026-09-18T15:00:00+00:00"),
]
zone = ZoneInfo("America/New_York")
users_by_day = defaultdict(set)
for user_id, value in events:
    instant = datetime.fromisoformat(value)
    local_day = instant.astimezone(zone).date()
    users_by_day[local_day].add(user_id)
for day, users in sorted(users_by_day.items()):
    print(day, len(users))

# A local calendar day need not last 24 hours.
start = datetime(2026, 11, 1, tzinfo=zone)
end = datetime(2026, 11, 2, tzinfo=zone)
hours = (end.astimezone(timezone.utc)
         - start.astimezone(timezone.utc)).total_seconds() / 3600
print("Hours in this local day:", hours)
assert [len(v) for k, v in sorted(users_by_day.items())] == [1, 2]
assert hours == 25

Expected output:

2026-09-17 1
2026-09-18 2
Hours in this local day: 25.0

The set removes repeat qualifying events from the same user within one local day. It does not repair a broken identity system: two IDs belonging to one person will still count twice unless you have a justified identity-resolution policy.

The daylight-saving boundary to test

In the example’s New York timezone, November 1, 2026 spans 25 elapsed hours between consecutive local midnights. Calculate each local boundary, convert both boundaries to UTC and filter with an inclusive start and exclusive end. Do not assume every local day is exactly 24 elapsed hours.

When clocks repeat an hour, a bare local timestamp such as 01:30 can be ambiguous. Retaining the original instant or offset avoids guessing which occurrence an event belongs to. The Python example converts from explicit UTC offsets before taking the date.

For a database implementation, compare the timestamp column against precomputed UTC boundaries where appropriate, then inspect the query plan. Date conversion and performance behavior depend on your database, column type and indexes.

Checks before presenting the chart

1. Activity: exclude nonqualifying events and document bot or internal-account rules.
2. Identity: decide how anonymous IDs, signed-in IDs and merged accounts are handled.
3. Boundaries: test events exactly at midnight and immediately before the next midnight.
4. Completeness: distinguish an incomplete day from a zero-activity day. Track late-arriving data and any restatement policy.
5. Comparison: compare complete days under the same definition. Annotate changes to instrumentation or timezone settings.

For a seven-day average DAU, calculate seven complete daily counts, include genuine zero days, sum them and divide by seven. Do not replace missing data with zero just to complete the chart.

How to explain this in an interview

A useful response begins: “I would define a qualifying event and user ID, choose the reporting timezone, then count distinct users within each local-day boundary. I would validate midnight and daylight-saving cases before interpreting growth.” Follow with the small example rather than an unsupported claim about production experience.

Should every global company report in UTC?

No single timezone fits every decision. UTC simplifies shared operational reporting; local business days may fit staffing, sales or market reporting. State the choice in the metric definition.

Are sessions the same as DAU?

No. One user can have multiple sessions or events during a day. Count the unit named in your definition.

Continue with SQL date functions, Python interview preparation and business metric case studies. For practice explaining your reasoning, see interview preparation plans. All sessions and feedback are in English; booking remains coming soon.