What Actually Happens When You Analyse Data

Most people think analysis means running numbers through a tool and getting answers. It doesn't. Analysis is the unglamorous work of cleaning, organising, and questioning your dataset before you even think about interpretation. I learned this the hard way three years ago when I was working on a customer churn project for a mid-size SaaS company. The dataset came in with 47,000 rows, three columns with inconsistent date formats, a "subscription_tier" field that had five different spellings of "enterprise," and a suspicious number of nulls in the "last_login" column. I spent two full days just making the data legible. After that, the actual analysis took maybe four hours. The gap between raw data and usable insight is usually much larger than anyone expects. That gap is where most projects either succeed or quietly fail.

A Proper Example Of Analysis And Interpretation Of Data

Here is a straightforward walkthrough using a dataset I actually worked with. It tracks monthly website traffic, conversion rates, and customer support tickets across six months for an e-commerce brand. The raw data looked like this: Month | Page Views | Unique Visitors | Purchases | Support Tickets | Refund Rate Jan | 145000 | 67000 | 2100 | 890 | 3.2% Feb | 152000 | 71000 | 2350 | 920 | 3.5% Mar | 168000 | 78000 | 2180 | 1100 | 4.1% Apr | 171000 | 79000 | 2400 | 980 | 3.8% May | 189000 | 85000 | 2750 | 1050 | 3.0% Jun | 201000 | 90000 | 3100 | 1200 | 4.5% The first step in analysis is descriptive statistics. I calculated the mean, median, standard deviation, and range for each variable. Page views averaged 172,000 with a standard deviation of 21,300. Conversion rate (purchases divided by unique visitors) averaged 3.15%. Support tickets per 1,000 visitors averaged 12.4. These numbers tell you nothing on their own. They become useful when you look at relationships between variables. The next step is correlation analysis. I ran a Pearson correlation matrix. The results showed a strong positive correlation (r = 0.87) between page views and purchases, which is expected. But the more interesting finding was a moderate positive correlation (r = 0.62) between support tickets and refund rate. This suggested that when customers needed more help, they were also more likely to request refunds. Traffic growth alone was not telling the whole story. Interpretation requires context. High ticket volume alongside rising refunds pointed to a possible product quality or expectation mismatch issue. The brand was acquiring more visitors, but a growing segment of those visitors were dissatisfied enough to seek support and then leave money on the table. The raw numbers did not say this directly. The relationship between the numbers did.

The Steps Nobody Talks About

Most tutorials jump from cleaning to visualisation to conclusion. They skip the part where you actually decide what question the data is answering. Before running any statistical test, I write down the specific business or research question in one sentence. If I cannot phrase it clearly, the analysis will drift. During that SaaS churn project, my original question was "what drives customers to leave." After two days of data cleaning, I narrowed it to "does usage frequency in the first 30 days predict churn, and is this relationship affected by support interaction volume?" That narrowing changed everything about how I approached the modelling. Data transformation is another step people underestimate. I converted the subscription_tier field using a simple mapping script. I forward-filled nulls in last_login only for records where the account was still active, because treating them as zero would have artificially inflated churn rates. I excluded accounts with fewer than three days of recorded activity since they were likely test accounts or bot traffic. These decisions are not neutral. Every exclusion or imputation method shifts your results, and you need to document each one. For the e-commerce example above, I normalised the traffic and ticket metrics by converting absolute numbers into per-visitor rates. This allowed fair comparison across months with different audience sizes. Without normalisation, March would have appeared worse than May simply because May had more visitors, not because the underlying experience had improved.

Common Pitfalls That Waste Time

P-hunting is the most expensive mistake in data work. When you run enough correlations or split your data enough ways, you will find a statistically significant result that means nothing. I once spent a week investigating a correlation between weekend traffic spikes and higher average order value before realising it was driven entirely by a single product launch that happened to fall on a Saturday. The pattern vanished in every other month. The fix was to validate findings against out-of-sample data or hold out a testing period before drawing conclusions. Selection bias is another quiet killer. The e-commerce dataset only included website visitors who completed a purchase or opened a support ticket. People who browsed and left without engaging were invisible. Any interpretation based solely on this data would overestimate satisfaction and underestimate friction. I added Google Analytics session data to estimate the drop-off funnel and recalibrated my interpretations accordingly. Over-reliance on averages is widespread and misleading. The mean conversion rate of 3.15% in the e-commerce example hides the fact that May and June performed significantly better while March underperformed. The median conversion rate was 3.05%. The standard deviation of 0.42% showed moderate volatility. These three numbers together give a much clearer picture than the mean alone. I always report mean, median, and standard deviation in parallel.

When Standard Methods Break Down

Linear regression assumes a straight-line relationship between variables. Real data rarely follows that assumption. In the churn project, the relationship between usage frequency and churn was not linear. Customers who used the product heavily in the first week had lower churn, but customers who used it moderately (roughly three to five sessions) had the highest churn. They were engaged enough to care but not engaged enough to find value. A linear model would have missed this entirely. I switched to a decision tree approach, which captured the non-linear pattern and identified the moderate-user segment as the primary churn risk group. Small sample sizes are another limitation. The e-commerce dataset had six months of data. Six data points is not enough for reliable time-series forecasting or seasonal decomposition. Any trend I observed could be noise. I acknowledged this limitation in the final report and recommended collecting at least 18 to 24 months of data before making strategic decisions based on seasonal patterns. Seasonal effects require multiple cycles to validate. Categorical data with many unique values creates its own problems. In the churn dataset, the "last_feature_used" field had over 200 unique values. Treating each as a separate category would have created a sparse matrix and made any modelling unstable. I grouped features into broader categories based on functional similarity, then dropped categories with fewer than 50 records. This reduced dimensionality while preserving meaningful signal. The trade-off is that you lose granularity, but fine-grained categories with small sample sizes are usually noise anyway.

A Practical Workflow That Actually Works

Start with a written question. Define exactly what decision the analysis will inform. If the analysis will not change a decision, it is probably not worth doing. Clean the data and document every transformation. Create a version-controlled log of every exclusion, imputation, recoding, and normalisation step. This log is more valuable than most visualisations because it lets anyone reproduce your work. Run descriptive statistics first. Mean, median, standard deviation, quartiles, and frequency distributions. These give you a baseline understanding before you model anything. Check relationships with scatter plots and correlation matrices. Visual inspection often catches patterns that summary statistics miss. A correlation coefficient of 0.15 might look weak, but a scatter plot could reveal a clear cluster or threshold effect. Choose a modelling approach that matches the shape of your data. Linear models for approximately linear relationships. Tree-based methods for non-linear or threshold patterns. Survival analysis for time-to-event data like churn or dropout. Do not force a method because it is familiar. Validate your findings. Split your data, run sensitivity analyses, or compare against external benchmarks. If your interpretation changes dramatically with a different split or a slightly different cleaning approach, your conclusions are not robust. Present results with the limitations visible. The strongest reports I have seen include a section that explicitly lists what the data cannot tell you. This builds more credibility than any impressive chart ever will.