What data do you need and what steps build a WAU dashboard?

WHAT THIS TESTS: This question tests whether you can decompose a fuzzy product request into a precise metric definition, a sound data model, and a practical BI implementation. The interviewer cares about your ability to reason about event granularity, time windows, deduplication, and the handoff between a data warehouse and a visualization layer. You are expected to show you understand that Weekly Active Users is not just a chart type but a modeling decision.

A GOOD ANSWER COVERS: First, define the atomic event. You need to know the specific feature interaction that counts as active, the user identifier to group by, and the timestamp to filter on. Second, choose the window semantics. A rolling seven-day window counts any user who had at least one qualifying event in the prior seven days from each reporting date, while a fixed calendar week uses Sunday-to-Saturday boundaries. Third, model the data. The canonical pattern is a user-period grain table where each row represents one user and one date, deduplicated so multiple events collapse to a single active flag. Fourth, build the BI layer. In Looker or Tableau you point to the modeled data, create a count-distinct measure on user ID filtered to active_flag equals true, and set the date dimension to the rolling period anchor. Fifth, validate the output by spot-checking a few users against the raw event stream to ensure the rolling logic matches expectations.

COMMON WRONG ANSWERS: A common mistake is to start with the BI tool and describe dragging a user ID onto a canvas without ever defining what event signals feature usage. Another red flag is ignoring deduplication, which inflates WAU when a user triggers the event many times per day. Some candidates also conflate rolling seven-day windows with fixed calendar weeks, leading to inconsistent week-over-week comparisons. Finally, suggesting you query the raw events directly from the BI tool at scale shows a lack of modeling discipline and will cause performance issues.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle late-arriving events or backfills, how to extend the same pattern to daily and monthly active users using the same user-period grain, or how you would optimize the table when the event volume exceeds billions of rows. They might also ask how you would expose this metric to other teams, such as building an exposed Looker Block or a Tableau published data source with certified fields.

ONE CONCRETE EXAMPLE: Suppose you have a tracks table where event_name equals feature_x_used and user_id is a UUID. You build a derived table that selects distinct user_id and date_trunc day timestamp as activity_date from the tracks table where event_name equals the target feature. Then you generate a rolling seven-day spine. For each reporting date, you count distinct user_id from the derived table where activity_date is between reporting_date minus six days and reporting_date. In Looker, you model this as an explore with a dimension on reporting_date and a measure type count_distinct on user_id. You add a sql_where clause to restrict to the feature event. The dashboard shows a daily line chart of that measure, and you validate it by picking a single user and manually verifying their event dates fall inside the rolling window.