Cross-Channel CVR Overwrite Protection Automation: One Channel's Real Number, Silently Discarded
Two real measurements, one shared field, and whichever assignment runs last wins by accident
Recalibrating a shared model field using real, freshly measured data from more than one independent source is a genuinely sound idea — each source's real number is more trustworthy than an earlier estimate, and both deserve to inform the model. The risk is specific to the exact mechanism used to apply them: if updating the field for one source is written as a plain, unconditional assignment, and updating it for a SECOND source is written as an equally unconditional assignment placed immediately afterward in the same function, the field's final value is entirely determined by which assignment happens to execute last in the source code — a detail with no actual relationship to which source's measurement is more current, more reliable, or more representative of the thing the field is actually meant to describe for that specific case.
How the underlying problem shows up before you fix it
A shared model field, meant to represent a single value, is updated by more than one independent, unconditional assignment in sequence within the same function — with no check for whether an earlier assignment to the identical field already ran.
Two genuinely real, independently measured values (here: a conversion rate reported separately by two different ad platforms) exist for the same underlying quantity, and the code combining them into one shared field picks whichever one happens to be assigned LAST in source order, rather than deliberately choosing or blending between them.
A recalibration or update process that is meant to make a model MORE accurate by incorporating real data can, for a specific measured channel, make it LESS accurate — because that channel's own genuine measurement is silently discarded in favor of a different channel's number that has no particular claim to being more correct for THIS specific case.
A budget, campaign, or forecast genuinely split across two channels uses a model field that, after recalibration, reflects only ONE of those two channels' real performance — understating or overstating the combined picture depending on which channel happened to be measured second in the code's own execution order.
The specific defect is invisible for any case where only ONE of the two measurements is actually available (the single, unconditional assignment for the other is simply skipped) — it manifests only when BOTH real measurements exist for the same recalibration pass, which is exactly the case a shared, blended field is supposed to handle well.
How a shared CVR field stopped losing whichever channel's number arrived first
Centriu Maestro periodically recalibrates a budget's own performance assumptions — its modeled cost-per-click, cost-per-thousand-impressions, and conversion rate — using real results measured from the ad platforms actually running the budget's campaigns, specifically so the model tracks reality rather than staying anchored to an initial estimate. The budget's assumptions keep this data inside a single "mid" scenario object, and that object holds one shared field, `cvr`, used by every calculation depending on conversion rate — regardless of whether the budget in question runs on Google, Meta, or a deliberate mix of both.
Before this fix, the calibration function applied real, measured CVR data with two separate, sequential, and independently unconditional lines: `if (calibration.googleCvrReal != null) newMid.cvr = calibration.googleCvrReal` immediately followed by `if (calibration.metaCvrReal != null) newMid.cvr = calibration.metaCvrReal`. Each condition checks only whether ITS OWN channel's real measurement is available — neither condition has any awareness of the other, and neither checks whether the shared field had already been set by the other line moments earlier in the same function call. For any budget where only one channel had a fresh real measurement available, this worked exactly as intended — one assignment ran, the other's condition was false, and the single real number correctly reached the shared field. For any budget where BOTH Google's and Meta's real CVR were available in the same calibration pass — an entirely ordinary case for a budget genuinely running on both channels — both conditions evaluated true, both assignments executed in the order they appear in the source, and Meta's assignment, running second, silently overwrote whatever Google's assignment had just written. Google's real, independently measured conversion rate was computed, held briefly in the shared field, and then discarded — with no error, no warning, and no trace in the resulting budget beyond a `cvr` value that, in fact, only ever reflected Meta's channel.
The consequence compounds specifically for a MIX-channel budget, the exact case where the shared field's value matters most to get right, since it is meant to represent a blended reality rather than either channel alone. A budget spending, for example, 70% of its total on Google and 30% on Meta would still have its shared conversion-rate assumption set entirely from Meta's smaller-share number, with Google's larger, and more representative, real measurement never factored in at all.
The fix replaces both unconditional assignments with a single, explicit resolution step that runs once real values from either or both channels are known. For a budget deliberately configured as single-channel (`channelMix === 'GOOGLE'` or `'META'`), the resolved value is simply that channel's own real measurement — an intentional design choice needing no blending at all, since only one channel's number is actually relevant to that specific budget. For a genuinely mixed-channel budget, the resolved value is a weighted blend of both channels' real measurements, weighted by each channel's own configured share of total spend (`mixShare.googlePct` and `mixShare.metaPct`) — falling back to an even split only in the unlikely case both configured shares are zero. If only one channel's real measurement happens to be available for a given pass, that single value is used directly, exactly matching the previous, correct behavior for that specific case — the fix changes only what happens when BOTH real measurements exist for the same recalibration.
What is actually built today
Centriu Maestro's budget-calibration engine resolves its shared conversion-rate field explicitly whenever real measurements from more than one ad-channel are available in the same recalibration pass, rather than letting whichever channel's assignment executes last silently win.
A single-channel budget's shared CVR field is set directly from that one channel's own real, measured conversion rate — unchanged from the prior, already-correct behavior for that specific case.
A genuinely mixed-channel budget's shared CVR field is set from a blend of both channels' real measurements, weighted by each channel's own configured share of total spend, so neither channel's genuine, measured performance is discarded in favor of the other's.
A budget with only ONE channel's real measurement available for a given calibration pass continues to use that single value directly — the fix changes behavior only for the specific case where both real measurements exist simultaneously.
The same resolution logic applies identically regardless of source-code ordering — the outcome no longer depends on which of two equally valid, equally unconditional assignments happens to run second.
Google's real number, computed, held briefly, and discarded (illustrative framing of the actual measured finding)
Before the fix, a budget genuinely running 70% of its spend on Google and 30% on Meta, recalibrated with real conversion data available from both platforms in the same pass, would end up with its shared conversion-rate assumption reflecting Meta's real number alone — the platform carrying less than a third of the budget's actual spend — while Google's real, independently measured conversion rate, carrying the majority of the spend, was computed and then silently discarded by the very next line of code. After the fix, the same recalibration blends both channels' real numbers weighted by their actual share of spend, so the shared field reflects a genuine picture of the budget's real, combined performance.
What changes operationally
Centriu Maestro's budget-calibration engine now explicitly resolves its shared conversion-rate assumption whenever real, measured data from more than one ad channel is available in the same pass — using a single channel's own real rate for a single-channel budget, and a spend-weighted blend of both channels' real rates for a genuinely mixed budget — closing a gap where one channel's real, measured performance could be silently discarded by the other channel's number simply executing second in the same function.
When this is not the right fit
This automation governs the internal correctness of Centriu Maestro's own budget-recalibration engine specifically for its shared conversion-rate field — it does not change any other assumption the engine calibrates (cost-per-click, cost-per-thousand-impressions, click-through rate each have their own, independent field with no equivalent overwrite risk found), and it applies specifically to a budget genuinely running on both Google and Meta in the same recalibration pass; a single-channel budget's calibration was already correct before this fix.
Two sequential unconditional assignments vs. one explicit resolution step
Writing two separate, unconditional "if available, assign" lines for two independent data sources feeding the same shared field is the simpler code to write, and works correctly for every case except the one where both sources happen to have data at the same time — exactly the case a genuinely shared, blended field exists to represent well. Replacing both lines with a single explicit resolution step, aware of both possible sources and of the budget's own actual channel configuration, costs a modest increase in complexity and removes the dependency on source-code ordering entirely — the outcome is now a deliberate choice about how to combine two real measurements, not an accident of which assignment happens to run last.
Related systems
Main system: Centriu Maestro.
What it does NOT do
- Does not change how Centriu Maestro measures a channel's real conversion rate in the first place — this fix corrects only how two channels' already-real, already-measured rates are COMBINED into the budget's shared assumption field.
- Does not affect a single-channel budget's calibration, which already used that one channel's own real rate correctly before this fix — the defect was specific to the case where both channels' real measurements existed in the same pass.
- Does not retroactively recalculate any budget's historical assumptions from before this fix shipped — a team wanting an updated, correctly-blended CVR for a specific past budget would need to trigger a fresh recalibration for it.
- Does not change any OTHER assumption the calibration engine recalculates (cost-per-click, cost-per-thousand-impressions, click-through rate) — each of those has its own independent field with no equivalent overwrite pattern found in this investigation.
- Does not overlap with this pillar's separate finding about Centriu Axis's own spontaneous-logout guard — that is covered on its own companion page and is an entirely unrelated system and mechanism.
Security and governance
Centriu Maestro's budget-calibration engine now explicitly resolves its shared conversion-rate assumption when real data from more than one ad channel is available, rather than allowing one channel's real, measured performance to be silently discarded by the other's assignment executing second. Full detail on access control and audit trails lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Did this affect ad spend or bidding directly?
This fix corrects the budget's own internal conversion-rate ASSUMPTION, used in forecasting and calibration calculations — it does not directly control bidding on either ad platform, which each manage their own bidding independently.
Was Google's CVR data ever actually wrong, or just unused?
Google's real, measured conversion rate was computed correctly in every case — the defect was that it could be silently overwritten and discarded by Meta's real measurement being applied immediately afterward to the same shared field, whenever both were available.
Did single-channel budgets have this problem?
No — a budget configured as single-channel (Google-only or Meta-only) only ever had one real measurement to apply, so the prior code's single relevant assignment worked correctly for that case.
How is the blended value calculated now for a mixed-channel budget?
As a weighted average of both channels' real conversion rates, weighted by each channel's own configured share of the budget's total spend — so a channel carrying more of the budget's spend has proportionally more influence on the shared assumption.
What happens if only one channel has real data available in a given pass?
That single value is used directly, exactly as it was before this fix — the change affects only the specific case where both channels' real measurements exist simultaneously.
What does Centriu Maestro cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Maestro blends real channel data without losing any of it
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.