Exploratory Data Analysis: Steps, Methods, and Examples

Someone exports fourteen months of orders, plots revenue by month, and announces in Slack that growth has stalled. It has not. The final bar covers eleven days of a month that is not over yet. That one mistake, reading a trend from a partial period, has quietly ruined more decisions than any modelling error I have seen. Exploratory data analysis exists to catch things like that before they turn into slides, budgets, and a hiring freeze.

The useful way to think about exploratory data analysis is as a sequence you actually walk, not a mood you get into with a plotting library. Profile the columns. Check the distributions and the missingness. Look at relationships between variables. Only then decide what is worth modelling, forecasting, or escalating. Each step has a specific output and a specific failure mode when you skip it. This guide walks the sequence with small business examples, orders, support tickets, and sales pipeline, because that is the data most teams actually have, and flags the traps that make confident people wrong.

What exploratory data analysis actually is

John Tukey named exploratory data analysis in the 1970s to argue for something unfashionable at the time: looking at data before testing hypotheses about it. Confirmatory statistics asks "is this effect real?" Exploratory work asks the prior question, "what is in here, and is it even the shape I assumed?"

That framing still holds. Exploratory data analysis in data science sits between raw extraction and any model. Its job is to build an accurate mental picture of a dataset: what each column means, how clean it is, how values are distributed, what varies with what, and where the data stops being trustworthy. The deliverable is not a dashboard. The deliverable is a set of decisions about what to do next and a written list of caveats.

Three things it is not, because the confusion is expensive:

It is not reporting. A report answers a settled question on a schedule. Exploration answers "what should we be asking?" If you already know the metric and the cut, you want ad hoc reporting, not exploration.

It is not data cleaning, though it finds the work. Exploration surfaces the duplicate customer records and the nine variants of "United States". Fixing them is a separate task.

It is not modelling. No model repairs a dataset where a third of the target column is missing, and missing for a reason. Exploration is how you find out whether modelling is worth attempting at all.

The exploratory data analysis steps, in order

Here is the sequence. The order matters because each step assumes the previous one produced a clean answer.

Most people start at step 5 because relationships are the fun part. That is exactly how you end up presenting a correlation between two columns where one of them is null for half the rows that matter.

These EDA steps scale down as well as up. A twelve column export from a support tool deserves the same walk as a warehouse table, it just takes twenty minutes instead of two days.

Step 1 and 2: frame the question, then profile the columns

Framing takes five minutes and saves days. Write the decision down: "we are deciding whether to add a second support shift", not "we are looking at ticket data". A decision tells you which variables are load bearing and which are scenery.

Then profile. For every column, get: data type, number of non null values, number of distinct values, and a few real examples. The profile alone answers questions people otherwise argue about for a week.

What to look for while profiling:

Cardinality that contradicts the name. A column called customer_id with 40,000 rows and 39,998 distinct values is fine. A column called customer_id with 40,000 rows and 40,000 distinct values is probably an order ID that someone renamed.

Types that are secretly strings. Revenue stored as text with currency symbols, dates stored as MM/DD/YYYY strings that sort alphabetically, booleans stored as "Yes", "yes", "Y", and "TRUE". Every one of these produces a plausible looking chart that is wrong.

Constant or near constant columns. If country is "US" for almost every row, it is useless for segmentation, but the remainder may be exactly the rows with tax anomalies.

Free text fields pretending to be categories. Lead source typed by hand gives you "Google", "google ads", "GoogleAds", and "adwords" as four categories. This is the most common reason marketing numbers do not reconcile, and it is worth reading alongside marketing report examples before you build on that field.

Timestamps without timezone. Ask which zone before you group by day. A UTC timestamp grouped by local day moves revenue across the date boundary, which is enough to make Mondays look weak.

Profiling is unglamorous and it is where most of the value hides. Half the surprising findings in any first pass are really profiling findings wearing a costume.

Distributions: what one variable tells you

Univariate analysis means looking at one variable at a time properly, which almost nobody does because the average feels sufficient. It is not.

For numeric variables, plot a histogram and read four things: center, spread, skew, and modality. Business data is relentlessly right skewed. Order values, ticket resolution times, days to pay an invoice, session lengths, deal sizes: all of them have a long right tail, which means the mean sits above the median and describes almost no actual case. If you report one number for a skewed variable, report the median, and report a high percentile next to it. "Median resolution time is 4 hours, the 90th percentile is 31 hours" is a sentence that changes staffing decisions. "Average resolution time is 9 hours" is a sentence that hides the problem.

Two humps in a histogram almost always means two populations got mixed. Mobile and desktop. Free plan and paid. Weekday and weekend. New customers and repeat. Splitting on the suspected variable and re-plotting is often the entire analysis.

For categorical variables, get value counts sorted descending and look at the tail. A category list with 6 real values and 40 typos tells you the field needs normalisation. A category where one value covers 94 percent of rows tells you the field will not be useful for splitting.

For dates, plot counts per day for the full history before you do anything else. This is where you see the gaps: the week the integration broke, the day the migration double loaded, the point where a field started being populated. It is also where you see the partial period at the right hand edge, which brings us to the traps.

