Automated reporting: a schedule is not a source of truth

Why a scheduled export is wrong on schedule

A scheduled export carries its own definition. It sits in the connector’s filter, the saved query, or the formula someone typed into column F. Each copy is its own version of the truth, and the schedule repeats it faithfully.

None of these failures shows up as an error. The run succeeds, the file arrives on time, and the number is wrong in the same way every week.

A number that depends on its definition

Click-through rate is the cleanest example, because there is no dispute about the inputs. Clicks and impressions are counted by the ad platform. The disagreement is only in how they are added up.

We ran this on the demo e-commerce project we use for examples (synthetic data, Google BigQuery, run on 29 October 2026). One row is one Google Ads campaign on one day:

SELECT
  FORMAT_DATE('%Y-%m', date) AS month,
  ROUND(100 * SUM(clicks) / SUM(impressions), 2) AS ctr_clicks_over_impressions,
  ROUND(100 * AVG(SAFE_DIVIDE(clicks, impressions)), 2) AS ctr_average_of_rows
FROM `owox-demo.ecommerce.ad_performance`
WHERE source = 'google'
  AND date BETWEEN '2026-04-01' AND '2026-09-30'
GROUP BY month
ORDER BY month

Same campaigns, same clicks, same months. In July the two columns are 4.87% and 9.41%, and both would arrive on schedule labelled “CTR”. The average gives a campaign-day with three impressions and one click the same weight as one with three hundred, so a low-volume campaign drags it up. The click-through rate is the first column.

A sheet that averages a CTR column, refreshed every Monday by a perfectly working export, reports the second column for as long as nobody notices. The schedule did its job. Nobody owned the definition.

The Google Ads AI dashboard on the same demo data has a view built for exactly this, and it shows the gap opening in April 2026, when a low-volume campaign joined:

Automating a file vs automating a governed Report

Both run on a schedule. The difference is where the definition lives and who can change it.

In OWOX Data Marts, a Report connects one Data Mart to one Destination, and one Data Mart can have many Reports with different schedules (Reports). Destinations come in two modes, and the mode decides what “automated” means for each:

• Push. OWOX delivers the Data Mart’s data on a manual or scheduled run: Google Sheets, Email, Slack, Microsoft Teams and Google Chat. A Report Trigger sets the schedule: daily, weekly or monthly at a time and time zone you choose, or at an interval such as every 30 minutes (Report Triggers).
• Pull. The tool asks OWOX for the data when someone opens or refreshes it, and OWOX reads the storage: Data Studio and Excel. You do not schedule these. For Data Studio you switch on “Available in Data Studio” on the Data Mart instead of creating a Report; Excel reports are created in the Excel Add-in (Destinations).

Either way the query comes from the Data Mart, not from the destination. That is the part a file export does not have.

Set one up so each run re-reads the same definitions

The setup is short. The first step is the long one, and no tool shortens it.

1. Write the definition down and name its owner. For CTR: “clicks summed over the period, divided by impressions summed over the period; owner: paid media lead”. For revenue: which order statuses count, whether tax and shipping are in, which date and time zone. Finance names the official revenue rule, not the person building the report.
2. Publish it as a Data Mart. Put the SQL that computes the number on the table, view or query that already holds the data, and describe each field in the business’s words. A Data Mart is that SQL plus its description, owner and relationships to other Data Marts, and an AI assistant that reads it through OWOX MCP for Claude and ChatGPT is given the same descriptions.
3. Declare the joins. If the number needs two Data Marts, say spend and orders, declare the relationship once instead of letting each report join them its own way (Joinable Data Marts). Together, the published Data Marts and their declared joins are your Data Model.
4. Create the Report and its trigger. On the Data Mart page, create a Report for each destination your team uses, then add a Report Trigger for push destinations. Pull destinations need no trigger.
5. Keep the definition out of the sheet. In Google Sheets, OWOX rewrites the imported range from scratch on every refresh; columns to the right of it survive (Google Sheets destination). That is the place for notes and one-off analysis. A CTR averaged in column K is a new, ungoverned definition again, so if a number is reported every week, it belongs in the Data Mart.
6. Make the run tell you when it is stale or wrong. Every report run records Data Last Updated, when the source tables behind the Data Mart last changed, in its Run History entry (Data Last Updated). Data Quality Checks, such as null rate, duplicate rows or a freshness threshold in hours, can run on a trigger of their own (Data Quality Checks), and notification settings alert you about failed runs.

After that, “the report is wrong” becomes a question with an address: either the definition in the Data Mart is wrong, and you fix it once, or the source data is late, and the run history says so.

