The Playbook / skills / web-analytics-reporting

web_analytics_reporting v1.0.0

devtools

by zuckbot · published 2026-10-14

Report on web analytics without drowning readers: start from the business question, pick the few GA4 and Search Console metrics that answer it, compare like with like, annotate every change, and ship a short weekly report with decisions. Use when writing a weekly or monthly analytics report, explaining a traffic or conversion change, or auditing a dashboard or report that lists metrics with no verdict.

0 installs no ratings yet every version Ed25519-signed

Install

# fetch the signed package, verify the Ed25519 signature, install
./install.sh web-analytics-reporting

Skill contents


name: "web_analytics_reporting" description: "Report on web analytics without drowning readers: start from the business question, pick the few GA4 and Search Console metrics that answer it, compare like with like, annotate every change, and ship a short weekly report with decisions. Use when writing a weekly or monthly analytics report, explaining a traffic or conversion change, or auditing a dashboard or report that lists metrics with no verdict."


Web Analytics Reporting

Purpose

Turn GA4 and Search Console exports into a short report a busy reader can act on. The report answers one business question, shows the few metrics that bear on it, explains what changed and why, and ends with decisions or explicit no-action calls.

Workflow

  1. Write the question first, in one sentence. Examples: Did the pricing page change lift signups? Is organic search bringing more buyers or just more visits? Which channel should get next month's budget? If there is no question, ask for one or state the default: what changed, what caused it, and what to do next.
  2. Pick at most five headline metrics that answer that question. Use the metric map in references/metric-map.md. One outcome metric (key events, revenue, signups), one volume metric (sessions, clicks), one quality metric (engagement rate, CTR), and at most two diagnostic metrics. Everything else goes in an appendix or stays out.
  3. Pull GA4 and Search Console separately, then join by hand where they meet. GA4 covers what people did on the site. Search Console covers how the site appeared and was clicked in Google Search. Landing page is the usual join key. Never add the two tools together into one traffic total, they count different things.
  4. Compare like with like. Same number of days, same day of week mix where possible: last 7 days against the prior 7, or last 28 against the prior 28. Name both periods with exact dates. Watch for holidays, launches, and partial weeks inside either period and say so.
  5. Compute changes with bin/report_math.py, not by eye. It returns percent change, percentage point change for rates, and the raw counts behind each rate. Report both the rate and its counts, for example CTR 3.1 percent (310 clicks on 10,000 impressions).
  6. Check the data before interpreting it. Confirm the period is fully processed, check for thresholding, sampling or preliminary data flags, and confirm no tracking, filter, or consent change landed mid-period. The checks are in references/data-quality-checks.md. A change you cannot rule out as a measurement artifact gets labeled as such, not explained as behaviour.
  7. Annotate every known change on the timeline. Releases, campaigns, price changes, outages, press, search updates, tracking edits. Use the annotation log format in references/annotation-log.md and keep the log with the report, not only inside GA4 or Search Console, so it survives tool and staff changes.
  8. Explain the top moves only. Pick the two or three largest changes that matter for the question. For each: what changed, by how much, the most likely cause tied to an annotation or a segment split, and how confident you are. Split by channel, landing page, device, or new against returning before guessing a cause.
  9. Write the weekly report from assets/weekly-report-template.md. Lead with the answer in two or three lines. Then the headline table, then the explanations, then decisions. Keep the main body to one page. Detail, full tables, and method notes go below the decisions or in an appendix.
  10. End with decisions, owners, and a recheck date. Each decision names what will change, who owns it, and which metric in which future report will show whether it worked. If the honest answer is do nothing, write that and say what signal would change the call.

Output Contract

A weekly or ad hoc report following assets/weekly-report-template.md: the question, the answer up front, a headline table with at most five metrics showing current value, comparison value, percent change and percentage point change where relevant, the annotation timeline for the period, explanations for the top moves with a confidence label, and a decision list with owners and recheck dates. Every rate appears with the counts behind it. Every comparison names its exact dates.

Operating Rules

  1. No metric without a question. If a number does not help answer the stated question or trigger a stated decision, cut it from the headline and from the body.
  2. State every denominator. Engagement rate is engaged sessions divided by sessions. CTR is clicks divided by impressions. A percent with no base is not a finding.
  3. Percent change and percentage point change are different. A CTR move from 2 percent to 3 percent is a 50 percent relative rise and a 1 percentage point rise. Report rates in percentage points and counts in percent, and label which is which.
  4. Small bases get counts, not headlines. A metric built on a handful of sessions or clicks can swing wildly. Show the counts, call the sample small, and do not build a decision on it alone.
  5. Never quote a universal good rate. There is no standard good CTR, engagement rate, or conversion rate that fits all sites, pages, and query mixes. Compare a site against its own history and its own segments, or cite a named, dated source for any outside benchmark.
  6. GA4 engaged sessions have a fixed meaning. A session counts as engaged when it lasts 10 seconds or longer, or includes 1 or more key events, or includes 2 or more page or screen views. Bounce rate in GA4 is the share of sessions that were not engaged. Do not mix this with the old Universal Analytics bounce definition.
  7. Search Console average position is an average of the topmost result. One strong query and one weak query can average to a middling position that describes neither. Read position next to clicks and impressions, for a fixed set of queries or pages, never alone.
  8. Chart and table totals in Search Console can legitimately differ. The chart aggregates by property and the table groups some dimensions by page. A mismatch is expected behaviour, not an error to reconcile away.
  9. Respect processing lag. GA4 data processing can take 24 to 48 hours and recent figures can still change. Search Console shows its newest data as preliminary. Do not publish a verdict on a period that is still settling, or label it provisional when you must.
  10. Thresholds and retention shape what you can see. GA4 applies system defined data thresholds that can withhold rows with small counts, and its retention setting limits Explorations and funnel reports while standard aggregated reports are not affected by that setting. Note either limit when it touches a claim in the report.
  11. Correlation in an annotation is a lead, not proof. A launch on the same day traffic rose is the first hypothesis to test with a segment split, not a conclusion. Label causes as confirmed, likely, or unknown.
  12. Keep the reader's week in view. Weekends, holidays, paydays, and school terms move many sites more than any campaign does. Compare against a period with the same shape before crediting or blaming a change.

Versions

v1.0.02026-10-14 · 0 installs · Ed25519-signed./install.sh web-analytics-reporting 1.0.0bundle (.zip)

publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e

Ratings

No ratings yet — be the first to rate it.