Missingness, duplicates, and the traps that end analyses

Data integrity is the step people compress into "I checked for nulls". Missingness has structure, and the structure is usually the finding.

Missing is rarely random. In a CRM, deal_value is often empty precisely for deals that never got qualified. Drop those rows and your average deal size jumps, because you deleted the small ones. Ask why a value is missing before deciding what to do with it. Three cases worth separating: missing because it does not apply, missing because a process failed, and missing because someone did not fill in the form. Only the third is close to random.

Duplicates hide behind near matches. Exact duplicate rows are easy. The expensive kind is the same customer appearing as three records with different email casing, or an order that got retried and written twice with different IDs and identical timestamps and amounts. Group by the fields that should be unique together, amount plus timestamp plus customer, and look at the counts.

Test and internal records. Almost every production dataset contains orders from @yourcompany.com addresses, a Stripe test customer, and a deal named "TEST DO NOT USE" worth ten million. Find them once and write the exclusion rule down.

The partial period trap. The last bar in any time series is almost always incomplete, and it always looks like a collapse. Either exclude the current period, or plot it in a visually distinct way, or use a trailing window. Related: month length. February will look like a bad month forever if you compare raw monthly totals without normalising for days, and a month with five Mondays will beat one with four in any B2B dataset.

Survivorship in your own systems. If your CRM deletes or archives closed lost deals after a year, historical win rate computed from current data will look magnificent. Same for support tools that purge spam tickets, and for board tools where completed cards get archived, which is one reason Trello reporting tends to overstate throughput unless you account for what left the board.

Simpson's paradox. A metric can improve in every segment while getting worse overall, if the mix of segments shifts. Whenever an aggregate moves and no segment explains it, check whether the composition changed.

Timezones, currencies, and refunds. Three columns that quietly break revenue analysis: mixed currency in one amount column, refunds stored as separate positive rows rather than negatives, timestamps in the tool's local zone rather than yours.

Relationships: the bivariate and multivariate pass

Only now do you look at how variables move together. The techniques depend on the pair of types.

Two rules that survive contact with real data. First, always plot before you trust a coefficient: a correlation near zero can hide a clean U shape, and a correlation near one can be produced by two outliers. Second, when a relationship looks strong, immediately ask what third variable could produce it. Deals with more logged calls close more often, and both are caused by the deal being real in the first place.

For a first pass, grouped summaries beat fancy plots. "Median days to close by lead source, with counts" is a five row table that answers more questions than a correlation matrix. Add the counts, always, so nobody builds a strategy on a segment with nine rows.

Data exploration techniques worth having in your hands

A short list of exploratory analysis methods that repay the effort:

Five number summary per numeric column. Min, 25th percentile, median, 75th, max. Compare min and max against physical reality: negative quantities, ages of 999, dates in 1970 or 2099. These are sentinel values, not observations.

Missingness heat map. Rows by columns, coloured by null. Blocks of missingness reveal when a field started being collected or when an integration failed.

Rolling averages for anything daily. Seven day trailing average removes the day of week pattern that otherwise dominates every operational chart.

Cohort tables. Group by signup month and follow each cohort forward. Cohorting separates "our product got worse" from "we acquired more of a worse fit segment", which no aggregate retention number can do.

Outlier interrogation, not removal. Look at the top ten and bottom ten rows for the key metric individually. Read them. Most outliers are either data errors worth fixing or the most interesting customers you have. Deleting them because they are inconvenient is how you lose both.

Sanity reconciliation. Pick one number you can verify elsewhere, last month's revenue in the payment processor, ticket volume in the support tool, and make your extract match it before you go further. If it does not match, the difference is the finding.

If the exploration points outward at a market rather than inward at your systems, the same discipline applies to sourcing: see market research reports for how to check the base of a third party number.

Worked examples: orders, tickets, and pipeline

Orders. Question: which product line should we discount in Q4? Profile shows discount_code is null for 71 percent of rows, and the nulls are concentrated before a date, which is when the field was added. That kills any full history comparison, so the analysis window shortens. Univariate on order value shows a long right tail and a spike at exactly one value, which turns out to be a bundle SKU. Bivariate on product line by month shows one line growing, but the growth disappears when you split by channel: a single marketplace integration went live mid period. The honest conclusion is not "line B is growing", it is "channel X launched", and the discount decision changes completely.

Support tickets. Question: do we need a second shift? Distribution of resolution time is right skewed with a median under four hours and a heavy tail. The tail is not random: cross tabbing by created hour shows tickets opened after 18:00 local carry most of it. But integrity check first, because the tool stores timestamps in UTC and the team is not in UTC. After correcting, the pattern holds and the case is real. Without the timezone check, the same chart would have pointed at the wrong hours.

Pipeline. Question: is win rate falling? Deal records for closed lost stages are archived after twelve months, so historical win rate is inflated. Within the trustworthy window, win rate by source shows one source dragging the average, and that source doubled in volume. The aggregate fell while every segment held steady, a textbook mix shift. Anyone maintaining pipeline data seriously runs into the same field hygiene issues described in financial CRM software and, for client work, in agency CRM.

