AeroSoftCorp.org: How I Actually Solve Business Problems as a Data Analyst

Showing posts with label How I Actually Solve Business Problems as a Data Analyst. Show all posts

Thursday, 13 August 2026

Beyond SQL: How I Actually Solve Business Problems as a Data Analyst

When I first started out, I thought a data analyst's job was entirely about writing SQL queries and building dashboards. I quickly realized that is just the tooling; the actual job is closer to being a detective. There is a big difference between reporting, which just tells you what happened, and problem-solving, which tells you why it happened and what to do about it.

When I am handed a symptom, like a metric moving in the wrong direction, my goal is to narrow down millions of rows of data into one defensible explanation and a recommendation that leadership can act on by Monday morning.

Here is the step-by-step framework I use to avoid freezing up when given a vague task.

1. Defining the Business Problem (No Queries Yet)

Before I touch any data, I have to know what I am solving.

"Orders are down" is not a problem statement; it is just a symptom.
I always rewrite vague asks into measurable statements.
For example, I will change "Orders are down" to "Total weekly orders fell 12% month-over-month, and I need to know whether that's driven by acquisition, frequency, or churn".
Defining the problem this way tells me exactly what my first three queries will be.

2. Asking the Right Questions via Decomposition

Broad questions like "Why did revenue drop?" will cause you to boil the ocean. Instead, I use decomposition to break a top-line number into its components.

Revenue = orders × average order value.
Orders = unique customers × orders per customer.
By checking each component separately, I usually find that only one or two actually moved, which saves me from investigating things that were never the problem.

3. Root Cause Analysis: The 5 Whys

To avoid stopping at a surface-level symptom, I use the 5 Whys technique.

Why did repeat orders drop? Customers aren't reordering within 30 days.
Why aren't they reordering? Delivery times got worse.
Why did delivery times get worse? Rider allocation per order increased.
Why did allocation time increase? Rider supply didn't scale with festive-season demand.
Why didn't supply scale? Onboarding pipeline for new riders has a 3-week lag. This takes a vague revenue issue and drills down to a process bottleneck (a 3-week onboarding lag) that operations can actually test and fix.

4. The Fishbone Diagram (Mapping Multiple Causes)

The 5 Whys assumes a linear chain, but real business problems often have two or three things happening at once. That is where I use a fishbone (Ishikawa) diagram to branch outward into different categories and check them independently.

For our app, I pull a small amount of data against each of these branches before committing to a hypothesis:

People: Rider shortages, support staff bandwidth, or training gaps.
Process: Allocation algorithm logic, refund policies, or escalation workflows.
Technology: App crashes, payment gateway failures, or slow load times.
External: Weather, competitor pricing, or festival demand shifts.
Restaurant Partners: Kitchen prep time, stock-outs, or menu accuracy.

5. Dodging Correlation Traps

It is incredibly easy to give a recommendation that does nothing. For instance, saying "rain causes cancellations" gives leadership nothing to act on because we cannot fix the weather.

Tracing it a step further shows that rider availability drops in rain, which increases allocation time, which drives cancellations.
This reveals an actual lever: a weather-linked incentive.

6. The Complete Loop & Case Study Application

I apply all of this using a repeatable structure: Define → Diagnose → Validate → Recommend → Measure.

Let’s say leadership flags a specific issue: The repeat order rate among first-month users dropped from 45% to 32% over the last quarter. Here is exactly how I break that down into my four-step investigation checklist:

1. Questions to Ask (Segmenting the Problem) I don't try to answer these immediately; I use them to figure out if this is one big problem or three smaller ones layered together:

Is this happening across all cities, or is it concentrated in just a few?
Is it just new users, or is an older existing cohort also disengaging?
Has the average delivery time changed in this exact same window?
Did our pricing, packaging fees, or minimum order values change?
Are competitors running aggressive discount campaigns in these same cities?
Is the drop concentrated around specific cuisines or restaurant partners?

2. Possible Causes (Forming Hypotheses) I map these back to my fishbone diagram so I don't just fixate on the first plausible idea:

People/Process: A rider shortage is inflating delivery times in high-drop-off cities.
Process: A recent fee change quietly reduced the perceived value for customers.
Process: Increased order errors, such as wrong or missing items, are causing refund friction.
External: A competitor launched a new subscription or loyalty program.
Technology: App performance issues, including crashes and slow checkouts, in the latest update.
Partners: Restaurant partner churn is reducing the menu variety users care about.

3. Data Required (Gathering Evidence) This is the data I need to pull to rule those causes in or out with actual evidence, separating a real recommendation from a guess:

Order-level data: Timestamps, delivery durations, cancellation/refund flags, city, and restaurant IDs.
Cohort data: Signup month, order frequency, and last-order dates.
Pricing history: Delivery fees, surge pricing logs, and minimum order thresholds.
App telemetry: Crash logs, checkout funnel drop-offs, and session lengths.
Competitor intel: Publicly tracked pricing, discounts, and app store reviews.
Support data: Customer service tickets and refund reason codes.

4. Potential Solutions (Actionable Recommendations) Every solution I propose is strictly conditional on what the data above confirms:

If it's a Rider Supply Issue: Implement dynamic incentive payouts for riders during peak windows in the affected cities.
If it's Fee-Related: Run an A/B test reverting the fee change in a subset of cities before doing a full rollback.
If it's Cohort-Specific: Launch a targeted win-back campaign, like a discount or free delivery, for users who haven't ordered in 30+ days.
If it's a Technical Issue: Prioritize the checkout funnel bug in the next engineering sprint and re-measure the conversion rate.
If it's Competitive Pressure: Test a loyalty/subscription counter-offer in an isolated market and measure the retention lift.

Finally, I make sure to do the step most analysts skip: going back three weeks later to confirm whether the fix actually moved the metric. That feedback loop is what builds credibility and separates a good analyst from someone who just makes charts.