Quick Commerce Analyst career guide

• Grocery delivery marketplace (Instacart-shape)

  Shopper picks from a partner store, substitutions are central (out-of-stock items get swapped at the shelf). The analyst owns substitution economics, basket composition, and the three-sided fee split. Heavy emphasis on GMV integrity and merchant relationships.

• Restaurant / prepared-food delivery (DoorDash / Uber Eats-shape)

  Less substitution, more dispatch and batching logistics. The analyst owns courier batching efficiency, surge pricing, delivery-time SLAs, and merchant acquisition / churn. Tip allocation and the dasher / courier P&L dominate.

• Convenience / q-commerce (Gopuff, Getir-style dark stores)

  Platform-owned micro-fulfillment, so the "merchant" is internal and the model collapses toward two-sided. The analyst focuses on shopper batching, delivery-zone economics, and inventory at the dark store. Faster delivery promise (10–20 min) raises the SLA bar.

• Marketplace strategy / finance team

  Sits closer to corporate finance. Owns the three-sided P&L, contribution-margin bridges, take-rate analysis, and board reporting. Less event-level SQL, more multi-CTE reconciliation and scenario modeling.

• Platform data / experimentation team

  Data engineering, the dbt event ledger, and the A/B platform behind surge, substitution policy, and batching algorithms. Adjacent to the business-analyst role but modeling-layer focused — a strong path for analysts who want to own the metric definitions.

1. 1

   Recruiter screen (30 min)

   Fit check. Be ready to explain why quick-commerce / marketplace specifically (vs retail, vs DTC). Grocery-delivery shops want substitution and basket fluency; restaurant-delivery wants batching and courier economics.

2. 2

   Hiring manager (45–60 min)

   Behavioral + domain depth. Expect a case: "Substitution rate spiked 3 points last month — what would you check?" They're testing whether you reach for GMV leakage, refund exposure, and merchant out-of-stock patterns fluently, and whether you understand the customer pays original / merchant paid sub asymmetry without prompting.

3. 3

   Technical SQL screen (60–90 min, usually take-home)

   A Postgres / Snowflake schema with a three-party order fact + substitutions + dispatches. Common asks: quantify substitution GMV leakage by merchant, build the three-sided fee waterfall, normalize shopper economics for batching. Edge cases matter — "shopper_payout is per dispatch but you summed it per order; what breaks?"

4. 4

   Cross-functional round (finance / ops / pricing)

   A non-analyst asks you to defend a metric. Finance will probe whether your P&L reconciles (customer_total = the three takes); Ops will challenge your batching normalization; Pricing will press on whether surge volume impact is real demand or a fee artifact.

5. 5

   Director / VP round

   Strategy and prioritization. Common ask: "If you had 8 weeks as our new marketplace analyst, what would you build first?" The strong answer is "the reconciled three-sided P&L with the substitution-leakage adjustment, before any new analysis" — the artifact every board review needs.

“How does a substitution inflate GMV, and how do you quantify it?”

When an item is out of stock, the shopper swaps a cheaper one but the customer still pays the original price; the merchant is only paid for the cheaper picked item. So customer_charged > merchant_paid on the substitution row. GMV leakage = SUM(customer_charged - merchant_paid). Reported GMV (customer-side) overstates the merchant-settled value by exactly this gap. M11 builds it per merchant; M24 carries it into the category P&L.

“Walk me through the three-sided fee waterfall.”

Start from SUM(customer_total) on delivered orders, subtract SUM(merchant_payout), subtract SUM(shopper_take), and the remainder is SUM(platform_take). Because the per-order identity customer_total = merchant_payout + shopper_take + platform_take holds by construction, a residual_check row should land at ~0. The classic mistake is adding a separate tip line — tip_amount is already inside shopper_take. M18 is the canonical mission.

“Why does naive per-order shopper pay double-count, and how do you fix it?”

shopper_payout is paid once per dispatch, but a dispatch can fulfill 2–3 orders (batch_size). If you join dispatches to orders and SUM shopper_payout per order, a triple batch counts the payout three times. The fix is to keep dispatch grain and divide SUM(shopper_payout) by SUM(batch_size) for true per-order economics. M12 surfaces the bug; M16 normalizes it into the quality score.

“How do you read surge pricing impact on volume?”

