Polynomial distributed lags: how long does marketing keep working?

TL;DR

Difficulty: Advanced

Most marketing works for weeks, not on the day, so a same week conversion rate undervalues every slow channel.

  • A distributed lag model gives one weight per week after the action. The sum is the total effect, the largest weight is the peak.
  • Unrestricted lags collapse under collinearity, above all with a regular send calendar.
  • The Almon restriction puts the weights on a low order polynomial, keeps it ordinary least squares and gives a stable curve.
  • In the example, a newsletter peaks a week after the send, is 94% delivered after three weeks and totals 4.27 orders per 1,000 emails.
  • The curve says when to send next. Only a split test says what more sends do to unsubscribes.

Most marketing does not work on the day you do it, and if you only count the effect in the send week, your budget drifts towards the fastest channel whether or not that is where the money is. I explain the distributed lag model and the Almon polynomial restriction that makes it work on ordinary business data, using 78 weeks of newsletter sends and orders at an invented Cork hamper shop, from the lag curve to a holdout check and a send cadence. Chapter 5 of 21 in the Marketing Analytics series.

The newsletter that keeps working after you have forgotten it

Priya runs Northgate Hampers, an invented online hamper shop in Cork at northgatehampers.example. She sends one newsletter a month to about 30,000 subscribers. Every send is followed by a bump in orders, and Priya, quite reasonably, counts the extra orders in the week of the send, divides by the emails sent and calls that the email conversion rate. It comes to just under one order per 1,000 emails, under 0.1%. Not exciting. She is about to cut the newsletter to once a quarter to save the writer's time.

The problem is that the bump in the send week is only the first instalment. A customer reads the email on Tuesday, mentions the Afternoon Tea Hamper to her sister, and they order it together ten days later for their mother's birthday. Some of the effect arrives in week two, some in week three. Measured properly, the newsletter is worth about 4.3 orders per 1,000 emails, more than four times what Priya counted, and nearly four fifths of it arrives after the week she stopped counting.

That is what a distributed lag model does. It tells you how much of a marketing action's effect arrives now, how much arrives later, and when it has finished arriving. Once you know that, you know when to send the next one. Northgate Hampers and every number in this chapter are made up so I can show each step.

Where this chapter sits in the series

This is chapter 5 of 21 in my Marketing Analytics series, in part two, the dependent variable techniques, where a business outcome (orders, bookings, enquiries) is explained by things you control. The previous chapter on demand and price elasticity used ordinary regression where cause and effect happen in the same period. This chapter adds time: the cause happens in week 10 and the effect dribbles out over weeks 10 to 15.

The next chapter on Poisson regression deals with a different problem, outcomes that are counts and cannot go negative. Later, in the chapter on media mix modelling and adstock, the lag idea comes back in a different costume. The basics used here, from the mean to regression, are built from scratch on the Foundations page.

One number for the email effect is the wrong shape

When you regress weekly orders on weekly emails sent, you get one coefficient: orders per 1,000 emails, in the same week. Every order that happens in a later week because of that email is credited to whatever else happened that week, or to the baseline, or to noise. The coefficient is too small, and the decision goes wrong in a predictable direction: you underinvest in anything with a slow effect and overinvest in anything with a fast one.

The fix is not a smarter single number. It is to admit the effect is a curve over time, estimate the curve, and then summarise it with the numbers that matter: where it peaks, when it has died, and what it adds up to.

An example: Priya's March newsletter goes to 30,000 subscribers. In the send week, orders are 28 above the usual level, so a same week rate says 28÷30=0.9328 \div 30 = 0.93 orders per 1,000 emails. Over the following three weeks orders run 40, 34 and 19 above normal while nothing else changed. A same week number credits the email with 28 orders. The curve credits it with 28+40+34+19=12128 + 40 + 34 + 19 = 121, and most of those would otherwise be put down to luck.

The distributed lag model

Write orders in week tt as yty_t and emails sent (in thousands) in week tt as xtx_t. A distributed lag model says this week's orders depend on this week's emails and on the emails of the previous LL weeks, each with its own weight:

yt=α+∑k=0Lβk xt−k+γ⊤zt+εty_t = \alpha + \sum_{k=0}^{L} \beta_k \, x_{t-k} + \gamma^\top z_t + \varepsilon_t

