Swiggy Business Analyst

Q: Swiggy’s order placement funnel shows: Restaurant Browse (1M users) → Add Items to Cart (400k, 40% conversion) → Proceed to Checkout (200k, 50% conversion) → Complete Payment (150k, 75% conversion). Overall completion rate is 15% (150k from 1M). Q1: Where is the biggest leakage? Q2: If you could improve ONE step by 10%, which would have the highest impact on final conversion rate? Q3: Provide 3 hypotheses for why ‘Add to Cart → Checkout’ has the lowest conversion rate (50%), and how you’d test each.

STAR Method Structure: - Situation: Order completion rate critical for GMV where 2-3% improvement across millions of orders = ₹100+ crores annual impact - Task: Identify biggest funnel leakage (absolute vs relative), calculate cascading impact of 10% improvement at each step, formulate testable hypotheses for lowest-converting step - Action: Analyze leakage (Browse→Cart 60% drop = 600k lost biggest absolute, Cart→Checkout 50% drop = 200k lost biggest relative), calculate improvement impact (Brow

This guide features 10 challenging Business Analyst interview questions for Swiggy (Business Analyst to Lead BA levels), covering growth analytics, operations analytics, commercial analytics, strategic planning, SQL proficiency, unit economics, and data-driven decision-making aligned with Swiggy’s mission of delivering convenience at scale.

1. Customer Retention Month-over-Month SQL Query - Most Frequently Asked

Difficulty Level: Hard

Role: Business Analyst

Source: YouTube (Balaji Kasiraj), InterviewQuery, HackerEarth

Topic: SQL, Retention Analysis, Window Functions

Interview Round: SQL Assessment + Technical Round (70 min)

Business Function: Growth Analytics

Question: “Write a SQL query to calculate month-over-month customer retention rate for Swiggy’s subscription business model. A customer is ‘retained’ if they made at least one transaction in the immediately previous month AND at least one transaction in the current month. Show retention rate as percentage, absolute retained user count, and total active users per month. Handle edge cases where a customer churned.”

Answer Framework

STAR Method Structure:
- Situation: Need to track subscription business health via retention metrics where 70%+ of BA technical rounds test this foundational query
- Task: Calculate MoM retention using window functions (preferred) vs self-join (traditional), handle first-month edge case, optimize for 10M+ row datasets
- Action: Use CTE + LAG window function to identify previous month activity, flag retained users (active in both consecutive months), aggregate by month with retention percentage
- Result: Query executes in <2s on 10M rows (vs 45s self-join), correctly handles NULL first month, enables retention cohort analysis driving LTV optimization

Key Competencies Evaluated:
- Window Functions Mastery: LAG/LEAD for temporal comparisons vs inefficient self-joins
- Date Handling: DATE_TRUNC for month boundaries, INTERVAL arithmetic for month-to-month logic
- Edge Case Handling: First month shows NULL/0% retention (no previous month), churned customers excluded from denominator
- Query Optimization: Explaining why window functions outperform self-joins (O(n) vs O(n²) complexity)

Answer

Retention query implementation uses CTE + window functions approach where monthly_users CTE extracts DISTINCT customer_id with DATE_TRUNC(‘month’, transaction_date) creating month_date granularity, retention_analysis CTE applies LAG(month_date) OVER (PARTITION BY customer_id ORDER BY month_date) capturing previous month activity per customer, CASE statement flags is_retained = 1 when LAG(month_date) = DATE_TRUNC(‘month’, month_date - INTERVAL 1 month) confirming consecutive month activity else 0, final SELECT aggregates COUNT(DISTINCT customer_id) as active_users, SUM(is_retained) as retained_users, ROUND(100.0 × SUM(is_retained) / COUNT(DISTINCT customer_id), 2) as retention_rate_pct grouped by month_date, filtering WHERE is_retained = 1 OR month_date != (SELECT MIN(month_date) FROM retention_analysis) to exclude first month from retention calculation while preserving it in output—interviewer evaluation assesses three competency levels: Basic (correctly identifying DISTINCT users per month and joining previous month data passes screening), Intermediate (using LAG/LEAD correctly with proper month-to-month transitions shows strong SQL foundation), Advanced (discussing partitioning strategy, explaining window function choice over self-join with EXPLAIN PLAN showing 3x faster execution on 10M rows, handling NULL values in first month gracefully distinguishes candidates), with common failure points including incorrect month comparison using MONTH() function alone failing across year boundaries, not handling first month showing errors instead of 0%/NULL, including churned customers in denominator instead of only active month users, and aggregating to daily level showing daily churn instead of monthly retention rate.

2. Complex Self-Join: Cumulative Sum Without Window Functions

Difficulty Level: Very Hard

Role: Senior Business Analyst

Source: YouTube (Analytics with Vipul), InterviewQuery

Topic: SQL Optimization, Self-Join Logic, Performance Analysis

Interview Round: SQL Assessment (60 min)

Business Function: Operations Analytics

Question: “Given a transactions table with customer_id, order_id, amount, and date, write a SQL query to calculate the running/cumulative sum of order amounts per customer. First, solve using window functions. Then, solve the same problem using SELF JOIN without window functions. Compare performance: which scales better? When would each approach be better in practice?”

Answer Framework

STAR Method Structure:
- Situation: Senior BA rounds test deeper SQL understanding beyond basic window functions, requiring performance trade-off analysis
- Task: Implement cumulative sum using both modern (window function) and traditional (self-join) approaches, benchmark performance at scale (1K to 10M+ rows)
- Action: Window function uses SUM() OVER (PARTITION BY customer_id ORDER BY transaction_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), self-join uses t1 JOIN t2 ON t1.customer_id = t2.customer_id AND t1.transaction_date >= t2.transaction_date GROUP BY t1 fields
- Result: Window function executes 30x faster at 10M rows (10s vs >5min timeout), self-join shows O(n²) complexity degradation, demonstrates understanding of when legacy approaches needed (MySQL <8.0, documentation purposes)

Key Competencies Evaluated:
- Query Optimization: Understanding algorithmic complexity (O(n) streaming vs O(n²) comparisons)
- Performance Reasoning: Using EXPLAIN PLAN to validate performance hypotheses
- Practical Trade-offs: Knowing when to use self-join (older databases, explanation clarity) vs window functions (production performance)
- Scalability Awareness: Testing on representative data sizes (100K, 1M, 10M rows)

Answer

Window function implementation uses SUM(amount) OVER (PARTITION BY customer_id ORDER BY transaction_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cumulative_sum providing O(n) streaming algorithm processing each row once, while self-join implementation uses transactions t1 JOIN transactions t2 ON t1.customer_id = t2.customer_id AND t1.transaction_date >= t2.transaction_date with GROUP BY t1.customer_id, t1.order_id, t1.amount, t1.transaction_date and SUM(t2.amount) AS cumulative_sum, requiring O(n²) comparisons where customer with 1000 orders forces row 500 to join with 500 previous rows—performance analysis shows 1K rows: window 50ms vs self-join 45ms (similar), 100K rows: window 200ms vs self-join 800ms (4x slower), 1M rows: window 1.5s vs self-join 45s (30x slower), 10M+ rows: window 10s vs self-join >5min timeout, with self-join degradation explained by each row requiring joins with all previous rows in partition creating quadratic growth. Interviewer discussion points probe “When would you use self-join in production?” (answer: explanation/documentation purposes, or when window functions unavailable in older databases like MySQL <8.0 or SQL Server <2012, but for performance-critical dashboards always use window functions), “How would you test which is faster?” (answer: use EXPLAIN PLAN or EXPLAIN ANALYZE in PostgreSQL, measure execution time on representative production-sized data, not toy datasets), “Can you optimize the self-join?” (answer: add indexes on (customer_id, transaction_date), consider materialized views if query runs daily, or incrementally update cumulative sums instead of recalculating from scratch, though these workarounds still inferior to native window function performance), with recommended action plan being quick win using window functions for production while documenting self-join approach for educational purposes or legacy system compatibility.

3. Top 20 KPIs for Food Delivery Platform Dashboard

Difficulty Level: Hard

Role: Senior Business Analyst

Source: LinkedIn (Nitin Kamal - The Data Monk), InterviewQuery

Topic: KPI Design, Multi-Stakeholder Metrics, Business Understanding

Interview Round: Case Study (60-90 min)

Business Function: Strategic Planning / Growth Analytics

Question: “You’re building a comprehensive metrics dashboard for Swiggy’s food delivery business serving leadership, restaurant partners, and delivery partners. Identify the top 20 KPIs across all stakeholders. For each metric, provide: 1) Definition, 2) Calculation formula, 3) Ideal benchmark, 4) How to segment the data (city, restaurant type, time of day), 5) What specific actions to take if the metric degrades 15%+.”

