Publisher Control In The Wrapper Wars: How To Keep Auctions Neutral When The Buy Side Owns The Wrapper

The header bidding wrapper has become the control surface of programmatic monetization. It sets the rules of engagement, orchestrates demand, and shapes outcomes that can tilt millions in revenue. In the last few years, wrappers are increasingly owned or operated by the buy side, from large marketplaces to DSP-affiliated bidding frameworks. That ownership brings real convenience, scale, and performance. It also introduces a structural conflict of interest that publishers cannot ignore. This thought piece lays out a practical playbook for preserving auction neutrality when the wrapper is not under your direct control. We focus on web, app, and connected TV, and we keep the recommendations grounded in operational realities. The objective is not ideological purity. It is to protect yield, transparency, and user experience while taking advantage of the reach and unique demand that buy-side wrappers can unlock. The good news is that neutrality is achievable with the right governance, instrumentation, and a few critical technical guardrails. The better news is that many of these controls are already available through open standards and modular, publisher-first technology.

What Exactly Is a Wrapper and Why Does Ownership Matter?

At its simplest, a wrapper is the software layer that standardizes how multiple demand sources participate in your auction. It coordinates requests, enforces timeouts, converts currencies, provides analytics hooks, and applies bidder-specific or impression-specific rules. In web, the wrapper is most often a client-side library such as Prebid.js or a proprietary SDK. In app, it is a mediation SDK or an in-app bidding SDK that controls the auction flow. In CTV, wrapper-like logic increasingly lives server-side in ad decision servers and SSAI workflows that manage pod construction and demand routing. Ownership matters because the wrapper decides the rules. When a buy-side entity owns or operates the wrapper, incentives can diverge from publisher neutrality. Here are examples of control points that can favor specific demand without obvious disclosure:

Adapter ordering and throttling: Subtle preference in call sequence or throttling under load can change who arrives in time.
Timeouts and retries: A 50 ms advantage in deadline or a selective retry policy can swing auction outcomes.
Currency conversion and rounding: Bid conversions and precision can bias close calls.
Floor application and bid adjustments: Module-level defaults may treat some buyers differently.
Data access: First-party data, identity signals, and contextual features can be distributed unevenly.
Visibility and logs: If analytics are partial or proprietary, audit is difficult and accountability fades.

None of this implies malfeasance by default. It simply highlights why publishers need a documented neutrality posture and the means to verify it in production.

The Neutral Auction Principles

Before debating wrappers, align on principles. A neutral publisher auction should be:

Transparent: Rules, modules, and configurations are documented and versioned, with change control.
Deterministic: Under the same inputs and timing constraints, the auction produces the same result.
Non-discriminatory: Buyers are treated equally for timeouts, currency conversion, and access to first-party signals, unless a publisher-defined rule applies.
Measurable: Sufficient log-level data exists to reconstruct the decision and detect bias or regressions.
Privacy-by-design: Data flows and identity modules comply with consent frameworks and regional laws.
Fail-safe: Degradation strategies and fallback paths are documented and tested.

These principles are not abstract. They map to specific controls publishers can implement today across web, app, and CTV.

Web: Controls You Can Implement Today

On the web, header bidding still centers on Prebid.js, Open Bidding, and server-to-server pathways that can be operated by buy-side partners. The following controls preserve neutrality while letting you benefit from buy-side owned scale.

1) Own the Config, Even If You Do Not Own the Code

If you use a buy-side hosted wrapper, insist on publisher-owned configuration and change control. Keep auction rules and modules in a repository you control, with pull-request workflows and release tagging. Require notification and opt-in for any change that affects auction logic, timeouts, or bidder enablement. A simple pattern is to host your Prebid configuration JSON in your domain and reference it at runtime. Even if the wrapper is delivered by a partner CDN, your config remains the source of truth.

// Example: Prebid configuration object hosted under your control
window.pbjs = window.pbjs || {};
pbjs.setConfig({
debug: false,
bidderTimeout: 1200,
userSync: { syncEnabled: true, iframeEnabled: true, filterSettings: { all: { bidders: '*', filter: 'include' } } },
currency: { adServerCurrency: 'USD', granularityMultiplier: 1.0 },
s2sConfig: [{
accountId: 'your_prebid_server_account',
bidders: ['ix', 'rubicon', 'openx', 'triplelift'],
timeout: 1100,
endpoint: 'https://pbs.yourdomain.com/openrtb2/auction',
adapter: 'prebidServer',
analytics: true
}],
auctionOptions: {
enableTIDs: true,
secondaryBidders: [],
suppressStaleRender: true
}
});

