Sign in Start free

Annotation Discipline

Six months after a change nobody remembers what shipped, so every traffic movement gets attributed to whatever is fashionable. Analytics annotation features are usually abandoned within a month because they require leaving your workflow. The fix is to make the log the cheapest possible artefact and to record the things people never think to record.

CATEGORY
Analytics & reporting
FORMAT
annotation-discipline.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when setting up or repairing the record of what changed on a site and when.

The skill file

annotation-discipline.md 
---
name: annotation-discipline
description: Use when setting up or repairing the record of what changed on a site and when.
---

# Annotation Discipline

Six months after a change nobody remembers what shipped, so every traffic movement gets attributed to whatever is fashionable. Analytics annotation features are usually abandoned within a month because they require leaving your workflow. The fix is to make the log the cheapest possible artefact and to record the things people never think to record.

## What you need first

- a single shared sheet or file, not a tool
- deploy access or a release feed
- agreement on who logs what

## Method

1. Use one flat table with date, what changed, URL pattern affected, who did it, expected effect. Anything richer will not be maintained.
2. Log non-SEO changes too: pricing pages, checkout flows, nav restructures, a consent banner change. Consent banner changes wreck analytics comparability and are never in an SEO log.
3. Record the expected effect before you see the data. This is the only defense against retro-fitting a story to whatever the graph did.
4. Log the date the change was live for crawlers, not the merge date. A cached template can be days behind.
5. Include things you did not do but that happened to you: a competitor relaunch, a SERP feature appearing, a supplier feed breaking.
6. Review the log at the start of every reporting cycle before you open the analytics, so the log frames the numbers rather than the reverse.

## What this produces

A maintained dated change log that any analyst can read cold and use to explain a graph.

## Where this goes wrong

- Logging only SEO work, so a marketing site rebuild that halved traffic appears as an unexplained algorithm event
- Backfilling from memory once a quarter, which produces confident dates that are wrong by weeks
- Keeping the log private to one person, so it dies when they leave

---

From the QuQi skill library - https://www.quqi.io/skills/annotation-discipline
Free to download · no account, no email

What you need first

  • a single shared sheet or file, not a tool
  • deploy access or a release feed
  • agreement on who logs what

Method

  1. 01 Use one flat table with date, what changed, URL pattern affected, who did it, expected effect. Anything richer will not be maintained.
  2. 02 Log non-SEO changes too: pricing pages, checkout flows, nav restructures, a consent banner change. Consent banner changes wreck analytics comparability and are never in an SEO log.
  3. 03 Record the expected effect before you see the data. This is the only defense against retro-fitting a story to whatever the graph did.
  4. 04 Log the date the change was live for crawlers, not the merge date. A cached template can be days behind.
  5. 05 Include things you did not do but that happened to you: a competitor relaunch, a SERP feature appearing, a supplier feed breaking.
  6. 06 Review the log at the start of every reporting cycle before you open the analytics, so the log frames the numbers rather than the reverse.

What this produces

A maintained dated change log that any analyst can read cold and use to explain a graph.

Where this goes wrong

  • Logging only SEO work, so a marketing site rebuild that halved traffic appears as an unexplained algorithm event
  • Backfilling from memory once a quarter, which produces confident dates that are wrong by weeks
  • Keeping the log private to one person, so it dies when they leave

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/annotation-discipline/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is a shared change log the right method rather than the annotation feature in the analytics tool?

When you are about to report on a site whose recent history nobody can reconstruct. Built-in annotations are usually abandoned inside a month, because using them means leaving your workflow to record something with no immediate payoff. A flat shared file survives for the opposite reason: it costs almost nothing to write and anyone can read it cold.

What do I need in hand before starting, and what happens if I start without it?

One shared file, a release feed or deploy access, and an agreement about who logs what. The agreement is the input people skip, and without it logging quietly becomes one person's job and dies when they leave. You also need a remit covering non-SEO work, because pricing, checkout, navigation and consent banner changes are the ones that later look like algorithm events.

What do I end up with, and which part of it actually gets used?

A dated table with what changed, the URL pattern affected, who did it and the expected effect. The expected effect column earns its place because it is written before the data arrives, and it is the only real defence against fitting a story to whatever the graph did. Record the date the change was live for crawlers, not the merge date.

What is the mistake that most often ruins this, and what does it cost?

Backfilling from memory once a quarter. It produces dates that feel confident and are wrong by weeks, which is worse than a gap because nobody thinks to doubt them. The other is logging only SEO work, so a site rebuild that halved traffic shows up as an unexplained algorithm event and gets answered with content work that cannot fix it.

More in Analytics & reporting

Striking Distance Query Analysis

Use when you have Search Console data and need to decide which queries are worth working on this...

Separating Algorithm Updates From Your Own Changes

Use when organic traffic drops and someone asks whether it was Google or something you shipped.

Organic Attribution Reality

Use when someone asks what organic search actually contributed to revenue and last-click says le...

A Report That Survives An Executive

Use when preparing an SEO report for people who will not read past the first page and will remem...