Answer Framework

STAR Method Structure:
- Situation: Three-sided platform requires balanced metrics across customers (demand), restaurants (supply), delivery partners (logistics), and business profitability
- Task: Design dashboard prioritizing actionable metrics over vanity metrics, with stakeholder-specific views and degradation response protocols
- Action: Customer-side (6 KPIs: DAU/MAU, order frequency, repeat rate, CAC, LTV, NPS), DP-side (4 KPIs: active DPs, earnings/hour, acceptance rate, on-time delivery), restaurant-side (3 KPIs: active restaurants, retention, fulfillment rate), business-side (7 KPIs: GMV, AOV, delivery time P95, delivery cost, success rate, commission revenue, contribution margin)
- Result: Dashboard enables proactive intervention (15%+ degradation triggers alerts), segments by city/restaurant type/time enabling root cause isolation, balances growth (GMV, DAU) with profitability (contribution margin)

Key Competencies Evaluated:
- Multi-Stakeholder Thinking: Understanding three-sided marketplace dynamics where optimizing one side may harm another
- Metrics Prioritization: Choosing leading indicators (order frequency) vs lagging (LTV), actionable (delivery time) vs vanity (total users)
- Business Acumen: Knowing which metrics drive profitability (contribution margin) vs growth (GMV)
- Segmentation Strategy: Breaking metrics by dimensions enabling root cause diagnosis

Answer

Customer-side KPIs include DAU/MAU (unique users placing ≥1 order daily/monthly, benchmark 10M DAU as of 2024, action if down 15%: investigate app crashes/bugs, check competitor promotions, analyze cohort churn), order frequency (average orders per active user per month, benchmark 3-4 orders/month, action: personalized recommendations and loyalty rewards), repeat order rate 30-day (% users ordering ≥2 times in 30 days, benchmark 45%+ for healthy retention, action if down: analyze first-order experience quality/delivery time, offer second-order incentives), CAC (total marketing spend ÷ new customers acquired, benchmark ₹80-120 varying by channel, action if rising: adjust channel mix, improve organic referrals/word-of-mouth), LTV (net margin per order × avg order frequency × customer lifetime months, benchmark ₹3,000-5,000, action if down: identify churn points, improve retention programs), and NPS ((Promoters - Detractors) / Total × 100, benchmark 50-70 healthy, action if down: conduct post-order surveys understanding pain points in delivery time/food quality/app usability)—delivery partner-side KPIs track active delivery partners (DPs making ≥1 delivery daily, benchmark 1.5M+ active in 2024, action if down: increase incentives, check weather impact, improve app stability), average earnings per hour (total DP earnings ÷ total hours worked, benchmark ₹200-300/hour varying by city, action if down: increase per-order incentive, reduce idle time through better routing), acceptance rate (deliveries accepted ÷ deliveries offered, benchmark 70%+, action if down: improve dispatch logic avoiding too many long-distance orders, increase incentives), and on-time delivery rate (orders delivered on time ÷ total orders, benchmark 95%+, action if down: improve restaurant prep time prediction, optimize routing, increase DP count in slow zones)—restaurant-side KPIs measure active restaurant partners (restaurants with ≥1 order daily, benchmark 50k+ in 2024, action if down: improve merchant experience, reduce commission if competitors undercutting), restaurant retention rate (restaurants active this month ÷ restaurants active last month, benchmark 80%+, action: build restaurant success tools like Menu Score, offer promotional features, improve support), and average order fulfillment rate (orders completed ÷ orders received by restaurant, benchmark 96%+, action if down: train restaurants on acceptance best practices, improve SLA communication)—business-side KPIs encompass GMV (total value of all orders, benchmark ₹10,000+ crores annually 2024, action if down: analyze demand trends, check competitor activity, run growth campaigns), AOV (GMV ÷ number of orders, benchmark ₹300-350, action: bundle offers, upsell premium restaurants, suggest add-ons), delivery time P95 (95th percentile delivery time, benchmark 35-40 minutes, action: optimize routing, increase restaurant/DP density in slow zones), delivery cost per order (total delivery costs including DP incentives and logistics ÷ orders, benchmark ₹35-45, action: reduce via better routing, increase batching with multiple orders per trip), delivery success rate (orders delivered successfully ÷ total orders, benchmark 98%+, action if down: improve DP availability, fix failed delivery reasons like customer unavailability or address issues), commission revenue (order value × commission %, benchmark 30% of order value ~₹90 per ₹300 order, action: monitor if commission rates need adjustment for competitiveness), and contribution margin ((commission revenue - delivery cost) ÷ orders, benchmark 20-25% per order, action: most critical profitability metric requiring immediate cost structure addressing if negative or declining)—dashboard structure presents three tabs (Demand showing DAU/order frequency/NPS, Supply showing active DPs/earnings/acceptance rate, Business showing GMV/CAC/contribution margin) with each metric having 4 dimensions (overall, by city, by restaurant type, by time of day) and red/yellow/green alerts when metric moves >15% from baseline enabling proactive intervention.