Here yty_t is the outcome in week tt, α\alpha is the baseline (orders that would happen with no email at all), βk\beta_k is the effect of 1,000 emails sent kk weeks ago on orders this week, xt−kx_{t-k} is the emails sent kk weeks before week tt, LL is the lag length (how many weeks back the effect may reach), ztz_t is a set of controls such as paid search spend, holiday weeks and a trend, γ\gamma holds their coefficients, and εt\varepsilon_t is the error. The weights β0,β1,…,βL\beta_0, \beta_1, \dots, \beta_L are the lag curve, and the curve is the whole point. It is a multiple regression like any other, with lagged copies of one variable as the inputs. Foundations: regression

Three summaries of the curve do most of the work. The total effect is the sum of the weights:

βtotal=∑k=0Lβk\beta_{\text{total}} = \sum_{k=0}^{L} \beta_k

Here βtotal\beta_{\text{total}} is how many orders 1,000 emails eventually produce, across every week in which they produce anything, and βk\beta_k and LL are as above. It is a plain sum, the same operation that sits on top of the mean. Foundations: the mean The peak lag is the kk with the largest βk\beta_k. And the mean lag is the average delay, weighted by how much effect arrives in each week:

kˉ=∑k=0Lk βk∑k=0Lβk\bar{k} = \frac{\sum_{k=0}^{L} k \, \beta_k}{\sum_{k=0}^{L} \beta_k}

Here kˉ\bar{k} is the mean lag in weeks, kk is each lag and βk\beta_k its weight. It is a weighted mean, with the weights doing the job that counts do in an ordinary average. Foundations: the mean

Worked example: the summaries for Priya's curve

Using the curve estimated later in this chapter (0.92, 1.33, 1.13, 0.64, 0.18 and 0.07 orders per 1,000 emails for lags 0 to 5):

βtotal=0.92+1.33+1.13+0.64+0.18+0.07=4.27\beta_{\text{total}} = 0.92 + 1.33 + 1.13 + 0.64 + 0.18 + 0.07 = 4.27

The total, βtotal\beta_{\text{total}}, is 4.27 orders per 1,000 emails. The peak is at lag 1, where β1=1.33\beta_1 = 1.33 is the largest weight. For the mean lag, multiply each weight by its lag: 0+1.33+2.26+1.92+0.72+0.35=6.580 + 1.33 + 2.26 + 1.92 + 0.72 + 0.35 = 6.58. Then

kˉ=6.584.27=1.54\bar{k} = \frac{6.58}{4.27} = 1.54

so kˉ\bar{k}, the average delay between sending and ordering, is about a week and a half.

Why unrestricted lags fall apart

The obvious approach is to put xt,xt−1,…,xt−Lx_t, x_{t-1}, \dots, x_{t-L} into an ordinary regression and read off the coefficients. Here is what that gives on Northgate's 78 weeks, with five lags. The numbers are invented, but the pattern is what you see on real data.

Lag kkUnrestricted βk\beta_kStd. errorReads as
01.310.62plausible
10.420.88too low, noisy
22.050.91too high
3minus 0.660.87emails destroy orders?
41.170.83a second peak?
5minus 0.080.61zero, probably
Total4.211.38fine, oddly

Two things went wrong. First, there are too many parameters: six lag weights plus controls from 73 usable weeks (78 minus the five lost to the lags). Second, and worse, the lagged variables are nearly copies of each other. Northgate sends on a fixed monthly rhythm, so a send week is followed with great regularity by another send four or five weeks later, and lags 0 and 4 become almost indistinguishable to the regression. That is collinearity, and its symptoms are exactly these: individual coefficients that swing and change sign, wide standard errors, and a total that is oddly stable because the errors cancel.1 The total is right and every individual number is useless.

There is an irony here I point out to every client with a rigid send calendar: a perfectly regular cadence is easy to run and almost impossible to measure. A bit of irregularity in the send dates is a gift to whoever has to analyse them.

The Almon trick: make the weights follow a curve

