Business Context

TaskRabbit operates a two-sided local services marketplace (home cleaning, furniture assembly, moving help) across ~60 metro areas in the US/Canada, with ~3M monthly active visitors and ~250K monthly completed tasks. Revenue is primarily driven by a service fee applied to the task price (plus occasional promotions). Leadership is considering a pricing model change to improve monetization without harming booking volume or marketplace health.

You are the analytics lead supporting a proposal to change the pricing model shown to clients at checkout. Today, clients see an hourly rate set by the Tasker plus a separate service fee line item. The proposed model bundles the service fee into a single “all-in hourly price” (and slightly adjusts the effective take rate). Product’s hypothesis: simplifying price presentation will reduce checkout drop-off and increase completed tasks, ultimately increasing TaskRabbit revenue.

Metric Scenario

Stakeholders disagree on what “success” means:

• Finance cares about net revenue (service fees collected minus refunds/credits and payment processing costs).
• Marketplace Ops worries higher all-in prices may reduce demand, causing Taskers to churn or multi-home.
• Support expects pricing confusion could increase disputes, refunds, and chargebacks.

You have 6 weeks to run an experiment and make a ship/no-ship recommendation for a Q2 rollout. The experiment must be safe across metros with different competitive intensity and different baseline price levels.

Available Data

What You Need to Produce

1. Experiment design: Define unit of randomization (client, request, or metro), treatment/control experiences, eligibility rules (new vs returning clients, categories), and how you will prevent interference (e.g., clients shopping across devices; Taskers seeing different demand).
2. Primary KPI definition: Choose a single primary metric that best captures “TaskRabbit revenue impact” and define it precisely (gross vs net, time window, inclusion/exclusion rules).
3. Metric suite: Specify leading indicators and guardrails across the funnel (quote → booking → completion → payment) and across marketplace health (Tasker utilization, cancellations, disputes).
4. Decomposition plan: Explain how you will break down results to diagnose why revenue moved (price perception vs conversion vs task duration vs refunds).
5. Decision framework: Provide explicit ship/no-ship criteria (minimum detectable lift, acceptable guardrail degradation thresholds) and how you will handle heterogeneous effects (by metro, category, device).

Constraints / Nuances

• Some clients request multiple quotes before booking; pricing is shown multiple times.
• A booking can be scheduled weeks in advance; revenue realization lags.
• Taskers may adjust their base hourly rate in response to observed demand over time.
• Promotions are common and may interact with perceived price transparency.

Your answer should be concrete enough that an experimentation engineer could implement assignment and an analyst could compute the metrics without ambiguity.