The marketing report that writes itself

The Monday report nobody has to assemble

Picture next Monday: a report lands in front of your team before the planning slot - real numbers from your real properties, deltas computed, big moves flagged, narrative written. Compare that to the ritual it replaces: someone spends an hour screenshotting dashboards into a doc that says what happened without saying what it means. The automated version is better on both counts: the assembly runs itself, and the hour goes into the part only you can do - deciding what to change.

The shape you're building: last week's data files and the prior week's sit in the repo, Claude computes the deltas, flags anything that moved more than 20%, and renders a self-contained HTML report with the narrative up top. Scheduled, delivered, done before you've had coffee.

Data in: exports, not integrations

Every tool in your measurement stack - your site analytics, your search console, your newsletter tool - exports CSVs. That export is the whole integration this lesson needs. Files land in data/analytics/, dated, and Claude takes it from there: no credentials to babysit, no API that changes under you, and the report works the same whatever tools the numbers come from. Be honest about the cost: for most stacks the weekly drop is a manual five-minute ritual, because site analytics and search consoles generally have no scheduled-CSV-email feature - a person does the export. Some newsletter tools can schedule theirs; treat that as a bonus, not the plan. And build the failure mode in: the weekly-report skill checks for the expected files first and opens with a loud 'data missing or stale' line when a pull isn't there. An honest gap beats a silently wrong report.

1. Create the folder convention: data/analytics/<source>/<YYYY-MM-DD>.csv - one folder per source, one dated file per pull.
2. Export last week and the week before from each source you care about, so the first report has something to diff.
3. Have Claude write a small normalizer - scripts/normalize_pulls.py - that reads whatever shape each source exports and writes one tidy weekly file per source. Export formats change rarely; when they do, you fix one script.
4. Smoke-test: ask Claude for 'sessions by channel, last week vs prior' from the files. Numbers match the dashboard you exported from? The data side is done.

Which sources, and how many

• Site analytics: sessions by channel, top pages, conversions - the spine of the report.
• Your search console: queries, clicks, impressions - essential for the SEO side, and where the programmatic cohort from the last lesson gets tracked.
• Newsletter stats: opens, clicks, and list growth per issue, from your sending tool's export.
• Channel and pipeline: social numbers from wherever you post, CRM-attributed pipeline if you want the report to reach revenue.

Start with two sources - site analytics and your search console cover most B2B marketing questions - and add more only when someone asks a question the report can't answer. Every source adds a weekly file and a bit of noise; the report earns extensions by being read.

The weekly-report skill

Reporting skills are well represented in the open catalogs - install the library's version if one matches your stack, then adapt it to your metric set, your folder convention, and the no-hallucination rule. Borrowed or built, the contract looks like this:

---
name: weekly-report
description: Build the Monday marketing report. Reads the dated pulls
  in data/analytics/ (last week vs the prior week), computes deltas,
  flags >20% moves, and writes a self-contained HTML report to
  reports/. Read-only against the data - never edits a pull.
disable-model-invocation: true
---

1. Define the metric set in the skill - 8-12 metrics you'd actually act on: sessions by channel, top pages by delta, conversions, search clicks and impressions, newsletter opens and clicks, the pSEO cohort if you ran lesson 2.
2. Read both weeks from the dated files, compute deltas, and flag every move beyond 20% - flags are where the narrative starts.
3. Generate the narrative first, numbers second: 3-5 sentences on what moved, why (attributed to specific pages or sends, traced from the data, never guessed), and what's worth doing about it. If the why isn't in the data, the report says 'cause unclear' - the no-hallucination rule applies to analytics too.
4. Render one self-contained HTML file - inline CSS, simple bar/line charts, no external dependencies - to reports/YYYY-MM-DD.html. Opens in any browser, attaches to anything, works in five years.
5. Schedule it: a Routine or cron firing early Monday, with the report (or its summary paragraph) delivered wherever your team already looks.

The first three weeks, read it skeptically against the source dashboards and tune: kill metrics nobody acts on, fix attributions the narrative gets lazy about. By week four it should be trusted enough that nobody opens a dashboard on Mondays. And note where this sits on the ladder: the report was a chat the first time you tried it, became a skill the second time (same asset twice - that's the law), and is now a scheduled automation. Nobody on the team re-prompts a report into existence, ever.

Track what compounds, kill what doesn't

The weekly report tells you what moved. The monthly question is different: what compounds? Some work keeps paying after you stop - search content, the comparison play, evergreen posts that feed the newsletter. Some work stops the moment you stop - most social, most launches. Both belong in a portfolio, but you should know which is which and steer spend toward what compounds.

1. Add a monthly section to the report: every published piece's cumulative traffic and conversions over time, from the published/ archive plus analytics.
2. Sort by trajectory, not totals: still-growing at 90 days = compounding; spiked-and-dead = consumable.
3. Rebalance quarterly: more of what compounds, and a conscious decision - not a default - about the consumables.

Do this now

Sources and further reading

• Claude Code skills docs
• How Anthropic teams use Claude Code