Automation Pipeline4 min read

If you set the re-measure date but never took the baseline, the experiment never started

Two weeks ago I added structured data to six content clusters and wrote 're-measure in two weeks.' The baseline was never taken, the daily snapshot was a rolling window I couldn't use, the impressions were attached to a different host than the one I'd worked on, and the second search channel had no dashboard at all.

#seo#measurement#reality-check#gotchas
A horizontal timeline with a vertical 'change' line; the left span is a dashed box with a question mark (no baseline), the right span is a solid bar. Below, one document connects via two forked arrows to two different host labels, and the impression count is attached only to the lower label
The re-measure date was set. The thing to measure was misaligned in three places.

Does your experiment have a re-measure date, or does it have only a re-measure date?

Two weeks ago I added a batch of structured data to six content clusters. My work log had a date on it — "re-measure in two weeks" — and a list of what to re-measure: search impressions and clicks, indexed count, whether answer engines cite it. I sat down to fill in the baseline before the re-measure date.

What would you do?

An automated report runs every day, accumulating search data. Would you treat the baseline as already there, or open up what that data actually contains and how? I treated it as there, and three things were misaligned.

One. The daily snapshot couldn't be used as a baseline

Since the automated report accumulates data every day, I assumed the baseline already existed. But that snapshot was a 28-day rolling window. The window moves every day, so there's no way to pin "the 28 days before the change." On top of that it aggregates at the site-property level, so it doesn't split by cluster path. I had to build a separate collector that pulls with a fixed window.

Two. The impressions weren't attached to the address I'd worked on

The structured data went on path-style addresses (domain/cluster/), and the canonical addresses all point there too. But the search impressions were landing on a subdomain property. The same files were served from two hosts, and the name the search engine indexed was the subdomain.

Looking at the path-style property alone, four of the six clusters show zero impressions. If I'd seen only that number on the re-measure date, I'd have concluded "no effect." In reality there are hundreds of impressions on the subdomain side.

Three. The second search channel's baseline wasn't "not collected" — it never existed

I'd sent index requests there too, but logging into its webmaster tool showed zero registered sites. Index requests work without registration because they use a key-file method, but there was never a place to see the results. Tools like this collect from the moment of verification onward, so the past isn't backfilled. The effect of this work on that channel can't be measured by any method.

Honestly

  • My work log said "baseline needs account access — not collected," and I let two weeks pass. If you set the re-measure date but not the baseline, the experiment hasn't started.
  • The second channel is unrecoverable for this particular experiment. I only built the dashboard for next time.
  • I haven't fixed the split between the canonical address and the actually-indexed host. Touching the live site now would mix the observation windows, so I deferred it until after the verdict.

What the baseline collector does

The point is pinning the window as a constant, not an argument.

WINDOWS = {
    "pre":  ("the 28 days before the change"),
    "post": ("the 28 days after the change"),
}

And it holds both the path-style and the subdomain. Holding only one falls straight into the trap above. It pulls at the page dimension and splits clusters by path prefix.

What was practically useful for registering the second channel:

  • One account's verification key works for every site. Placing one verification file at the root and in each folder handled seven properties in one pass.
  • You don't have to download the file. Expanding the "meta tag" method tab shows the same key, so you can build the XML directly from that value.
  • The search-console import is convenient but it's an approval that hands one search provider access to another provider's account. Manual add plus file verification finishes without that delegation.

Three checks

  • Do you have an experiment where you assumed "there's a daily report, so there's a baseline"? Is that report's aggregation window fixed or rolling? A rolling window can't pin before-and-after.
  • Is the address you optimized the same as the host name the search engine actually indexed? If the same files serve from two hosts, the impressions attach to only one.
  • For every channel you sent an index request to, is there a verified dashboard to see the result? The period before verification isn't backfilled.

For the prequel that doubted the metric itself, there's the score my site computed whose inputs weren't in the code. That one is "the metric measured nothing"; this one is "there was no place to measure from."

Next time you write a re-measure date, write on the same line which dashboard you pulled the baseline from, and when. If you can't write it, the experiment hasn't started.

Related