Cross-Platform Ad-Spend Metrics-Basis Integrity Automation: R$26,172 of Real Spend, Zero Rows of Visibility

A data pipeline with three intended stages — a function that records raw numbers, a view that derives a meaningful daily figure from them, and a downstream consumer that reads that figure — can have the second and third stages built correctly, tested correctly, and still produce nothing useful, if the first stage simply never runs. From outside the pipeline, "the view returns zero rows because there's no data yet" and "the view returns zero rows because the one function that was supposed to write data never actually existed in production" look identical — the difference only becomes visible to whoever traces the chain all the way back to its source.

A well-designed data contract — one function writes, a view derives, another function reads — describes what SHOULD happen at each stage, and it's entirely possible for two of those three stages to be implemented, reviewed, and even tested against sample data, while the third quietly never makes it into the branch of code that actually ships. This is especially easy to miss when a project maintains more than one copy of a module's backend during a migration or restructuring: work done in the copy someone is actively editing can look identical, at a glance, to work done in the copy that is genuinely deployed, and only a direct comparison against what is actually running in production reveals the difference.

The reporting view at the center of this — which derives each day's ad spend as the difference between today's and yesterday's recorded campaign totals — had a real, working reader elsewhere in the pipeline and a real, correctly-defined view. What it did not have, in the code actually deployed to production, was any function writing new snapshots for it to compare. That specific piece of logic existed only inside an older, no-longer-deployed copy of the module's own backend code — confirmed directly against the deployed bundle, where it appears zero times. The measured effect: 246 existing snapshot records, every one of them dated from the same day roughly two months earlier, exactly one per campaign — and because the view requires two DIFFERENT days of snapshots for the same campaign to compute any change at all, one-per-campaign meant it had been mathematically incapable of returning a single row this entire time. Meanwhile, the connected advertising accounts held 273 real Meta campaigns with R$26,172.45 in genuine spend and 3.2 million impressions, current as of the same day the audit ran — real activity, invisible to the one view meant to report it.

Reconnecting the real producer function to production immediately surfaced two further, genuine problems that the two-month gap had been masking. First: one connected advertising platform reports a lifetime, ever-growing cumulative total on every read, while the others report a rolling 30-day window that rises and falls — subtracting two rolling-window numbers produces noise, not a real daily figure, and would have silently mixed real numbers with meaningless ones the day the first non-lifetime-reporting account was connected. The fix has every recorded snapshot declare, explicitly, which kind of number it is, and the reporting view now derives daily change ONLY from snapshots declared as the cumulative kind — a rolling-window snapshot is still recorded for reference but deliberately excluded from the daily-change calculation. Second: the very first calculation performed after reconnecting spanned a roughly two-month gap between snapshots, and a naive subtraction attributed the entire two months of real spend to a single day — a specific, measured example: roughly R$2,354 in genuine spend across two months, misread as a single day's figure. The fix caps how large a gap between two snapshots can be before the view will compute a daily figure from them at all — past that limit, no number is produced for that gap, on the explicit principle that no reported figure is better than a wrong one presented with the same confidence as a correct one.

Worth stating clearly: every part of this fix operates read-only against connected advertising platforms' own reporting APIs. No campaign was created, paused, modified, or had its budget changed by any part of this work.

A set of connected Meta campaigns accumulates real, ongoing spend for two months while the daily-reporting pipeline's producer function is missing from production — the underlying accounts show genuine activity throughout, but the reporting view shows nothing because no new snapshot has been recorded to compare against the last one. Once the real producer function is reconnected, the FIRST calculation performed spans that entire two-month gap — without a gap limit, that calculation would attribute the whole two months of spend to a single day; with the fix in place, a gap that long instead produces no daily figure at all, and the view resumes producing genuine day-by-day numbers from the very next pair of consecutive snapshots.

Centriu Maestro's daily ad-spend reporting view now reflects real, currently-recorded campaign activity rather than two-month-old, mathematically zero-yielding data — and the two defects that would otherwise have corrupted that same data the moment it started flowing again (a platform-basis mismatch, an unbounded reporting gap) are closed structurally, not patched for this one incident.

This page covers the correctness of Centriu Maestro's OWN daily ad-spend snapshot and reporting-view pipeline — it does not describe or promise any specific cross-product feature for connecting that data to another Centriu system as a marketed integration; the confirmed downstream reliance cited here (an independent Axis reporting tool) is presented as evidence the underlying view is real, current infrastructure, not as a described product feature.

A data pipeline can have a correctly-defined view and a correctly-built downstream reader while still producing nothing useful, if nobody has specifically confirmed the writer at the START of the chain is the one actually deployed rather than a copy sitting in code that never ships. Centriu Maestro's fix didn't stop at restoring the missing producer — it re-verified the full chain against real, measured numbers, and used that same reconnection to surface and close two further defects the gap had been hiding.