Big data for marketers: what actually changes and what does not

The slide that promised everything

Last autumn I sat in on a vendor pitch with the owner of The Gift Bow, my Solidus demo hamper shop that I treat throughout this series as if it were a real client. The slide said "Unlock the power of your big data". The shop has about 20,000 customers, 61,000 order lines and 240 products. All of it fits in a spreadsheet. The vendor wanted a five figure annual licence to stream it into a customer data platform and run AI driven recommendations. Afterwards the owner asked me, a little embarrassed, whether she had big data. She does not. She has a good small dataset and three or four questions she has never asked of it.

A week later the founder of Werkbank, the Rails SaaS for craft businesses I also use as an example, told me the opposite worry. Werkbank writes about 40 million application events a year: every quote opened, every invoice sent, every drag on the scheduling calendar. He felt he was sitting on a gold mine and mining none of it. He is half right. This chapter is about telling those two situations apart, about what genuinely changes when the data gets big, and about what does not change at all, which is most of it. As everywhere in this series, the numbers are illustrative.

Where this sits in the series

This is chapter 21 of 21 and the second half of part five, testing and big data. The previous chapter, Statistical testing: sample size, lift and full factorial designs, was about learning as much as possible from a deliberately small experiment. This one is about the opposite temptation: believing that enough rows will do the thinking for you. It leans on the very first chapter, Statistics for marketers: the numbers you cannot skip, because nothing in that chapter stops being true when the table gets longer. There is no next chapter, only a checklist and an invitation.

What big data is, and what it is not

The textbook definition has three Vs, and they describe three genuinely different situations. Volume: more rows than one machine handles comfortably, which in 2026 means hundreds of millions, not hundreds of thousands. Variety: data that does not arrive as tidy columns, such as free text reviews, support chats, product photos, clickstreams and server logs. Velocity: data that arrives continuously and needs an answer before the next batch, such as fraud scoring or a nudge inside an app. What big data is not is a strategy. It describes the input and promises nothing about the output. A bad question asked of 100 rows is still a bad question at 100 million. "Which customers should we contact" is a bad question; "which customers would buy a second hamper in December if reminded, and would not without the reminder" is a good one, and it needs the incremental thinking from the testing chapter far more than it needs rows.

Measured against the three Vs, The Gift Bow has none. Werkbank has a little of two. Its 40 million events are a real volume for a small company, and a handful of decisions do need velocity, such as noticing that a trial account has not created a single quote three days in. But almost every question worth asking collapses those events to 1,400 rows, one per paying account, or 9,000 rows, one per trial. The unit of analysis is the account, and there are not many accounts. That is small data wearing a big coat.

Why more rows rarely fix a bad question

A bigger dataset does two things for you and refuses to do a third. The first thing it does is shrink random error. Recall from chapter 1:

$$SE(\bar{x}) = \frac{\sigma}{\sqrt{n}}$$

Here $SE(\bar{x})$ is the standard error of a mean, $\sigma$ is the standard deviation in the population and $n$ is the number of observations. Go from 1,000 rows to 100,000 and your estimate becomes ten times more precise. That is real. It is also precision about whatever you happened to measure, including the wrong thing.

Because the third thing, the one it refuses to do, is remove bias. If The Gift Bow measures the effect of its Christmas email by comparing repeat purchases among people who received it with those who did not, the second group consists of people who unsubscribed, bounced or never opted in. They were less engaged before any email went out. That comparison is biased with 20,000 rows and exactly as biased with 20 million. More data makes the wrong answer more confident, which is worse, because someone will act on it.

The second thing a bigger dataset does is let a model learn more of the pattern that is actually in the columns. The useful way to think about it is a learning curve:

$$E(n) = E_{\infty} + \frac{a}{n^{b}}$$

$E(n)$ is the prediction error of a model trained on $n$ rows. $E_{\infty}$ is the floor: the error you would still have with infinite rows, because the things that decide the outcome are not in your columns at all. $a$ scales the curve and $b$, typically between 0.3 and 1, is how quickly the error falls. The row count moves you along the curve. The columns set the floor. A model of repeat hamper buying with no idea whether the first purchase was a gift or a treat for oneself will plateau early, however many customers you pour in.

Here is what that looked like when I fitted a repeat purchase model on The Gift Bow's customers with growing training samples, measured by AUC on a holdout year (0.5 is a coin toss, 1.0 is clairvoyance):

Diminishing returns: the last 80,000 rows buy one point of AUC. The 50k and 100k bars are simulated by resampling, the shop does not have that many customers.

