Monday reporting took seven hours of manual work.
Every Monday, the marketing team assembled six platform exports with different naming, date logic and refresh timing. Preparation took about seven hours, and a technically successful export could still contain incomplete data. The manual effort concealed a reliability problem as well as an efficiency opportunity.
Collect the data and check what is missing
Reporting definitions aligned dates, time zones, channel names and measures across the six sources. Each connector was mapped for available fields, lag, transformations and known limits, allowing the refresh schedule to match the reporting need.
Extracted data was normalized before reaching Looker Studio. This moved platform-specific cleanup into a controlled flow rather than requiring the dashboard or a person to repair six incompatible exports every week.
Validate the result and expose the failure
Checks considered source totals, row and date coverage, and unexpected variance. A process could therefore complete technically yet still be flagged for investigation when the expected information had not arrived.
Freshness indicators, retry and alert paths supplied a visible status and an accountable owner. Remaining preparation time covered validation, commentary and exception handling, preserving the quality controls that routine copying had previously mixed with data collection.
A source used for a weekly decision did not automatically need continuous extraction. Cadence considered lag, connector behavior and cost, while validation checked whether the expected period and totals were present.
Failure ownership was explicit because retries alone could not resolve every connector or source issue. The team retained enough context to distinguish a failed run from an incomplete result, preserving a recoverable reporting process after routine preparation became faster.
Check the data, not just whether the workflow ran.
Each reporting run checked source availability, freshness and completeness. A missing feed raised an exception with a named owner instead of silently producing a partial report.
| Refresh condition | Control | Reporting treatment |
|---|---|---|
| Execution failed | Log the failure and apply the defined retry or review route | Expose freshness and a named recovery owner |
| Expected coverage missing | Check rows, dates and source completeness | Flag the dataset rather than presenting silent partial totals |
| Unexpected variance | Compare relevant totals and known lag | Investigate before treating the movement as business performance |
| Ready for use | Required checks pass for the reporting purpose | Release the view with its applicable freshness context |
A successful run could still contain incomplete figures. The handover included checks for what the report actually contained.
Ownership when a source fails
A completed connector run could not be the only success condition. Row coverage, date coverage and source totals needed checks, with delayed conversions and differing reporting lags considered before escalating an apparent discrepancy.
Refresh cadence followed the decision cadence. More frequent extraction could increase cost and failure exposure without improving a weekly decision, while visible exceptions allowed the team to retain quality control after reducing manual preparation.
What reporting looked like after eight weeks
Weekly report preparation fell from seven hours to ninety minutes. Failed refreshes had a visible status, a named owner and a defined recovery path.
The preparation saving concerns routine assembly, not the removal of quality control. Refresh completion, data completeness and freshness remained separate checks, with unresolved failures visible to the person responsible for recovery.
A successful extraction was not enough. The report needed complete, fresh inputs and a named recovery owner, so preparation time could fall without making incomplete data harder to spot.