Key idea: the partner can operate infrastructure, but the semantics of the auction are explicit, reviewable, and pinned by your team.

2) Normalize Timeouts

Timeout parity is essential. Any per-bidder differences should be publisher-defined and justified by observed network performance, not by relationships. Establish a budget, split client and server timelines, and keep a separate pool for retries that is applied uniformly.

pbjs.setConfig({
bidderTimeout: 1200,
// Optional per-bidder timeouts tied to observed p95 latency, not commercial relationships
bidderTimeouts: {
'rubicon': 1100,
'ix': 1100,
'openx': 1100,
'triplelift': 1100
},
timeoutBuffer: 100 // reserve to account for postMessage and GAM latency
});

Document the rationale and revisit monthly using p95 and p99 timing from analytics adapters.

3) Floors: Publisher Logic, Explicit Data Sources

Floor mechanics can meaningfully change win rates. Use transparent modules and data sources. The Prebid Floors Module lets you set floors based on domain, placement, and device with line-by-line visibility. If a buy-side wrapper offers dynamic floors, require that the underlying model and data refresh cadence are documented, with a break-glass override that reverts to your static table.

pbjs.setConfig({
floors: {
enforcement: { enforceFloors: true, bidAdjustmentForAuctionWinner: true },
defaultFloor: 0.50,
additionalSchemaFields: ['mediaType', 'size'],
data: {
schema: { fields: ['mediaType', 'size', 'adUnitCode'] },
values: {
'banner|300x250|adunit_top': 0.80,
'banner|300x250|adunit_sidebar': 0.60,
'video|640x360|adunit_video': 12.00
},
currency: 'USD',
skipRate: 0 // full enforcement by default
}
}
});

If any bidder supports its own floor negotiation, ensure you have a written rule that the stricter of the two applies, not the looser.

4) Randomize Adapter Sequence or Prove It Is Harmless

Prefer random or parallel adapter invocation. If sequence is fixed for technical reasons, require a bench test showing no statistically significant lift for early bidders once latency is controlled. Keep the test plan on file.

pbjs.setConfig({
bidderSequence: 'random', // 'fixed' only with test evidence
prioritizeDeals: true // deterministic rule you control
});

5) Currency Conversion Must Be Precise and Public

When bids are converted to your ad server currency, set rounding and precision explicitly. Publish the policy to buyers. Currency bias is hard to detect without care.

pbjs.setConfig({
currency: {
adServerCurrency: 'USD',
bidderCurrencyDefault: { '*': 'USD' },
granularityMultiplier: 1.0,
conversionRateFile: 'https://cdn.yourdomain.com/fx/latest.json',
useDefaultRate: true // deterministic fallback
}
});

6) Parity in Signals and Identity

Whether you use identity modules or contextual signals, apply them consistently. Avoid exclusive data feeds to a single buyer through the wrapper. If a partner offers unique modeled audiences, bind them to private marketplace deals where the priority is explicit rather than allowing covert auction preference.

pbjs.setConfig({
ortb2: {
site: { page: 'https://example.com/article/123', domain: 'example.com' },
user: { data: [{ name: 'pub_segments', segment: [{ id: 'sports_fans' }] }] }
},
userSync: {
// Consent-aware syncs through the Consent Management Module
syncEnabled: true
},
consentManagement: {
gpp: { cmpApi: 'iab', timeout: 120, defaultGppData: {} },
gdpr: { cmpApi: 'iab', timeout: 120, allowAuctionWithoutConsent: false },
usp: { cmpApi: 'iab', timeout: 120 }
}
});

7) Keep Independent Analytics

Use at least one analytics adapter or external pipeline you operate. The objective is not to duplicate everything, but to have enough log-level data to detect bias and regressions. At minimum, capture timestamps for request start, bid received, currency conversion, floor applied, and GAM line item called. Store bidder code, deal IDs, and schain. Below is a simple SQL pattern in BigQuery-like syntax for detecting timeout favoritism:

-- Detect asymmetric timeout behavior by bidder
WITH bid_events AS (
SELECT
auction_id,
bidder,
MIN(IF(event = 'request_start', ts, NULL)) AS t_request,
MIN(IF(event = 'bid_received', ts, NULL)) AS t_response,
MIN(IF(event = 'timeout', ts, NULL)) AS t_timeout
FROM `pub.logs.prebid_events`
WHERE _PARTITIONTIME BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP()
GROUP BY auction_id, bidder
),
latency AS (
SELECT
bidder,
APPROX_QUANTILES(TIMESTAMP_DIFF(t_response, t_request, MILLISECOND), 100)[OFFSET(95)] AS p95_latency_ms,
COUNTIF(t_timeout IS NOT NULL) / COUNT(*) AS timeout_rate
FROM bid_events
GROUP BY bidder
)
SELECT *
FROM latency
ORDER BY timeout_rate DESC;

Track the top five outliers over time and correlate with code releases or partner-side changes.

8) Use Ads.txt, Sellers.json, and Schain to Trace Supply Paths

Layer supply path transparency into your audit. Confirm that all buyers appearing in your wrapper and intermediaries in your ad server are declared in ads.txt and sellers.json, and that winning bids carry a valid schain. This is not just compliance. It helps detect routing through preferred exchanges that a wrapper might encourage. References:

IAB Tech Lab ads.txt specification: https://iabtechlab.com/ads-txt
IAB Tech Lab sellers.json: https://iabtechlab.com/sellers-json
OpenRTB SupplyChain Object: https://iabtechlab.com/supplychain
9) Define a Break-Glass Path

Document how to bypass a buy-side wrapper in production if you detect material bias or outage. This can be as simple as a feature flag that shifts traffic to your Prebid.js local build or a reduced set of direct server-to-server connections. Test it quarterly.

In-App: Mediation, In-App Bidding, and Neutrality

Mobile app monetization evolved from waterfall mediation to in-app bidding. Many of the most popular SDKs are owned by buy-side aligned platforms. The mechanics are different from web, but the neutrality controls are similar.

1) Explicit Auction Control in SDK Mediation

When using mediation, keep the automation honest. Pin eCPM floors and instance capping rules to your data, not to partner auto-optimization that you cannot audit. If in-app bidding is available, prefer it over waterfall waterfalls, but keep the levers:
- Unified timeouts: Set the same request time budget across adapters unless proven otherwise by latency tests.
- Network ordering: If the SDK does not allow randomized parallel calls, design A/B tests that rotate the ordering and confirm no consistent bias.
- Price floors: Keep a publisher-side floor table that overrides network suggestions when they conflict with your goals.
2) Prebid Mobile For Config Transparency

If neutrality is a priority, consider Prebid Mobile. It lets you externalize much of the logic into Prebid Server where you can enforce parity and gather logs.
```
// Swift example snippet for Prebid Mobile configuration
let request = PBMAdRequest(configId: "your-config-id", adFormat: .banner)
request.adSizes = [NSValueFrom(CGSize(width: 320, height: 50))]
request.timeout = 1.2 // seconds
// First party data and context
let targeting = Prebid.shared
targeting.storeURL = "https://exampleapp.com"
targeting.addUserData(key: "subscriber_tier", value: "premium")
// Load and add targeting to your GAM request
request.fetchDemand(adObject: gamRequest) { result in
// Inspect demand result and continue with GAM load
}
```
Bind this to your Prebid Server account and keep the server configuration in your own repo. Even if a buy-side partner hosts infrastructure, publish the server-side logic.

3) SKAdNetwork and Privacy Parity

For iOS, ensure SKAdNetwork postbacks and source app IDs are handled consistently across buyers. For Android, keep parity in Google Play Install Referrer usage and attribution windows. If a network has privileged attribution visibility, move the advantage into a private deal class rather than global auction priority. Reference:
IAB Tech Lab Global Privacy Platform: https://iabtechlab.com/gpp
4) Data Access and Reporting Rights

In app, many SDKs throttle access to log-level data. Negotiate explicit rights to event-level data needed for neutrality audits, even if it is delayed. At minimum, secure impression-level data for win bias and timeout analysis by network, placement, and country.

CTV: SSAI, Pods, and Marketplace Neutrality

CTV wrappers often live inside ad decisioning workflows, pod construction logic, or server-to-server marketplaces operated by buy-side aligned partners. The neutrality stakes are high because CTV inventory is scarce and CPMs are large.

1) Separate Pod Policy From Demand Routing