4. Delivery Economics: Unit Economics Analysis & Profitability Levers

Difficulty Level: Very Hard

Role: Senior Business Analyst

Source: Swiggy Blog (Delivered: Profitability), Financial Analysis Studies

Topic: Unit Economics, P&L Analysis, Profitability Modeling

Interview Round: Case Study + Guesstimates (60-90 min)

Business Function: Commercial Analytics

Question: “Swiggy’s unit economics: Delivery cost per order ₹40, Average order value ₹300, Commission rate 30% (₹90 gross revenue), Delivery partner incentive 50% of delivery fee collected from customer. Calculate: 1) Net margin per order, 2) Breakeven delivery cost to stay profitable, 3) Orders/day needed across 500 cities to reach ₹1,000 crore annual profit, 4) Which three levers (pricing, cost reduction, volume, AOV) would you prioritize to improve margins and why?”

Answer Framework

STAR Method Structure:
- Situation: Swiggy achieved profitability March 2023, requiring deep understanding of unit economics optimization for sustainable growth
- Task: Model per-order economics accounting for all revenue streams and variable costs, identify breakeven thresholds, calculate scale requirements for profit targets
- Action: Calculate revenue (commission ₹90 + delivery fee ₹40 = ₹130), variable costs (DP incentive ₹20 + delivery ₹40 + support ₹5 + restaurant incentives ₹15 + refunds ₹6 + payment fees ₹4.5 = ₹90.5), contribution margin ₹39.5, corporate overhead ₹2/order, net profit ₹37.5/order
- Result: ₹1,000 crore profit requires 267M orders/year (731k/day), prioritize AOV increase (fastest ROI ₹320 crore via ₹350 AOV), delivery cost reduction (₹200 crore via routing/batching/EV fleet), retention/frequency improvement (₹500 crore long-term via loyalty programs)

Key Competencies Evaluated:
- Unit Economics Mastery: Understanding all cost components (COGS, variable costs, fixed overhead allocation)
- Profitability Analysis: Calculating contribution margin, breakeven points, scale requirements
- Lever Prioritization: Using impact-effort matrix balancing quick wins vs long-term value
- Business Modeling: Sensitivity analysis showing how 10% improvement in each lever affects bottom line

Answer

Per-order unit economics calculates revenue as commission from restaurant (AOV × 30% = ₹300 × 0.30 = ₹90) plus delivery fee from customer (₹40) totaling ₹130 gross revenue, with variable costs including DP incentive (50% × delivery fee = 0.5 × ₹40 = ₹20), delivery cost fleet/fuel/logistics (₹40 given), call center/support (₹5), restaurant incentives/discounts (avg 5% of AOV = ₹15), food quality issues/refunds (avg 2% of AOV = ₹6), and payment processing fees (1.5% of AOV = ₹4.5) totaling ₹90.5 variable costs, yielding adjusted contribution ₹130 - ₹90.5 = ₹39.5/order, less corporate overhead (Swiggy annual corporate costs ~₹800 Cr ÷ 400M orders/year = ₹2/order for HQ/tech/marketing/admin) producing net profit per order ₹39.5 - ₹2 = ₹37.5/order—profitability at scale shows achieving ₹1,000 crore annual profit requires ₹1,000 Cr ÷ ₹37.5 per order = 267M orders/year = 731k orders/day, with Swiggy 2024 delivering ~400M orders/year = ~1.1M/day already above breakeven, and breakeven delivery cost calculated as revenue ₹130 = variable costs (DP incentive + delivery + support) where if delivery cost is X then ₹130 = 0.5X + X + ₹5 solving ₹125 = 1.5X yielding X = ₹83.3 meaning delivery cost exceeding ₹83.3 creates unprofitability per order (ignoring incentives/refunds)—three prioritized levers include Lever 1 (Reduce delivery cost with impact ₹5-10 per order improvement from current ₹40 via AI-optimized routing reducing travel time 15% = -₹6, increased batching with 2 orders per trip = -₹5 per order average, EV fleet reducing fuel cost 15% = -₹2, requiring medium effort and 6-12 months implementation, yielding ROI of ₹5 reduction × 400M orders/year = ₹200 crore profit improvement), Lever 2 (Increase AOV with impact ₹8-15 per order improvement from current ₹300 AOV → 30% commission = ₹90 via bundle offers food + Instamart, premium restaurant suggestions, add-ons upsell, where AOV rising to ₹350 generates commission ₹105 yielding additional ₹15 offset by ₹7 additional refunds/incentives = net ₹8 improvement, requiring low effort and 1-3 months implementation, yielding ROI of ₹8 × 400M = ₹320 crore improvement representing HIGHEST ROI pursued first), and Lever 3 (Improve retention/frequency with impact increasing orders volume from current 3 orders/customer/month to 4 orders = +33% orders = +133M orders/year at ₹37.5/order = ₹500 crore additional profit, requiring 3-6 months implementation via better recommendations and loyalty programs, representing very high ROI but longer payback)—recommended prioritization pursues Lever 2 (AOV increase) first for highest ROI with fastest implementation, simultaneously executes Lever 1 (delivery cost reduction) for 2025-26, treats Lever 3 (frequency) as long-term retention play, with combined levers driving Swiggy from current ₹1,000 crore profit target to ₹2,000+ crore by 2026.

5. Order Cancellation Rate Spike - Root Cause Analysis Case Study

Difficulty Level: Hard

Role: Senior Business Analyst

Source: InterviewQuery - Swiggy BA Guide

Topic: Root Cause Analysis, Problem Segmentation, Hypothesis Testing

Interview Round: Case Study (60 min)

Business Function: Operations Analytics

Question: “Order cancellation rate in Mumbai spiked from 5% to 8% last week (historically 3-4%, up 3 percentage points is significant). Mumbai is Swiggy’s second-largest market. As a Business Analyst, walk through your RCA (root cause analysis) framework: 1) How would you segment the problem to isolate root cause? 2) What data queries would you run first? 3) What are your top 3 hypotheses? 4) How would you test each hypothesis? 5) What product/operational recommendations would you make?”