Shirley Almon's idea, published in 1965, is simple and still the cleanest fix I know.2 Instead of estimating six free weights, assume the weights lie on a smooth, low order polynomial in the lag:

βk=a0+a1k+a2k2+⋯+apkp=∑j=0pajkj\beta_k = a_0 + a_1 k + a_2 k^2 + \dots + a_p k^p = \sum_{j=0}^{p} a_j k^j

Here βk\beta_k is the weight at lag kk (in weeks), pp is the degree of the polynomial (2 or 3 in practice) and the aja_j are the polynomial's coefficients. Instead of L+1L+1 weights you estimate p+1p+1 coefficients and recover the weights from them. A quadratic can describe a hump. A cubic can describe a quick rise, a hump and a long tail, which is the shape most marketing effects have. Foundations: regression

The clever part is that this is still ordinary least squares. Substitute the polynomial into the lag model and swap the order of the sums:

yt=α+∑j=0paj(∑k=0Lkj xt−k)+γ⊤zt+εt=α+∑j=0paj wjt+γ⊤zt+εty_t = \alpha + \sum_{j=0}^{p} a_j \left( \sum_{k=0}^{L} k^j \, x_{t-k} \right) + \gamma^\top z_t + \varepsilon_t = \alpha + \sum_{j=0}^{p} a_j \, w_{jt} + \gamma^\top z_t + \varepsilon_t

Each wjt=∑kkjxt−kw_{jt} = \sum_{k} k^j x_{t-k} is a constructed variable: w0tw_{0t} is the plain sum of the last L+1L+1 weeks of emails, w1tw_{1t} is the same sum with each week multiplied by its lag, w2tw_{2t} by the lag squared, and so on. The other symbols (α\alpha, aja_j, γ\gamma, ztz_t, εt\varepsilon_t) are as before. You build these columns in a spreadsheet or a few lines of code, regress yty_t on them and the controls, and the aja_j fall out. Then each βk\beta_k is the polynomial evaluated at kk.3 Foundations: regression

What you buy is stability: six weights now share four parameters, so they cannot flip sign from one lag to the next. What you pay is an assumption, that the true curve is smooth. For emails, catalogues and most advertising that is a good assumption. For a flash sale with a hard deadline it is not, and the pitfalls come back to it.

Worked example: building one Almon column

Take week 30. The emails sent (in thousands) in weeks 30 back to 25 were 0, 0, 30, 0, 0, 0, so only lag 2 has a send (x28=30x_{28} = 30). The four columns for week 30 are:

w0,30=20×30=30,w1,30=21×30=60,w2,30=22×30=120,w3,30=23×30=240w_{0,30} = 2^0 \times 30 = 30, \quad w_{1,30} = 2^1 \times 30 = 60, \quad w_{2,30} = 2^2 \times 30 = 120, \quad w_{3,30} = 2^3 \times 30 = 240

Each wj,30w_{j,30} is the lagged emails weighted by the lag to the power jj. One send two weeks ago becomes four numbers that tell the regression both how much was sent and how long ago. A send in week 29 instead would give 30, 30, 30 and 30, because 1j=11^j = 1, and the regression can tell those two weeks apart.

Choosing the lag length and the degree

Two decisions, and neither should be made by staring at p values alone.

Lag length LL. Start generous. If you think the effect is gone in four weeks, fit with eight. Look at the tail weights: if β6\beta_6, β7\beta_7 and β8\beta_8 are indistinguishable from zero and the curve has flattened, cut back to where it died and refit. Compare the fits with an information criterion such as AIC or BIC, which reward fit but penalise parameters, and pick the shortest LL that is not clearly worse. Too short an LL is the expensive mistake: the late effect is silently pushed into the baseline and the total is understated.

Degree pp. Fit degree 2 and degree 3 and compare. If the cubic's a3a_3 is clearly different from zero and the curve has a visibly different shape, keep it. If not, the quadratic is grand. I very rarely go above 3 with weekly marketing data, because a quartic on 78 weeks is fitting noise.

Test the restriction itself, too. The Almon model imposes L−pL - p linear restrictions on the unrestricted lags (here 5−3=25 - 3 = 2), so an F test between the two nested models tells you whether the polynomial is too rigid. If it rejects at the 1% level, look at the residuals before believing either model. Foundations: hypothesis tests

