Cut the window into months: the test one lucky period cannot pass

Take any long window of search figures, cut it into calendar months, compute the daily average inside each month, and line them up in order. If every month beats the one before it, you are looking at something that compounded. If one month carries the whole rise and the rest are flat, you are looking at an event. The clawlaw.in export on our proof page is run through that test below. It covers 2026-07-13 to 2026-10-12, 92 days with data, exported on 2026-10-14, and the four monthly daily averages read 59, then 154, then 282, then 349 clicks a day.

Why a total cannot answer the question

The window holds 18,537 clicks and 929,405 impressions. Neither of those figures can tell you whether the rise was gradual or whether one week carried it, because a total has no shape. Two completely different programmes produce the same total: one that climbed every month, and one that was flat for eleven weeks and then had a fortnight of press coverage.

A multiple has the same problem. The daily click figure went from 59 at the start of the window to 349 at the end, which is the endpoints and nothing in between. Endpoints are better than a ratio because the reader can see the base, and they still cannot distinguish a curve from a step.

The test, run on the file

Month	Clicks a day	Impressions a day	Days contributed	Beat the month before
July 2026	59	2,253	19	first month in the window
August 2026	154	7,276	31	yes
September 2026	282	14,703	30	yes
October 2026	349	18,331	12	yes

Three consecutive improvements across four months, on both columns. The impressions line rose alongside the clicks line rather than instead of it, which matters: a rise in clicks with flat impressions would point at a change in how the same appearances were converting, and that is a different finding with a different cause.

Note the day counts and treat them as part of the method rather than a footnote. July contributes 19 days and October contributes 12, because the window opens mid July and closes on 12 October. That is exactly why the test uses a daily average inside each month: monthly totals would show October collapsing, and the collapse would be the calendar rather than the site.

What a lucky period looks like under the same test

It looks like one month doing all the work. Flat, flat, large, flat. The total can be identical and the shape is unmistakable once the window is cut, which is the whole reason to cut it.

There is a second signature worth knowing. A lucky period usually shows up in impressions and clicks at the same instant, because something external put the site in front of a lot of people at once. Compounding shows up in impressions first and in clicks afterwards, because more pages being shown precedes more pages being chosen. A month where both jumped together is a month to ask about.

The questions the test does not answer on its own

It does not tell you what caused the rise. Four improving months are consistent with the search work and also consistent with four months of something else running in parallel, so the test narrows the possibilities rather than closing them.

So ask three things alongside it. What share of the clicks were brand searches, since brand demand follows advertising rather than search work. What else ran in the same period: a launch, press, paid media, a competitor leaving. And what the site was on day one, because a window that starts at 59 clicks a day inherited everything that produced the 59.

The strongest version of this is to hold something back and compare, which almost nobody does in search work. The measurement section in how to read a case study properly and write one that holds up sets out the control group version, including the longer pre period that lets you tell a campaign effect from the usual seasonal shape.

Running it on your own figures

• Export the window from Google Search Console as a Performance on Search export, and switch the table under the chart to Dates so you have one row per day.
• Group the rows by calendar month and divide each month's total by its own number of rows, not by thirty.
• Print the day count beside each monthly average. A reader who can see that July held 19 days will not misread July.
• Publish all four columns, including the one that did not improve if there is one. A sequence with a dull month in it reads as a measurement, and a sequence with no dull month ever reads as a selection.

For the figure by figure reading of this same export, including what the impressions line was doing while the clicks were still flat, what a real 92 day Search Console export looks like takes it apart column by column.

We sell the measurement behind this and the work that moves it, which is why the monthly cut is published rather than the headline multiple. A single ratio would have been easier to quote and impossible to check.

Questions about telling compounding from a lucky month

How many months does the test need?

Three at minimum, so that there are two consecutive comparisons rather than one. Two months is a single before and after, and a single before and after is exactly what one lucky period produces.

Why daily averages instead of monthly totals?

Because the first and last months of almost any window are partial. In this window July contributed 19 days and October contributed 12, so totals would show a fall in October that is purely a counting artefact of where the window ends.

What if one month in the middle dips?

Publish it and name what happened that month. A programme with one flat month and three rising ones is a more believable object than four perfect months, and the explanation is usually recoverable from the calendar rather than from the data.

Does the test work on impressions alone?

It works better on both columns read together. Impressions rising ahead of clicks is the normal order, so a month where impressions moved and clicks did not is on track rather than off it, and the test should not punish it.

Can this test be applied to whether an assistant names a business?

Only as repeated readings rather than as a window, because there is no export behind an assistant's answer. The equivalent is the same question set, run again on a stated interval, with both counts and both dates kept. 83 of 102 build spec conversations run on ChatGPT and Gemini on 15 October 2026 asked for a repeat count or a variance for exactly this reason.