Answer Framework

STAR Method Structure:
- Situation: 3% cancellation spike in ₹50 crore city represents ₹1.5 crore lost revenue requiring rapid diagnosis
- Task: Segment problem isolating affected cohorts (temporal, customer, restaurant, order type), run targeted SQL queries, test hypotheses systematically
- Action: Segment by time (lunch/dinner peaks), customer type (new/repeat), restaurant type (cloud kitchen/QSR/fine-dining), order type (cuisine, price bracket), run SQL queries (cancellation reason breakdown, temporal patterns, restaurant-level impact, DP availability), test top 3 hypotheses (restaurant prep time increased 40%, DP availability dropped 30%, technical/app issue 15%)
- Result: Diagnose root cause within 24-48 hours, implement targeted fixes (if prep time: alert restaurants about surge, if DP shortage: increase incentives 20%, if technical: rollback app changes), prevent ₹1.5 crore monthly revenue loss

Key Competencies Evaluated:
- Problem Decomposition: Breaking ambiguous problem into testable segments
- SQL Proficiency: Writing diagnostic queries (cancellation reason, temporal patterns, cohort analysis)
- Hypothesis Testing: Formulating testable hypotheses with likelihood estimates, designing validation queries
- Decision Making: Recommending actions based on data findings, not intuition

Answer

Problem segmentation avoids asking “Why did cancellation rate go up?” instead targeting temporal (is spike uniform across all hours or concentrated in lunch peak 12-1pm vs dinner 7-9pm, did spike happen Monday-Friday vs weekend), customer (new customers vs repeats, which price brackets affected with high AOV ₹500+ vs low ₹100-200), restaurant (all restaurant types or specific like cloud kitchen/QSR/fine-dining, are cloud kitchens affected more despite lower prep time, specific restaurants or city-wide), and order type (dine-in vs delivery, which cuisines like veg vs non-veg or Indian vs international)—SQL queries prioritized include Query 1 (root cause breakdown: SELECT cancellation_reason, COUNT() as cancellations, ROUND(100.0 × COUNT() / total_orders, 2) as pct FROM orders WHERE city=‘Mumbai’ AND week=current_week GROUP BY cancellation_reason ORDER BY COUNT() DESC), Query 2 (temporal pattern: SELECT EXTRACT(HOUR FROM order_time) as hour_of_day, COUNT() as total_orders, SUM(CASE WHEN status=‘cancelled’ THEN 1 ELSE 0 END) as cancellations, cancellation_rate FROM orders WHERE city=‘Mumbai’ AND week=current_week GROUP BY hour_of_day), Query 3 (restaurant-level impact: SELECT restaurant_id, restaurant_name, COUNT() as orders, cancellations, cancellation_rate FROM orders WHERE city=‘Mumbai’ AND week=current_week GROUP BY restaurant_id HAVING COUNT() > 20 ORDER BY cancellation_rate DESC LIMIT 20), Query 4 (delivery partner angle: SELECT delivery_partner_id, deliveries_offered, cancellations, cancellation_rate, avg_delivery_time FROM orders WHERE city=‘Mumbai’ AND week=current_week GROUP BY delivery_partner_id HAVING COUNT(*) > 5 ORDER BY cancellation_rate DESC)—top 3 hypotheses include Hypothesis A (Restaurant preparation time increased with 40% likelihood where restaurants couldn’t keep up with order surge causing customers to wait 20+ mins for pickup and cancel, signal being cancellations concentrated in lunch peak 12-1pm and dinner 7-9pm, tested by correlating cancellations with avg prep time by restaurant using SQL comparing current week vs previous week prep times), Hypothesis B (Delivery partner availability dropped with 30% likelihood due to weather/rain, festival, or low incentives causing customers unable to find available DP with order timing out, signal being high-cancel areas clustered geographically, tested by checking DP count by zone vs baseline and app-on time), Hypothesis C (Technical/app issue with 15% likelihood from app glitch causing forced cancellations, payment failures, or confirmation issues, signal being cancellations spike at specific times when app was down not gradual, tested by checking app crash logs, error rate logs, payment failure rate)—testing each hypothesis validates Hypothesis A via SQL analyzing avg prep time current week vs last week by restaurant showing if prep time up 30%+ and cancellation up 3%+ then likely, Hypothesis B via SQL comparing weekly active DPs and orders per DP showing if orders per DP increased (more demand, fewer DPs) then likely, Hypothesis C via SQL checking hourly errors and cancellations showing if specific hour has spike in errors + cancellations vs gradual rise then technical issue likely—recommendations by root cause prescribe if Hypothesis A (prep time) then short-term alert restaurants about order surge helping prioritize high-demand items, medium-term improve kitchen load forecasting suggesting better menu optimization, long-term recommend restaurants run parallel prep with multiple chefs working simultaneously; if Hypothesis B (DP shortage) then short-term increase DP incentives in Mumbai by 20% deploying incentive surge pricing, medium-term improve dispatch algorithm reducing assignment time (faster dispatch = more DP comfort accepting), long-term launch DP recruitment drive improving retention; if Hypothesis C (technical) then immediate rollback recent app changes fixing bugs monitoring error rates, post-fix A/B test improvements slowly avoiding future issues.

6. Guesstimate: Orders Delivered by Swiggy Per Hour in India

Difficulty Level: Medium-Hard

Role: Business Analyst

Source: LinkedIn (Aryan Sharan - 100 Days of Product), APM Interview Guides

Topic: Market Sizing, Estimation Skills, Sanity Checking

Interview Round: Guesstimate (30-45 min)

Business Function: Growth Analytics

Question: “Estimate the total number of food delivery orders that Swiggy delivers per hour across all of India. Show your approach (top-down or bottom-up), state all assumptions clearly, and sanity-check your final number against public data (company financials, revenue, known market metrics). Break down by time of day (peak lunch, dinner, off-peak hours).”

Answer Framework

STAR Method Structure:
- Situation: Guesstimate reveals mental model of business, ability to decompose ambiguous problems, and sanity-checking discipline
- Task: Size user base (India population → urban → food delivery penetration → DAU), estimate daily orders (DAU × order frequency), break down by time of day (lunch/dinner peaks vs off-peak)
- Action: Bottom-up approach: 1.4B population → 500M urban (40%) → 50M food delivery users (10% penetration) → 8M DAU (15-20% active daily) → 3 orders/month frequency → 0.8M orders/day base estimate, sanity-check against ₹11,247 Cr FY24 revenue
- Result: Revised estimate 2M orders/day (83k/hour average), peak lunch 400-500k/hour, peak dinner 200-250k/hour, off-peak 20-30k/hour, aligns with ₹18.5 Cr/day revenue estimate

