Reporting Cadence and Annotations
Build an SEO reporting cadence that turns weekly, monthly, and quarterly evidence into decisions, with dated annotations that make attribution defensible.
Reporting is the control system for SEO and AI visibility work, not a narrated tour of charts. A useful report changes a priority, approves an intervention, stops waste, or confirms that the current plan should continue. If a report repeatedly ends without a decision, it should not exist as a recurring report.
Phase: P16 · Reporting cadence and annotations. Stage: D · Measure and improve. Timebox: one day to design the reporting system, then 30 minutes weekly, 60–90 minutes monthly, and two hours quarterly. Accountable owner: measurement lead or SEO lead. Readers: channel operators weekly, budget and product owners monthly, and executive sponsors quarterly.
The operating rule is simple: every material change gets a dated annotation, and every recurring report ends with a decision, an owner, and a due date. A change without an annotation weakens later attribution. A chart without a decision consumes attention without controlling the work.
Why this phase, and why here
P16 consumes the goal definitions, baseline, production records, and measurement design established earlier in the playbook. Most importantly, it follows conversion and revenue tracking , which defines the events, values, costs, and attribution model used to connect a visit or AI-assisted discovery to a business outcome. An attribution model is the explicit rule for assigning conversion credit across touchpoints. Reporting must not quietly invent a different rule after seeing the result.
This order prevents two common distortions. First, a team that reports before measurement is agreed will substitute whatever number is easiest to retrieve for the outcome the business actually chose. Second, a team that annotates retrospectively will remember the successful release and forget the template edit, campaign, outage, or tracking change that happened in the same window.
Skip this phase and earlier work becomes a collection of activities rather than a managed system. Run it too early and the reporting pack hardens around unstable definitions, incomplete sources, and metrics with no accountable owner. Run it after every other activity has finished and the change history needed for attribution has already been lost. Reporting design happens here; annotations begin the moment implementation begins and continue indefinitely.
Inputs and outputs
The outputs are the contract with the next phase. They must be precise enough that a refresh owner can open the decision log and know what to change, why, by when, and how the result will be judged.
| Direction | Item | Acceptance condition |
|---|---|---|
| Input | Approved goals and metric dictionary | Every primary metric has a definition, source, owner, reporting grain, and business reason. |
| Input | Frozen baseline and segment map | Starting values are dated and split by the directories, page types, markets, or product lines used in decisions. |
| Input | Conversion and revenue measurement | Conversion events, values, costs, exclusions, and attribution rules are documented and tested. |
| Input | Delivery and release records | Published URLs, technical releases, campaigns, incidents, and owners can be tied to dates. |
| Input | Data-quality status | Known source delays, tracking gaps, consent effects, and connection failures are visible before interpretation. |
| Output | Reporting matrix | Defines weekly, monthly, and quarterly audiences, metrics, thresholds, decisions, owners, and distribution. |
| Output | Annotation ledger | Records each material change with date, scope, hypothesis, expected metric movement, checkpoint, and evidence link. |
| Output | Decision log | Records the decision, evidence, owner, due date, status, and later outcome for every review. |
| Output | Quarterly learning memo | States which hypotheses held, failed, or remained inconclusive and how priorities change next quarter. |
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
The checklist
1. Assign every metric to a decision
What: Map each recurring metric to one decision and one accountable decision-maker.
Why: A dashboard grows by accumulation. Without a decision map, familiar numbers survive because they are easy to show, while costly questions remain unanswered.
How: For each metric, complete the sentence: “When this crosses ___ for ___ segment over ___ window, ___ decides whether to ___.” Separate diagnostic measures such as impressions and crawl errors from business outcomes such as qualified conversions, revenue, or retained margin. Remove any metric that cannot complete the sentence.
Tool: Use the metric dictionary, the baseline, and the AmICited report that supplies the evidence.
Done when: Every recurring row names its threshold, segment, comparison window, decision, owner, and source. Zero “for awareness” rows remain in the core pack; optional context moves to an appendix.
2. Design the weekly operating review
What: Create a short exception report for the people who can repair or redirect work this week.
Why: Weekly data is useful for detecting breakage, delivery risk, and unusually large movement. It is usually too noisy for declaring strategy successful, especially when ranking, demand, and attribution data arrive on different schedules.
How: Limit the review to data health, incidents, releases, annotations due, severe traffic or conversion exceptions, and the status of last week’s actions. Compare complete like-for-like weeks. Exclude partial current days. Let operators drill into pages and queries, but keep the meeting at decision level.
Tool: Open the report inventory in Reports Hub at app.amicited.com/reports , then use the underlying source view for any triggered exception.
Done when: The weekly pack takes no more than 30 minutes to review, contains no more than 10 core measures, and ends with a written action, owner, and date for every breached threshold—or an explicit “no action” with a reason.
3. Design the monthly performance review
What: Build a decision review for the SEO lead, content or engineering leads, product owner, and budget holder.
Why: A complete month smooths ordinary day-to-day variation and aligns better with staffing, campaign, and financial planning. It is the right level for deciding which segments deserve more work, not for diagnosing a single URL in the meeting.
How: Compare the latest complete month with the previous complete month and the same month a year earlier when valid history exists. Show goal progress, segment contribution, conversion and revenue outcomes, AI visibility, organic demand, completed work, annotation outcomes, and open risks. State data limitations beside the affected conclusion.
Tool: Use Cockpit at app.amicited.com/reports/cockpit to inspect contribution and threshold-triggered actions, then attach the source exports behind any decision.
Done when: The review produces a prioritized list of continue, stop, investigate, and start decisions; each decision names an owner and due date; and every performance claim identifies its comparison window and affected segment.
4. Design the quarterly strategy review
What: Create a portfolio-level review for the executive sponsor, SEO lead, product or commercial owner, and leaders who can reallocate people or budget.
Why: Strategy needs enough elapsed time for shipped work to be discovered, used, and measured. Quarterly review also creates a deliberate point to challenge targets and assumptions instead of carrying them forward because the dashboard still exists.
How: Roll up three complete months, compare with the prior quarter and the year-earlier quarter where available, and separate existing-content performance from newly launched work. Review goal progress, investment by workstream, resolved annotation outcomes, repeated misses, competitive movement, operational reliability, and the next quarter’s constraints. Do not fill the deck with weekly incident detail unless it changed strategy.
Tool: Use Annotation Outcomes for hypothesis history, Cockpit for business drivers, and exported source evidence for disputed conclusions.
Done when: Leadership approves no more than five next-quarter priorities, explicitly stops or deprioritizes at least the work that no longer clears its decision rule, and records any revised target with its effective date rather than overwriting history.
5. Annotate every material change on the day it happens
What: Log releases, content changes, redirects, internal-link changes, migrations, campaigns, pricing changes, outages, tracking changes, and known external events with their actual dates.
Why: Attribution starts with chronology. An annotation does not prove causation, but without a trustworthy timeline it is impossible to test whether an outcome followed the proposed cause or a competing event.
How: Record the timestamp, owner, scope, affected URLs or directory, category, reason, reference ticket, metric expected to move, direction, magnitude or threshold, and checkpoint date. Create separate annotations for unrelated hypotheses. If several inseparable changes ship together, state that the bundle cannot be attributed internally.
Tool: Add the annotation from the relevant AmICited report, then review its checkpoint in Annotation Outcomes at app.amicited.com/reports/annotation-outcomes .
Done when: 100% of material releases in the deployment or editorial log have a matching annotation within one business day, every annotation has at least one measurable expectation and checkpoint, and the affected scope is specific enough to query.
6. Separate a useful signal from algorithm-update noise
What: Test whether observed movement is localized, sustained, measurable, and consistent with the annotated hypothesis before assigning a cause.
Why: Search systems, competitors, demand, SERP layouts, tracking, and the site itself can move during the same week. Calling every unexplained decline an “algorithm update” hides faults the team controls; calling every rise a win overstates the evidence.
How: First validate tracking and source completeness. Then compare affected pages with a stable reference segment, inspect query and country patterns, check whether the movement starts near an annotated change, and compare at least two complete windows. Record confirmed public update windows as context, never as automatic causation. Use “inconclusive” when explanations overlap or the sample is too thin.
Tool: Use the source reports reached through Reports Hub, the annotation ledger, and external update records approved by the team. AmICited outcome grading is evidence of association, not proof of cause.
Done when: Every material movement is classified as expected, unexpected, data-quality issue, external-context candidate, or inconclusive; the classification cites at least two checks; and no algorithm explanation is presented as fact solely because dates overlap.
7. Close every report with a recorded decision
What: Convert the evidence into continue, stop, start, investigate, or no-action decisions and track them to closure.
Why: Reporting creates value only when it changes or confirms behavior. A meeting that ends with “interesting” transfers no responsibility and makes the same discussion likely next month.
How: Write the decision in one sentence, attach the evidence and uncertainty, name one owner, set a due date, and define the completion proof. At the next cadence, review overdue actions before introducing new charts. Close an action only when the evidence exists, not when someone says the work is underway.
Tool: Use the team’s decision log and link each row back to the relevant AmICited view, annotation, or export.
Done when: 100% of recurring reviews end with a signed-off decision log, zero actions lack an owner or date, and every prior overdue action is resolved, re-dated with a reason, or escalated.
Tools in AmICited
AmICited supplies the shared evidence and change history. The meeting format and decision rights still belong to the team.
| Product view | Use in this phase | Deep link | Evidence to retain |
|---|---|---|---|
| Reports Hub | Find the report that answers the decision and expose missing data-source connections instead of treating an empty chart as zero. | Open Reports Hub | Date range, comparison, source state, filters, and export. |
| Cockpit | Review material business drivers and threshold-triggered actions for the monthly decision meeting. | Open Cockpit | Contribution window, trigger crossed, affected driver, and assigned action. |
| Annotation Outcomes | Grade dated expectations as met, missed, inconclusive, due, or pending and inspect the ledger behind the roll-up. | Open Annotation Outcomes | Annotation scope, baseline, checkpoint, expectation, automatic verdict, override reason, and sample. |
| SLA Reports | Supply monthly uptime evidence when availability is a reporting dependency or customer commitment. | Open SLA Reports | Month, monitor, target, uptime, exclusions, incidents, and export. |
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Decision rules
These are operating thresholds for the reporting process, not claims about universal search-engine behavior. Calibrate performance thresholds from the frozen baseline; keep the process thresholds fixed unless the governance owner approves a dated change.
| Check | Bad looks like, in numbers | Required decision |
|---|---|---|
| Decision yield | Fewer than 1 recorded decision in 2 consecutive editions of a recurring report. | Remove the report, change its audience or threshold, or move it to an appendix. |
| Annotation coverage | Fewer than 100% of material changes annotated within 1 business day. | Reconcile the release log before making attribution claims. |
| Annotation quality | Any annotation has 0 scoped URLs/directories, 0 expected metrics, or 0 checkpoint dates. | Return it to the owner; it cannot be graded. |
| Weekly pack size | More than 10 core measures or more than 30 minutes of routine review. | Keep only exception-triggering measures in the core pack. |
| Monthly comparison | A claim uses a partial month, or only 1 comparison window when valid prior-month data exists. | Delay the claim or label it provisional and add the missing comparison. |
| Quarterly priority load | More than 5 approved strategic priorities for the same accountable team. | Rank and defer the excess; a list without capacity is not a plan. |
| Unexplained movement | A primary metric moves by at least 20% versus its valid comparison and has 0 documented checks. | Open an investigation before changing strategy or claiming a win. |
| Algorithm attribution | Fewer than 2 independent checks support the algorithm explanation. | Classify it as a candidate or inconclusive, not a conclusion. |
| Action ownership | Any action has 0 owners, 0 due dates, or 0 completion conditions. | The review cannot close until the fields are assigned. |
| Outcome confidence | The affected segment has fewer than 28 complete days of post-change data for a monthly hypothesis, unless a faster checkpoint was defined in advance. | Keep the verdict pending or inconclusive; do not move the goalposts after seeing the data. |
The 20% investigation trigger is intentionally a triage threshold, not a definition of statistical significance. Teams with high-volume, stable data may use a tighter alert; volatile or seasonal businesses may need a wider one. Document the local threshold before the period begins so it cannot be chosen to fit the result.
Deliverable: the reporting and annotation control pack
Hand over one versioned folder or workspace containing four linked artifacts:
01-reporting-matrix
Cadence | Audience | Decision right | Metric | Definition | Source
Segment | Comparison | Threshold | Owner | Distribution | Meeting time
02-annotation-ledger
Change date/time | Owner | Category | Scope | Reference ticket
Hypothesis | Expected metric/direction | Baseline | Checkpoint | Status
03-decision-log
Review date | Evidence link | Decision | Confidence/limitation
Owner | Due date | Completion proof | Status | Outcome
04-quarterly-learning-memo
Goals | Investment | Results | Met/missed/inconclusive hypotheses
External context | What stops | What continues | Next priorities
The pack is accepted when a reader can reproduce every reported number from its named source, trace every material change to an annotation, and follow every decision to an owner and outcome. Store exports with immutable dates. Never overwrite a prior target, annotation, or verdict; append the correction and explain why it changed.
What goes wrong
- The report is a performance theater deck. Screenshots are polished, but no threshold can trigger an action. Start with decision rights and rebuild the pack around them.
- Every audience receives the same report. Operators drown in quarterly context while executives debate individual queries. Give weekly, monthly, and quarterly readers different levels of aggregation and authority.
- Annotations are added at month end. Dates are guessed, unsuccessful changes disappear, and bundled releases become one vague note. Reconcile annotations against deployment and editorial logs every week.
- A date overlap becomes a causal claim. Traffic rises after a release, so the release receives full credit despite a campaign and seasonal peak. Use a reference segment and an inconclusive verdict when causes cannot be separated.
- Algorithm updates explain everything. The label delays investigation of a tracking break, deindexing event, competitor change, or demand shift. Validate owned systems first and require two independent checks.
- Percentages hide denominators. “Success rate doubled” may describe one resolved checkpoint becoming two. Always show the count, eligible population, and missing or pending records.
- Partial periods are compared with complete periods. A seven-day current month is placed beside a completed prior month. Use complete like-for-like windows or label the comparison as pacing, not performance.
- Targets are rewritten after a miss. Historical reports silently inherit the new target and make the original decision impossible to audit. Apply revised targets prospectively with an effective date.
- The dashboard becomes the source of truth for definitions. A label changes but the metric dictionary does not. The approved definition, source grain, and exclusions govern; the interface displays them.
Next phase
The next phase, continuous refresh and iteration , receives the reporting matrix, annotation ledger, decision log, resolved outcomes, and prioritized exceptions. It uses them to choose which pages, technical systems, or experiments should be refreshed, retired, expanded, or re-tested.
Do not hand over a list of charts or a backlog ranked only by traffic. The refresh owner needs a diagnosed gap, an affected segment, supporting evidence, the previous change history, a proposed decision, and the metric and checkpoint that will judge the next intervention. P17 should act on measured learning, not recreate the investigation P16 was meant to finish.
Make the next report end in a decision
Start by opening the reporting cockpit for the latest complete window. Identify one threshold that requires a decision, assign its owner, and annotate the intervention before it ships. Then carry the resulting evidence and decision into the next iteration cycle.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card