How do you build a weekly marketing report nobody has to assemble?

How do I build a weekly report nobody has to assemble?

Decide the five numbers first, pull each one from a source that has an export or an API, write them into one sheet on a schedule, and have the automation send a short summary rather than a dashboard link. The assembly has to be machine work or it will stop happening.

Every manual weekly report I have seen dies the same way. It survives for six weeks, then the person who builds it gets busy, then it becomes fortnightly, then it quietly stops and nobody notices for a month. The cause is never laziness. It is that assembly is genuinely tedious.

What follows is the sequence I would actually build, in the order that matters, for a small marketing team with no data engineer.

What should actually be in it?

Five numbers and one sentence. Sessions or users, your top three pages, where the traffic came from, how many conversions you got, and what changed compared with last week. If you cannot name five, you are not ready to automate anything.

The discipline of picking five is the most valuable part of this whole exercise, and it is the part everyone skips. A report with thirty metrics is not more informative, it is less, because nobody can tell which movement matters.

The sentence is not optional either. A human should write one line each week saying what they think happened. Without it the report is data, and data does not change behaviour. I have worked through which numbers earn a permanent place in which marketing numbers deserve a dashboard.

Where does the traffic data come from?

If your site is on Webflow, its own Analyze tooling is the shortest path, because it exposes exactly the report shapes a weekly summary needs. It provides a traffic time series, a top pages report, a top dimensions report, a top engagement events report, and a time on page report that can return either one aggregate value or day and week buckets.

The metric choice is explicit. You can count by session, by user, or by pageview, which matters because those three tell different stories and mixing them between weeks is how reports lose credibility. One detail worth knowing before you design anything: Webflow's own tooling documents that pageview is not supported for the top dimensions report, so if you want a breakdown by country or source you are counting sessions or users, not pageviews.

The dimension list is generous enough for most weekly reporting. It includes page path, referrer, traffic source, country, device type, browser, and the full set of UTM parameters, which is what lets a weekly report answer where the traffic came from without any extra tooling.

What are the constraints on the analytics data?

Three that will bite you if you discover them after building. Timestamps have to be UTC, the history does not go back forever, and there is a cap on how wide a window you can request.

On timestamps, Webflow's Analyze tooling requires ISO 8601 UTC values ending in Z and explicitly does not accept numeric offsets such as minus four hours. If your automation builds a date range in local time, it will fail, and the failure will look like a mysterious error rather than a timezone problem.

On history, the same tooling states that the start of a query must be on or after the ninth of April 2025. That is a real boundary for anyone trying to build a year over year comparison, and it is better to know now than to build a template that silently returns nothing.

On window width, the range from start to end must not exceed one hundred days. For a weekly report that is irrelevant, but for the quarterly rollup you will inevitably be asked for, you will need to chunk the requests. Bucket boundaries are aligned to an IANA time zone you supply, so decide once whether your week starts in your time zone or in UTC and then never change it.

How do you get search data in without copy and paste?

Use Search Console's export rather than reading numbers off the screen. Google documents that you can export up to one hundred thousand rows of data, that pages containing a single table offer a download button which exports the entire table up to one thousand rows, and that you can export as a CSV file or directly as a Google Sheet.

The Google Sheet option is the one that makes this automatable without writing much code. If the export lands in a sheet, an automation can read it, and you have avoided the single most fragile step in most reporting setups, which is a human downloading a file and putting it somewhere.

The thousand row ceiling on single table downloads is worth planning around. For a weekly report you almost certainly want your top twenty queries and top twenty pages, so you will be nowhere near it, but if you start exporting everything you will hit it and get a truncated view without an obvious warning.

How do you stitch the sources together?

One sheet, one row per week, one column per number. Nothing clever. The sheet is the store, and everything else either writes to it or reads from it.

That shape has two properties that matter. It is append only, so last week's numbers cannot be accidentally overwritten when this week's job runs. And it is readable by a human without any tooling, which means when something looks wrong you can check it in ten seconds.

Resist the urge to put the logic in the sheet. Formulas that reach across tabs and reference ranges by position are the most common cause of silently wrong reports. Let the automation compute and write plain values, and keep the sheet dumb.

What should the automation actually send?

A short message with the five numbers, the change from last week, and a link to the sheet. Not a dashboard invitation. Not an attachment. Something a person reads on a phone in fifteen seconds.

The reason is behavioural. A report that requires clicking through gets clicked through in week one and ignored by week four. A report that delivers the answer in the message itself gets read, and the link is there for the one week in five when somebody wants to dig.

Keep the message boring and identical every week. Same order, same labels, same formatting. Consistency is what lets someone notice an anomaly without reading carefully, and noticing anomalies is the entire point. The same principle applies to operational alerts, which I have written about in what a nightly automation should email you.

One last practical note on cost. If you build this on a platform that bills per action, do the arithmetic first. Zapier's own documentation defines a task as any successful action that runs in Zapier, and a report that pulls from three sources, writes to a sheet and sends a message is several actions per run. Weekly frequency is what makes it affordable, which is a good reason to resist making the report more frequent than the decisions it informs. Check current rates on the vendor's own documentation, because they change.

How do you stop the report from growing?

Make additions cost something. My rule is that a new metric can only go in if an existing one comes out, and whoever wants the addition has to say which decision it will change.

Without that rule, reports grow monotonically, because adding a number is easy and removing one feels like hiding something. Across more than 70 projects for more than 25 clients over more than six years, every abandoned report I have inherited was abandoned after it got too long to read, not because the numbers were wrong.

The related discipline is upstream. If your traffic sources are not tagged consistently, no amount of reporting design will produce a trustworthy breakdown, which is why conventions have to be settled first. I have set out how to do that in how to set up UTM conventions for a small team.

What breaks, and how do you know?

The report stops arriving, or it arrives with a zero in it. Those are the two failure modes, and only one of them is obvious.

A missing report is easy to notice because a human expects it. A zero is dangerous, because it looks like a bad week rather than a broken pipeline. The fix is to have the automation refuse to send anything if a value is missing, and to send an explicit failure message instead. A loud failure is always better than a plausible number.

Build in one sanity check at minimum. If this week's sessions are zero, or ten times last week's, stop and alert rather than reporting it. Those thresholds do not need to be smart to catch almost everything that goes wrong.

What should you do next?

Write down your five numbers today, before touching any tooling. Then find, for each one, where it comes from and whether that source has an export or an API. If any number has no automatable source, either replace it or accept that it will be manual forever.

Then build the dumbest possible version: one sheet, one weekly job, one short message. Run it for a month before you improve anything, because a month of real data will tell you which of your five numbers you actually look at.

If you want a second opinion on which five numbers belong in your weekly report, reach out. Choosing them is harder than building the pipeline, and getting it wrong is what kills reports.