StudentStudent
Sign out

MODULE 01 · CHAPTER 1.5 · BEGINNER

Analytics Methodology

Plan an end-to-end, auditable analytical workflow.

~1 h instructor-led~2 h independentVideo → reading → lab → quiz
INSTRUCTOR VIDEO · CHAPTER 1.5

Video lesson — Analytics Methodology

Reserved space for your recorded lesson. Add its URL to assets/app.js → VIDEO_URLS['1.5'] to display the video here.

Step 1: Watch the video before reading.Video awaiting upload

Chapter 1.5 · Analytics Methodology

An analyst can produce a correct calculation and still deliver the wrong answer. A revenue report may use an outdated extract; a predictive model may target a question the business did not ask; or an attractive dashboard may hide the fact that its totals never reconciled. An analytical methodology reduces these risks by making the work repeatable and reviewable.

Consider again Meridian Retail. To explain a revenue decline responsibly, the analyst must move between business understanding, data sourcing, preparation, exploration, validation and communication. These activities are connected. A discovery during exploration may change the original business question; a failed quality check may require a new data extract.

Learning objectives
  • Describe the end-to-end analytics lifecycle
  • Use a CRISP-DM-style iterative workflow
  • Distinguish cleaning from validation
  • Plan quality gates and peer review
  • Document analysis so that a colleague can reproduce it

1.5.1 The analytical lifecycle

An effective project starts by understanding the business objective and the required decision. Next, the analyst identifies relevant sources, checks their fitness for use, prepares the information, explores it for patterns and exceptions, performs appropriate analysis, validates the findings and communicates a decision-ready result. Monitoring follows if the output becomes a recurring process.

An iterative workflow
DEFINEDecision
SOURCEData
PREPAREQuality
ANALYSEEvidence
COMMUNICATEAction
Figure 1.5 — Quality reviews happen throughout; discoveries may send the team back to earlier stages.

This sequence resembles the spirit of CRISP-DM (Cross-Industry Standard Process for Data Mining), which groups work into business understanding, data understanding, data preparation, modelling, evaluation and deployment. Not every reporting project needs a predictive model; the important principle is to work iteratively and validate results against business objectives.

1.5.2 Business understanding and analytical design

Start by defining the decision, owners, reporting period and measures of success. Decide whether the task is descriptive, diagnostic, predictive or prescriptive; this influences the data and techniques required. For Meridian, the initial task is largely descriptive and diagnostic. A forecasting model would be premature until the underlying measurements are trustworthy.

A short design note should identify the population of interest, proposed metrics, expected outputs, key comparisons, constraints and known uncertainties. This note becomes a reference when the team encounters ambiguous fields or unexpected results.

1.5.3 Data sourcing and preparation

Obtain data through approved channels and retain source details, extract times and business owners. Data preparation may involve standardizing dates, converting types, handling missing values, filtering cancelled transactions and combining related tables. These are transformations, not invisible corrections: record what changed and why.

Suppose the sales file includes a duplicate order and a missing channel. Silently dropping both rows could alter reported revenue without an audit trail. A better approach is to quantify the issue, agree on a rule, apply it consistently and preserve a reconciliation table. Analysts should distinguish actual errors from valid but unusual business activity.

1.5.4 Exploration and hypothesis testing

Exploration uses totals, distributions, time trends and comparisons to understand what the data contain. For Meridian, compare August and September net revenue by channel, order volume and average order value; then inspect daily patterns. Write hypotheses explicitly, such as “The decline is concentrated in the online channel.”

A hypothesis is not proven simply because one chart appears to support it. Check alternative explanations, data quality and sample stability. Correlations can arise from confounding factors, measurement changes or coincidence. Where causality matters, investigate the design of experiments, natural comparisons or other defensible evidence.

1.5.5 Quality gates and validation

A quality gate is a condition that must be met before work proceeds or is published. At the source stage, check permissions and documentation. During preparation, test completeness, types, date ranges and unique IDs. Before reporting, reconcile totals, inspect exceptions and ask a second reviewer to test the logic.

GateCheckPass condition
SourceApproved extract with period and ownerSource metadata recorded
IntegrityMissing keys and duplicate order IDsAll material exceptions resolved or disclosed
ReconciliationMonthly totals versus finance controlDifference within agreed tolerance
InterpretationMetric definitions and denominator alignmentReviewed by relevant business owner
PublicationSources, caveats and decision ownerReview sign-off documented

1.5.6 Reproducibility and responsible reporting

Reproducible work can be followed, reviewed and rerun by someone other than the original author. Keep a clean source dataset, document transformations, store calculation logic and distinguish draft analysis from published results. Version major changes, and use clear filenames and data dictionaries rather than unexplained edits to one workbook.

Present the findings in a way that reflects the strength of the evidence. “Online conversion decreased in the measured periods” is supported by the given counts. “The new checkout caused the decrease” requires evidence beyond those counts. Document this distinction as part of validation, not as a footnote added afterward.

1.5.7 Applying the methodology to Meridian

The project begins with a short requirements brief. The analyst then loads the sales and traffic datasets, confirms the date boundaries, checks that order IDs are unique, reconciles monthly revenue and calculates the channel-level change. If online conversion appears lower, the analyst checks whether the traffic measurement remained stable, asks about relevant website changes and prepares a prioritized investigation plan. A reviewer verifies the formulas before the results reach management.

This sequence does not make uncertainty disappear. It makes uncertainty visible and shows stakeholders what is known, what is still being tested and what action can be taken now.

1.5.8 Chapter summary

Analytics is a controlled, iterative process—not merely data cleaning followed by charts. Define the decision, source and prepare data responsibly, explore alternative explanations, validate figures with quality gates, and communicate conclusions at the strength the evidence justifies. Record enough detail for another professional to understand and reproduce the work.

Finished the chapter?

Mark your reading complete, then move to the separate learning activities.