Endpoint restrictions, forcing the weight just beyond the last lag or just before lag 0 to be zero, are available and sometimes sensible.3 I use the far endpoint when the tail is clearly zero. I never force the near end, because an instant effect is real for email.

Northgate's lag curve, week by week

Same 78 weeks, same controls, L=5L = 5 and p=3p = 3, chosen by the recipe above. The estimated polynomial coefficients are a0=0.92a_0 = 0.92, a1=0.83a_1 = 0.83, a2=−0.47a_2 = -0.47 and a3=0.054a_3 = 0.054. Evaluating the cubic at each lag gives the curve.

Worked example: from the coefficients to the weights

At lag 2:

β2=0.92+0.83×2−0.47×4+0.054×8=0.92+1.66−1.88+0.432=1.13\beta_2 = 0.92 + 0.83 \times 2 - 0.47 \times 4 + 0.054 \times 8 = 0.92 + 1.66 - 1.88 + 0.432 = 1.13

Here β2\beta_2 is the effect two weeks after the send, built from the four aja_j times 2j2^j. The same sum at every lag fills the table.

Lag kk (weeks after send)Almon βk\beta_k (orders per 1,000 emails)Std. errorCumulativeShare of total
00.920.210.9222%
11.330.192.2553%
21.130.173.3879%
30.640.164.0294%
40.180.154.2098%
50.070.194.27100%
Total4.270.54

Reading it line by line. Lag 0: in the week of the send, 1,000 emails produce 0.92 extra orders, about a fifth of everything they will ever produce. This is the number Priya was measuring, and she measured it correctly. It was just the wrong number. Lag 1: the following week is the peak, 1.33 orders per 1,000, and by its end just over half the effect has arrived. Lag 2 is still strong at 1.13, and by its end four fifths are in. Lag 3, at 0.64, is the last week that matters commercially. Lags 4 and 5 are small, with standard errors about as large as the estimates, so I read them as close to zero.

The total is 4.27 orders per 1,000 emails with a standard error of 0.54, so a 95% interval of 4.27±1.96×0.544.27 \pm 1.96 \times 0.54, roughly 3.2 to 5.3. Foundations: confidence intervals On a 30,000 email send that is about 30×4.27=12830 \times 4.27 = 128 orders per newsletter, somewhere between 96 and 160.

Compare the unrestricted table: the same total within noise, but now the shape is readable. A peak at one week, commercially dead after three, nothing after five.

Northgate Hampers lag curveExtra orders per 1,000 emails in each week after a newsletter: 0.92 in the send week, 1.33 a week later, 1.13 after two weeks, 0.64 after three, then 0.18 and 0.07.Orders per 1,000 emails by weeks after the send00.511.520.9Week 01.3Week 11.1Week 20.6Week 30.2Week 40.1Week 5Orders per 1,000 emailsWeeks after the send

The horizontal axis is the number of weeks since the newsletter went out, with week 0 the send week. The vertical axis is the extra orders per 1,000 emails in that week. The takeaway: the peak is one week after the send, not on the day, and almost nothing arrives after week 4.

And the cumulative view, which is the one that drives the cadence decision:

Cumulative share of the email effectThe share of a newsletter's total effect delivered by the end of each week: 22% in the send week, 53% after one week, 79% after two, 94% after three, 98% after four and 100% after five.Share of the total effect delivered0%50%100%150%200%Week 0Week 1Week 2Week 3Week 4Week 5Cumulative share in %% of total effectWeeks after the send

The horizontal axis is again weeks since the send. The vertical axis is the share of the newsletter's total effect that has arrived by the end of that week. The takeaway: by the end of week 3, 94% of the effect is in, and weeks 4 and 5 add the last 6%.

One warning about totals. 4.27 per 1,000 is the average effect at the volumes and frequencies Northgate has actually run. It is not a promise about the 18th send of the year if the cadence goes up. That is a marginal question, and marginal ROI is not average ROI. The next section comes back to it. Foundations: marginal versus average

From lag curve to send cadence

Now the decision Priya actually faces. On the monthly calendar a send lands every four to five weeks. By then 94% to 98% of the previous send has arrived, and for the last week or two the list is producing almost nothing from email. That is the gap.