Key Competencies Evaluated:
- Estimation Skills: Breaking complex problem into logical steps with reasonable assumptions
- Assumption Clarity: Stating all assumptions explicitly (DAU %, order frequency, AOV)
- Sanity Checking: Cross-validating estimate against public data (revenue, market size)
- Business Understanding: Knowing industry benchmarks (penetration rates, order frequency patterns)

Answer

User base sizing starts India population 1.4 billion → urban population 30-40% live in cities = 420-560 million using 500M, food delivery penetration 10% have used food delivery = 50 million cumulative users, active users on any given day not all users active daily with assumption 15-20% DAU = 7.5-10M daily active users using conservative 8M DAU as reasonable middle ground—daily orders estimation calculates orders per active user per month where heavy users (10% of users) order 2x/week = 8-9 orders/month, medium users (30%) order 1x/week = 4 orders/month, light users (60%) order 1-2x/month = 1.5 orders/month, yielding weighted average 0.1×8 + 0.3×4 + 0.6×1.5 = 0.8 + 1.2 + 0.9 = 2.9 orders/month ≈ 3/month, producing daily orders 8M DAU × 3 orders/month ÷ 30 days = 0.8M orders/day with cross-check at ₹300 AOV × 30% commission = ₹90/order × 0.8M orders/day = ₹72L/day = ₹26 Cr/year, comparing against Swiggy FY24 revenue ₹11,247 Cr × 60% food delivery = ₹6,748 Cr ÷ 365 = ₹18.5 Cr/day showing my estimate ₹26 Cr is 40% high requiring adjustment down to 2 orders/month = ₹17 Cr/day closer to reality—time of day breakdown allocates peak lunch 12pm-1pm as highest concentration with 20-25% of daily orders compressed into 1 hour assuming 25% of daily orders in lunch window = 0.8M × 25% = 200k orders in peak lunch hour, dinner 7pm-9pm as second highest with 25-30% spread across 2 hours = 0.8M × 28% ÷ 2 hours = 110k orders/hour peak dinner average, off-peak other 19 hours assuming 1pm-7pm and 9pm-12am are low with remaining 47% = 0.8M × 47% ÷ 19 hours = 20k orders/hour—sanity check against public data shows my estimate daily 0.8M orders and annual 292M orders producing revenue at 30% commission on ₹300 AOV = ₹88 Cr/year food delivery only, comparing Swiggy FY24 total revenue ₹11,247 Cr with food delivery estimated 60% = ₹6,748 Cr revealing my estimate ₹88 Cr is WAY too low off by 75x indicating underestimated DAU or order frequency, with revised calculation if annual revenue ₹6,748 Cr ÷ ₹90/order commission = 74.9M orders/year = 205k orders/day still too low versus my estimate, reconsidering users’ order frequency might be higher 4-5 orders/month not 3, DAU might be higher 15M not 8M, delivery fee revenue exists beyond just commission, yielding revised estimate if 15M DAU × 4 orders/month ÷ 30 = 2M orders/day with commission + delivery fees aligning better with ₹18.5 Cr/day revenue—final answer estimates daily orders 2 million orders/day, hourly average 83,333 orders/hour, peak lunch 12-1pm 400-500k orders/hour, peak dinner 7-8pm 200-250k orders/hour, off-peak 20-30k orders/hour, annual estimate 730M orders/year, with reality check noting Swiggy doesn’t publicly disclose exact order volumes but based on ₹11,247 Cr FY24 revenue and estimated 60% food delivery ~400-500M orders/year is reasonable implying ~1.1M-1.4M orders/day average aligning with peak demand but including large off-peak hours, making my estimate of 2M/day average likely 40-50% high but directionally correct.

7. CAC vs LTV Analysis - Business Case Development

Difficulty Level: Hard

Role: Business Analyst

Source: LinkedIn (Vishal Bagla), InterviewQuery

Topic: Unit Economics, LTV Calculation, Lever Prioritization

Interview Round: Case Study (60 min)

Business Function: Growth Analytics / Commercial Analytics

Question: “Swiggy spends ₹100 to acquire a customer (CAC). Average order value ₹300, gross margin 30% (₹90/order), delivery cost ₹40, net margin ₹50/order. Assuming customers place 3 orders/month on average and stay active for 2 years (24 months), calculate: 1) Customer lifetime value (LTV). 2) LTV/CAC ratio (benchmark should be ≥3:1). 3) Payback period (when LTV exceeds CAC?). 4) If Swiggy wants LTV/CAC ratio of 5:1, what levers (pricing, retention, frequency, AOV) would you prioritize and why?”

Answer Framework

STAR Method Structure:
- Situation: LTV/CAC ratio determines unit economics health and profitability, directly impacting Swiggy’s growth from ₹5 billion to ₹11 billion revenue
- Task: Calculate LTV with realistic churn assumptions (not naive 24-month retention), determine payback period, identify levers to reach 5:1 target ratio
- Action: Base case assumes no churn yielding LTV ₹3,600 and LTV/CAC 36:1 (unrealistic), revised with 50% monthly churn yields LTV ₹300 and LTV/CAC 3:1 (tight baseline), payback 1.3 months
- Result: To reach LTV/CAC 5:1 (need LTV ₹500), prioritize improve retention (30% churn → LTV ₹500, medium effort 3-6 months), increase frequency (3→5 orders/month → LTV ₹500, medium effort 2-4 months), increase AOV (₹300→₹450 → LTV ₹420 combined with frequency = ₹320 total, low effort 1-2 months), reduce CAC (₹100→₹60 → ratio 5:1, high effort 6-12 months)

Key Competencies Evaluated:
- LTV Calculation: Understanding geometric series for churn modeling, not naive multiplication
- Financial Analysis: Calculating payback period, contribution margin, cumulative profit curves
- Lever Prioritization: Using impact-effort matrix balancing quick wins vs sustainable value
- Business Modeling: Sensitivity analysis showing how each lever affects LTV and ratio

Answer

