Articles
Marketplace Product Analyst Interview Cases: Liquidity, Matching, and Supply Constraints
Prepare for marketplace product analyst interviews with worked liquidity cases, matching diagnostics, supply constraints, and experiments with network effects.
Marketplace product analyst interview cases require you to look beyond one aggregate funnel. A buyer needs a suitable seller at the right time, place, price, and capacity. More traffic can increase completed transactions while making the average buyer's experience worse.
The central task is to locate the constraint before recommending growth. Define a demand opportunity, trace it through matching and completion, and examine the supply that was actually feasible for that opportunity. Then connect the diagnosis to an experiment and an economic decision.
Evidence boundary: Official engineering articles and primary research support the experimentation principles below. No verified candidate report establishes this exact case or an employer's rubric. All numbers, diagnoses, and answer recommendations are original practice material. For event-grain foundations, use the related Product Analyst SQL case.
What does liquidity mean in this case?
Begin with the service being exchanged. In a home-repair marketplace, a customer might need a qualified plumber tomorrow morning within a travel radius. Ten thousand registered providers nationally say little about whether that request can be fulfilled.
Original metric definition: Define buyer liquidity as the probability that a qualified service request receives an acceptable match within its promised response window. Separately track completed jobs per qualified request. A match can fail later through cancellation, no-show, or payment failure.
Ask whether the denominator includes requests rejected as unserviceable. Excluding every request with zero eligible providers can make liquidity look excellent while hiding the largest customer problem. Show both total qualified demand and the serviceable subset, with a written eligibility rule.
For the supply side, use available provider-hours, feasible offers, accepted jobs, completed jobs, and earnings per available hour. Registered accounts and logged-in accounts are not interchangeable with usable capacity. A provider already booked, too far away, or lacking the required certification is not available for that request.
Your first response could be: “I would define the service, geography, time window, and acceptable match, then measure unmet requests alongside idle feasible capacity. That tells us whether to add supply, improve allocation, or reduce friction after acceptance.” This gives the interviewer a decision structure rather than a list of marketplace vocabulary.
Can completion fall while both regions improve?
Original case: A platform expands marketing outside its downtown core. Compare two equal-length periods. Each request is counted once, each has a mature completion window, and the geographic assignment is based on the requested service location.
| Region | Period 1: requests → completions | Period 2: requests → completions |
|---|---|---|
| Downtown | 800 → 720, or 90% | 400 → 368, or 92% |
| Outer zone | 200 → 100, or 50% | 800 → 440, or 55% |
| Total | 1,000 → 820, or 82% | 1,200 → 808, or 67.3% |
Downtown improves by two percentage points. The outer zone improves by five. Yet the overall rate drops by about 14.7 points, and completed jobs fall from 820 to 808. Most new demand arrives where fulfillment is weaker.
Now hold the original demand weights fixed. Period 2's standardized completion rate is 0.8 × 92% + 0.2 × 55% = 84.6%. Relative to the original 82%, that is a 2.6-point improvement in within-region rates under the old mix.
The remaining difference between 84.6% and the observed 67.3% reflects changing weights under this chosen decomposition. It is descriptive, not proof that marketing caused the shift or that the matching algorithm improved. Different decomposition conventions can allocate interaction terms differently; state which weights you use.
The recommendation is therefore narrower than “roll back the algorithm.” Investigate outer-zone capacity, acquisition targeting, and promises shown before booking. Keep the within-region improvement and aggregate deterioration visible together. One summary metric cannot answer both operational performance and portfolio mix questions.
An interviewer may ask whether 808 completions is acceptable if revenue rose. Ask about job value, platform margin, customer acquisition cost, and repeat use. A higher-priced mix might support revenue while disappointing more requesters. The business decision needs both economics and customer outcomes.
Is the bottleneck supply or matching?
Follow the request through observable states. Did it have any feasible providers? Did eligible providers receive offers? Did someone accept? Did the accepted job finish? Use timestamps and stable request identifiers to distinguish an absent event from an event that has not arrived yet.
Original diagnostic map:
| Observed pattern | Next evidence to inspect |
|---|---|
| Few requests have any feasible provider | Coverage, schedules, certification, travel radius |
| Feasible providers exist but receive no offer | Dispatch eligibility, ranking, delivery logs |
| Offers arrive but acceptance is low | Compensation, distance, workload, offer clarity |
| Acceptance is healthy but completion is low | Cancellations, no-shows, coordination, payment |
These are hypotheses, not automatic diagnoses. Low acceptance can mean unattractive compensation, stale availability, or a notification defect. Interview answers become stronger when each hypothesis has an observation that could disprove it.
Consider 100 unfilled outer-zone requests. Suppose 70 had no feasible provider at request time, while 30 had at least one feasible provider who never accepted. Improving ranking alone cannot create capacity for the first 70 under the current service constraints. But recruiting more providers may waste money if the remaining 30 are mainly lost to delayed notifications.
Check whether “feasible” is trustworthy. If provider calendars update only nightly, a database match may not represent real availability. Sample request histories with operations and compare logged eligibility with provider behavior. A neat dashboard built on stale calendars can produce a precise but wrong recommendation.
Also inspect time-to-match as a distribution. A median can improve while a long tail exceeds the promised response window. Report the fraction matched within that window and a relevant upper percentile, with unmatched requests handled explicitly rather than silently dropped.
How do you measure the seller-side consequence?
A buyer intervention redistributes opportunity. A ranking change that raises total matches may concentrate jobs among a small group of providers, increase travel, or reduce new providers' chance to establish a history.
Editorial recommendation: Pair the primary buyer outcome with provider utilization, earnings per available hour, acceptance, cancellation, and retention. Segment by tenure and geography when there is a mechanism worth testing; do not mine dozens of segments solely to find an encouraging result.
Define utilization carefully. If completed work occupies 300 of 500 genuinely available provider-hours, utilization is 60%. Dividing by 1,000 registered-provider hours that were never available answers a different question. Travel and unpaid waiting may matter for earnings even when they are excluded from productive service time.
High utilization is not an unconditional target. At very high load, a small demand spike can create long waits and missed promises. Conversely, buying idle supply everywhere can protect availability while destroying contribution margin. The analyst must identify where extra capacity has the greatest expected value.
For a supply incentive, distinguish newly available hours from hours moved from neighboring districts or time slots. Suppose an outer-zone bonus adds 100 hours locally but removes 80 downtown. The platform gained only 20 hours overall, and the reallocation may harm higher-value requests. Measure displacement, not just the rewarded area's gross increase.
A short follow-up answer is: “I would evaluate incremental completed jobs and provider earnings after incentive cost, while checking adjacent cells for lost capacity. The bonus is useful only if its total effect beats a cheaper allocation or promise-setting change.”
How would you test a marketplace intervention?
Start with the interference mechanism. If treatment requests get priority access to a shared provider pool, control requests may be pushed back. A user-level difference then need not equal the effect of giving the policy to the entire market.
Primary research: Holtz and coauthors study interference in marketplace pricing experiments and compare individual and clustered assignment. Their findings support taking marketplace connections seriously; they do not establish one universal bias percentage or optimal design for every marketplace. Reducing Interference Bias in Online Marketplace Pricing Experiments.
Official engineering example: DoorDash describes switching treatment across geographic regions and time windows to study changes affected by network effects. This documents an experimentation approach, not DoorDash's current interview process. DoorDash's switchback explanation.
For our home-repair case, choose the design based on how long effects last. A notification-routing policy might be reversible quickly. Recruiting providers or changing their expectations can persist for weeks, so rapidly alternating treatment may be inappropriate. A geographic cluster design may be more credible if clusters capture meaningful provider competition, though cross-border work still needs measurement.
State the estimand: the total effect on completed qualified requests per market-period, or another explicit business outcome. Predefine assignment, exposure, maturity windows, exclusion rules, and analysis. Account for the randomization unit when estimating uncertainty; thousands of request rows do not create thousands of independent market assignments.
For time-based designs, check carryover and calendar balance. Do not assume alternating every hour makes treatment random. The related switchback interview guide develops those design and inference questions in more depth.
What recommendation would you present?
Present the diagnosis, the intervention it supports, and the uncertainty that could change your decision. For the synthetic case: “Overall completion fell mainly because demand shifted toward the outer zone. Both regional rates improved, so the aggregate alone does not establish a matching regression. I would first validate the geographic mix and provider-availability logs, then target the largest verified source of unfilled requests.”
Name the intervention conditionally. If zero-feasible-provider requests dominate, test a limited supply expansion or reduce acquisition in unsupported windows. If feasible capacity exists but offers fail, test dispatch or offer improvements. If accepted jobs fail, investigate post-match coordination before buying more traffic.
Specify a rollout criterion before results arrive: an economically meaningful improvement in completed qualified requests, acceptable wait and cancellation outcomes, no material neighboring-market harm, and positive incremental contribution after incentives. Include uncertainty and a mature follow-up window for repeat demand.
Do not promise that a short experiment measures the new equilibrium. Providers may change schedules, buyers may learn different expectations, and competitors may respond. Distinguish the observed short-run result from a longer-run forecast and define what continued monitoring would resolve.
Rehearse the separate analytical decisions
| Practice question | What to rehearse |
|---|---|
| Evaluate a Bike-Delivery Pilot with Marketplace Metrics | Separate demand growth from capacity available to fulfill it. |
| Measure a Discovery Boost in a Two-Sided Marketplace | Ask whether shared supply changes the control experience. |
| Turn a Marketplace Data Insight into an Actionable Product Plan | Tie one observed bottleneck to a falsifiable intervention. |
| Define Marketplace Success Metrics and Investigate Their Movement | Define buyer and provider denominators before diagnosis. |
| Design DoorDash Marketplace Experiments | Defend the randomization unit under marketplace interference. |
Recompute the geographic example, then explain which extra observation would make you choose supply incentives over matching changes. If your recommendation stays the same regardless of that observation, it is probably too generic.
Sources and Further Reading
- Holtz and coauthors: Reducing Interference Bias in Online Marketplace Pricing Experiments — primary field-experiment research.
- DoorDash: Switchback Tests and Randomized Experimentation Under Network Effects — official engineering explanation.
- DoorDash: Experiment Rigor for Switchback Experiment Analysis — official discussion of assignment and dependent observations.
Research checked September 21, 2026. The case's definitions and thresholds are illustrative; actual marketplace contracts and experimental constraints vary.