Define the report’s job

For this illustrative workflow, a marketing lead needs a weekly view of channel performance before a planning meeting. The report should make meaningful changes visible, identify data limitations and help the team choose what to investigate. It does not automatically reallocate budgets or claim to explain every movement.

Begin with the questions the meeting needs to answer. Which campaigns changed materially? Are the numbers complete enough to compare? What requires a channel owner’s attention? The reporting specification follows those questions, rather than collecting every metric an API happens to provide.

Agree a shared measurement contract

List the sources, reporting period, time zone, currency, account scope and calculation for each measure. Agree what a conversion means in each source. An ad platform conversion, an analytics event and a qualified CRM opportunity are different observations; combining them under one label creates false certainty.

Store definitions alongside the report. If a measure changes, record when the definition changed and whether historical comparisons remain valid. Keep attribution windows visible. A report should distinguish the platform’s reported results from outcomes verified elsewhere.

  • Source and account scope
  • Time zone, date range and comparison period
  • Metric formula and inclusion rules
  • Attribution window and known limitations
  • Owner of each definition

Collect, then check

The scheduled run collects the agreed source data into a controlled reporting layer. Access is scoped to what the workflow needs. This example can begin with read-only source permissions and a separate permission to write the reviewed report to its destination.

Before calculating a summary, check freshness, expected date coverage, missing accounts, duplicate records and required fields. A source returning no rows is not automatically evidence of zero activity. Compare the response with what the connector and reporting contract expect.

If a critical source is incomplete, hold the affected section and show the reason. Preserve the last successful output with its original timestamp. Do not silently present old numbers as the current period or fill the gap with a model’s estimate.

Calculate before asking for a narrative

Compute totals, rates and period comparisons using explicit formulas. For example, cost per lead needs an agreed spend field and lead count from compatible scopes. If the denominator is zero or unavailable, display an explanation rather than an invented rate.

Only then provide the validated results and their definitions to the narrative step. Ask it to separate observations, possible explanations and proposed investigations. A rise in reported cost per lead is an observation. Creative fatigue is a hypothesis until additional evidence supports it. Every numerical statement should be traceable to the calculation output.

Put review at the decision point

The reviewer receives the summary, source references, freshness indicators and unresolved checks together. They can correct the interpretation, request an investigation or approve the report for distribution. The workflow records the approved version and avoids sending multiple copies when a run is retried.

Budget changes, publishing and customer-facing claims remain separate actions with their own authority. A reporting system should not inherit those permissions just because it can suggest a next step. The aim is a clearer decision with supporting context.

  • What changed: validated observations
  • What might explain it: labelled hypotheses
  • What is uncertain: coverage and attribution limits
  • What happens next: action, owner and review date

Design recovery and ownership

Each run needs a record of the sources used, checks completed, output produced and delivery status. If a connector fails, the owner should see which part failed and whether a retry is safe. If delivery fails after approval, recovery should resend the approved output rather than rerun analysis without a reason.

Operating guidance should cover expired permissions, changes to source fields, corrected historical data and metric-definition updates. Agree monitoring and response responsibilities explicitly. A build does not imply round-the-clock support or an unchanging external API.

Evaluate whether the engine helps

Compare the new workflow with a baseline: preparation effort, data corrections, review time and how often the report supports a clear action. A faster report is not necessarily a better decision. Review whether the people using it understand its definitions and can challenge its conclusions.

Taking this illustrative architecture into production requires verified source access, agreed definitions and testing in the team’s environment. Begin with one reporting decision and enough evidence to judge whether the workflow helps, then expand as the operating model becomes dependable.

Continue exploring

How we build a marketing system ↗