Base case calculation assuming no churn computes LTV = net margin per order × orders per month × customer lifetime months = ₹50/order × 3 orders/month × 24 months = ₹3,600 yielding LTV/CAC = ₹3,600 / ₹100 = 36:1 extremely healthy with payback period = CAC / monthly contribution where monthly contribution = ₹50/order × 3 orders = ₹150/month producing payback = ₹100 / ₹150 = 0.67 months ≈ 3 weeks, but reality includes CHURN with realistic assumption based on food delivery industry showing 50% monthly churn where customer activity drops to 0 by month 2 on average for many customers—revised LTV with 50% monthly churn calculates Month 1: ₹150 profit (3 orders × ₹50), Month 2: ₹150 × 0.5 = ₹75 profit (50% stay), Month 3: ₹75 × 0.5 = ₹37.5 profit (25% stay), Month 4+: negligible, yielding LTV = ₹150 + ₹75 + ₹37.5 + ₹18.75 + … (geometric series) = ₹150 / (1 - 0.5) = ₹300 producing LTV/CAC = ₹300 / ₹100 = 3:1 healthy baseline but tight, with payback period after month 1: ₹150 profit (still ₹50 short), after month 2: ₹150 + ₹75 = ₹225 profit (exceeded CAC) = ~1.3 months—reaching LTV/CAC 5:1 requiring LTV ₹500 evaluates four levers: Lever 1 (Improve retention lowering churn from 50% to 30% monthly) calculates LTV (30% churn) = ₹150 / (1 - 0.7) = ₹500 ✓ with impact +₹200 LTV improvement, medium effort building loyalty features/personalization/quality improvements, 3-6 months payback; Lever 2 (Increase order frequency from 3 to 5 orders/month) calculates monthly contribution = ₹50 × 5 = ₹250 yielding LTV (50% churn) = ₹250 / (1 - 0.5) = ₹500 ✓ with impact +₹200 LTV improvement, medium effort via better recommendations/gamification/loyalty programs, 2-4 months payback; Lever 3 (Increase AOV from ₹300 to ₹450) calculates net margin at ₹450 AOV where commission 30% = ₹135 (vs ₹90 before, +₹45) but delivery cost ₹40 same and customer acquired for ₹450 AOV might have higher expectations assuming net margin improves only by ₹20 to ₹70/order, producing monthly contribution = ₹70 × 3 = ₹210 and LTV (50% churn) = ₹210 / 0.5 = ₹420 not enough alone with impact +₹120 LTV improvement but combined with frequency = ₹320 total, low effort via upsell/bundles/premium restaurants, 1-2 months payback; Lever 4 (Reduce CAC from ₹100 to ₹60) maintains LTV ₹300 yielding LTV/CAC = ₹300 / ₹60 = 5:1 ✓ via leveraging organic growth referrals/word-of-mouth, focusing on high-LTV segments avoiding low-value users, improving conversion rates lowering acquisition per order, with impact improving ratio but not growing absolute LTV, high effort requiring brand building/word-of-mouth, 6-12 months payback—recommended prioritization pursues first priority Months 1-2 (Increase order frequency + Increase AOV) with combined impact ₹200 LTV lift, low effort and fast payback via examples like “Repeat last order” button and bundles food + instamart, expecting LTV/CAC 3:1 → 4:1; second priority Months 3-6 (Improve retention) with impact ₹200 LTV lift, medium effort but sustainable via Swiggy One subscription and personalized recommendations, expecting LTV/CAC 4:1 → 5:1; longer-term (Improve CAC efficiency) complementing levers 1-2 but not core driver, using to improve margins not growth.

8. Restaurant Partner Onboarding Economics - Business Case

Difficulty Level: Hard

Role: Senior Business Analyst

Source: Swiggy Restaurant Menu Score case study, InterviewExperiences.in

Topic: Investment Analysis, Retention Modeling, ROI Calculation

Interview Round: Case Study (60 min)

Business Function: Commercial Analytics

Question: “Swiggy wants to onboard 1,000 new restaurant partners in Delhi in Q1 2025. Building onboarding infrastructure (ops team, training, system integration) costs ₹50 lakhs. Each restaurant generates ₹50,000 annual commission revenue. Restaurant retention rate is 80% annually. Calculate: 1) Payback period for the ₹50L investment. 2) Three-year cumulative revenue and profit from 1,000 restaurants. 3) What specific actions would you take to improve retention (which directly impacts ROI)? 4) Build a business case for investing in a ‘Restaurant Success Tool’ (similar to Swiggy’s Menu Score).”

Answer Framework

STAR Method Structure:
- Situation: Swiggy actively manages restaurant profitability competing with Zomato, requiring commercial decision modeling beyond customer-side metrics
- Task: Model 3-year revenue with 80% annual retention, calculate payback period, sensitivity analysis showing retention impact, build ROI case for retention tools
- Action: Year 1: 1,000 restaurants × ₹50k = ₹5 Cr - ₹50L onboarding = ₹4.5 Cr net, Year 2: 800 retained × ₹50k = ₹4 Cr, Year 3: 640 retained × ₹50k = ₹3.2 Cr, 3-year total ₹11.2 Cr net, payback 1.2 months
- Result: 10% retention improvement (80%→90%) = ₹1.35 Cr additional 3-year profit, Menu Score Tool investment ₹20L/year yields ROI 200% via 5% retention lift + 10% revenue uplift per restaurant, payback ~6 months

Key Competencies Evaluated:
- Investment Analysis: Calculating payback period, multi-year revenue modeling with retention decay
- Retention Modeling: Understanding compound effects of retention (80% Year 1 → 64% Year 2 → 51% Year 3)
- ROI Calculation: Building business case with cost-benefit analysis, sensitivity scenarios
- Strategic Thinking: Knowing which investments (Menu Score Tool) drive mutual value (restaurant + Swiggy win)

Answer