At a three week cadence, the next send goes out once the previous one has delivered 79%, and its remaining fifth overlaps with the start of the new one. At a fortnightly cadence only 53% is in when the next send goes, and nearly half overlaps, so a fresh message lands on readers who have not finished responding to the last. Three weeks removes the idle weeks while keeping the overlap small.

Worked example: what three weekly sends might add

Twelve sends a year become 52÷3=17.352 \div 3 = 17.3, call it 17. If every send kept its full effect of about 128 orders, email would deliver 17×128=2,17617 \times 128 = 2{,}176 orders a year instead of 12×128=1,53612 \times 128 = 1{,}536, an extra 640.

I would not believe the full 640, and neither should Priya. The model was estimated on monthly sends and knows nothing about what happens to opens and unsubscribes at a higher frequency. Northgate did send twice two weeks apart for its Father's Day range in weeks 22 and 24, and the unsubscribe rate on the second send was roughly double the usual. That is one observation, not evidence, but it is a warning.

So the honest memo gives a range. The low end assumes each of the five extra sends delivers only 60% of the current effect: 5×128×0.6=3845 \times 128 \times 0.6 = 384. The expected gain is about 380 to 640 orders a year, with the risk sitting on the unsubscribe side.

And it says how to find out: split the list at random, half on three weekly sends, half on monthly, run it for twelve weeks and compare orders, unsubscribes and revenue. The split test is the right tool for the part the model cannot see, and I have written a complete guide to marketing testing methods if you want the design details.

Why not fortnightly? Because half the effect is still arriving when the next send goes, and the one piece of frequency evidence points the wrong way. Three weeks is where the curve, the evidence and the writer's calendar agree.

Where adstock fits in

If you have met adstock in media mix modelling, you have met a distributed lag with a very strict shape. Classic adstock assumes the effect decays geometrically, shrinking by the same proportion every week:

βk=β0 λk\beta_k = \beta_0 \, \lambda^k

Here βk\beta_k is the effect at lag kk, β0\beta_0 is the effect in the week of exposure, and λ\lambda is the retention rate, a number between 0 and 1 that says what share of this week's effect survives into the next. It is compounding run backwards, a steady decay instead of steady growth. Foundations: compounding

One parameter for the whole curve is economical when you have twelve channels and three years of weeks, and wrong whenever the peak is not at lag 0. Geometric adstock assumes the effect peaks in the same period as the exposure.4 Northgate's peak is at lag 1, so a geometric decay would put too much weight on the send week and too little on the following two.

Google's researchers proposed a delayed adstock for exactly this, with weights that rise to a peak and then fall:4

w(l)=α(l−θ)2w(l) = \alpha^{(l - \theta)^2}

Here w(l)w(l) is the weight at lag ll, α\alpha is a retention rate between 0 and 1, and θ\theta is the lag at which the effect peaks. The curve has the bell shape of a normal density centred on θ\theta. Foundations: distributions The Almon polynomial is the more flexible cousin: a few parameters, any smooth shape, estimated by plain least squares.

Worked example: geometric adstock against Priya's curve

Fit a geometric decay through the send week, β0=0.92\beta_0 = 0.92, with λ=0.5\lambda = 0.5. The implied weights are 0.920.92, 0.92×0.5=0.460.92 \times 0.5 = 0.46, 0.92×0.25=0.230.92 \times 0.25 = 0.23, and so on. At lag 1 that says 0.46, where the Almon curve says 1.33. No value of λ\lambda below 1 can make lag 1 larger than lag 0, so the geometric form can never draw Priya's hump.

How to run it yourself

The data you need: one row per week, at least 60 weeks and preferably 100 or more, with the outcome (orders, enquiries, bookings), the marketing action in a sensible unit (thousands of emails, catalogue copies, euro of spend), and the controls that also move the outcome: paid search spend, price changes, bank holiday and school holiday flags, a linear trend, perhaps a launch flag. Weekly is the right grain for email. Daily is too noisy and monthly hides the curve entirely.

The steps, as I run them:

