The data health gate: never decide on ads with broken data

It is 9:40 on a Tuesday. Someone on the performance team opens the dashboard: the summer campaign shows a ROAS of 0.4 against a rule threshold of 1.0. The rule is built correctly, the condition is written correctly, the action is chosen correctly, and the campaign is paused. By mid-afternoon the platform's conversion records catch up and that same campaign's return for the day lands at roughly double the threshold. The rule did not misfire. The table feeding it was nineteen hours stale, and part of the conversions had not been written yet. The numbers here are illustrative, but the situation is familiar: what got paused was not a bad campaign, it was a sentence read off half a table.

This article is about the mechanism that stops that sentence from ever being read. We start by separating where ad data actually breaks. Then we work through what a data health gate should verify, under three headings: freshness, coverage and currency. After that we cover how a rule should behave while the gate is closed, which tests a rule should pass before you switch it on, and how to turn all of this into a weekly routine. Frequently asked questions close the piece.

Where does ad data actually break?

“The data is broken” is useless on its own, because breakage never happens in one place. A number that reaches an ad decision passes at least four stops: the platform's own reporting layer, the sync that pulls it to your side, the match between the record and your CRM, and finally the summary table the rule reads. Each stop has its own failure mode, and they look nothing alike. When a dashboard says twelve sales yesterday while a rule sees seven, one of those stops is running behind.

The most common break is the link between campaign and record snapping. A visitor arrives from an ad, fills in a form, the record lands in the CRM, and nothing records which campaign sent them. The platform side says “conversion”, the revenue side stays silent, and true return looks lower than it is. Finding where the link broke means rebuilding the tagging scheme from scratch, and putting campaign tags on a single consistent schema is the dullest high-return step in the whole stack.

The second frequent failure is a sync that stops entirely. An access token expires, an account owner leaves, or the ad account gets restricted on the platform side. The dashboard keeps showing yesterday's numbers, so nothing looks wrong. The only way to catch that silent outage is to look at the age of the data rather than the data itself. When an account is fully shut down the symptom is louder but the fix is longer; what to do when an ad account is restricted is a subject of its own.

• Lagging conversions: ROAS read before the attribution window closes is always understated.
• Partial day: Today's incomplete data gets pushed into a daily threshold.
• Currency mismatch: The account bills in one currency, the threshold is written in another.
• Time zone drift: The platform's day and the report's day do not start at the same hour.
• Duplicate records: The same conversion is counted from both the platform and the CRM.

What does a data health gate verify, and what does it not?

A gate, by definition, is the thing that blocks passage. The data health gate in Ads Automation will not let a rule be created until three things check out: sync freshness, 28-day data coverage and account currency. These are mechanical checks. They need no interpretation, they are not open to debate, and they behave the same way in every account regardless of what the rule says. Decisions not coming out of stale data is therefore a precondition, not a recommendation.

It is worth being just as clear about what the gate does not do. It has no idea whether the metric you picked is the right metric. If you set a CPA threshold when the real constraint on the business is CPL, the decision is wrong even with flawless data. The gate also does not reconcile platforms that define the same metric differently, where a conversion means seven days post-click in one place and one day in another. Surfacing that difference is the job of a setup that brings campaigns into one dashboard, not of the gate.

Gates and guardrails are also worth keeping apart. A gate decides whether a rule runs at all. Guardrails limit how much can change once it does: budget change limits, cooldowns between actions, a daily budget floor, and skipping targets still in the learning phase. They sit back to back. The gate says “no decision comes out of this data”; the guardrail says “if a decision is coming out anyway, only this far”.

Sync freshness: how stale is too stale for a decision?

The freshness threshold depends on how reversible the decision is. Six hours of lag is fine for sending an alert; the same six hours is too much for halving a budget. The distinction that works in practice: the harder the action and the harder it is to undo, the tighter the freshness threshold has to be. Raising a budget by ten percent and pausing a campaign do not deserve the same data age.

The table below is the kind of frame that ends the argument inside a team. Threshold values are examples and will shift with your sync cadence and attribution window. What matters is not the numbers but that every check has an owner and a defined behaviour when the gate closes.