The interesting comparison is not on the chart. At 5,000 rows I added one column, a flag for whether the delivery address differed from the billing address, my best proxy for a gift purchase. AUC went from 0.72 to 0.78. One column at 5,000 rows beat 95,000 extra rows. That is the whole argument of Counting and summing beats machine learning in a single number, and it is why I ask about the columns before I ask about the rows.

What genuinely changes

Some things do change when the data gets big, and pretending otherwise would be as silly as the vendor slide.

For the analytics itself, three things. Streaming: when the decision has to be made before the next nightly batch, you are no longer in a modelling problem but an engineering one. Werkbank's "trial has not created a quote in three days" nudge needs an event stream, a threshold and a message queue. It does not need a model at all. Unstructured data: text, images and audio used to need a specialist team. In 2026 a language model turns 3,000 support tickets into twelve complaint categories in an afternoon, and from then on it is counting again. Variety has become the most useful V for small companies, precisely because the tooling caught up. Compute: a gradient boosted model on a million rows trains on a laptop in minutes. The barrier is no longer hardware. It is the question and the plumbing.

For strategy, two things. Speed of learning: the sample size maths from the previous chapter does not change, but the calendar does. A shop that used to learn once a year at Christmas can, with a clean event pipeline, learn something every week. Personalisation at scale: the segments from the middle of this series can in principle become individuals. In practice the constraint is not the model but the differentiation you can actually produce. The Gift Bow has 240 products and one person writing emails. She can deliver perhaps six different messages. A recommender that produces 20,000 distinct rankings is impressive and pointless if the template has one slot.

The exotic algorithms, in plain words

Every big data conversation eventually lands on the algorithms, so here they are without the mystique. I have written elsewhere about the difference between AI and machine learning; this table is about when each one earns its place against the regression you already know.

Technique	What it does, in plain words	Beats regression when	Stick with regression when
Gradient boosting (XGBoost, LightGBM)	Hundreds of small decision trees, each one correcting the mistakes of the ones before	Many predictors, strong non linearities and interactions, 10,000 plus rows, and prediction is the goal	You must explain the effect of a variable to a board, you have a few hundred rows, or the question is causal
Neural networks	Stacked layers of weighted sums with squashing functions	Images, audio, free text, long sequences, millions of examples	Tabular business data of any size an SME has
Clustering at scale (k means, mini batch variants, DBSCAN)	Groups similar rows without a target variable	Millions of rows where hierarchical clustering cannot run	The segmentation has no strategy behind it yet; the algorithm will not supply one
Recommendation engines (collaborative filtering, matrix factorisation)	"People who bought this also bought that", learned from a sparse customer by item matrix	Thousands of items, a long tail, many interactions per customer	A few hundred products where four rules cover 90 percent of the value
Regularised regression (lasso, ridge)	Regression with a penalty that shrinks or removes weak coefficients	Many candidate variables and not enough rows to trust them all	You already have a handful of theory driven variables

Since gradient boosting is the one that wins on tabular data, here it is in one line:

$$F_m(x) = F_{m-1}(x) + \eta \, h_m(x), \qquad h_m(x) \approx -\left.\frac{\partial L\big(y, F(x)\big)}{\partial F(x)}\right|_{F = F_{m-1}}$$

$F_m(x)$ is the model after $m$ rounds and $F_{m-1}(x)$ is what you had before this round. $h_m(x)$ is a small decision tree fitted not to the outcome but to the negative gradient of the loss function $L$, which for squared error is simply the residuals: what the previous model got wrong. $\eta$ is the learning rate, a number like 0.05 that stops any single tree being trusted too much. Fit, look at what you missed, fit a small model to the misses, add a fraction of it, repeat three hundred times. It is regression's stubborn cousin, and on messy tabular data with interactions you did not think of, it is usually a few points better than a hand built regression. A few points, not a different world.

Worked example: the hamper shop and Werkbank, question by question

Here are the two businesses side by side, with the questions their owners actually raised, the rows each question touches and whether any V is involved.

Question	Who asks	Rows it touches	Big data?	What actually answers it
Who is worth a Christmas reminder	The Gift Bow	20,000 customers	No	Recency, frequency and value plus a logistic regression
What should each email recommend	The Gift Bow	61,000 order lines	Not really	Rules by buyer type, or a small recommender, tested against each other
Why do trials not convert	Werkbank	9,000 trials	No	Funnel counts by onboarding step, then a logistic model on the steps
Which trial needs a nudge right now	Werkbank	40 million events	Velocity, yes	An event stream and a threshold rule, no model
What do customers complain about	Both	3,000 tickets and 1,200 reviews	Variety, yes	A language model classifying into twelve themes, then counting per month
Which accounts churn next quarter	Werkbank	1,400 accounts	No	A survival model with a handful of usage covariates

