Metrics and Stakeholder Dashboards for a Store-Page Most-Ordered Items Feature

You are interviewing for a data analyst role on the team responsible for stores at a food-delivery marketplace. In a case interview you are given one of the team's new features and asked to work through two things: how you would define the metrics that show whether the feature is working, and how you would build a dashboard for the different stakeholders who care about it. The report does not name the feature; it says only that the questions centered on the team's new features. So that the metrics can be concrete, this version assumes the feature is a new section at the top of each store's page in the customer app that lists that store's most-ordered items. Customers can tap an item in the section to view it or add it to their cart. ### Clarifying Questions - What is the feature meant to achieve: more orders, faster ordering, larger baskets, or easier choices for customers new to a store? - Is the feature fully launched, or rolling out behind an experiment with a holdout? - How is "most-ordered" computed: over what time window, and is the list the same for every customer or personalized? - Which stakeholders will use the dashboard, and what decisions do they make with it? - Will merchants see any of these numbers, or is the dashboard internal only? ### Part 1 — Define the metrics Define a goal metric, the supporting metrics that explain it, and the guardrails. Give precise definitions (unit, numerator, denominator, time window) for the most important ones, and explain how you would tell whether the feature itself caused any change. ```hint Who could be affected A store visit where the section never appeared cannot be changed by it. Ask which visits belong in your denominators, and whether the answer differs between customers who get the feature and those who do not. ``` ```hint Moving orders around A popular-items list can help customers order the same things faster without ordering more, and it can pull sales toward a few items. Ask what you would measure to see each of those. ``` #### What This Part Should Cover - A goal metric tied to the feature's purpose, with an exact definition - Funnel and diagnostic metrics from store visit to order - Guardrails for customers, merchants and the platform, including items the section does not show - How the metrics separate the feature's effect from other changes ### Part 2 — Build the dashboard for different stakeholders Design the dashboard or set of views: who uses each view, what decision it supports, which metrics and cuts it shows, how often it refreshes, and how you keep the numbers consistent across views. ```hint Start from the decision A leader, a product manager and a merchant-facing team ask different questions of the same numbers. Ask what each of them will do differently after looking at the dashboard. ``` #### What This Part Should Cover - Views tailored to each stakeholder and the decision each supports - Shared metric definitions, the underlying data model and refresh cadence - Comparisons, cuts and alerts that make movements interpretable ### What a Strong Answer Covers - Metrics that follow from the feature's purpose rather than a generic engagement list - Exact definitions with denominators that keep treated and untreated customers comparable - Guardrails that catch cannibalization, item concentration and product health problems - A clear line between descriptive dashboard trends and causal evidence from a holdout or experiment - Stakeholder views built on one consistent metric layer, with data-quality monitoring ### Follow-up Questions - Store conversion rose after launch. How would you show whether the feature caused it? - A merchant complains that the section always shows the same few items and their new menu items are not selling. What would you look at, and what would you suggest? - The goal metric drops sharply one day on the leadership view. How do you triage it? - How would your metrics change if the section were personalized for each customer?