Skip to main content
The weekly report answers one question: does anything need attention right now? It runs on the flat file and the data dictionary, and every later report, monthly, quarterly, and annual, is built by rolling up the weeks this process produces. Getting this cycle right is what makes every longer cadence cheap to produce.
This process uses the data dictionary, the flat file, and the weekly report template.

What you’ll end up with

  • A week’s worth of new rows added to the flat file, checked and trustworthy.
  • A one-page report, filed in the weekly report archive, comparing performance against target and flagging anything outside its normal range.

Before you start

  • Your data dictionary Part 1 is filled in: north star, KPI tiers, attribution model, and sources of truth are settled.
  • Your flat file exists and has at least a few weeks of history to compare against.

The process at a glance

1

Load the week's rows

Pull each metric from its source of truth and add the week’s rows to the flat file.
2

Check them

Run the flat file checks before trusting a single number in the report.
3

Check the change log

Read the data dictionary’s change log for anything that happened this week.
4

Write the report

Fill in the weekly report template: pacing, exceptions, and anything needing a decision.
5

Quality check and deliver

Confirm the numbers and send, with a short message giving the headline.
6

File it

Log the report in the weekly report archive.

1. Load the week’s rows

Pull each metric from the system named as its source of truth in the data dictionary, and add one row per channel and metric to the flat file for the week just ended. Load raw inputs only, spend, clicks, purchases, revenue; never a calculated ratio. Wait at least two days after the week ends before loading it. Conversion data settles over a couple of days, and a week loaded too early will need correcting later.

2. Check them

Run through the flat file’s checks before using the new rows for anything. At minimum: spend matches the ad platforms, revenue matches the source of truth, and nothing looks unclassified or missing that wasn’t missing last week. If a check fails, fix it before writing the report. An error caught here costs a few minutes; the same error found after the report has already shaped a decision costs a great deal more.

3. Check the change log

Read the data dictionary’s change log for anything logged during the week: a promotion, a price change, a tracking change, a site issue. This is what prevents the “why did revenue spike on Wednesday” conversation from becoming its own investigation when the answer was already on record.

4. Write the report

Fill in the weekly report template. Compare against target and normal range, not against last week; week-over-week movement on weekly data is mostly noise. Only include a metric in the exceptions section if it’s genuinely outside its normal range, and give each exception a real cause or an honest “unknown, investigating.”
Not every movement has a cause. A metric that moved inside its normal range gets no mention. Inventing an explanation for ordinary noise teaches readers that the report’s explanations are decorative.

5. Quality check and deliver

Before sending, confirm: the summary matches the numbers in the pacing table, percentages are calculated in the right direction, and last week’s “needs a decision” items are carried forward and marked resolved or not. Send on the scheduled day with a two- or three-line message giving the headline and the ask. A report attached with no summary in the message body tends to get opened later, which in practice often means never.

6. File it

Log the report in the weekly report archive. Weekly reports are logged by folder location rather than one row per report; see the archive page for the retention period.
Last modified on July 24, 2026