Check	What it looks at	Example threshold	If the gate closes
Sync freshness	Last successful data pull	No older than 6 hours	Rule does not run, reason logged
Data coverage	Unbroken days of history	All 28 days present	Rule stays a draft
Currency	Account unit vs threshold unit	Exact match	Budget actions blocked
Time zone	Day boundary in account and report	Same start hour	Daily thresholds disabled
Conversion maturity	Whether the attribution window closed	Last 3 days excluded	Pause routed to approval

Freshness has a quiet failure mode too: the sync runs, data arrives, and the data is always the same. The rule then runs every hour, nothing ever matches, and nobody notices. The silent-rule notification in Ads Automation exists for exactly this case — if a rule produces no result run after run, marketing owners get told. The most dangerous form of broken automation is not a wrong decision, it is looking switched on while deciding nothing.

How many days of data justify a pause?

There is no single right answer, but the wrong answers are obvious: “yesterday was bad” is not an answer. To claim a campaign is genuinely underperforming, you have to have seen its normal variance. On a campaign with modest daily spend, three days of data says almost nothing; on one taking hundreds of conversions a day, the same three days is more than enough. The decision window comes out of volume, not the calendar.

That is why a minimum data window is defined as a guardrail and pinned as a minimum data-days requirement in account-level policy, which no individual rule can loosen on its own. Instead of writing “last 7 days” into a rule and moving on, ask how many conversions those seven days contain. The reasoning is the same habit as asking for sample size before calling a comparison test; the logic behind deciding between two options with data applies here as directly as it does in a creative test.

Then there is the learning phase. Algorithmic campaigns behave erratically for a stretch after launch, and ROAS measured in that window does not represent mature performance. Skipping targets in the learning phase is a guardrail for precisely that reason. Keeping that period separate matters when you decide how much rope to give the platform; when to let the algorithm run its own optimisation is a separate set of decisions that should not collide with your rule engine.

How do currency and time zone mismatches distort a budget decision?

A currency error is silent, which is exactly why it is expensive. If the account bills in one currency and you wrote the threshold in another, the rule compares against the wrong number and the result still looks plausible. A rule that says “cut budget if CPA is above 40” either never fires or fires every single day once the account unit and the threshold unit diverge. Neither outcome reads as a fault signal; both read as an ordinary chart.

Time zone drift is subtler. If the platform's day and your report's day start at different hours, a daily spend threshold is permanently measuring half a day. In month-end budget pacing this drift accumulates: the gap between ideal, actual and projected spend widens a little every day, and the last week of the month arrives with a sudden brake. Seeing where spend actually went, at query level, makes the source of that drift much easier to trace, and cutting budget that leaks into irrelevant searches is the first correction in most accounts.

What these two checks share is that they can be verified once at setup and then forgotten. Because the data health gate validates account currency before a rule is created, this class of error gets caught on the setup screen rather than over the lifetime of the rule. One second of friction while writing a rule beats a wrongly throttled budget three weeks later.

Why is reading ROAS too early when conversions lag?

In businesses with long sales cycles, weeks can sit between the conversion value a platform reports and money actually arriving. An ad brings in a form today, sales speaks to them two weeks later, the opportunity closes in week three. Pausing on today's ROAS in that setup is like writing the review ten minutes into the film. The problem is not the speed of the rule; it is that the thing being measured has not happened yet.

The fix is to move the measure off the platform's conversion value and onto revenue. The true-ROAS-from-CRM approach in Ads Automation does exactly that: it measures opportunity revenue won in the sales process instead of the platform's own conversion value, and it stops a loss verdict being reached before cohorts mature. For that measure to exist at all, spend and revenue have to match on the same identity, so closing the loop between ad spend and CRM revenue is the precondition for this section.

The same data hygiene applies to lists you push back to the platforms. Dirty email fields, missing country values or duplicated records make an audience look smaller or simply wrong. When building audiences from CRM records and the match rate drops, the fault is usually in the source table rather than the platform. The gate is a reminder to take outbound data as seriously as inbound.

