"What metric would you use to decide this test, and what else would you watch?" is usually the first question in an experiment case, right after you state the hypothesis. Choosing experiment metrics means deciding, before an A/B test starts, which single number decides whether the change ships, which numbers can only block it, and which numbers only explain why the deciding one moved. You pick among metrics the company already tracks.

When the goal can be measured within the test window, one primary metric and a couple of guardrails are enough. You need a surrogate, a short-term metric that stands in for the goal, only when the goal takes months to measure. If treatment can change a ratio's denominator, as with revenue per order, check its per-user version before using the ratio to make a decision. Designing a company-wide north-star metric is product analytics work and is not covered here.

The running example is an online grocery delivery app with about 400k weekly active users. It is testing a "Buy it again" carousel on the home screen that lists items each user ordered before. Users are randomized by user identifier (ID), 50/50, and the business goal is more repeat ordering and better long-term retention. Today users place about 1.2 orders per week at about $54 per order.

How deep you need to go depends on the round. In a mid-level round, committing to one sensible primary metric and naming a few guardrails is a strong answer. In a senior round, the interviewer will push further: why not a faster metric, how you would measure a goal that takes 90 days to show up, and whether a drop in a ratio like revenue per order means the change hurt the business.

This section assumes you already have a written hypothesis and a randomization unit from Experiment Design. Everything here starts from that point and ends before sample size and analysis.