Measurement and Optimization

Optimization Decision Log

Preserve each content optimization decision with its evidence, alternatives, expected reader effect, implementation scope, owner, and reevaluation trigger.

Free editable Markdown · Growth teams, content strategists, and product teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Decision context

Decision ID, date, and owner: [Enter]
Affected asset, URL, and version: [Enter]
Audience and reader task: [Enter]
Observed problem: [State]
Evidence and period: [References]
Known limitations: [Enter]
Plausible causes: [List]
Urgency and cost of inaction: [Enter]

Options and selected change

Options considered: [No change / Research / Content / Design / Technical / Other]
Selected option and rationale: [Enter]
Expected mechanism: [Because we change X, readers can do Y]
Exact scope: [Pages, components, locales, channels]
Out of scope: [List]
Dependencies and approvals: [List]
Reader and organizational risks: [List]
Rollback or containment plan: [Enter]

Measurement and review

Baseline and frozen reference: [Enter]
Primary outcome signal: [Define]
Guardrails: [Accuracy / Accessibility / Complaints / Other]
Release date and annotation: [Enter]
Observation window/minimum evidence: [Enter]
Decision rule: [Keep / Revise / Revert / Investigate]
Concurrent changes: [List]
Result and confidence: [Complete later]
Review decision, owner, and next date: [Complete later]

How to use this template

Capture the reader problem, affected content, baseline version, and supporting evidence.
List plausible causes and alternative actions before selecting the change.
Define scope, dependencies, risks, approvals, expected mechanism, and owners.
Set measures, guardrails, observation period, and a decision rule before release.
Verify implementation, review the outcome in context, and record the next decision.

Define the problem at reader level

Start with an observed barrier, not a preferred edit. Identify the audience, page or journey, current behavior, evidence period, and consequence. A low click-through rate may reflect result layout or query mix; repeated support questions may come from product behavior rather than copy. Link quantitative and qualitative evidence, then distinguish confirmed facts from diagnosis. Write the expected mechanism: shortening an introduction might help returning users reach a control sooner, while adding a decision table might help first-time visitors compare plans. If the team cannot explain how the proposed change addresses the observed barrier, gather more evidence before changing several elements at once.

Preserve alternatives, scope, and risk

Record options considered, including no change, further research, technical repair, navigation work, consolidation, or a targeted content edit. Explain the selection criteria and why the chosen option is proportionate. Freeze the baseline and exact pre-change version. List affected URLs, components, locales, channels, analytics events, internal links, and downstream documents so a local optimization does not create inconsistency elsewhere. Assess factual, accessibility, legal, privacy, brand, and user risks; schedule qualified review when needed. Prefer a reversible scope when confidence is low, and avoid combining unrelated edits if the team wants to learn which mechanism mattered.

Define success without rewriting history

State the expected reader outcome, primary signal, guardrails, observation window, minimum evidence, and decision rule before release. Do not choose a metric after seeing which one improved. Note seasonality, campaigns, releases, measurement changes, and search processing that could affect interpretation. Assign implementation, quality assurance, analysis, and final decision owners. At review, compare results with the prior expectation and record unexpected effects, including no measurable change. Keep the original rationale intact; append a new entry for reversals or follow-up changes. A useful log supports institutional learning by showing when reasonable decisions failed, not only when teams found a positive chart.

See the fields in context

Fictional example: pricing explanation order

ClearHarbor and its results are invented.

Problem: Fictional trial users asked whether unused credits carried over after reading a pricing page.
Change: Move the verified rollover rule beside the credit definition; do not alter the offer.
Expected mechanism: Readers encounter the decision-critical condition before selecting a plan.
Guardrails: No increase in cancellations caused by misleading interpretation and no accessibility defects.
Decision rule: Keep only if comprehension improves in task testing without new confusion.

Frequently asked questions

Does every copy edit need a decision log?

No. Use it for material changes tied to outcomes, risk, experiments, disputed choices, or lessons that future maintainers need.

Can several URLs share one entry?

Yes when they use one rationale, change, release, and measure. Split the record when audiences, mechanisms, risks, or owners differ.

What if no metric moves?

Record the result and inspect implementation, power, timing, and qualitative evidence. A null result is not permission to invent a success story.

Should a reverted change be deleted from the log?

No. Preserve the original entry and append the reversal, evidence, and follow-up so the team does not unknowingly repeat it.