Six questions, two of which touch a V, and neither needs an exotic model. The velocity one needs a rule, the variety one a classifier and a bar chart. Everything else is small data, answered by the methods from parts two and three of this series.

The second row deserves a proper test, because it is where the vendor's pitch lived. In November I ran a three arm email to 18,000 of The Gift Bow's customers, 6,000 per arm, same subject line, same send time. Arm A recommended the three bestsellers to everyone. Arm B used a two variable logistic regression: buyer type (gift versus self, from the address flag) and the price band of the last hamper, four cells and four rules such as "gift buyer, premium band, show the two premium hampers and the corporate page". Arm C used an item to item collaborative filter trained on the full 20,000 by 240 purchase matrix, producing an individual ranking for each customer.

Arm	Method	Build effort	Orders per 1,000 emails	Revenue per email	Lift versus A
A	Three bestsellers for everyone	One hour	14.1	£0.92	baseline
B	Two variable regression, four rules	Two days	19.6	£1.31	plus 42 percent
C	Item to item recommender, individual ranking	Two weeks plus hosting	20.4	£1.38	plus 50 percent

Read it line by line. A is the honest baseline, and £0.92 per email is not bad for a shop this size. B, two days of work and four rules a human can read aloud, lifts revenue per email by 42 percent: 118 orders against 85. That gap is well outside noise on 6,000 per arm; run the maths from the previous chapter and the confidence interval never touches zero. C adds another 5 orders, 122 against 118, comfortably inside the noise. I cannot tell you that C beat B. I can tell you that C cost roughly ten times as much to build, needs a server and a retraining job, and produces rankings the shop cannot act on because the email template has three slots. With 5,000 products and millions of baskets a recommender is the only sensible option; at 240 products and 20,000 customers the two variable regression wins, because the structure of the business, gift versus self and a price band, carries most of the signal. Knowing that is worth more than the algorithm.

A data stack an SME actually needs

The stack that answers every question above is small, and I draw it here so nobody can sell you a bigger one without arguing against a picture.

One database, one nightly job, one schema, one dashboard tool and one place to run Python. Nothing here costs more than a mid range laptop per year.

The warehouse is a Postgres instance with a schema per source and a schema of cleaned tables, one row per customer, one per order, one per trial. The nightly extract is a scheduled script. The SQL models are a folder of views with names a marketer understands. The dashboard is Metabase or similar. The notebooks are where models get built, and the only output that leaves them is a scored list written back to the CRM. The consent ledger sits at the entrance, not at the exit.

What is not in the picture: a data lake, a streaming platform, a customer data platform, a feature store, a vector database. Each is a fine tool for a company whose nightly job takes longer than a night. Until then they are a fixed cost with no question attached. Werkbank's one velocity use case, the three day nudge, is a small worker process reading the application's own event table, inside the app, not in the stack.

Privacy by design, or the appetite problem

Big data has an appetite. Its instinct is to keep everything, because you never know what will turn out to be predictive. GDPR says the opposite: collect for a purpose, keep the minimum, delete when done. I have come to think the law is also good analytics advice. Fewer, cleaner columns with a purpose beat a wide table of things you happened to log.

In practice this means four habits. Pseudonymise at the extract, so the warehouse holds a customer key and not a name or an email address. Let the consent ledger decide what enters a model: a visitor who declined marketing cookies can appear in aggregate counts, but their events must never feed a retargeting audience or a personal score, and they need a different event name so nobody downstream mixes them in by accident. Set retention per table and let the nightly job enforce it. And report in aggregates: the dashboard shows segments and months, never a list of people; the only person level output is the scored list in the CRM the company already controls. None of this slows the analysis down. All of it removes a category of conversation with a lawyer.

Where AI fits in 2026

Since every pitch deck now says AI, it is worth being precise about what language models are good at in this stack; I have set this out at more length in my complete guide to AI in business. They are superb at variety: turning free text into columns. Classify 1,200 reviews into themes, extract the product mentioned in a complaint, tag whether a ticket is about delivery or the product. Give the model a fixed list of categories, hand label 200 examples yourself, and measure agreement before you trust it. They are also good at drafting SQL against a schema you show them and at explaining a coefficient table to a colleague.

They are not a prediction engine for numbers. Asking a language model which customers will churn is asking it to guess, fluently. They do not do causal inference, they invent confident figures when the data is missing, and they cannot tell you the confidence interval on anything. In this stack the language model sits in the box marked notebooks and models, as one tool next to logistic regression, and the statistics from chapter 1 sit in judgement over both. That has been my position since I wrote you do not need a data scientist yet, and 2026 has made it more true, not less: the exotic tools got easier, so the scarce skill is knowing which question to point them at.

Running it in practice

Here is the order of operations when someone tells me they have big data.