Estimating an Almon lag curveBuild the weekly table, build lags 0 to L of the sends, build the Almon columns, run least squares with the controls and recover the lag weights. If the tail weights are not near zero, increase L and refit. Then compare a cubic with a quadratic, keep the better degree, forecast a 12 week holdout and write up the total effect, the peak, the mean lag and the cadence memo.Weekly table: outcome, sends, controlsBuild lags 0 to L of the sendsBuild the Almon columns w0 to wpLeast squares on the w columns pluscontrolsRecover the lag weights from the acoefficientsTail weights near zero?noIncrease L and refityesCubic clearly better than quadratic?Keep the better degreeForecast the last 12 weeks as a holdoutTotal effect, peak, mean lag and thecadence memo

The diagram runs from the weekly table to the memo. The one loop is the tail check: if the last weights are not close to zero, the lag is too short, so lengthen it and start again from the lags. Most of the time goes into the weekly table and the controls, not the regression.

In Python with statsmodels it is short:

import numpy as np, pandas as pd, statsmodels.api as sm

L, p = 5, 3                                  # lag length, polynomial degree
x = df["emails_k"]                           # emails sent per week, in thousands
for j in range(p + 1):                       # Almon columns w_j = sum_k k^j x_{t-k}
    df[f"w{j}"] = sum((k ** j) * x.shift(k) for k in range(L + 1))
cols = [f"w{j}" for j in range(p + 1)] + ["paid_search", "holiday", "trend"]
X = sm.add_constant(df[cols])
fit = sm.OLS(df["orders"], X, missing="drop").fit(cov_type="HAC", cov_kwds={"maxlags": 4})
a = fit.params[[f"w{j}" for j in range(p + 1)]].to_numpy()
beta = np.array([sum(a[j] * k ** j for j in range(p + 1)) for k in range(L + 1)])
print(np.round(beta, 2), "total:", round(beta.sum(), 2))

The HAC (heteroscedasticity and autocorrelation consistent) standard errors matter. Weekly residuals are autocorrelated, and plain least squares standard errors will flatter you.5 Check the residual autocorrelation. If it is strong, add a lagged outcome or model the errors, and treat the interval on the total with more suspicion.

Worked example: the holdout

Before you trust the curve, hold out. Fit on the first 66 weeks, forecast the last 12 and compare:

WeekEmails (000s)Actual ordersForecastError
6731101956%
680981046%
69091943%
70086807%
71064686%
722997925%
730931008%
74099936%
75072777%
763090956%
7701081035%
78089946%

Each error is the miss as a share of the actual figure. Week 67, for instance, is (101−95)÷101=5.9%(101 - 95) \div 101 = 5.9\%. The mean absolute percentage error averages those twelve misses:

MAPE=1n∑t=1n∣At−FtAt∣×100\text{MAPE} = \frac{1}{n} \sum_{t=1}^{n} \left| \frac{A_t - F_t}{A_t} \right| \times 100

Here nn is the number of holdout weeks (12), AtA_t is the actual orders in week tt and FtF_t the forecast. Foundations: percentages For this table it is about 6%, against 14% for a seasonal baseline that ignores email.

More important is the shape. The three highest forecasts are exactly the weeks after a send (68, 73 and 77), and in the actual figures week 77 is the highest of the twelve. Week 71, four weeks after a send, is the lowest in both. The model has the timing right, and the timing is what you are going to act on.

How long does it take? With a clean weekly table, an afternoon. Building that table from a mail platform export, an analytics export and a finance sheet, and agreeing what counts as an order, takes a week.

Pitfalls

A regular cadence makes the lags collinear. It is the most common reason the unrestricted model fails and the Almon model is quietly misspecified: if you always send on the first Tuesday, lag 0 and lag 4 or 5 are nearly the same variable. Move the send date by a week now and then.

Smoothness is an assumption. A polynomial cannot draw a cliff. A flash sale that ends on Sunday has an effect that is large for six days and zero on Monday, and a cubic will smear it into the following week and invent a tail that is not there. For hard deadline promotions, use short unrestricted lags at daily grain, or model the deadline directly.

Something else changed that week. Suppose Northgate's biggest order week in the sample was not an email week but the week a food magazine reviewed its hampers. If the review is not in the controls, the model will explain it with whatever email was nearby, and the curve gets a phantom bump. Keep a log of everything that happened and put the big events in as flags.

