Register the metric and baseline before shipping; re-measure at a stated interval; state a verdict. This is what separates "we shipped things and traffic went up" from knowing which thing worked.
Render through growth-report-format. A registration and a verdict are
records, not reports, so they keep the structure below rather than the
TL;DR/Findings frame — but they still owe the provenance grammar, the Method
block, and the five rules.
Where records live
Not on disk. In claude.ai and Cowork the filesystem is session-scoped, so a
baseline written to data/ or /tmp/ is gone before the 28-day re-measure it
exists for. That would make the discipline this skill teaches impossible to
complete — you could register and never deliver a verdict.
Records go in a private records skill, which survives sessions.
Create the store if it does not exist, then write to it:
- Look for
growth-records-<property>(for this property,growth-records-agentman) withfind_skillsoropen_skill. - If it does not exist, create it with
create_skill: private (tenant scope), SKILL.md stating it is a durable record store holding real property IDs and never published. Thenpublish_skillso its files can be read back. - Write with
save_skill_resource, pathrecords/exp-<short-name>-<YYYY-MM-DD>.md. - Read the store's
references/record-format.mdfor the exact field list before writing your first record in a session.
Read back with read_skill_file using the combined path form —
<skill-slug>/records/<file>.md, not a slug argument plus a relative path.
If no records skill exists and you cannot create one, say so plainly and emit the record in your response for the user to save. Do not write it to a path that will evaporate and call the experiment registered.
First: is this property powered for an experiment?
Check before registering. Pull 28 days with
mcp__google_search_mcp__gsc_search_analytics and
mcp__google_search_mcp__ga4_key_events, and look at the metric you intend to
move.
A change is only detectable if the expected effect exceeds normal variation. On a page with 40 clicks a month, a real 15% improvement is 6 clicks — invisible against week-to-week noise. Registering it as an experiment produces an INCONCLUSIVE verdict by construction, which teaches nothing and costs the ceremony.
| Situation | Mode |
|---|---|
| Metric has enough volume that a plausible effect clears normal variation | Powered — full registration and verdict below |
| Metric is too small for that | Record mode — baseline file only, no verdict claimed |
Say which mode you are in, in the record itself. Record mode is not a failure; it is the honest form for a small property, and it still prevents the worst outcome — claiming a win with no baseline to check it against.
In record mode, write the baseline, ship, re-measure, and report the observed difference with its provenance — explicitly not a verdict:
Observed: went from to over . This property is underpowered for a verdict at this volume; the change is recorded, not claimed.
Register (before shipping)
- Name the one metric this change should move, and the direction. A change judged by whichever number happens to rise is not an experiment.
- Pull the baseline with the real call —
gsc_search_analyticsfor search metrics,ga4_run_reportfor behaviour — and record the window, the values, and the call itself. When the metric is page-scoped, filter the pull withdimension_filter_groupsand confirmresponseAggregationTypeisbyPage; an unfiltered pull returns property-wide numbers that read as page data. - Record the mechanism: why this change should move that metric. A change with no mechanism is a guess, and a guess that wins is still a guess.
- Set the re-measure date. 14 days minimum before reading anything, 28 before a verdict on search metrics.
Type: experiment
Status: OPEN
Mode: powered | record
Property: GSC <property> · GA4 <property-id>
Metric: <metric>, expected direction <up|down>
Mechanism: <why this change should move that metric>
Created: <YYYY-MM-DD>
Baseline window: <range> · Fetched: <timestamp>
Source call: <tool_name>(<key args>)
Aggregation: byPage | byProperty (state which, when page-scoped)
Baseline values: <the numbers>
Shipped: <date>
Re-measure: <shipped + 28 days>
Verdict (at the re-measure date)
Re-pull with the same call, same window length, same segmentation. A different window is a different experiment.
| Verdict | When |
|---|---|
| WIN | Moved in the predicted direction, beyond normal variation, no confound |
| LOSS | Moved against the prediction |
| INCONCLUSIVE | Moved within normal variation, or the window is too short to tell |
| CONFOUNDED | Something else plausibly explains it — position moved more than ~1.5, an algorithm update landed, another deploy overlapped |
CONFOUNDED is the most common honest answer and the least reported one. Reach for it whenever a competing explanation is live. It is not a failure of the experiment; it is the experiment telling the truth.
Append the verdict to the record's own file under a dated heading and update its
Status. Never edit the original baseline block — a baseline whose history is
editable is not evidence.
Rules
- Retroactive registration is refused. If a change already shipped without a baseline, say so plainly and baseline now for next time. A baseline reconstructed after the fact is not a baseline — you already know the outcome, and that knowledge shapes what you pick.
- A recorded baseline that fails to reproduce loses to the fresh pull. It has happened in this suite's own history. Trust the fresh call, append a correction noting both figures.
- One metric per experiment. Report secondary movements as observations, never as the verdict.
- Never cite an experiment record not in context. Read it from the records skill first. If it is genuinely absent, the honest verdict is that no verdict is possible.
Where the lightweight version already lives
seo-title-rewrite carries its own baseline-and-re-measure loop — baseline record
before ship, 28-day re-measure, CONFOUNDED if position moved more than ~1.5. That
is this discipline at the scale most title work actually needs, and it does not
require opening this skill.
Use this skill when the change is bigger than a title, when several changes need
tracking at once, or when someone will ask "did that work?" about something with
no natural home. Do not open it to add ceremony to a change that
seo-title-rewrite already handles end to end.
growth-report reads the records skill and lists anything past its re-measure
date as OVERDUE. An experiment nobody re-measures is a superstition.
Publishing
Real experiment records name property IDs, metrics, and event taxonomies. They live only in the private records skill. Never publish a records skill or copy its contents into this master skill — this file must stay portable across properties.