Start from the decision, not the dataset. Write down the three decisions the business will make differently if the analysis works; if nobody can name three, stop and do that first. Then find the unit of analysis for each decision, a customer, an account, a trial, a week, and collapse the raw events to one row per unit. That single step turns Werkbank's 40 million events into 9,000 rows:

-- One row per trial: what happened in the first three days?
select t.account_id,
       t.started_at::date                                   as trial_day,
       min(e.created_at) filter (where e.name = 'quote_created')   as first_quote_at,
       count(*)          filter (where e.name = 'calendar_drag')   as drags_3d,
       max(case when e.name = 'invoice_sent' then 1 else 0 end)    as sent_invoice_3d,
       t.converted
from trials t
left join events e
       on e.account_id = t.account_id
      and e.created_at <  t.started_at + interval '3 days'
group by t.account_id, t.started_at, t.converted;

Sample intelligently. For exploration, a stratified sample of 50,000 rows tells you everything a hundred million would, and it fits in memory anywhere. Then draw the learning curve before you argue about data volume, because the curve settles the argument:

from sklearn.model_selection import learning_curve
from sklearn.ensemble import HistGradientBoostingClassifier

sizes, train_auc, test_auc = learning_curve(
    HistGradientBoostingClassifier(max_iter=300, learning_rate=0.05),
    X, y, train_sizes=[500, 1000, 2000, 5000, 10000, 20000],
    cv=5, scoring="roc_auc", shuffle=True, random_state=7)

for n, auc in zip(sizes, test_auc.mean(axis=1)):
    print(f"{n:>6} rows   holdout AUC {auc:.3f}")

If the curve is still rising steeply at your full sample, more rows will help. If it has flattened, go and find a column. Then the checks before you trust anything: hold out by time, not at random, because a model that has seen December cannot be judged on December. Compare every exotic model against a regression with the same variables and report the gap honestly. Check calibration, meaning customers scored at 20 percent do buy about 20 percent of the time. Read the top twenty variables for anything that could only be known after the outcome. For a company like these two, the cycle from first extract to a scored list and a decision memo takes two to four weeks. If a proposal says six months, the months are for the stack, not the answer.

Pitfalls

Leakage grows with width. The more columns you have, the more likely one of them quietly knows the future. A churn model I reviewed had "cancellation reason" among its predictors and an AUC of 0.99. Big data makes this more likely, not less, because nobody has read all the columns.

Precision mistaken for truth. On two million rows every coefficient is significant and every p value is a row of zeros. That tells you the effects are not exactly zero, which you knew. Report effect sizes with intervals and ask whether the effect is large enough to change a decision, exactly as in chapter 1.

Predictions nobody can act on. Twenty thousand rankings and one email template. A churn score updated hourly and an account manager who calls on Thursdays. Match the granularity of the model to the granularity of the action, or the model is decoration.

Training on the wrong season. A model trained on January to October and deployed in December has never seen a corporate order. Velocity makes this worse, because the model retrains automatically and drifts confidently. Hold out by time and look at the calendar.

How I do this for clients

When a company comes to me with a big data question, the first deliverable is usually smaller than they expected, and better. It begins with the free workshop: half a day in which we write down the decisions, name the unit of analysis for each, and look at the actual tables. Often we discover in that room that the data is small and the question is good, which is the best possible outcome. Then two weeks of real work on me, before anyone commits to anything.

The data I need is an export from the shop or application database, the event table if there is one, the CRM and email tool, and the consent records. At the end of the two weeks the client gets a two page decision memo: for each question, the method, the number, the error margin and the risk, and an honest verdict on whether more data would change it. Where a model is warranted, they get the model itself, versioned in their own repository, a scored list in their CRM, and a dashboard that answers one question per screen. Where a stack is needed, I build the small one from the diagram above and hand over the keys; it is yours, as everything I build is. My data science work covers the modelling; where personalisation belongs on the site itself rather than in an email, the smart websites practice picks it up. What it costs is set out plainly on the pricing page: a fixed monthly capacity from one accountable person, or, for growth work, a commission on results. Nobody pays for a data lake they will never fill.

Questions to ask before anyone says big data again

• Which three decisions will we make differently if this analysis works, and who makes them?
• What is the unit of analysis, and how many rows does the question really have once we collapse to it?
• Have we drawn the learning curve, and is it still rising at the data we already own?
• Which column, not which extra rows, would most reduce the error floor?
• Can the marketing team act on the model's granularity with the templates and people they actually have?
• Where does the consent ledger sit in the pipeline, and what happens to a visitor who said no?

This series is inspired by Mike Grigsby's Marketing Analytics (Kogan Page). The explanations, examples and numbers here are my own.