Reverse timing. Marketers send when they expect demand: before Christmas, before Mother's Day, after a launch. If sends are timed to orders that were coming anyway, the lag model credits email with them. Seasonal controls help, an honest holdout helps more, and a test with randomised send timing settles it.

Week boundaries. A Thursday send puts three days of lag 0 in the send week and four in the next, so part of a "peak at lag 1" is a calendar artefact. If you send on a fixed weekday, start your analysis weeks on that weekday. It sounds pedantic. It moves the peak.

How I do this for clients

The deliverable is a lag curve you can act on, not a regression printout. I need a weekly export from your email or campaign tool (sends, opens, unsubscribes), the outcome from your shop or product database (orders, trials, enquiries) and whatever else you spent money on week by week, plus a calendar of launches, price changes and anything unusual. Sixty weeks is the floor. If you have less, I will say so and we will talk about what can honestly be learned from it.

It starts with the free workshop, where we agree the question (for Priya it would be "how often should we send?"), the outcome that counts and where the data lives. Then I do two weeks of real work before you commit to anything: the weekly table, the model, the holdout and a first draft of the curve. If the data cannot support an answer, you hear that plainly.

What you get is a one page decision memo with a number and a risk (in the example, 4.27 orders per 1,000 emails with its interval, the three weekly recommendation, the expected gain and the unsubscribe risk), the fitted model as a notebook you own and can rerun each quarter, and a small dashboard that answers one question: how much of last month's orders did email deliver, and when. Running and reading the split test belongs to my Performance Marketing work, and the modelling sits under Data Science. The fees are spelled out on the pricing page.

Questions to ask whoever measures your marketing

  • How many weeks after a send do you keep counting its effect, and why that number?
  • Can you show me the lag curve, not just a conversion rate, for our last twelve campaigns?
  • What controls are in the model, and is the magazine review from March in there?
  • Did you hold out the last quarter and forecast it before telling me the model works?
  • What is the confidence interval on the total effect, and would the decision change at the low end?
  • Is our send calendar so regular that the lags cannot be separated, and should we vary it?
  • Does the cadence recommendation allow for fatigue and unsubscribes, or only for the curve?

The series is inspired by Mike Grigsby's Marketing Analytics.6 The explanations, examples and numbers here are my own.

Footnotes

  1. Dave Giles, Explaining the Almon distributed lag model, Econometrics Beat, 6 January 2017, https://davegiles.blogspot.com/2017/01/explaining-almon-distributed-lag-model.html

  2. Shirley Almon, The Distributed Lag Between Capital Appropriations and Expenditures, Econometrica, volume 33, issue 1, pages 178 to 196, January 1965, https://www.econometricsociety.org/publications/econometrica/1965/01/01/distributed-lag-between-capital-appropriations-and-expenditures

  3. Kuan-Pin Lin, Topic 10: Distributed lag models (polynomial lag, the constructed Z variables and the end point restrictions), EC 570/571 Econometrics, Portland State University, https://web.pdx.edu/~crkl/ec571/lecture10.htm

  4. Yuxue Jin, Yueqing Wang, Yunting Sun, David Chan and Jim Koehler, Bayesian Methods for Media Mix Modeling with Carryover and Shape Effects, Google Inc., 2017, section 2.1, https://research.google/pubs/bayesian-methods-for-media-mix-modeling-with-carryover-and-shape-effects/

  5. statsmodels developers, RegressionResults.get_robustcov_results, statsmodels documentation, https://www.statsmodels.org/stable/generated/statsmodels.regression.linear_model.RegressionResults.get_robustcov_results.html

  6. Mike Grigsby, Marketing Analytics: A Practical Guide to Improving Consumer Insights Using Data Techniques, Kogan Page, 2022, ISBN 9781398608191, https://www.netgalley.co.uk/catalog/book/267990

If you have a year or more of weekly sends and orders and have never seen the lag curve behind them, bring both exports to the free workshop and we will agree what they can honestly tell you. Then the first two weeks of real work are on me, with a curve, a number with its error margin and a cadence you can defend.