What should a rule do while the gate is closed?

A closed gate is not an error message; it is a decision, and that decision needs a defined behaviour. There are three reasonable options: do not run the rule at all, run it but route the action to approval, or send an alert only. The wrong fourth option is to ignore the gate and apply the action. Which one is right depends on how hard the action hits.

For hard actions, a human is the cheapest insurance available. Pausing a campaign, doubling a budget or shutting off an audience should not execute automatically while the data is in question. That is what an approval queue is for: the match lands in a queue, the reason and the exact change are visible, and nothing touches the campaign until you approve it. The process-side equivalent is familiar — adding a human approval step into an automated flow is not lost speed, it is braking distance ahead of an irreversible step.

For soft actions, stopping is an unnecessary cost. Sending an alert, trimming a budget by five percent or flagging a campaign stays reasonable even with slightly stale data. The real rule here: every action applied while the gate is closed must be reversible. If you can undo a single applied decision or an entire run within 24 hours, moving on a day when the gate is closed carries a bounded cost.

How do you test a rule before opening the gate?

You can measure how a rule will behave against your data rather than guess. A backtest shows how many times and on which campaigns a rule would have fired over the last 28 days, without touching anything. What to look at there is not just the count but the distribution. Firing twice in 28 days usually means the threshold is too tight; firing every day on every campaign usually means the rule has written a policy rather than a threshold.

The second test is a simulation with your own numbers. You enter example metrics by hand and watch whether the condition matches and how the guardrail trims the change; nothing is written to the account in this step. The third is choosing the threshold from data rather than instinct: look at how the metric is distributed across your campaigns, turn the median into a threshold in one click, and read how many campaigns that catches. The same discipline works on the creative side, where testing systematically which asset wins and why turns threshold arguments into evidence rather than opinion.

Then comes a staged rollout. Run the rule on a small slice of campaigns first, in show-only mode; read the decisions, count how often the gate closed, then move to approval mode. Switch to automatic once it has earned it. The point of that sequence is not to move slowly, it is to discover cheaply that a rule is wrong.

How do you turn data health into a weekly routine?

The gate runs by itself, but reading the days it closed is human work. Fifteen minutes once a week is enough for most accounts: which rules were blocked and how often, whether the block was freshness or coverage, and which account keeps repeating. After a while the list starts repeating itself, and every repeating item is a fixable setup error rather than a data accident.

The second routine is post-action reading. When the window before and after each applied action is compared over equal periods, you get an observational read on whether the rule is helping. That comparison does not claim causality and should not — season, stock and competition also moved that week. Still, if an account shows no aggregate improvement after a rule has repeatedly paused campaigns, its threshold deserves another conversation.

The third is conflict checking. When rule pairs in the same scope, one raising a budget while the other cuts it, are flagged, they get resolved on one screen. As rule count grows, the chance of conflict rises faster than linearly, which is why setting rule execution order deliberately is a design decision rather than a setting. If you want to run your rules with that discipline alongside a data health gate, open a Rocketly account and start the first rule in show-only mode.

FAQ

Does the data health gate stop a rule entirely?

The gate prevents a rule from being created until validation completes: no rule operates before sync freshness, 28-day data coverage and account currency check out. For a rule already live, you decide what happens when the gate closes — skip the run, route it to approval, or send an alert only.

Do thresholds need setting per account?

Yes, because freshness and coverage needs follow account volume and sales cycle length. An account taking a handful of conversions a day genuinely needs the 28-day window, while a high-volume account can make shorter windows meaningful. Account-level policy is where those limits live in one place.

If the data is stale, why not let the rule make an approximate call?

An approximate call is reasonable for reversible actions. For pauses and large budget swings, where reversal is expensive, an approximate call converts a missed opportunity into a fixed cost. The split is made on how hard the action hits, not on how stale the data feels.

If the gate is open, does that mean the data is correct?

No. The gate clears mechanical checks: is the data fresh, is coverage complete, is the unit consistent. Whether the metric is the right metric, whether the attribution definition fits your business, and whether records matched correctly in the CRM are things the gate cannot know. That layer is still your design decision.