The Analytics Lifecycle

A data analyst who dives straight into a spreadsheet is like a surgeon who picks up a scalpel before reading the chart. The lifecycle is not bureaucracy — it is the sequence of decisions that separates insight from noise.

Learning Objectives

• Trace a business problem from raw question to actionable recommendation
• Name the owner and common failure mode of each lifecycle phase
• Recognize when a project is stuck and know how to unstick it

---

The Six Phases

Business Question
      │
      ▼
Data Collection & Discovery
      │
      ▼
Data Cleaning & Preparation
      │
      ▼
Analysis & Modeling
      │
      ▼
Visualization & Communication
      │
      ▼
Decision & Action  ──► (loop back with new questions)

Each phase feeds the next. Skipping or rushing any phase does not save time — it creates rework downstream.

---

Phase 1: Business Question

What happens here: A stakeholder (a VP, a product manager, a finance lead) notices something or needs to make a decision. They come to the analytics team with a request — rarely a clean question.

What you actually hear: - "Can you pull a report on sales?" - "Something seems off with our retention numbers." - "Leadership wants to understand why Q3 underperformed."

What you need to produce: A precise, answerable analytics question.

Vague Request	Precise Analytics Question
"Pull a report on sales"	"What is weekly revenue by product category for the last 13 weeks, compared to the same period last year?"
"Something is off with retention"	"What is the 30-day and 90-day retention rate by acquisition cohort for users who signed up in the last 6 months?"
"Why did Q3 underperform?"	"Which product lines, regions, and customer segments showed the largest year-over-year revenue decline in Q3, and when did the decline begin?"

Who owns it: The analyst and the stakeholder — jointly. The analyst should never accept a vague brief without asking follow-up questions.

Common failure point: Analysts skip this negotiation and build the wrong thing. The stakeholder says "yes, that's what I asked for" to a completed dashboard they won't use.

The most expensive analytics mistake

Starting work before the business question is locked is the single most common source of wasted analyst time. A 15-minute scoping conversation prevents 15 hours of rework. Make it non-negotiable.

For mid-level analysts

When scoping, always ask: "What decision will you make with this analysis?" If they cannot answer, the project is not ready. Your job is to help them find that answer — not to produce a report and wait for a decision that never comes.

For senior analysts

Document the business question in writing and get explicit sign-off before starting. This protects you when scope creeps and protects the stakeholder from misremembering what they asked for. One paragraph, one email — saves weeks of political friction.

---

Phase 2: Data Collection and Discovery

What happens here: You figure out what data exists, where it lives, whether it is usable, and what its limitations are.

Activities: - Identifying relevant data sources (transactional databases, CRM exports, marketing platforms, third-party data) - Pulling sample records to understand structure, volume, and grain - Talking to data engineers or system owners to understand how data is captured - Cataloging known issues: gaps, latency, sampling bias, definitional inconsistencies

Business example — Q3 sales investigation: - Source 1: Salesforce CRM (deal-level data, but only updated by reps who log correctly) - Source 2: ERP system (actual invoiced revenue — the ground truth) - Source 3: Web analytics (traffic and lead volume) - Source 4: Finance's revenue model (budget vs actuals)

The analyst discovers that Salesforce data lags the ERP by 1–2 weeks and that two regional reps stopped logging deals in August. This is a critical finding — not because it answers the original question, but because it changes how you interpret any analysis built on Salesforce data.

Who owns it: The analyst, often with support from data engineering or a data steward.

Common failure point: Analysts assume the data they have is the data they need. Availability bias is real — you analyze what you can pull, not necessarily what would answer the question.

Data discovery is non-negotiable

Plan for at least 20–30% of your project time here. What you find in this phase will reshape Phase 1 — sometimes the business question itself changes once you know what data exists.

---

Phase 3: Data Cleaning and Preparation

What happens here: Raw data is almost never analysis-ready. This phase transforms it into a structure you can actually analyze.

Common cleaning tasks:

# Example: cleaning a sales dataset in Python (pandas)
import pandas as pd

df = pd.read_csv("q3_sales_raw.csv")

# Remove duplicate transaction IDs
df = df.drop_duplicates(subset="transaction_id")

