Budget reallocation at the DSP level sounds straightforward in concept: read performance data across platforms, identify where spend is converting efficiently, move money there. The execution has a few layers worth understanding — both for teams evaluating cross-DSP optimization tools and for teams considering whether to build this capability internally.
Here's how Brandpathio's 4-hour optimization cycle works in practice.
Phase 1: Data ingestion across connected platforms
Every 4 hours, the system makes authenticated API calls to each connected DSP to pull current campaign performance data. The specific data pulled varies by platform:
- Google DV360: Via the Display & Video 360 API — insertion order pacing, campaign-level conversion data, audience segment performance, creative rotation data. DV360's reporting API provides access to Floodlight conversion events, which are the most reliable first-party signal if the client has Floodlight tags deployed.
- The Trade Desk: Via the Campaign Management API — campaign budget pacing, ad group level performance, audience segment win rates and impression volumes. TTD's API includes bid landscape data useful for identifying CPM efficiency gaps between platforms.
- StackAdapt: Via the GraphQL API — native campaign performance, audience segment click-through and conversion rates, creative variant performance data. StackAdapt's audience predictive scoring data feeds into the cross-platform creative-audience model.
- Amazon DSP: Via the Campaign Optimization API — performance by supply source, audience segment overlap with Amazon's first-party shopper data, conversion attribution (particularly relevant for clients with Amazon retail presence).
The ingestion step runs asynchronously — calls to each platform happen in parallel rather than sequentially, keeping the data fetch window under 8 minutes for up to 8 connected platforms.
Phase 2: Conversion signal reconciliation
Platform-reported conversion data can't be taken at face value in a multi-DSP setup. Attribution overlap means the same conversion event may have been claimed by multiple platforms. Before any budget decision is made, the conversion signal needs to be reconciled against the canonical source of truth.
That source of truth is whatever the client uses as their primary conversion tracking layer — typically one of: GA4 conversion events (pulled via the Reporting API), CRM closed-won data synced on a rolling 24-hour basis, server-side pixel events received at a dedicated endpoint, or mobile attribution data from AppsFlyer or Adjust.
The reconciliation step joins impression-level data from each DSP to the canonical conversion events using a probabilistic matching model. This is not a perfect deduplication — probabilistic matching at impression level without a deterministic user ID across platforms has inherent uncertainty. The output is a deduplication-adjusted conversion count per creative-audience-platform combination, with confidence intervals that reflect the matching uncertainty.
This adjusted conversion signal is the input to budget allocation decisions. Using raw platform-reported conversions would systematically over-allocate to whichever platform has the most aggressive attribution window.
Phase 3: Budget allocation model
The allocation model takes the deduplication-adjusted performance data and scores each creative-audience-platform combination on conversion-weighted ROAS. It then calculates an optimal budget distribution across platforms that maximizes the expected total conversions given the current total budget envelope.
The model operates within a set of constraints defined during client onboarding:
- Minimum DSP allocation floors: Clients typically define a minimum monthly budget per connected platform to maintain seat activity and algorithmic learning. Budget reallocation won't drop any platform below its configured floor.
- Maximum single-cycle shift limits: Large sudden budget moves can disrupt DSP pacing algorithms and cause temporary underperformance. The default maximum shift per 4-hour cycle is 15% of the platform's current daily allocation, configurable per client.
- Audience exclusion windows: Users who have already converted within the configured attribution window are excluded from active retargeting pools across all platforms — the system writes exclusion list updates back to connected DSPs as part of each cycle.
Phase 4: API write-back
Budget shifts are written back to each DSP via their campaign management APIs. For DV360, this means updating insertion order budget amounts through the Display & Video 360 API. For Trade Desk, it's campaign budget updates through the Campaign Management API. For StackAdapt, budget writes go through the GraphQL mutations endpoint.
Each write-back is logged with a timestamp, the previous budget value, the new budget value, and the signal data that drove the change. This creates a complete audit trail of every budget decision the system made and why — visible in the Brandpathio dashboard and exportable to BigQuery or Snowflake on Enterprise tier.
The write-back step has error handling for API rate limits (each platform has different rate limit tiers), authentication token expiry (OAuth token refresh is handled automatically), and temporary API unavailability. If a write-back fails, the system retries on the next cycle and logs the failure for human review.
What the 4-hour cadence enables
The difference between a 4-hour cycle and a daily or weekly manual process is signal latency. A creative variant that starts converting at 3× the campaign average at 9am on a Tuesday will have budget shifted toward it by 1pm. Under a weekly reporting cycle, you'd see that signal in Monday's report and act on it the following Tuesday — nine days of misallocated budget.
The 4-hour cadence was chosen as the balance point between signal timeliness and DSP pacing stability. Sub-hourly cycles would generate more volatile budget shifts that interfere with DSP algorithmic pacing, producing worse outcomes than the instability they're trying to correct. Enterprise tier clients can opt into 1-hour cycles with explicit pacing stability trade-off acknowledgment.
What it doesn't do
Brandpathio is not a DSP. It doesn't bid on inventory, doesn't participate in RTB auctions, and doesn't touch your creative delivery. Budget changes happen at the campaign and insertion order level — the DSP continues making all impression-level bid decisions within its updated budget envelope. The optimization layer is above the auction, not inside it.
This distinction matters for teams evaluating the platform: adopting cross-DSP budget optimization doesn't change your DSP relationships, your seat agreements, or your creative trafficking workflow. It adds a coordination layer on top of the systems you already use.
How the allocation model handles uncertainty
Performance data collected over a 4-hour window is inherently noisier than data collected over a week. A creative-audience combination that shows a 3× ROAS in a 4-hour window may be experiencing statistical variance rather than a genuine performance shift. If the optimization model treats every intra-day signal fluctuation as actionable, it will make frequent small budget moves that interfere with DSP pacing stability and chase noise rather than signal.
The allocation model addresses this with a confidence-weighted scoring system. Each creative-audience-platform combination is scored not just on its current-cycle ROAS but on the statistical confidence of that estimate given the volume of observed conversions. A combination with 80 conversion events in the current cycle gets full weight in the allocation calculation. A combination with 4 conversion events gets partial weight, with the remainder of its score anchored to its trailing 7-day performance average.
This means the model is slower to act on new combinations (which have low statistical confidence) and faster to act on established combinations (where the signal-to-noise ratio is higher). New creative launches, for example, are protected from immediate budget deprioritization during their ramp period — the system needs to accumulate enough conversion events to have confidence in the performance estimate before making allocation decisions based on it. The ramp period is configurable but defaults to 48 hours or 30 conversion events, whichever comes first.
The floor and ceiling constraints: why they matter
Budget floor constraints per DSP exist for a reason that goes beyond client preference: DSP learning algorithms need consistent exposure to perform. Both DV360 and Trade Desk operate machine learning bid models that update based on observed conversion outcomes. If budget drops to near zero on a platform for several days, the algorithm's conversion model deteriorates — it stops seeing outcomes and loses the ability to optimize bids toward high-converting inventory.
When budget is restored, the algorithm needs a re-learning period of typically 5-10 days before bid optimization returns to prior performance levels. This "cold start" problem means that aggressive budget cuts on an underperforming platform, followed by increases when performance recovers, can produce worse outcomes than a steadier allocation with moderate adjustments. The maximum per-cycle shift limit and the platform floor constraints are designed to keep every connected platform within its functional operating range at all times.
The ceiling constraint works differently. When a platform is performing well and the model wants to concentrate budget there, there's a practical limit to how much incremental budget a DSP can deploy efficiently in a given time window. Programmatic inventory on any given platform has a finite supply at target CPM ranges. Pushing too much budget into a single platform quickly will push the pacing algorithm to reach for lower-quality inventory or higher CPMs to fulfill the budget. The maximum shift ceiling prevents budget concentration from defeating its own purpose.
What the audit trail enables
The logged decision record — every budget shift with its input signals, previous value, new value, and timestamp — serves two functions beyond compliance. First, it makes the optimization logic auditable by your team. When a budget shift appears unexpected, the audit log shows exactly what signal the model saw and what weight it assigned. This is important for building internal trust in automated budget decisions and for identifying cases where the model may be responding to a spurious signal.
Second, it generates a training dataset for model improvement over time. If a budget shift that the model made at high confidence produced poor outcomes over the following 48 hours, that discrepancy is available as a labeled example for model evaluation. Aggregate analysis of decision accuracy over time tells you whether the model's confidence calibration is well-specified — whether high-confidence decisions are actually producing better outcomes than low-confidence decisions.
For teams with data warehouse infrastructure (BigQuery, Snowflake, Redshift), the audit log export creates an operational data source for custom analysis. Some performance teams use this data to build custom reporting on optimization velocity — how frequently budgets are moving, how large the average shift is, whether shift magnitude correlates with performance improvement. This analysis isn't provided as a default dashboard view but is accessible to teams with the SQL capacity to query the audit log export.
A note on what cannot be automated
The 4-hour cycle optimizes within a defined campaign structure. It does not restructure your campaigns, redesign your audience strategy, or address structural problems in your programmatic setup that predate the optimization layer.
If your DV360 campaign has no view-through conversion tags deployed correctly, the system can't pull reliable conversion data from that platform and will default to click-attribution signals — which will produce suboptimal allocation decisions for campaigns where view-through events are important. If your audience segments across platforms are poorly defined or inconsistently labeled, the creative-audience performance model will be working with noisy segment data and its recommendations will be less precise. If your campaign pacing settings in the individual DSPs are set to "accelerated delivery" rather than "even pacing," external budget increases from the reallocation layer may cause overspend spikes before the daily delivery algorithm adjusts.
These are setup quality issues that need to be resolved at the campaign configuration level before the optimization layer can perform well. Brandpathio runs a pre-onboarding audit of each connected platform's campaign structure to identify configuration issues that would undermine optimization accuracy. It's not a guarantee of clean data — platform configurations change, tags break, audience list definitions drift — but it establishes a baseline and identifies the highest-impact issues before the first optimization cycle runs.