Pod policies like competitor separation, ad length distribution, and slot-by-slot brand suitability should be your rules. Demand routing is the partner’s job, not the arbiter of policy. Put policies in explicit configuration with version control and require your partner to attest that the router treats all buyers equally under those policies.
```
{
"pod_policy_version": "1.3.2",
"slots": [
{ "position": 1, "min_duration": 15, "max_duration": 30, "allow_competitor_back_to_back": false },
{ "position": 2, "min_duration": 15, "max_duration": 30, "allow_competitor_back_to_back": false },
{ "position": 3, "min_duration": 15, "max_duration": 30, "allow_competitor_back_to_back": true }
],
"brand_categories_blocklist": ["IAB25-1", "IAB25-2"],
"frequency_caps": { "advertiser": 1, "campaign": 2 }
}
```
2) Enforce Deal Priority as a Publisher Rule

CTV often runs on private marketplace and programmatic guaranteed deals. Treat deal priority as a clear, publisher-owned rule that supersedes marketplace preferences. If the partner offers curated deals, keep them in a clearly labeled priority tier, never co-mingled with open auction without your explicit mapping in the ad server.

3) SSAI Integrity

Use VAST and VMAP macros to propagate schain, content metadata, and regulatory flags consistently to all buyers. Enable ads.cert or similar authenticated connections where available to prevent spoofing and to establish a consistent identity handshake. References:
IAB Tech Lab ads.cert: https://iabtechlab.com/ads-cert
VAST and VMAP specifications: https://iabtechlab.com/standards/vast
4) Latency Budgets and Retry Parity

Server-to-server CTV marketplaces introduce multiple network hops. Define per-hop budgets that apply to every buyer. If a partner retries failed buyers, ensure retries are uniform or disabled. Capture respond-by timestamps in server logs to detect biased grace periods.

5) QA With Synthetic Pods

Create a test rig that requests a pod with synthetic demand where all buyers submit identical bids and latencies. If the outcome is not uniform over many runs, the router is not neutral. Run the rig in staging and in limited production traffic during low-volume windows.

Governance: The Non-Technical Work That Makes the Technical Work Stick

Technology enforces rules. Governance makes the rules real. The most common failure mode in neutrality is not bad actors. It is weak process that lets quiet defaults creep back.

1) A Lightweight Auction Integrity Charter

Publish a short, public charter that states your neutrality principles and the control points you reserve. This sets expectations with partners and your internal teams.
```
# auction-integrity-charter.yml
version: 1.0
owner: Monetization & Ad Ops
principles:
```
transparency
determinism
non_discrimination
privacy_by_design

measurability controls: config_ownership: publisher change_control: pull_request + approval timeout_policy: parity_with_latency_justification floors_policy: publisher_defined_with_partner_input analytics: independent_log_level_pipeline break_glass: feature_flag + fallbacks disclosure: buyers_get_equal_access_to_signals: true preferential_routing_prohibited: true audit: cadence: monthly reviewer: RevOps + Data Science


