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.
- 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.
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.
| Gate | Check | Pass condition |
|---|---|---|
| Source | Approved extract with period and owner | Source metadata recorded |
| Integrity | Missing keys and duplicate order IDs | All material exceptions resolved or disclosed |
| Reconciliation | Monthly totals versus finance control | Difference within agreed tolerance |
| Interpretation | Metric definitions and denominator alignment | Reviewed by relevant business owner |
| Publication | Sources, caveats and decision owner | Review 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.