Base case with 80% annual retention calculates Year 1: 1,000 new restaurants onboarded generating revenue 1,000 × ₹50,000 = ₹5 Cr less onboarding cost ₹50L yielding net Year 1 ₹4.5 Cr, Year 2: retained from Year 1 = 1,000 × 0.8 = 800 restaurants generating revenue 800 × ₹50,000 = ₹4 Cr with no new onboarding cost yielding net Year 2 ₹4 Cr, Year 3: retained from Year 2 = 800 × 0.8 = 640 restaurants generating revenue 640 × ₹50,000 = ₹3.2 Cr yielding net Year 3 ₹3.2 Cr, producing 3-year total ₹11.7 Cr gross and ₹11.2 Cr net after onboarding, with payback period ₹50L ÷ (₹5Cr / 12 months) = 1.2 months showing onboarding investment recouped within first month of full onboarding—sensitivity to retention shows 70% retention (low): Year 1 ₹4.5Cr + Year 2 ₹3.5Cr + Year 3 ₹2.45Cr = ₹10.45Cr total, 80% retention (base): Year 1 ₹4.5Cr + Year 2 ₹4.0Cr + Year 3 ₹3.2Cr = ₹11.7Cr total, 90% retention (high): Year 1 ₹4.5Cr + Year 2 ₹4.5Cr + Year 3 ₹4.05Cr = ₹13.05Cr total, demonstrating 10% retention improvement = ₹1.35Cr additional 3-year profit—actions to improve retention include Action 1 (Build restaurant analytics dashboard “Menu Score Tool” costing ₹20L/year engineering with expected impact improving retention from 80% to 85% +5%, revenue impact 5% × ₹4Cr Year 2 + 5% × ₹3.2Cr Year 3 = ₹36L additional 3-year revenue, ROI ₹36L revenue / ₹20L cost = 1.8x in just 2-3 years, noting Swiggy already launched this with proven ROI), Action 2 (Dedicated success managers for top 10% restaurants costing ₹1 Cr/year for 10 FTEs × ₹10L each targeting 100 restaurants top 10% by GMV with expected impact improving retention for this cohort from 80% to 92%, revenue impact 12% × 100 × ₹50k = ₹60L additional annual, ROI -₹40L initially cost > benefit but pays back in Year 2-3, strategic value keeping high-value restaurants likely accounting for 30% of revenue with 10% of restaurants), Action 3 (Promotional features & incentive optimization costing ₹10L/year engineering for promotional tools with expected impact restaurants using platform more actively with higher engagement and better retention improving to 85% combined with menu score tool, ROI high as restaurants directly benefit with more orders = higher commission = mutual win)—business case for Restaurant Success Tool investment shows investment ₹20L/year comparing Scenario 1 (without tool at 80% retention) producing 3-year revenue ₹11.7 Cr versus Scenario 2 (with tool at 85% retention) producing Year 1: 1,000 × ₹50k - ₹50L - ₹20L = ₹4.3 Cr, Year 2: 850 × ₹50k - ₹20L = ₹4.05 Cr, Year 3: 722 × ₹50k - ₹20L = ₹3.41 Cr totaling ₹11.79 Cr with incremental profit ₹11.79 - ₹11.7 = ₹0.09 Cr not compelling on its own, but additional benefit exists where restaurants with menu optimization INCREASE their own order frequency, and if menu optimization lifts average restaurant revenue by 10% then ₹50k base × 1.1 = ₹55k producing Year 2 at 85% retention: 850 × ₹55k = ₹4.675 Cr (vs ₹4.25 without tool) yielding additional benefit ₹4.675 - ₹4.25 = ₹42.5L year 2 alone, with full ROI including revenue uplift showing 3-year additional profit ₹1.2 Cr, investment ₹60L (₹20L × 3 years), payback ~6 months, ROI 200%, strongly recommending pursuing Menu Score Tool investment.

9. Behavioral: Data-Driven Decision Making Under Ambiguity

Difficulty Level: Hard

Role: Senior Business Analyst

Source: InterviewExperiences.in, LinkedIn (Raghav Bakshi)

Topic: Data-Driven Thinking, Stakeholder Communication, Impact Quantification

Interview Round: Behavioral (45 min)

Business Function: Any / Cross-functional

Question: “Tell us about a time you used data analysis to influence a business decision that wasn’t obvious from intuition or initial assumptions. For example: leadership wanted to expand to a city, but data suggested otherwise. Or a feature was underperforming, and you diagnosed the root cause others missed. Walk us through: 1) The initial situation and ambiguity, 2) What data you gathered and analyzed, 3) What insights you uncovered, 4) How you communicated findings to non-technical stakeholders, 5) Final business outcome and what you learned.”

Answer Framework

STAR Method Structure:
- Situation: Business decision with ambiguity where intuition conflicts with data, requiring analytical rigor to guide choice
- Task: Use data to challenge assumptions, segment analysis revealing hidden patterns, communicate simply to non-technical stakeholders
- Action: Gather relevant data (cohort analysis, segmentation), run analysis (SQL queries, statistical tests), uncover insights (segment-specific patterns), communicate findings (simple tables/charts for executives), quantify impact (revenue, profit, user metrics)
- Result: Data-driven decision implemented, measurable business outcome (revenue/profit/retention improvement), learning documented for future decisions

Key Competencies Evaluated:
- Data-Driven Thinking: Using data to guide decisions, not just confirm biases
- Communication Skills: Translating technical analysis into business language for executives
- Problem Decomposition: Segmenting problems to isolate root causes
- Ownership: Taking responsibility for outcomes, not blaming when results differ from projections

Answer

Situation describes leadership wanting to increase delivery fees by 15% from ₹40 to ₹46 improving unit economics and delivery partner earnings but lacking data to predict customer impact, with some believing “customers won’t care about ₹6 more” while others feared “we’ll lose 20% of orders” and no one knowing the truth—Task as BA for Growth involved analyzing price sensitivity and recommending whether to implement the increase—Action executed segmentation instead of guessing by analyzing AOV distribution showing 30% of users order ₹100-200 (very price-sensitive), 40% order ₹200-400 (medium price-sensitive), 30% order ₹400+ (less price-sensitive), running cohort analysis on historical data finding users who placed orders with ₹5 delivery fees vs ₹40 showed no significant drop-off in low-AOV users while users facing ₹50 delivery fee surge pricing showed low-AOV users had 8% order cancellation increase with high-AOV users unaffected by fee changes, recommending TIERED approach where low-AOV orders ₹100-200 keep ₹40 protecting user base volume-based, high-AOV orders ₹400+ increase to ₹50 as they don’t care earning more, mid-AOV A/B test ₹45, communicating findings to leadership via simple table showing (AOV segment | current order rate | predicted order rate at +₹6) explaining “If we increase uniformly, we risk 6-10% decline in low-AOV orders, but tiered approach lets us capture profit from high-AOV users while protecting growth in low-AOV,” quantifying impact as “+₹15 crores annual net profit vs risk of -₹10 crores if uniform increase”—Result showed leadership approved tiered approach with implementation keeping low-AOV fees ₹40, increasing high-AOV fees to ₹48 (tested, then settled at ₹48 vs proposed ₹50), mixed-AOV A/B testing ₹44 vs ₹40 finding ₹44 lost <2% orders, producing outcome of order volume -1.2% (vs feared -10%), revenue +₹12 crores (vs projected ₹15, still strong), DP earnings increased 8% improving retention, with lesson learned that segment-based decisions outperform one-size-fits-all—what made this answer strong included using real data to challenge assumption (not “let’s try and see” but “let’s check what data tells us”), communicating simply via table-based summary for non-technical stakeholders, quantifying impact with ₹12 crores, 1.2% order decline, 8% DP retention as numbers executives understand, owning the outcome when result was ₹12Cr not ₹15Cr by explaining why and what was learned not blaming assumptions, and showing learning that “segment-based decisions outperform one-size-fits-all,” while avoiding red flags like “I convinced leadership I was right” (combative not collaborative), “The intuition was wrong” (dismissive of non-data people), “We should have tested more” (no ownership), and no mention of actual business outcome where metrics matter.