### 2) Change Control and Versioning
Use Git for wrapper configurations, floors tables, and ad server mapping. Tag releases and include a changelog that highlights any change that affects auction outcomes. Make it a policy that no partner can push a change to your production wrapper config without a PR and an approval.
### 3) A/B Framework For Wrapper Changes
Run any material change behind an A/B flag at 5 to 10 percent traffic for at least one business cycle. Measure lift by inventory segment and buyer cluster, not just total revenue. Watch for shifts in share of voice that cannot be attributed to demand changes.
### 4) Data Retention and Access
Retain at least 90 days of log-level auction data in a cloud dataset you control. This horizon lets you compare pre and post change periods and seasonal effects. If the partner owns the wrapper, insist on periodic exports in a documented schema.
### 5) Commercial Terms That Align Incentives
Bake neutrality into the contract. Ask for:
<ul>
<li><strong>Config ownership</strong>: You own the config, partner may host the code.</li>
<li><strong>Change notice</strong>: Minimum 7 days before rollout of any auction logic change.</li>
<li><strong>Audit rights</strong>: Quarterly audit by a mutually agreed independent auditor.</li>
<li><strong>Log-level access</strong>: Event and auction logs with agreed SLA and schema.</li>
<li><strong>Termination assistance</strong>: 60 to 90 day transition support and data continuity.</li>
</ul>
These terms do not accuse anyone of bias. They simply make neutrality operable.
## Measuring Neutrality: A Practical Scorecard
Construct a simple scorecard to review quarterly with your partner and internal stakeholders. For each control point, define green, yellow, red criteria.
<ul>
<li><strong>Timeout parity</strong>: Green if p95 latency-adjusted timeout rates vary by less than 3 percent across bidders.</li>
<li><strong>Adapter sequence</strong>: Green if random or test-proven harmless ordering.</li>
<li><strong>Floors enforcement</strong>: Green if 98 percent of bids show expected floor application.</li>
<li><strong>Currency consistency</strong>: Green if conversion discrepancies under 0.1 percent in price buckets.</li>
<li><strong>Signal parity</strong>: Green if all buyers receive the same context and identity flags given consent.</li>
<li><strong>Log health</strong>: Green if 99 percent of auctions are reconstructible from logs.</li>
</ul>
Automate as much of this as possible and put it on a dashboard that the business uses, not just engineering.
## The Role of Red Volcano: Independent Visibility at Scale
Neutrality does not live only in code. It lives in ecosystem awareness. That is where Red Volcano can strengthen your position with publisher intelligence that is independent of any buy-side agenda.
Here is how to leverage research tooling to keep auctions honest and performant:
<ul>
<li><strong>Wrapper discovery and version tracking</strong>: Detect which wrappers and versions are live across your portfolio and your peers. Watch for sudden shifts in partner code or adapter lists that correlate with revenue swings.</li>
<li><strong>Technology stack context</strong>: Map identity modules, analytics adapters, CMPs, and server endpoints. Neutrality often breaks at the seams between modules.</li>
<li><strong>Ads.txt and sellers.json monitoring</strong>: Validate that all declared intermediaries match observed supply paths. Alert on new reseller entries that appear only when a particular wrapper is live.</li>
<li><strong>SDK intelligence for app</strong>: Track mediation and bidding SDK updates that can change auction rules. Align version rollouts with your A/B plan.</li>
<li><strong>CTV data platform</strong>: Identify SSAI vendors, ad decision servers, and pod policies in use. Benchmark fill rates and pod integrity against the market.</li>
<li><strong>Sales outreach signals</strong>: For publishers who operate networks or resell, use the same signals to approach partners with evidence and concrete neutrality safeguards as a value proposition.</li>
</ul>
Independent market context helps you distinguish between a real demand shift and a wrapper-side change. That distinction is the heart of smart action.
## Comparing Wrapper Options: A Publisher-Centric View
A short comparative table helps ground the trade-offs. Your mileage will vary, but the axes to consider are consistent.
| Wrapper Type | Typical Owner | Pros for Publisher | Risks to Neutrality | Data Access |
|---|---|---|---|---|
| Prebid.js client-side | Publisher or neutral ops | Maximum config control, transparent modules, rich analytics | Page latency, complex upkeep without discipline | Full if you instrument |
| Prebid Server hosted by partner | Neutral or partner-hosted | S2S scale and performance, centralized config | Opacity if partner controls adapters and logs | Strong if contractually secured |
| Buy-side proprietary web wrapper | DSP or marketplace | Unique demand, integration convenience | Ordering, timeouts, floors can drift toward owner | Varies, often aggregated |
| App mediation SDK with bidding | Buy-side aligned | Huge reach, easy rollout | Auto-optimization opaque, limited event logs | Limited, needs negotiation |
| CTV marketplace with SSAI | Marketplace or DSP | Pod fill, premium demand | Router bias, deal co-mingling | Often summary-level unless negotiated |
The best choice is often a hybrid. Use buy-side wrappers to unlock demand where they excel, and keep a neutral nucleus under your control for policy and measurement.
## A Minimal Neutrality Toolkit
If you do nothing else, assemble this minimal kit:
<ul>
<li><strong>Publisher-owned config</strong>: Your repo, your change control, your floors.</li>
<li><strong>Timeout parity</strong>: One policy, measured and enforced.</li>
<li><strong>Independent logs</strong>: A basic pipeline with timestamps, bidder codes, and outcomes.</li>
<li><strong>Ads.txt, sellers.json, schain rigor</strong>: Supply path transparency by design.</li>
<li><strong>A/B safety net</strong>: Feature flags and rollout discipline.</li>
<li><strong>Commercial guardrails</strong>: Audit rights, data rights, and termination support.</li>
</ul>
With these in place, you can pragmatically adopt buy-side wrappers without surrendering auction integrity.
## Common Anti-Patterns To Avoid
Publishers often fall into patterns that erode neutrality without realizing it. Steer clear of these:
<ul>
<li><strong>Default trust without data</strong>: Accepting a new wrapper default because it worked for someone else without testing it in your stack.</li>
<li><strong>Mixed priority classes</strong>: Letting partner-curated deals sit at the same priority as your direct PG without explicit mapping.</li>
<li><strong>Silent floors drift</strong>: Allowing dynamic floors to override your table without change logs or audit trails.</li>
<li><strong>Opaque currency files</strong>: Using partner FX endpoints you cannot pin or reproduce.</li>
<li><strong>Log purges</strong>: Rotating away log-level data before you have a complete A/B cycle review.</li>
</ul>
## Privacy, Consent, and the Neutral Auction
Neutrality must respect the law. Consent-driven data flows change who sees what, and that can look like bias if you do not model it. Make sure your neutrality analyses are segmented by consent state and region. The IAB Tech Lab Global Privacy Platform, TCF, and US Privacy frameworks provide the signals wrappers should propagate consistently. If a buy-side wrapper applies different logic for consent, document it and enforce parity.
References:

IAB Europe TCF documentation: https://iabeurope.eu/tcf
IAB Tech Lab Global Privacy Platform: https://iabtechlab.com/gpp
The Path Ahead: Privacy Sandbox, PA APIs, and Server-Centricity

Chrome’s Privacy Sandbox and the growth of Protected Audience style on-device auctions will push more logic into browsers and servers. Wrappers will become orchestration layers that negotiate auctions across client and server boundaries. This shift increases the importance of:
- Reproducible configs: More moving parts means more drift risk without version control.
- Server logs: Client-level visibility will shrink; server logs become the ground truth.
- Latency budgets: Multiple hops require hop-by-hop budgets to keep user experience intact.
Monitor the specifications and insist on documentation from partners about how their Sandbox integrations preserve parity for all buyers sharing the same rules.

Conclusion: Neutrality Is a Choice, Not a Hope

When the buy side owns the wrapper, neutrality does not disappear. It simply moves from code you own to governance, contracts, and data you control. Publishers can and should use buy-side wrappers for their strengths. The key is to set the rules in writing, instrument them in code, and verify them with logs. This is the strategic posture that makes you resilient. It protects your yield, preserves buyer trust, and gives your teams confidence to experiment without losing control. In the wrapper wars, neutrality is not a slogan. It is a disciplined operating model that any publisher can adopt with the right toolkit and resolve.

Further Reading and References

The following resources are useful for grounding the controls discussed above:
- Prebid.org documentation: Modules for floors, currency, consent, and analytics. https://docs.prebid.org
- IAB Tech Lab ads.txt and sellers.json: Supply path transparency specifications. https://iabtechlab.com/ads-txt and https://iabtechlab.com/sellers-json
- OpenRTB SupplyChain Object: How to transmit schain in bid requests. https://iabtechlab.com/supplychain
- IAB Tech Lab Global Privacy Platform: Cross-regional consent signaling. https://iabtechlab.com/gpp
- VAST and VMAP: CTV ad delivery standards. https://iabtechlab.com/standards/vast
- ads.cert: Authenticated connections for ad tech. https://iabtechlab.com/ads-cert
These are not endorsements, but they represent the open, standard building blocks of a publisher-first neutrality strategy.

Publisher Control In The Wrapper Wars: How To Keep Auctions Neutral When The Buy Side Owns The Wrapper

What Exactly Is a Wrapper and Why Does Ownership Matter?

The Neutral Auction Principles

Web: Controls You Can Implement Today

1) Own the Config, Even If You Do Not Own the Code

2) Normalize Timeouts

3) Floors: Publisher Logic, Explicit Data Sources

4) Randomize Adapter Sequence or Prove It Is Harmless

5) Currency Conversion Must Be Precise and Public

6) Parity in Signals and Identity

7) Keep Independent Analytics

8) Use Ads.txt, Sellers.json, and Schain to Trace Supply Paths

9) Define a Break-Glass Path

In-App: Mediation, In-App Bidding, and Neutrality

1) Explicit Auction Control in SDK Mediation

2) Prebid Mobile For Config Transparency

3) SKAdNetwork and Privacy Parity

4) Data Access and Reporting Rights

CTV: SSAI, Pods, and Marketplace Neutrality

1) Separate Pod Policy From Demand Routing

2) Enforce Deal Priority as a Publisher Rule

3) SSAI Integrity

4) Latency Budgets and Retry Parity

5) QA With Synthetic Pods

Governance: The Non-Technical Work That Makes the Technical Work Stick

1) A Lightweight Auction Integrity Charter

The Path Ahead: Privacy Sandbox, PA APIs, and Server-Centricity

Conclusion: Neutrality Is a Choice, Not a Hope

Further Reading and References