# Standardize product category names (inconsistent entry by reps)
df["category"] = df["category"].str.strip().str.title()
df["category"] = df["category"].replace({
    "Softwar": "Software",
    "software ": "Software",
    "HW": "Hardware"
})

# Parse date columns
df["sale_date"] = pd.to_datetime(df["sale_date"], errors="coerce")

# Flag and handle missing revenue values
df["revenue_missing"] = df["revenue"].isna()
df["revenue"] = df["revenue"].fillna(0)  # or investigate and impute

# Remove test records
df = df[~df["customer_name"].str.contains("test", case=False, na=False)]

print(f"Clean rows: {len(df)}")
print(f"Date range: {df['sale_date'].min()} to {df['sale_date'].max()}")
print(df["category"].value_counts())

The 80/20 reality: In most analytics projects, 70–80% of time is spent here. This is not a failure — it is the work. An analyst who says "I spent most of my time cleaning data" is being honest, not inefficient.

Who owns it: The analyst. In mature data organizations, a data engineer owns pipeline-level cleaning; the analyst handles analysis-level transformations.

Common failure point: Cleaning is treated as a one-time step. In reality, you will discover new data quality issues during analysis and loop back to this phase multiple times.

Irreversible cleaning decisions

Never overwrite your raw data. Always create a separate "clean" copy. When your stakeholder asks "where did those 500 records go?" you need to show your work. Document every transformation decision and why you made it.

For mid-level analysts

Build a data quality audit as a deliverable in itself. A one-page summary of "what we found in the data and what we did about it" builds stakeholder trust and surfaces issues that leadership often doesn't know about — bad data entry habits, missing integrations, stale records.

For senior analysts

If the same cleaning work happens every week for a recurring report, that work should be automated in a pipeline. If you are manually cleaning a dataset every Monday, that is a data engineering ticket, not an analyst task. Push for it.

---

Phase 4: Analysis and Modeling

What happens here: You apply analytical methods to answer the business question.

Methods scale with the question:

Business Question	Method
"What happened to sales?"	Aggregation, trend analysis, YoY comparison
"Which segment drove the decline?"	Segmentation, drill-down, contribution analysis
"Is this decline statistically real?"	Hypothesis testing, confidence intervals
"Will sales recover next quarter?"	Forecasting (regression, time series)
"What should we do?"	Scenario modeling, optimization

Business example — Q3 investigation:

-- Step 1: Total revenue by quarter, YoY comparison
SELECT
    YEAR(sale_date)    AS year,
    QUARTER(sale_date) AS quarter,
    product_category,
    SUM(revenue)       AS total_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers,
    SUM(revenue) / COUNT(DISTINCT customer_id) AS revenue_per_customer
FROM sales
WHERE sale_date BETWEEN '2023-01-01' AND '2024-09-30'
GROUP BY 1, 2, 3
ORDER BY 3, 1, 2;

-- Step 2: Identify which categories drove the YoY decline
WITH quarterly AS (
    SELECT
        product_category,
        SUM(CASE WHEN YEAR(sale_date) = 2023 AND QUARTER(sale_date) = 3
                 THEN revenue ELSE 0 END) AS q3_2023,
        SUM(CASE WHEN YEAR(sale_date) = 2024 AND QUARTER(sale_date) = 3
                 THEN revenue ELSE 0 END) AS q3_2024
    FROM sales
    GROUP BY product_category
)
SELECT
    product_category,
    q3_2023,
    q3_2024,
    q3_2024 - q3_2023                               AS revenue_delta,
    ROUND((q3_2024 - q3_2023) / q3_2023 * 100, 1)  AS pct_change
FROM quarterly
ORDER BY revenue_delta ASC;

Who owns it: The analyst. For predictive or prescriptive analytics, a data scientist may own the modeling while the analyst owns the business framing and interpretation.

Common failure point: Analysis without a hypothesis. Analysts who explore data without a question in mind produce interesting findings that lack business context. Always start with a hypothesis: "I think the decline is concentrated in the Enterprise segment in the Midwest region."

For senior analysts