An EDA checklist you can run in an hour

Print this. It is the EDA checklist I would hand a new analyst on day one.

1. Write the decision this analysis feeds in one sentence.
2. Row count, column count, and date range of the extract.
3. Per column: type, null rate, distinct count, three sample values.
4. Reconcile one total against the source system.
5. Histogram every numeric column, value counts for every categorical.
6. Plot record counts per day across the full history and look for gaps.
7. Identify and exclude test, internal, and refunded records. Write the rule down.
8. Check duplicates on the natural key, not just exact row matches.
9. Confirm timezone and currency handling explicitly.
10. Drop or flag the incomplete final period.
11. Grouped summaries for the three most plausible splits, with counts.
12. Read the top and bottom ten rows on the key metric individually.
13. Write the caveats list before writing the conclusion.

Point 13 is the one that separates an analyst from someone with a plotting library. The caveats list is a deliverable, and it is the part that survives longest. Knowing which questions your data can and cannot answer is most of what a business intelligence analyst actually does in the first month at any company.

Where Skopx fits in exploratory data analysis, and where it does not

Let us be exact about this, because the category is full of tools claiming to replace analysis.

Skopx is not a notebook. It does not replace pandas, R, a warehouse, or a statistician. It builds no dashboards, stores no warehouse tables, and runs no ETL pipelines. If your exploration needs a distribution fit, a regression diagnostic, or a reproducible script your team can review, open an IDE. Nothing here changes that.

What Skopx is useful for is the pass that happens before anyone opens an IDE. It is an AI workspace that connects to nearly 1,000 tools a company already uses, Gmail, Slack, Stripe, HubSpot, QuickBooks, Google Analytics and more, and answers questions in chat with citations back to the underlying records. In the exploratory phase that maps onto a few honest jobs:

Scoping questions before extraction. "How many orders do we have with a null discount code, and when did that field start being populated?" is a question you would otherwise answer by exporting a CSV. Getting it in chat, with the source cited, tells you whether the extract is worth building.

Finding where the data lives. In most companies the hardest part of a first pass is knowing which of five systems holds the authoritative version of a number. Search across connected systems is what enterprise search products charge heavily for, as Glean pricing shows, and it is the same job here at a far lower price point.

Catching anomalies you were not looking for. The insights engine flags risks and unusual movements across connected tools, and the morning brief surfaces them without anyone running a query. That is not analysis, it is a prompt to go and analyse.

Standing checks. Workflows built by describing them in chat can run a recurring integrity check so the same trap does not catch you twice.

Weekly data integrity check before analysis

Monday 08:00

Weekly schedule

Pull last week's records

Orders, tickets and deals from connected systems

Profile columns

Null rates, distinct counts, date range

Flag anomalies

New null spikes, duplicate keys, test records

Post summary to Slack

With links back to the source records

Pricing is Solo at $5 per month and Team at $16 per seat per month, and you bring your own AI key for any major model with zero markup, which is set out on the pricing page. The reason that matters for exploration specifically is that a first pass involves a lot of cheap, half formed questions, and you should not be rationing them.

Where it does not fit: anything requiring statistical rigour, reproducibility, or a defensible methodology. Chat answers are a starting point that you verify, not a citation for a board deck. Treat the first pass as reconnaissance and the notebook as the actual analysis.

Frequently asked questions

How long should exploratory data analysis take?

For a single business dataset with a few dozen columns, a focused first pass is a few hours, and the checklist above is an hour of it. For a new warehouse table feeding a model, budget days. The signal that you are done is not that you ran out of plots, it is that you can write the caveats list and state which questions the data can answer.

What is the difference between exploratory data analysis and reporting?

Reporting answers a known question repeatedly and is optimised for consistency. Exploration answers "what is going on here" once and is optimised for discovery. Reports need stable definitions, exploration deliberately questions the definitions. A useful rule: if you would be annoyed when the number changes, it is a report.

Which data exploration techniques matter most for small business data?

Distribution plots on your key numeric columns, value counts on every categorical field, a record count per day across the full history, and grouped summaries with counts attached. Those four cover most first pass findings in orders, tickets, and pipeline data. Correlation matrices and dimensionality reduction are usually premature at that size.

Do I need Python for exploratory data analysis?

No, though it helps beyond a certain size. A spreadsheet handles profiling, distributions, and cross tabs for tens of thousands of rows. Python or R earns its place when you need reproducibility, larger data, or statistical methods a spreadsheet handles badly. The exploratory analysis methods are the same either way.

What is the most common mistake in exploratory data analysis?

Reading a trend from an incomplete period. The current month, week, or day is nearly always partial, and it nearly always looks like a decline. Second place goes to reporting a mean on a right skewed distribution, which understates how bad the tail is.

Can an AI tool do exploratory data analysis for me?

It can accelerate the reconnaissance: locating the data, summarising what is in it, answering scoping questions with citations. It cannot own the judgement calls, why a value is missing, which rows are legitimately excluded, whether a relationship is plausible. Use AI to shorten the path to the right question, then do the analysis properly.