10. Funnel Analysis: Order Abandonment & Conversion Optimization

Difficulty Level: Medium-Hard

Role: Business Analyst

Source: YouTube (Swiggy Business Analysis with SQL), InterviewQuery

Topic: Funnel Analysis, Conversion Optimization, Impact Prioritization

Interview Round: Case Study (60 min)

Business Function: Growth Analytics

Question: “Swiggy’s order placement funnel shows: Restaurant Browse (1M users) → Add Items to Cart (400k, 40% conversion) → Proceed to Checkout (200k, 50% conversion) → Complete Payment (150k, 75% conversion). Overall completion rate is 15% (150k from 1M). Q1: Where is the biggest leakage? Q2: If you could improve ONE step by 10%, which would have the highest impact on final conversion rate? Q3: Provide 3 hypotheses for why ‘Add to Cart → Checkout’ has the lowest conversion rate (50%), and how you’d test each.”

Answer Framework

STAR Method Structure:
- Situation: Order completion rate critical for GMV where 2-3% improvement across millions of orders = ₹100+ crores annual impact
- Task: Identify biggest funnel leakage (absolute vs relative), calculate cascading impact of 10% improvement at each step, formulate testable hypotheses for lowest-converting step
- Action: Analyze leakage (Browse→Cart 60% drop = 600k lost biggest absolute, Cart→Checkout 50% drop = 200k lost biggest relative), calculate improvement impact (Browse→Cart +10% = +2.25% overall conversion highest, Checkout→Payment +10% = +0.5% lowest), test hypotheses (delivery charge shock 50%, payment friction 30%, form abandonment 15%)
- Result: Prioritize Browse→Cart optimization (biggest impact +2.25%) while pursuing quick wins in payment friction (easy fix 1-2 weeks), implement targeted solutions (show delivery fee earlier, add payment options, simplify checkout form), prevent ₹100+ crore revenue loss

Key Competencies Evaluated:
- Funnel Analysis: Understanding absolute vs relative leakage, cascading effects through funnel
- Impact Prioritization: Calculating which step improvement yields highest overall conversion lift
- Hypothesis Testing: Formulating testable hypotheses with likelihood estimates, designing validation approaches
- Conversion Optimization: Knowing common friction points (delivery fees, payment methods, form complexity)

Answer

Biggest leakage identification analyzes Step 1→2: 1M → 400k drop = 600k lost (60% drop rate), Step 2→3: 400k → 200k drop = 200k lost (50% drop rate), Step 3→4: 200k → 150k drop = 50k lost (25% drop rate), showing biggest absolute leakage Browse → Cart (600k users), biggest relative leakage Browse → Cart (60% don’t add items), with question for interviewer “Are we focusing on absolute impact (more users affected) or efficiency (highest conversion)?” where if absolute then Step 1-2 is biggest lever, if efficiency then Step 3-4 has lowest friction and highest conversion—improvement impact analysis calculates if improve Browse → Cart by 10%: 600k × 0.1 = 60k additional to step 2 cascading through funnel 60k × 0.5 × 0.75 = 22.5k additional final orders yielding impact 22.5k / 1M = 2.25% increase in overall conversion; if improve Cart → Checkout by 10%: 200k × 0.1 = 20k additional cascading 20k × 0.75 = 15k additional final orders yielding impact 15k / 1M = 1.5% increase; if improve Checkout → Payment by 10%: 50k × 0.1 = 5k additional with no cascading (final step) yielding impact 5k / 1M = 0.5% increase, declaring winner as Improve Browse → Cart (biggest impact +2.25%), but tradeoff exists where effort consideration shows Browse → Cart (60% drop) likely hard problems requiring significant product changes in restaurant discovery and menu clarity, while Checkout → Payment (25% drop) likely easy fixes in payment method friction and form errors fixable in 1-2 weeks, suggesting best approach pursues quick win first (payment +10%) while parallely working on larger browse→cart optimization—three hypotheses for Cart → Checkout low conversion 50% include Hypothesis A (Delivery charge shock with 50% likelihood) where customer adds items seeing total = cart items + delivery fee perceiving “₹400 for food + ₹40 delivery = ₹440 seems expensive” causing customer to not checkout and browse other restaurants, tested by showing delivery fee during browse/cart not just at checkout via A/B test with Control group (see fee at checkout) versus Treatment (see fee during browse) expecting Treatment group should have higher cart abandonment but LOWER checkout abandonment from more informed decision-making earlier; Hypothesis B (Payment friction with 30% likelihood) from limited payment methods (only card, UPI), failed payment attempts, and EMI options not clearly shown, tested by logging payment method selection rate tracking what % of users select each method, tracking payment failure rate by method, A/B testing adding more payment options (wallets, Buy Now Pay Later) expecting offering more payment options should improve conversion by 2-5%; Hypothesis C (Form abandonment / technical issues with 15% likelihood) from checkout form too long (asking for address twice), form validation errors (zip code format, phone number), and app crashes during checkout, tested by analyzing form errors (how many users fail validation), checking app crash logs during checkout, measuring form completion time vs abandonment, A/B testing simplified checkout (fewer fields) expecting streamlining checkout form could improve by 3-5%; Additional Hypothesis D (Time pressure / latency with 15% likelihood) from checkout page loading slowly (>2 seconds) causing customers to perceive it as “broken” and navigate away, tested by checking Core Web Vitals (Largest Contentful Paint, First Input Delay), measuring correlation between page load time and abandonment, optimizing image loading and reducing JavaScript expecting 20% improvement in load time should lift conversion 1-2%—recommended action plan executes Quick Win Week 1-2 (Fix payment friction + simplify checkout form) expecting impact +2-4% checkout conversion, Medium-term Month 1 (Show delivery fee earlier during browse/cart) expecting impact +1-3% checkout conversion with trade-off potentially losing some browsers early but more informed decisions later, Long-term Month 2-3 (Improve restaurant discovery addressing why only 40% add items) as hardest problem likely requiring better recommendations, filters, and search.