Growth Experiment

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:

  1. Look for growth-records-<property> (for this property, growth-records-agentman) with find_skills or open_skill.
  2. 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. Then publish_skill so its files can be read back.
  3. Write with save_skill_resource, path records/exp-<short-name>-<YYYY-MM-DD>.md.
  4. Read the store's references/record-format.md for 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)

  1. Name the one metric this change should move, and the direction. A change judged by whichever number happens to rise is not an experiment.
  2. Pull the baseline with the real call — gsc_search_analytics for search metrics, ga4_run_report for behaviour — and record the window, the values, and the call itself. When the metric is page-scoped, filter the pull with dimension_filter_groups and confirm responseAggregationType is byPage; an unfiltered pull returns property-wide numbers that read as page data.
  3. 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.
  4. 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.

Growth Experiment

By Agentman

Register a growth change with its metric and baseline BEFORE shipping, re-measure at a stated interval, and deliver a verdict — WIN, LOSS, INCONCLUSIVE, or CONFOUNDED. Sized to the property: on low-tr

Marketingv1.2.0
experimentsgrowthbaselinesmeasurementgscga4mcp-bound

Included Files

  • SKILL.md(7.6 KB)— shown above

Ready to use this skill?

Attach it to your Agentman agents, or clone it and make it yours.

Free to use. Clone this and any other public skill with a free Agentman account — publishing your own is free up to 10 skills.

AgentSkills is more than a copy-paste library

  • Versioned, not pastedEdit a skill once and every agent using it follows the new version.
  • Shared with your teamOne library with per-skill access control and a record of who did what.
  • One connectionA single MCP link works across Claude, ChatGPT, Cursor and Agentman agents.
Explore AgentSkills →

Or try it in an assistant