Change Events
The structured change log. Every SEO, content or technical change you ship is recorded as a Change Event with a type, a date, the page groups / URLs it affects, an owner, and (optionally) a Jira / Git link and before/after snapshot. This is the foundation Metricstab uses to attribute traffic shifts to the work that caused them.
Why bother logging changes?
Most SEO teams ship 20–50 changes a month and can't tell you which ones moved the needle. A structured change log fixes that. Once a change is logged, Metricstab can:
- Overlay it on every traffic chart so you can see the impact in context.
- Use it as the start date of a before-vs-after measurement.
- Roll up “impact by change type” so you learn what works on your site.
- Flag confounding — if two changes overlap on the same pages, both measurements get a warning instead of a misleading result.
Where to log a change
Open the Change Log page from the left-hand site nav and click Log Change Event. Title, type and start date are the only required fields. Everything else is optional but unlocks more downstream features.
You can also log events from Manage site → Change Events if you prefer.
Field reference
| Field | Required? | What it does |
|---|---|---|
| Title | Yes | Short label that appears on chart annotations and in dashboards. |
| Change type | Yes | Controlled vocabulary (title, meta, content refresh, schema, internal links, canonical, robots, redirect, template, performance, algorithm, other). Drives “impact by change type” rollups. |
| Start date | Yes | The day the change went live. This is the day-zero of any before-vs-after measurement built on top of this event. |
| End date | No | For multi-day rollouts (e.g. a phased migration). Leave blank for a single-day change. |
| Expected impact window | No | How many days you expect Google to take to react. Auto-suggests the observation window when measuring the impact of this change. |
| Owner | No | Team member responsible for shipping this change. Powers “impact by team member” reports. |
| Hypothesis / context | No | One-line statement of what you expect to happen. The single biggest safeguard against post-hoc rationalisation. |
| Page groups | No | Which configured page groups are affected. Reuses your existing Page Groups rules; scopes the impact measurement to just those pages. |
| Page types | No | Which page types (product, category, blog, landing, …) are affected. Reuses your Page Type Rules; scopes template-level rollups. |
| Specific URLs | No | Newline-separated URLs for changes that don't fit a group or type (e.g. a single hub page). |
| Before / After | No | Snapshot of the field that changed (e.g. old title text vs new title text). Becomes the evidence shown alongside the impact measurement. |
| Jira / Linear URL | No | Link back to the ticket where the work was tracked. |
| GitHub / GitLab URL | No | Link back to the PR or commit that shipped the change. |
Change-type vocabulary
Pick the closest match. The vocabulary is intentionally controlled so rollup reports (“impact by change type”) stay meaningful.
| Type | When to use it | Suggested expected-impact window |
|---|---|---|
| Title change | Rewriting <title> tags on one or many pages. |
~14 days |
| Meta description change | Rewriting <meta name="description">. |
~14 days |
| H1 change | Editing the visible H1 heading. | ~21 days |
| Content refresh | Material rewrite or expansion of body copy. | ~42 days |
| Structured data / schema | Adding or removing JSON-LD, microdata, etc. | ~14 days |
| Internal linking | Adding hub links, breadcrumbs, related-content modules. | ~30 days |
| Canonical change | Adding/removing/changing rel=canonical.
High-risk. |
~21 days |
| Robots / noindex change | robots.txt or page-level noindex changes.
High-risk. |
~21 days |
| Redirect change | 301/302 changes, redirect chain edits. | ~21 days |
| Template change | Markup changes that affect a whole category of pages at once. | ~30 days |
| Performance / speed change | Image optimisation, JS removal, CDN changes affecting Core Web Vitals. | ~30 days |
| Google algorithm update | Confirmed Google update (Core, Spam, Helpful Content…) — log it so other experiments running in this window get a confounding warning. | ~14 days |
| Other SEO change | Anything that doesn't fit above. | — |
| Note / Release / Migration / Incident | Free-form Phase 1 annotations, kept for backward compatibility. | — |
What happens after you log a change
- It immediately appears as an annotation marker on every traffic chart for the targeted period.
- It appears on the site's Change Log page (accessible from the left-hand nav under Change Log), where it can be filtered by type or searched by title.
- It is visible to the “What changed this period?” Overview card, so executive recaps reference real shipped work.
- It becomes the start of a before-vs-after impact measurement — Metricstab uses the page groups, URLs and expected impact window you supplied here to scope the measurement automatically.
- If a second change overlaps the same page groups during an active measurement window, both results will be flagged with a confounding-risk warning so you don't misattribute the outcome.
Related features
- Traffic Trend — Annotation markers appear as vertical lines on this chart.
- SEO A/B Testing Engine — Uses change event dates and page-group scope to define before/after measurement windows.
- Insights Reference — Logged changes surface in the “What Changed” narrative on the Overview Dashboard.
Integrity notes
- Log before you ship when you can. Logging in arrears is fine but the hypothesis field gets weaker the further you are from the change.
- One change event per discrete change. If you ship a title rewrite and a schema addition together, log them as two events on the same date — they will confound each other and Metricstab will tell you so.
- Don't backfill the “After” field with the result. The before/after fields describe the page state, not the metric outcome. The outcome lives in the impact measurement.