Docs / Change diary
How the connector checks whether your change worked
Log what you shipped and when. Later, the same connector reads the pre and post windows and runs a z-test on the difference instead of eyeballing a chart.
Signature
cr_log_changeRecords something you shipped into the change diary, with its date and what it touched.cr_list_changesThe diary itself: what was shipped and when, with impact verdicts where they have been measured.cr_update_changeEdits or dismisses a diary entry. A dismissed row is retained and still retrievable, never deleted.cr_verify_change_impactReads the pre and post windows for a diary entry and runs a z-test on the difference.
What you ask
Prompts land with the captured session, so that what is printed here is what actually worked rather than what should have.
What runs
What comes back
No session to show
The transcript and the screenshot for this instrument have not been captured yet. Everything else on this page is the real tool surface.
When to reach for this
Use this the day you ship, not the day you wonder
The diary is worth almost nothing written retrospectively and worth a great deal written at the moment of the change. Log what you shipped and when; the measurement is only possible because the before window is defined before the after window exists.
Use it to settle whether the fix worked
Once an entry has enough days on both sides, the connector reads the pre and post windows and runs a z-test on the difference. That replaces the usual argument about whether a chart moved with a number and a verdict.
Not this one to find what to change
The diary measures decisions you already made. Finding the decision is what the audit, the funnel and the hypothesis library are for.
How to read it
A verdict of "no significant change" is the common case and it is useful
Most site changes do not move conversion measurably, and a tool that confirms this is doing you a favour. It stops a team crediting a redesign for a seasonal swing, and it stops the opposite: reverting something that was never the problem.
The pre window is the part that goes wrong
An entry logged with the wrong date silently ruins the comparison, because the before window then contains days that already had the change in them. This is why the tool lets you correct a date afterwards, and why correcting it matters more than it looks.
Two changes in one window cannot be separated
Ship a new product page and a new campaign in the same week and the diary can tell you the number moved, not which one moved it. The discipline the diary rewards is one change at a time, which is also the discipline that makes any of this measurable.
A dismissed entry is retained, not deleted
Dismissing an entry sets its status and drops it from the working list; the row survives and is still retrievable. That is deliberate: an experiment you abandoned is part of the record of what you tried, and deleting it makes the history lie.
Limits
- It measures correlation across a before and after window. It is not an A/B test: nothing was randomised, so a significant change is still not proof of cause.
- It needs enough traffic on both sides of the date. A low-volume store will get "not enough data" more often than a verdict, and that is the correct answer.
- It can only measure what you logged. An unlogged change is invisible, and an audit run against an empty diary will say so.
- Seasonality, campaigns and outages inside either window contaminate the comparison and the tool cannot see them unless they were logged too.
Related instruments
Go deeper
Try it on your own data
Every instrument runs on your own GA4, read-only, inside Claude or ChatGPT. One connector covers all of them.
Add the connector →Session captured 2026-08-03 against the ConvRadar demo property. Masked in the image: cropped to the conversation column, so the account sidebar and workspace name are out of frame, no connector URL is in frame, so no token can leak, no account email or avatar is in frame.