Most ad scaling decisions are driven by:

* Day-one ROAS
* Cost per acquisition
* Front-end revenue
* Pixel-reported conversions

When these numbers look strong, budgets increase.

When they weaken, campaigns pause.

This reflex ignores backend revenue.

CBSplit was built to anchor scaling decisions in lifecycle truth.

Front-end metrics capture:

* Initial purchase value
* Immediate upsell revenue
* Short attribution windows

They do not include:

* Refund-adjusted revenue
* Subscription rebills
* Churn timing
* Chargeback exposure

Scaling based solely on front-end data risks amplifying hidden instability.

Backend revenue reflects:

* Rebill survival
* Cohort-based LTV
* Upsell retention impact
* Refund containment

Campaigns with stable backend revenue are structurally stronger.

Campaigns dependent on fragile front-end spikes are vulnerable.

CBSplit measures durability before expansion.

At low volume, refund ratios may appear manageable.

When scaled:

* Refund counts multiply
* Net revenue shrinks
* Processor scrutiny increases
* Risk thresholds approach

Backend weakness becomes financially significant only at scale.

Scaling without backend evaluation accelerates loss.

In recurring models, profitability depends on:

* First rebill success
* Early churn velocity
* Retention stability
* Retry recovery efficiency

These signals mature after initial acquisition.

Scaling before they stabilize introduces structural bias.

CBSplit aligns scaling speed with lifecycle maturity.

Two campaigns may show identical front-end metrics.

Over time, one may:

* Produce durable subscribers
* Maintain low refund ratios
* Generate stable LTV

The other may:

* Experience early cancellations
* Create refund clusters
* Reduce net margin

Backend revenue reveals traffic quality differences.

Ad dashboards often aggregate:

* Revenue across cohorts
* Refund impact across segments
* Retention across traffic sources

Blended reporting hides weak segments.

CBSplit segments backend performance before scaling decisions are made.

Responsible scaling requires:

* Refund window closure
* Rebill cycle observation
* Cohort-based LTV validation
* Processor-safe performance thresholds

Backend revenue confirms structural stability.

Front-end revenue suggests possibility.