Split delivered orders into surge (surge_multiplier > 1.0) vs normal and compare order_count, avg_order_value, and avg_units. The trap: avg_order_value is mechanically higher under surge because surge_fee inflates customer_total — that is not evidence surge is harmless. The honest signal is whether avg_units or volume share softens, which reflects real demand suppression. M19 is the mission.

“How do you build a shopper attrition cohort-decay grid?”

Derive a DISTINCT (shopper_id, active_month) set from dispatch activity, join each shopper to their signup cohort_month, and compute months_since as (year diff)*12 + (month diff) on the truncated dates. COUNT(DISTINCT shopper_id) per (cohort_month, months_since) yields the survivor curve. The grid is triangular — recent cohorts have fewer months observed. M22 is the canonical mission; subtracting text dates instead of computing the month gap is the common failure.

“What separates a substitution reason worth tightening from one worth keeping?”

Score each reason on three levers: GMV leakage (SUM of the price gap), reject rate (customer_approved = 0), and refund rate (order_status = refunded, which requires the join to fact_orders). High-leakage, high-rejection reasons are the policies to tighten; a high-volume but clean like-for-like swap is the one you keep. M25 is the policy capstone.

• dbt Analytics Engineering certification

  Gold standard

  Marketplaces run dbt over enormous event ledgers. The cert is signal, but a public sample dbt project modeling a three-sided order ledger is worth more.

• Looker LookML developer certification

  Nice to have

  Useful at marketplaces on Looker. Lower signal than demonstrable SQL fluency on multi-grain marketplace data.

• SnowPro Core (Snowflake)

  Nice to have

  Relevant at the Snowflake-based marketplaces. Demonstrates warehouse fluency without being mandatory.

• A/B testing / experimentation course (e.g. Udacity, Reforge)

  Nice to have

  Marketplaces are experimentation-heavy (surge, substitution policy, batching algorithms). Causal-inference fluency differentiates senior candidates.

• Google Analytics 4 / GA4 certification

  Skip

  Marketplace analytics relies on the company event ledger, not GA4. Skip in favor of dbt or experimentation skills.

• Summing per-order shopper_take to get shopper cost on batched dispatches. shopper_payout is per dispatch — divide by SUM(batch_size), or you triple-count a triple batch. M12 is built around this.
• Reading reported GMV as net revenue. Substitution swaps make customer-side GMV overstate merchant-settled value by SUM(customer_charged - merchant_paid). M11 quantifies the gap.
• Adding a separate tip line to the fee waterfall. tip_amount is already inside shopper_take — a tip step double-counts and the residual stops reconciling. M18 traps this.
• Treating higher surge order value as proof surge is fine. surge_fee inflates customer_total mechanically; the real signal is avg_units / volume. M19 is the mission.
• Computing months-since-signup by subtracting TEXT dates. Always use (year diff)*12 + (month diff) on truncated dates, or the cohort-decay grid is nonsense. M22.
• Joining substitutions before aggregating in the P&L. That fans each order out by its substitution rows and inflates every money column — pre-aggregate leakage to order grain first. M24.
• INNER JOINing orders to substitutions when you want all merchants / customers. Zero-substitution entities vanish; LEFT JOIN + COALESCE keeps them. M7, M23.
• Forgetting NULLIF on rate denominators. A merchant with zero orders errors the whole substitution-rate query. M7.
• Counting substitutions with COUNT(*) over a LEFT JOIN instead of COUNT(substitution_id). COUNT(*) counts the order rows (always 1+) and inflates the rate. M23.
• Over-indexing on Python early. Quick-commerce analytics rewards rock-solid multi-grain SQL + marketplace-economics fluency first; Python is the later lever.

The caseSQL Quick Commerce path can't hand you Instacart's actual ledger or DoorDash's batching algorithm — but the schema is the right shape, the gotchas are the same gotchas (substitution GMV leakage, the batching grain, the three-party fee identity, surge-fee inflation, cohort decay), and the canonical missions force the SQL the hiring loop screens on. The Hard tier (M11–M15) approximates the live SQL screen; the Expert and Master tiers (M16–M25) are take-home territory. M21 — the reconciled three-sided P&L — is the question you'll be asked in some form on every senior marketplace analyst loop.