Every analysis should have a stated hypothesis before you run a single query. Exploratory work is valid, but it should be time-boxed. Set a 2-hour exploration limit; then form a hypothesis and test it.

---

Phase 5: Visualization and Communication

What happens here: Findings become something a non-analyst can understand and act on.

The core principle: A chart is not a deliverable. A recommendation is a deliverable. The chart is evidence for the recommendation.

Deliverable formats by audience:

Audience	Format	Length
Executive / VP	Slide deck, top-line numbers	3–5 slides
Operations manager	Dashboard or recurring report	Auto-refreshing
Finance team	Detailed spreadsheet with assumptions	Full detail
Product team	Annotated funnel chart or cohort table	Medium detail
Engineering	Data spec document	Technical detail

Communication structure for analyst findings:

1. Lead with the answer — state the finding in one sentence
2. Show the evidence — two or three supporting charts or numbers
3. Explain the "so what" — what this means for the business
4. Recommend the "now what" — what action you suggest
5. Note the caveats — data limitations, assumptions, confidence level

Common failure point: Leading with methodology instead of findings. Nobody in a leadership meeting needs to know how you joined the tables. They need to know what to do on Monday.

The buried lede problem

Analysts frequently put their most important finding on slide 8 of a 12-slide deck. Put the finding on slide 1. Put the evidence on slides 2–4. Use the remaining slides for appendix. If the meeting gets cut short, the decision still got made.

---

Phase 6: Decision and Action

What happens here: The business makes a decision and takes action — ideally based on what you just presented.

Why analysts must care about this phase: Your job is not finished when you send the analysis. Analytics that does not influence action is a cost center, not a value driver.

What you should track: - Was the recommendation adopted? Why or why not? - What was the outcome of the action taken? - What new questions did the decision generate?

Closing the loop: The best analysts build feedback mechanisms. If the Q3 analysis leads to a new sales incentive program, the analyst should be involved in measuring whether it worked — which starts the lifecycle over with a new business question.

Key rule: analytics is a loop, not a line

Every answered question generates new questions. An analyst who tracks outcomes becomes invaluable because they accumulate institutional knowledge about what works. An analyst who only produces reports and never follows up on outcomes is replaceable.

---

How Analysts Fit in Cross-Functional Teams

A data analyst typically sits at the intersection of several functions:

            Finance
               │
    Product ───┼─── Marketing
               │
          [Analyst]
               │
    Engineering─┼─── Operations
               │
          Leadership

Relationships and what you provide each:

Partner	What they bring to you	What you provide to them
Finance	Budget data, actuals, P&L structure	Revenue attribution, cost analysis, variance explanations
Product	Feature usage data, experiment results	User behavior analysis, funnel analysis, A/B test results
Marketing	Campaign data, channel spend	Attribution, ROI analysis, audience segmentation
Engineering	Data pipelines, system logs	Query requirements, data quality feedback
Operations	Process data, capacity metrics	Efficiency metrics, bottleneck identification
Leadership	Strategic priorities, decision authority	Executive summaries, KPI dashboards

The political reality: Being a good analyst means managing relationships, not just running queries. The analyst who is trusted by finance, product, and engineering simultaneously is worth significantly more than one who only serves one team.

---

Common Lifecycle Failure Modes

Phase	What Goes Wrong	Result
Business Question	Vague brief accepted without clarification	Wrong output delivered; rework
Data Collection	Assumed data is available or accurate	Analysis based on bad data
Data Cleaning	Transformations not documented	Can't reproduce results; audit failure
Analysis	Correlation mistaken for causation	Bad business decision
Visualization	Findings buried in jargon or too much data	Decision not made
Decision/Action	Analyst not in the room when decision happens	Findings ignored or misinterpreted

---

Key Takeaways

What you should be able to say without notes

1. The analytics lifecycle has six phases: business question, data collection, cleaning, analysis, visualization, decision.
2. Phase 1 (business question) is the most commonly skipped and the most expensive to skip.
3. Phase 3 (cleaning) takes 70–80% of the time on most projects — that is normal.
4. The deliverable is a recommendation, not a chart.
5. Analytics is a loop — outcomes generate new questions.

---

Previous: 00-agenda | Next: 02-types-of-analytics