Quick summary
Summarize this blog with AI
Many data analyst candidates learn SQL, Python, Excel, and Power BI, then still feel unprepared for interviews. The missing skill is often business domain knowledge. They can write a query, but they are not sure what question the business is actually asking, what metric matters, or which assumption could change the answer.
Domain knowledge does not mean memorizing every term in banking, healthcare, e-commerce, SaaS, or retail. It means understanding how a business creates value, what events generate data, which metrics leaders care about, and what tradeoffs sit behind a dashboard. You can build that skill deliberately, even before you have years of job experience.
Use a Simple Domain Map
Start every domain with five questions. They work for most analyst interviews and portfolio projects.
- Who is the customer or user? A buyer, patient, merchant, driver, advertiser, employee, subscriber, or account holder.
- What is the core event? An order, visit, claim, payment, ticket, shipment, booking, login, click, or application.
- What changes over time? Acquisition, activation, usage, retention, churn, revenue, margin, risk, inventory, or service level.
- What can go wrong? Fraud, late delivery, duplicate records, bad data entry, leakage, stockouts, slow response, or low conversion.
- What decision will the analysis support? Invest, stop, segment, prioritize, price, staff, alert, approve, reject, or investigate.
This map turns a vague domain into tables, metrics, and questions. For example, e-commerce becomes customers, orders, order items, payments, returns, product categories, and marketing channels. Healthcare becomes patients, appointments, diagnoses, claims, providers, and outcomes. SaaS becomes accounts, users, subscriptions, events, seats, invoices, and support tickets.
Translate Business Language Into Data Language
Interview prompts often sound business-heavy: improve retention, understand churn, find top customers, explain a revenue drop, or evaluate a campaign. Your job is to translate that into data decisions.
| Business phrase | Data translation |
|---|---|
| Retention is down | Define active user, cohort, return window, and incomplete periods |
| Revenue dropped | Separate volume, price, discount, refunds, mix, and seasonality |
| Top customers | Choose revenue, margin, frequency, recency, or lifetime value |
| Campaign worked | Define exposed users, control group, conversion window, and attribution |
| Operational backlog | Measure created work, completed work, aging, priority, and capacity |
Good analysts do this translation before they write SQL. That is why two candidates can know the same syntax but perform very differently in interviews.
Build a Metric Glossary for One Domain
Pick one domain and make a small metric glossary. Do not try to learn every industry at once. For each metric, define:
- Name: monthly active users, gross revenue, net revenue retention, average order value, fill rate, approval rate, or ticket resolution time.
- Grain: one row per user per month, account per month, order, ticket, product, store, or provider.
- Numerator: what counts.
- Denominator: what the rate is divided by.
- Filters: statuses, channels, countries, product lines, fraud exclusions, test accounts, or canceled records.
- Common caveat: late data, refunds, duplicate users, time zones, seasonality, or missing dimensions.
Here is an example for an e-commerce analyst interview:
| Metric | Definition | Common trap |
|---|---|---|
| Conversion rate | Purchasing sessions divided by eligible sessions | Counting orders instead of sessions |
| Average order value | Net order revenue divided by paid orders | Including canceled or refunded orders |
| Repeat purchase rate | Customers with a second purchase divided by first-time purchasers | Not allowing enough observation time |
| Return rate | Returned items divided by shipped items | Mixing order-level and item-level grain |
A glossary like this prepares you for both SQL and case interviews because it forces you to define what the numbers mean.
Practice Asking Better Clarifying Questions
When an interviewer asks a vague question, do not rush into the query. Ask questions that reduce ambiguity:
- What is the business goal behind this metric?
- What is the unit of analysis?
- Which statuses should be included or excluded?
- What time zone and date boundary should we use?
- Do we care about first occurrence, latest occurrence, or all events?
- Should ties be included?
- Is the current partial period included?
- What action will someone take from this result?
These questions are not filler. They show that you understand real analytics work. Most production data questions are ambiguous until someone defines grain, metric, and business use.
Turn Domain Knowledge Into SQL Practice
After you choose a domain, write SQL prompts from business questions instead of only solving generic puzzles.
For e-commerce:
- Which product categories had the largest month-over-month revenue decline?
- Are first-time buyers returning within 30 days?
- Which marketing channel has high revenue but low margin?
- Which products have high return rates after controlling for sales volume?
For SaaS:
- Which accounts activated within seven days of signup?
- Which features are used by retained accounts but not churned accounts?
- Which plan has the highest downgrade risk?
- How does support ticket volume relate to renewal?
For operations:
- Which queue is creating the oldest unresolved tickets?
- Which location misses service-level targets most often?
- Which work type has the largest gap between demand and capacity?
- Which exception category creates the most rework?
For each prompt, write the target grain before the SQL. Then write one sentence explaining what a manager might do with the result.
Read Public Business Material Like an Analyst
You can build domain knowledge from public material. Use annual reports, investor presentations, job descriptions, product pages, help-center articles, and marketplace policies. Do not read them passively. Extract nouns, events, metrics, and risks.
For example, a marketplace company page may mention buyers, sellers, listings, bookings, cancellations, payouts, disputes, and trust signals. Those become tables and interview prompts. A healthcare job description may mention claims, eligibility, providers, member engagement, care gaps, and compliance. Those become metrics and data quality concerns.
After reading, write a one-page domain brief:
- Core users and stakeholders
- Core transaction or event
- Three important metrics
- Three data quality risks
- Three likely interview questions
Use Portfolio Projects to Prove Business Thinking
A portfolio project is stronger when it shows judgment, not just charts. Instead of building a dashboard with ten visuals, build one focused analysis:
- State the business question.
- Define the metric and grain.
- Clean or validate the data.
- Write SQL that creates the analysis dataset.
- Build a simple dashboard or chart.
- Explain the recommendation and limitations.
For example: Instead of a generic sales dashboard, write an analysis on why a product category lost revenue. Separate traffic, conversion, average order value, returns, and discounting. That project shows business thinking because it moves from symptom to diagnosis.
A 30-Day Domain Knowledge Routine
Use this routine if interviews are coming soon.
Days 1 to 5: Pick One Domain
Choose the domain closest to your target jobs. Collect 10 job descriptions and highlight repeated nouns, tools, metrics, and responsibilities.
Days 6 to 10: Build the Domain Map
Write the users, events, tables, and common business decisions. Sketch a simple schema with five to eight tables.
Days 11 to 17: Build the Metric Glossary
Define 10 metrics. For each, include grain, numerator, denominator, filters, and common traps.
Days 18 to 24: Write SQL Prompts
Create 15 business questions and solve at least eight. Include joins, dates, window functions, and conditional aggregation.
Days 25 to 30: Practice Interview Explanation
For each solved prompt, explain the business goal, assumptions, SQL approach, validation checks, and possible recommendation. Record yourself once or twice. It will expose unclear reasoning quickly.
What Strong Domain Thinking Sounds Like
A weak answer starts with syntax. A stronger answer starts with the business definition.
Weak answer: I would join orders to customers and group by month.
Stronger answer: I would first define whether revenue means gross booked revenue, paid revenue, or net revenue after refunds. Then I would use one row per order for the monthly trend, exclude canceled orders, and separately check whether the drop comes from fewer orders, lower average order value, or a higher refund rate.
The second answer is not longer because it is vague. It is longer because it protects the business from a misleading number.
FAQ
Can I build domain knowledge without job experience?
Yes. Use public job descriptions, company materials, datasets, and case studies. Focus on how the business works, which events create data, and which metrics support decisions. You do not need insider knowledge to practice that reasoning.
Which domain should a beginner data analyst learn first?
E-commerce, SaaS, retail, and operations are good starting points because the tables and metrics are easy to model. Healthcare, banking, and insurance are valuable too, but they require more attention to regulation and domain terminology.
How much domain knowledge is enough for an interview?
You should be able to explain the core customer, transaction, key metrics, common data quality issues, and likely business decisions for the role. You do not need to sound like a ten-year industry expert.
How do I show business thinking in SQL answers?
Define the metric, grain, filters, and edge cases before writing the query. After the query, explain how you would validate the result and what decision the result could support.
