Skills of a Great Business Analyst in 2026

# Problem Brief — Cart abandonment on mobile

## TL;DR
Mobile checkout abandonment is 68% vs 42% on desktop. Our own
research and analytics suggest the abandonment is concentrated
at the payment step, not the cart or address. Fixing the payment
step alone could recover an estimated ₹14L/month in revenue.

## What we observed
- Mobile cart-to-order conversion: 32% (vs 58% on desktop)
- Payment step abandonment: 41% of mobile checkouts
- Top exit point on mobile: after "Continue to payment"
- Support tickets about "card not working": 312 in last 30 days
- Sample size: 8,400 sessions over 4 weeks

## What we think is happening
Three hypotheses, ranked by evidence:
1. **Autofill failure on card forms** — 62% of exit sessions
   had failed autofill events in analytics.
2. **Page performance** — mobile checkout LCP is 4.8s vs 2.1s
   on desktop; users abandon during load.
3. **3D Secure redirect** — customers report "stuck on bank
   page" in support tickets; 18% of sessions never return from
   the redirect.

## What we recommend
1. Ship a mobile card form with native autofill (Apple/Google
   Pay as first-class options) — estimated 3-week effort.
2. Reduce checkout page weight by 40% (remove unused JS,
   defer analytics) — 1-week effort.
3. Add a "come back to checkout" deep link after 3D Secure —
   3-day effort.

## What we are NOT doing
- We are not redesigning the cart yet — data suggests cart is
  fine on mobile.
- We are not changing pricing — no evidence pricing is the
  issue.
- We are not adding more payment methods yet — first, fix the
  current flow.

## Success metric
Mobile checkout conversion: 32% → 45% within 8 weeks of launch.

## Open questions
- Are the 41% exits concentrated in a specific card network?
- Do failed autofill events correlate with browser version?

# Why this works:
# - TL;DR at the top so a busy stakeholder reads it in 20 seconds.
# - Evidence with numbers, not opinions.
# - Recommendations are ranked, effort-scoped, and named.
# - "What we are NOT doing" is honest about scope.
# - Success metric is measurable, with a target and a timeframe.
#
# What an average BA would write:
# - A 20-page BRD with no clear recommendation.
# - "It appears users are abandoning carts" — no numbers.
# - A wishlist of 15 features with no prioritisation.
# - No "what we're not doing" — so scope creeps endlessly.

-- cart_abandonment.sql — a real query a business analyst writes
-- This is exactly what a great BA runs before proposing a fix.

WITH sessions AS (
  SELECT
    s.session_id,
    s.device_type,
    s.user_id,
    MAX(CASE WHEN e.event_name = 'view_cart'      THEN 1 ELSE 0 END) AS viewed_cart,
    MAX(CASE WHEN e.event_name = 'begin_checkout' THEN 1 ELSE 0 END) AS began_checkout,
    MAX(CASE WHEN e.event_name = 'add_payment'    THEN 1 ELSE 0 END) AS added_payment,
    MAX(CASE WHEN e.event_name = 'purchase'       THEN 1 ELSE 0 END) AS purchased,
    MAX(CASE WHEN e.event_name = 'autofill_failed' THEN 1 ELSE 0 END) AS autofill_failed,
    MAX(e.session_duration_seconds) AS duration_s
  FROM events e
  JOIN site_sessions s USING (session_id)
  WHERE e.event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  GROUP BY 1, 2, 3
),

-- Funnel by device
funnel AS (
  SELECT
    device_type,
    COUNT(*)                                                  AS sessions,
    SUM(viewed_cart)                                          AS carts,
    SUM(began_checkout)                                       AS checkouts,
    SUM(added_payment)                                        AS payments_attempted,
    SUM(purchased)                                            AS purchases,
    SUM(autofill_failed)                                      AS autofill_failures,
    ROUND(AVG(duration_s), 0)                                 AS avg_duration_s
  FROM sessions
  WHERE viewed_cart = 1
  GROUP BY device_type
)

SELECT
  device_type,
  sessions,
  carts,
  checkouts,
  payments_attempted,
  purchases,
  ROUND(purchases * 100.0 / sessions, 1)                    AS cart_to_order_pct,
  ROUND((payments_attempted - purchases) * 100.0
        / NULLIF(payments_attempted, 0), 1)                 AS payment_step_drop_pct,
  autofill_failures,
  ROUND(autofill_failures * 100.0 / NULLIF(sessions, 0), 1) AS autofill_fail_pct,
  avg_duration_s
FROM funnel
ORDER BY cart_to_order_pct ASC;

-- What this query reveals:
-- - Where exactly the drop is happening (cart? payment? confirmation?)
-- - Whether the drop is device-specific
-- - Whether autofill failures correlate with the drop
-- - How long sessions take before abandoning
--
-- What an average BA does instead:
-- - Asks the data team for a report and waits a week.
-- - Reads a Tableau dashboard someone else built.
-- - Guesses at the reason without looking at session events.
--
-- What a great BA does:
-- - Runs this in 10 minutes.
-- - Cross-checks the number against the analytics dashboard.
-- - Presents the finding in the problem brief.
# - Owns the metric all the way to the fix.

# Using AI tools as a BA — a daily workflow
# These are the tasks where a great BA uses AI to save hours,
# and the ones where they do not.

# === WHERE AI HELPS ===

# 1. Drafting a first version of a document
# - "Draft a problem brief for mobile cart abandonment based on
#   these analytics numbers: [paste data]. Keep it to one page,
#   TL;DR at the top, include a 'what we are NOT doing' section."

# 2. Summarising a stakeholder meeting
# - "Summarise this transcript into: (a) decisions made, (b) open
#   questions, (c) who owns what. Under 200 words."

# 3. Generating test cases
# - "List 20 test cases for a checkout flow with saved cards,
#   including boundary and error scenarios."

# 4. Writing user stories
# - "Convert these requirements into user stories with acceptance
#   criteria in Gherkin format: [paste requirements]."

# 5. Explaining technical concepts
# - "Explain what a webhook is in simple terms a non-technical
#   stakeholder would understand."

# === WHERE AI DOES NOT HELP (and can hurt) ===

# 1. Deciding what to build
# - The AI does not know the business context, the roadmap, or the
#   trade-offs. It can suggest options; you decide.

# 2. Judging data quality
# - AI will happily summarise a bad dataset. You must verify
#   before trusting the output.

# 3. Facilitating a difficult conversation
# - The human work of aligning stakeholders cannot be delegated.

# 4. Taking responsibility for an outcome
# - When the feature ships and the metric moves the wrong way,
#   the AI is not in the room. You are.

# === A simple prompt pattern for BAs ===

"""
You are helping me as a senior business analyst.

Context:
- Product: mobile e-commerce checkout
- Problem: 68% cart abandonment on mobile (42% on desktop)
- Data I have: [paste key metrics]
- Constraint: 3-week engineering window

Task:
Write a one-page problem brief with:
1. TL;DR (3 sentences)
2. What we observed (numbered, with numbers)
3. What we think is happening (ranked hypotheses)
4. What we recommend (ranked, effort-scoped)
5. What we are NOT doing (and why)
6. Success metric (target + timeline)
7. Open questions

Keep it under 400 words. Do not add fluff.
"""

# What great BAs do with this output:
# - They treat it as a first draft, not a final answer.
# - They add specific numbers from their own analysis.
# - They add a recommendation they would defend in a meeting.
# - They own the outcome, not the document.