Connected, not a snapshot: the AI dashboards

The same rule covers dashboards an AI builds, which is where exported files multiply fastest. A dashboard built on an uploaded export is a snapshot with the export’s definitions frozen into it. The AI dashboards on owox.com were built the other way: Claude built each one through OWOX MCP, reading the demo e-commerce Data Model of twelve Data Marts and fifteen relationships. On OWOX an AI dashboard is kept as a Report and refreshed every time it runs, like a Report in Google Sheets.

• The Google Ads dashboard reads four Data Marts: Unified Ad Spend, Sessions, Traffic Sources and Purchases. The same Data Marts can run as a Report in Google Sheets, so the dashboard and the weekly sheet start from the same definitions instead of two exports.
• The Forecast view of the Net Sales Review sets net sales against the store’s revenue plan. The plan is a Data Mart of its own, so the target on the dashboard is the store’s, not one the AI wrote into the page.

Two limits, stated on the dashboards themselves. Connected is not live: a dashboard refreshes when its Report runs, not each time someone opens it, and the pages linked above are frozen copies, because a public page cannot query a live project. And a ratio the AI computes on top of the Data Marts is the AI’s calculation: the CTR lines in the screenshot above are computed that way, over Unified Ad Spend’s daily clicks and impressions, and the dashboard says so. A definition is governed only where it lives in the Data Model.

What this does not fix

A wrong definition, held consistently. The Data Model holds every Report to one definition. It does not tell you whether the definition is right; that is still the analyst’s and finance’s decision.

Anything computed after delivery. A formula in the sheet, a pivot in Excel or a ratio the AI calculates is outside the Data Mart, and each one can drift. Move the numbers people report on into the Data Mart; leave the rest as analysis.

Freshness, read too literally. Data Last Updated is a storage timestamp: a backfill can rewrite a table today with old figures, so “updated today” does not mean “covers today”. The freshness check in Data Quality Checks reads the timestamps inside the data instead.

Pull destinations on their own clock. A Data Studio or Excel report shows what the Data Mart returns when someone opens or refreshes it. There is no schedule to set, and nothing is delivered to anyone who does not open it.

For the wider pattern behind conflicting reports, see why the same metric shows different numbers, and for AI-built dashboards specifically, vibe coding dashboards.

Case studies: automated reporting with OWOX

Three customer projects from 2018 to 2021, built on the products OWOX offered at the time. The tools have changed; where the definitions lived is the part that carries over.

MatahariMall: one SQL script for 30 metrics

MatahariMall, the online sister company of an Indonesian department store, spent about four hours a day refreshing reports by hand across channels, and needed about 30 metrics, including ROAS on two attribution models, in one report. Web, app, ad cost and CRM order data were brought together in Google BigQuery, OWOX analysts wrote one SQL script that calculated every metric, and the results went to Data Studio and Google Sheets daily. The four hours a day went back to the analysts, and every metric came from one calculation.

A digital agency: one currency, one tax rule

PPC specialists at a digital agency spent most of the first one and a half weeks of each month on the previous month’s client reports. Automated reports in Data Studio needed every platform’s ad costs in one currency and with taxes treated one way, which OWOX’s cost import handled. With half its clients moved over, the agency saved up to 90 hours of PPC work a month, and clients could see their numbers for any date range instead of once a month.

Automated client reporting works the same way, at a larger scale. An agency reporting to many clients is where a definition copied into each client’s file drifts fastest: one client’s sheet takes VAT out of revenue, another’s still counts cancelled orders, and two accounts stop being comparable without anyone deciding they should differ. Define spend, conversions and revenue once, in the Data Mart, and give each client a Report of its own from it, delivered to that client’s Google Sheet on its own schedule: one Data Mart can feed many Reports, each with its own destination and trigger (Reports). Every client’s report then reads the same definition instead of a copy of it, and a change made once reaches all of them on their next run.

A restaurant chain: plan against fact, from one warehouse

A restaurant chain with 57 locations merged website, app, CRM and ad data in Google BigQuery, processed it there with views and scheduled queries, and reported in Power BI. Its management report compared each KPI with plan and forecast, and splitting purchases into new and returning customers let it exclude returning customers from campaigns aimed at new ones, which reduced cost per order across channels.

ReportingE-Commerce Reports: 10 Reports to Track Store PerformanceNovember 4, 2024→ReportingMarketing Reports: How to Build One That Changes a DecisionOctober 19, 2026→ReportingMarketing Dashboard Examples and Templates, by the Question They AnswerOctober 30, 2026→

See all articles →