Evaluate smart cart idea and design experiment
Company: PayPal
Role: Data Scientist
Category: Analytics & Experimentation
Difficulty: easy
Interview Round: Onsite
##### Question
Instacart is partnering with a local grocery store to introduce a **smart cart** in the physical store. While shopping in the partner store, a customer can use the smart cart UI to:
1. search/browse the **current store's products and in-store prices**, and
2. simultaneously see **products and prices from other nearby stores available on the Instacart app**.
You are a Data Scientist asked to evaluate whether this is a good product idea and to design how you would measure its impact. Assume you can instrument cart events and link them to Instacart account activity, but the feature is only available in some partner stores initially.
1. **Is this a good idea?** State your reasoning, the objective it should serve, and the key risks/tradeoffs.
2. **Hypotheses.** Propose clear, directional, testable hypotheses (primary and secondary) for how the smart cart could impact the business. Include both intended positive effects and potential negative effects (e.g. cross-store switching/cannibalization of the partner store, choice overload, price-perception/trust).
3. **Metrics.** Define a measurement plan with:
- a **primary success metric**,
- **2-4 diagnostic metrics** (to explain *why* the primary metric moved), and
- **1-3 guardrail metrics** (to ensure no harm).
Be explicit about attribution windows and whether outcomes are measured at the trip/store-visit level or the user level.
4. **Experiment design.** Design an A/B test (or alternative) to measure causal impact, covering:
- **unit of randomization** (user, trip, cart, store, store-day/time-block) and why,
- how you would handle **interference/spillovers** (shoppers seeing others use the cart, shared store environment, staff behavior),
- required **logging/instrumentation**,
- **power/MDE** considerations and how you would estimate them, and
- **key threats to validity** (selection bias, noncompliance, novelty, SRM) with mitigations, and how you would make a ship/no-ship decision.
5. **Quasi-experimental fallback.** If you cannot run a clean randomized experiment, propose a credible quasi-experimental alternative (e.g. difference-in-differences or synthetic control) and the key assumptions you would validate.
Quick Answer: A PayPal data science onsite case: evaluate an Instacart smart-cart feature that shows in-store and competitor prices, then form hypotheses, define primary/diagnostic/guardrail metrics, and design a causal experiment. It tests product sense, experimentation design, causal inference, and metric definition, including handling interference via store-level or switchback randomization and a difference-in-differences fallback.