Introduction
Video monetization is now truly omnichannel. Audiences stream on the big screen, scroll on mobile, and browse on desktop. Publishers chase that demand across CTV, web, and in-app, while buyers seek quality, consistency, and clarity about where their money goes and how their ads are delivered. That creates a strategic challenge for the supply side. Each channel evolved with different delivery stacks, different auction models, and very different operational norms. CTV leaned into server-side ad insertion with podding and heavy direct deals. Web built client-side competition through header bidding, then shifted a lot of volume to server-side wrappers. In-app kept SDK networks and mediation in the loop, then layered in server-to-server exchanges and parallel auctions. A single video auction is the publisher answer. It is an architecture and operating model that brings demand from CTV, web, and in-app into one coherent decisioning layer, with transparent provenance, consistent policy, and measurable outcomes. This thought piece lays out the blueprint. You will see how to unify decisioning without obscuring paths, how to preserve channel-specific strengths, and how to create a transparency-first governance model that buyers and auditors can trust. Along the way we will highlight practical code patterns, schema design choices, and standards that matter, including OpenRTB, VAST, OMID, ads.txt and app-ads.txt, sellers.json, schain, and the Global Privacy Platform. Red Volcano focuses on intelligence for the supply side. The perspective here is grounded in publisher and SSP realities, with an emphasis on reusable data assets, privacy-by-design, and resource discipline.
What We Mean by a Single Video Auction
A single video auction is not a single server or a single tag. It is a cross-channel decisioning layer, with shared policies and data, that determines the winning video ad for a placement regardless of where the ad will render. In practice this means:
- One decision service: An auction gateway that normalizes bid requests from CTV SSAI, web players, and in-app SDK or S2S calls, then runs a fair competition with consistent business rules.
- Shared controls: Floors, brand safety, competitive separation, podding rules, and buyer eligibility applied centrally, with channel-aware exceptions where necessary.
- Unified transparency Every winning path discloses supply chain identity, authorized sellers, and the original media context, with logs that can be reconciled across partners.
- Channel-appropriate rendering: SSAI for CTV, VAST delivery for web or app, OMID measurement when supported, and accurate event beacons back to measurement vendors.
The goal is not to erase channel differences. The goal is to harmonize auction pressure, policy, and reporting, so publishers can allocate demand rationally without losing the transparency signals that buyers, compliance teams, and revenue operations depend on.
Why Consolidate: Business Outcomes That Matter
A single video auction is not just an architectural preference. It should move the needle on revenue, cost, and buyer trust.
- Yield and revenue predictability: Unified floors, fair competition, and pod-aware auctioning increase fill and eCPM, while reducing volatile swings created by fragmented rules and unsynchronized timeouts.
- Fewer operational dead ends: Managing dozens of per-channel waterfalls, hard-coded SDK priorities, and custom pod rules is slow and expensive. Central controls and shared taxonomies reduce toil.
- Buyer trust and budget unlock: Clear supply chain identity, accurate ads.txt and app-ads.txt alignment, consistent sellers.json and schain disclosures, and measurable log-level truth are non-negotiable for large buyers.
- Privacy alignment at scale: Consent, kids flags, regional regulations, and sensitive data handling converge in one enforcement layer rather than three disconnected stacks.
- Faster testing: One experiment framework controls experiments across channels, so you can iterate on floors, creatives, and pod rules quickly without channel-by-channel duplication.
Transparency Principles That Must Survive Unification
Several transparency signals are table stakes for modern programmatic video. A single auction should strengthen, not dilute, these foundations.
- ads.txt and app-ads.txt authorization: Every exchange seat transacting your inventory must appear as authorized in your public files. This is how buyers validate legitimate paths. See IAB Tech Lab documentation for ads.txt and app-ads.txt.
- sellers.json: Your direct relationships and intermediaries should publish accurate sellers.json so buyers can identify sellers of record and their roles. See sellers.json.
- SupplyChain Object (schain): Pass a complete, correct schain that reflects every hop between you and the buyer, with node order, seats, and domains. See SupplyChain Object.
- VAST and VMAP conformance: Use VAST 4.x for video delivery and verification vendor integrations, and VMAP where podding is defined by the publisher. See VAST.
- Open Measurement: Implement OM SDK where supported for viewability and verification. For web and in-app, see Open Measurement.
- Privacy frameworks: Enforce consent signals and region-specific rules via IAB GPP for multi-regional support, and TCF where applicable. See GPP and TCF.
These are not nice-to-haves. They are the backbone of buyer decisioning, third-party verification, and audits. A unified auction should log, expose, and test these signals consistently across channels.
Architecture Patterns That Work
There is no one vendor stack that solves this end to end. The pattern to aim for is modular and standards-driven.
The Control Plane vs The Data Plane
Think about two planes of responsibility.
- Control plane: Policies, taxonomy, pricing, eligibility rules, floors, brand safety, competitive separation, podding profiles, and experiment configurations. Centralized, versioned, and auditable.
- Data plane: Real-time auction execution, request normalization, channel adapters, event beacons, log streaming, and API integration to SSAI, players, SDKs, and exchanges.
This separation lets you change floors or eligibility without redeploying your adapters or SSAI integrations.
Channel Adapters
Each channel needs a first-mile adapter that collects signals, enforces minimal latency budgets, and translates to your internal request schema.
- Web: Player integration via client-side header bidding plus a server-side wrapper is common. Client-side helps with direct integration of OMID and player signals. The server-side wrapper lifts scale and reduces page overhead.
- In-app: SDK mediation is often required by the app runtime, but you can route parallel S2S demand through your auction gateway. Keep SDK calls lean and use deferred decisioning where the SDK fetches a token or VAST URL from your gateway.
- CTV: SSAI controls stitching and often pod policy. Integrate your gateway so the SSAI service requests a pod decision set from your auction layer, then stitches based on returned pod instructions.
Normalized Request Schema
Whether you use OpenRTB internally or map to an internal schema, normalize consistently. Key elements to harmonize:
- Context: site vs app, content metadata, channel tags (web, in-app, CTV), live vs VOD, genre, rating, content length.
- User and device: Device type, platform, IP handling, privacy flags, consent strings, children’s privacy flags, coarse geolocation where allowed.
- Impression: Placement type, player size, autoplay policy, skippability, max duration, pod position or desired pod structure, creative requirements, mime types.
- Transparency: schain, seller account, domain or bundle, inventory identifiers, page or app store URL, ads.txt alignment status.
- Controls: Floors, blocklists, allowlists, competitive separation categories, creative deduplication keys, experiment ids.
Decision Service and Auction Logic
Your decision service performs three jobs:
- Normalize and enrich: Validate, map, and enrich incoming requests with taxonomy, brand safety signals, and historical floor guidance.
- Distribute and collect: Fan out to exchanges, direct deals, programmatic guaranteed endpoints, and network waterfalls as needed. Use channel-aware timeouts and response contracts.
- Score and allocate: Run a first-price or hybrid algorithm with configurable fees, currency normalization, fraud and invalid traffic screening, and pod allocation rules.
For video pods, you will often run a multi-winner allocation. A single auction can score candidates, then fill a pod with revenue and policy constraints satisfied in order.
A Pod-First View: Competitive Separation and User Experience
Podding is central to CTV, and increasingly relevant for long-form web and in-app video. Your unified auction should treat pods as first-class, not as multiple independent slots. Key considerations:
- Competitive separation: Avoid placing competing brands or categories in the same pod. Maintain separation windows by brand or NAICS category using IAB content and advertiser taxonomies.
- Frequency smoothing: Cap pod-level repetition and allocate diversity across the pod.
- Mid-roll logic: Align pod lengths and ad durations to content length and viewer drop-off profiles. Shorter mid-roll pods often improve retention.
- Direct vs programmatic commitments: Reserve first positions or ACR-driven guarantees for premium deals, then backfill with programmatic candidates competitively.
When unified correctly, your CTV pod rules can also guide web long-form and in-app long-form pods, creating a consistent viewer experience, and consistent buyer expectations.
Floors, Fees, and Fairness
Floor management is one of the most sensitive levers you have. In a single auction, floors must be consistent and explainable.
- Unified pricing policies: Use channel-aware base floors, then layer dynamic adjustments based on win rates, fill, and historical bid density.
- Fee normalization: When comparing bids from different intermediaries, normalize for expected fees to avoid artificial advantages that harm both buyers and your revenue.
- Currency handling: Normalize currency consistently, ideally at the edge before scoring.
- Transparency logs: Persist final paid price, gross to net adjustments, and associated fee assumptions per bid path.
Measurement and Verification
Measurement gets tricky across channels, especially with SSAI. Plan for these realities.
- OMID and verification: Use OM SDK where available for viewability and fraud checks. For CTV SSAI, support server-side beacons that forward client-side events when possible, and maintain partner-specific macros in VAST tracking.
- IVT filtering: Use trusted detection vendors and reconcile filters in your revenue analytics. Apply the same IVT policy across channels.
- Log-level parity: Emit comparable auction and delivery logs across channels, with consistent keys so buyers can reconcile post-campaign.
Standards worth reviewing: VAST 4.x for server-side events and error handling, OMID for measurement portability, and the IAB Tech Lab SSAI guidance for tracking and beacon proxying. See VAST and OMID references at IAB Tech Lab linked earlier.
Privacy-by-Design Across Channels
Privacy is not a bolt-on. Unification lets you enforce privacy and compliance consistently.
- GPP and TCF signals: Accept and forward region-aware consent signals consistently. Do not inject user identifiers if consent is missing or disallowed by jurisdiction. See IAB GPP.
- Children’s privacy: Respect contextual and explicit flags for children’s content. Remove personalized signals and restrict buyer eligibility when required.
- Data minimization: Only pass the signals that are necessary for bidding, and prioritize contextual and content signals over user-level identifiers when possible.
- Auditability: Store policy decisions and privacy checks with traceable IDs for audit and incident response.
Practical Build Options
There are three common build patterns, often combined based on your current stack.
1) Server-Side Wrapper First
You centralize server-side header bidding and extend it to in-app and CTV.
- Pros: Central control, fewer client SDK updates, consistent auction pressure.
- Cons: Needs careful player signal capture, especially for OMID and viewability on web and app.
- Good for: Publishers with strong Prebid Server or equivalent wrapper expertise and existing exchange integrations.
2) SSAI-Led with Gateway
Your SSAI vendor becomes the first-mile for CTV, and you insert a decision gateway that also handles web and app.
- Pros: CTV podding and ad stitching remain robust, you centralize pricing and buyer controls.
- Cons: Requires tight integration agreements with SSAI provider and alignment on event tracking and logs.
- Good for: CTV-heavy publishers who want consistent policy across channels without ripping out SSAI.
3) SDK Mediation with S2S Extension
You keep SDK mediation for in-app but route programmatic competition through a server gateway that also handles web and CTV.
- Pros: Minimal app code churn, strong in-app monetization continuity.
- Cons: Mediation rules can conflict with central floors unless you enforce mediation neutral modes.
- Good for: Mobile-first publishers modernizing their in-app auctions while planning for CTV expansion.
A Minimal Internal Schema That Works
Even if you use OpenRTB externally, many teams prefer an internal schema that is purpose-built for video and pods. Here is a simplified JSON schema you can adapt. It demonstrates how to carry context, privacy, transparency, and pod instructions.
{
"request_id": "c0a8017e-4f21-4c5f-b7a4-8fa64f26a3ee",
"timestamp_ms": 1734321000000,
"channel": "ctv | web | inapp",
"context": {
"site": {
"domain": "example.com",
"page": "https://example.com/show/episode-3"
},
"app": {
"bundle": "com.example.app",
"store_url": "https://apps.apple.com/app/id1234567890"
},
"content": {
"title": "My Show - Episode 3",
"genre": ["Reality"],
"length_sec": 1320,
"livestream": false,
"rating": "TV-PG"
}
},
"device": {
"type": "tv | phone | tablet | desktop",
"ua": "Mozilla/5.0 ...",
"ifa": "00000000-0000-0000-0000-000000000000",
"lmt": 1,
"ip": "198.51.100.10",
"geo_coarse": "US-CA"
},
"privacy": {
"gpp": "DBABMA~CPXxRfAPXxRfAAf...",
"gpp_sections": [7, 8],
"tcf_consent": "CPXxRfAPXxRfAAf...",
"coppa": 0,
"california_limit_use": 0
},
"transparency": {
"publisher_id": "pub-12345",
"seller_account": "seller-67890",
"schain": {
"ver": "1.0",
"complete": 1,
"nodes": [
{ "asi": "exchangeA.com", "sid": "1234", "hp": 1, "rid": "req-1", "name": "Exchange A" }
]
},
"ads_txt_status": "authorized"
},
"impressions": [
{
"imp_id": "p1-1",
"placement": {
"type": "instream",
"player_size": "1920x1080",
"autoplay": "muted",
"skippable": true
},
"video": {
"mimes": ["video/mp4", "video/webm"],
"maxduration": 30,
"minduration": 5,
"protocols": [2, 3, 5, 6],
"api": [7],
"linearity": 1
},
"pod": {
"pod_id": "pod-1",
"position": 1,
"pod_max_ads": 3,
"pod_max_dur_sec": 90
},
"controls": {
"floor": 9.50,
"blocked_categories": ["IAB7-5"],
"brand_separation": ["Automotive"]
}
}
],
"experiments": {
"floor_strategy": "dyn-v3",
"timeout_ms": { "ctv": 1200, "web": 800, "inapp": 900 }
}
}
This model ensures your adapters can speak a common language. Your external OpenRTB translators map to and from this schema, and your auction logic does not have to guess about channel differences.
OpenRTB Request Patterns You Will Use
The external interface to exchanges will likely be OpenRTB 2.5 or newer with standard video fields, content object, privacy, and schain. Here is a trimmed example for a web instream request.
{
"id": "req-987",
"source": {
"tid": "c67fb0e5-3421-41a6-8f1a-6b0e3040b812",
"ext": {
"schain": {
"ver": "1.0",
"complete": 1,
"nodes": [
{ "asi": "pub.com", "sid": "pub-123", "hp": 1, "rid": "req-987", "name": "Publisher Direct" },
{ "asi": "sspA.com", "sid": "seat-999", "hp": 0 }
]
}
}
},
"site": {
"domain": "example.com",
"page": "https://example.com/video/123",
"publisher": { "id": "pub-123", "name": "Example Media" },
"content": {
"title": "Episode 3",
"genre": "Reality",
"len": 1320,
"livestream": 0,
"language": "en"
}
},
"device": {
"ua": "Mozilla/5.0 ...",
"ip": "198.51.100.10",
"devicetype": 2
},
"user": {
"id": "anon-abc",
"ext": {
"consent": "CPXxRfAPXxRfAAf..."
}
},
"regs": {
"coppa": 0,
"ext": {
"gpp": "DBABMA~CPXxRfAPXxRfAAf...",
"gpp_sid": [7, 8]
}
},
"imp": [
{
"id": "1",
"video": {
"mimes": ["video/mp4"],
"minduration": 5,
"maxduration": 30,
"protocols": [2, 3, 5, 6],
"w": 1920,
"h": 1080,
"startdelay": 0,
"linearity": 1,
"api": [7]
},
"bidfloor": 9.5,
"bidfloorcur": "USD",
"secure": 1
}
],
"tmax": 800,
"cur": ["USD"]
}
And one for a CTV context using app semantics with a TV device type.
{
"id": "req-ctv-42",
"app": {
"bundle": "tv.example.ctvapp",
"name": "Example CTV",
"publisher": { "id": "pub-123", "name": "Example Media" },
"storeurl": "https://www.example.com/ctvapp"
},
"device": {
"ip": "198.51.100.20",
"ua": "Mozilla/5.0 ...",
"ifa": "00000000-0000-0000-0000-000000000000",
"devicetype": 3
},
"source": {
"ext": {
"schain": {
"ver": "1.0",
"complete": 1,
"nodes": [
{ "asi": "ssai.example", "sid": "ssai-01", "hp": 1 },
{ "asi": "sspB.com", "sid": "seat-22", "hp": 0 }
]
}
}
},
"user": {
"id": "anon-ctv-xyz",
"ext": { "consent": "" }
},
"regs": {
"coppa": 0,
"ext": { "gpp": "DBABMA~", "gpp_sid": [7] }
},
"imp": [
{
"id": "pod-1-slot-1",
"video": {
"mimes": ["video/mp4"],
"minduration": 5,
"maxduration": 30,
"protocols": [2, 3, 5, 6],
"w": 1920, "h": 1080,
"linearity": 1
},
"bidfloor": 12.00,
"secure": 1
}
],
"tmax": 1200
}
These show the essentials: site or app, content, privacy, schain, and video parameters. For pods, you either send multiple related impressions or use exchange-specific extensions that let you request a pod package and allocate positions later. Keep those extensions documented, documented means they must be versioned and discoverable for partners and auditors.
Orchestrating Pods: A Greedy But Transparent Allocator
For many teams, a simple greedy allocator for pods is a solid starting point. It is easy to explain to buyers and to your revenue operations team.
# Pseudocode for a transparent pod allocator
def allocate_pod(candidates, pod_size, max_duration, rules):
"""
candidates: list of bids with attributes
- price (net normalized)
- duration
- brand
- category
- creative_id
- deal_id
- source_path (schain)
rules:
- brand_separation set
- category_separation set
- repeat_creative: bool
- max_ads
- max_duration
- priority_for_deals: bool
"""
# 1) Sort by priority: deals first if enabled, then price
def sort_key(b):
return (0 if (rules.priority_for_deals and b.deal_id) else 1, -b.price)
sorted_bids = sorted(candidates, key=sort_key)
pod = []
used_brands = set()
used_categories = set()
used_creatives = set()
total_duration = 0
for b in sorted_bids:
if len(pod) >= rules.max_ads:
break
if total_duration + b.duration > rules.max_duration:
continue
if b.brand in used_brands and b.brand in rules.brand_separation:
continue
if b.category in used_categories and b.category in rules.category_separation:
continue
if not rules.repeat_creative and b.creative_id in used_creatives:
continue
pod.append(b)
used_brands.add(b.brand)
used_categories.add(b.category)
used_creatives.add(b.creative_id)
total_duration += b.duration
# Return pod and reasons for rejections for transparency logs
return pod
Add transparency logging that records why a bid was skipped, including duration overflow, separation conflicts, or creative deduplication. These reasons feed your buyer-facing reporting and your own revenue optimization analysis.
Latency Budgets and Failover
Video is sensitive to latency, especially in SSAI workflows.
- Set channel-aware timeouts: CTV can afford a bit more decision time than web instream because of the buffer window, but keep budgets tight.
- Fail soft: When decision time is exceeded, return a safe backfill path with clear logs. Do not silently drop demand, and do not obscure which paths were time-limited.
- Adaptive fan-out: Reduce partner calls dynamically when past response times exceed thresholds. Learn partner reliability and adjust concurrency.
Governance, Logging, and Buyer Reconciliation
A single video auction must be auditable. Build governance into the fabric, not on the side.
- Policy versioning: Every decision references a policy version. You can reconstruct what floors, separation rules, and eligibility existed at decision time.
- Path transparency: Persist schain, sellers.json mapping, and ads.txt authorization status for each bid and for the winner.
- Economics: Store gross bid, normalized net used for scoring, fees assumed, and final paid price.
- Privacy enforcement: Log consent presence, region, and redactions made before bid fan-out.
- Buyer APIs: Offer a secure reconciliation endpoint where buyers can query log-level decisions for their campaigns, subject to data sharing agreements.
Common Anti-Patterns That Break Trust
When publishers move toward unification, a few shortcuts tend to create downstream problems.
- Opaque mediation priorities: Hard-coded SDK order creates unpredictable advantages, and buyers cannot reconcile allocation logic.
- Missing or incorrect schain: If you collapse nodes or omit hops to make a path look simpler, buyers will discover mismatches with sellers.json and ads.txt quickly.
- Mixed net and gross bids: Scoring with a mix of fee-inclusive and fee-exclusive bids distorts competition. Normalize or do not compete those bids together.
- Inconsistent privacy behavior: If consent enforcement differs by channel, you will trigger audit findings and potential regulatory risk.
- SSAI event black holes: If you do not proxy verification and quartile beacons consistently, buyers will see delivery gaps and undercount, which leads to make-goods and lost trust.
KPIs to Monitor
Do not wait for a quarter-end to discover issues. Track a small, meaningful set of KPIs.
- eCPM and fill by channel and pod position: Watch for divergence after policy changes or partner rollouts.
- Timeout and error rates by partner: Drop or adaptively throttle slow paths.
- Bid density and price compression: Healthy auctions have sufficient bid distribution around floors.
- Transparency coverage: Percent of traffic with valid schain, sellers.json alignment, and ads.txt authorization.
- Measurement parity: Discrepancy between your logs and verification vendors by channel and partner.
- Audit pass rate: Internal checks for privacy flags, consent, and kids content routing.
How Red Volcano Helps
A single video auction is as much a data problem as it is an engineering problem. Red Volcano’s intelligence platform is designed to de-risk and accelerate this journey for supply-side teams.
- Publisher discovery and mapping: Use Magma Web to see which domains, apps, and channels align to your seller identities, and where technology stacks differ.
- Technology stack tracking: Understand which players, SDKs, SSAI vendors, and wrappers your properties use, then plan integration and adapter priorities.
- ads.txt and sellers.json monitoring: Detect authorization gaps that will break buyer trust before you route traffic through a new path.
- SDK and CTV data intelligence: See SDK prevalence, version drift, and CTV app distribution to forecast where auction improvements will have the biggest impact.
- Sales outreach intelligence: Equip your commercial team with transparency stories backed by data, including path quality and brand safety readiness by channel.
The north star is simple: better data in, better auctions out, fewer surprises, and stronger, more trusted paths to demand.
Implementation Roadmap
Even for mature teams, a phase-driven approach reduces risk.
Phase 1: Assessment and Policy Centralization
- Inventory and mapping: Catalog domains, apps, and CTV endpoints. Map each to seller accounts, schain positions, and authorized ad paths.
- Policy baseline: Document floors, separation rules, buyer allowlists, and privacy enforcement per channel. Identify conflicts and gaps.
- Control plane MVP: Stand up a versioned policy service with a simple API that your adapters can call for decisions.
- Transparency audit: Validate ads.txt and app-ads.txt files and cross-check sellers.json alignment for all partners.
Phase 2: Unified Gateway and Limited Pilot
- Gateway deployment: Introduce the auction gateway for a subset of web instream traffic and one CTV app via SSAI integration.
- Partner integration: Connect top exchanges and one or two high-impact direct deals.
- Logging and buyer reconciliation: Turn on log-level export and build secure access paths for pilot buyers to validate.
- KPIs: Monitor eCPM, fill, transparency coverage, and discrepancy rates.
Phase 3: Pod Intelligence and Scale-Out
- Pod allocator and analytics: Enable multi-winner allocation with separation rules and duration packing. Analyze pod position value.
- Adaptive floors: Launch controlled experiments with dynamic floors and partner-specific timeouts.
- In-app extension: Add in-app S2S routes and migrate SDK mediation to a neutral configuration that respects gateway decisions.
- Buyer enablement: Publish a transparency and reconciliation guide that explains your unified auction behavior.
Buyer Communication and Positioning
When you take a unified auction to market, explain the benefits in buyer language.
- Path clarity: Buyers can choose direct, low-hop paths with verifiable sellers.json, schain, and ads.txt consistency.
- Predictable economics: Floors and fees are disclosed, consistent, and aligned to viewability and completion rates.
- Measurement alignment: Support for OMID, VAST 4.x tracking, and SSAI beacon proxying reduces discrepancy.
- Privacy assurance: Region-aware GPP and TCF enforcement applied uniformly across channels.
Security and Reliability Considerations
Your auction gateway is a critical control point. Treat it with production-grade rigor.
- Rate limiting and abuse prevention: Protect endpoints that can be exploited for scraping or flooding.
- SLOs and degradation paths: Define timeouts, fallbacks, and degraded modes that still uphold privacy and transparency.
- Secrets and key rotation: Manage exchange credentials, SSAI tokens, and buyer allowlists securely with rotation policies.
- Resilience: Deploy multi-region with traffic steering to keep latency predictable and availability high.
Example: Policy Service Contract
A simple, explicit configuration contract helps you evolve without guesswork from adapter teams.
# Policy service response v1.2
request_id: c0a8017e-4f21-4c5f-b7a4-8fa64f26a3ee
policy_version: 1.2.7
channel: ctv
floors:
base_usd: 11.00
dynamic:
enabled: true
strategy: "dyn-v3"
timeouts_ms:
fanout: 1100
partner_overrides:
sspA: 900
sspB: 1000
podding:
max_ads: 3
max_duration_sec: 90
separation:
brand: ["Automotive", "Telecom"]
category: ["IAB1", "IAB7-5"]
eligibility:
buyers_allowlist: ["seat-999", "seat-22"]
deals_priority: true
privacy:
gpp_required: true
coppa_strict: true
transparency:
schain_required: true
reject_on_ads_txt_mismatch: true
experiments:
floor_strategy: "dyn-v3"
Adapters consume this and respond predictably. You can increment versions and provide deprecation windows.
The Strategic Payoff
Unifying video auctions across CTV, web, and in-app is not about squeezing out another half dollar by turning one knob. It is about rewiring how you compete for demand while getting credit for the trust you earn. With a single auction:
- You command a coherent story: Buyers hear one set of policies and see one set of behaviors across screens.
- You keep your options open: Modular adapters and standard interfaces reduce lock-in to a single SSAI or mediation provider.
- You capitalize on data: Transparency signals turn into datasets that guide floors, pod strategies, and partner selection.
- You respect users: Privacy rules apply uniformly, which is both compliant and good business.
References and Standards Worth Bookmarking
These are core resources that underpin the practices described here.
- IAB Tech Lab: ads.txt
- IAB Tech Lab: app-ads.txt
- IAB Tech Lab: sellers.json
- IAB Tech Lab: SupplyChain Object
- IAB Tech Lab: VAST
- IAB Tech Lab: Open Measurement SDK
- IAB Tech Lab: Global Privacy Platform
- Prebid Project
Conclusion
The single video auction is not a theory. It is a practical, standards-aligned path to better yield and stronger buyer relationships. Publishers do not have to choose between CTV podcraft excellence, web header bidding competitiveness, or in-app scale. You can harmonize decisioning, preserve the right channel-specific behaviors, and make transparency a first-class feature rather than an afterthought. If you start with a clean control plane, a normalized request schema, and an auditable decision service, the rest follows. Pods become predictable and fair. Floors make sense. Buyers get reconcilable logs. Privacy rules hold everywhere. Your teams spend less time firefighting and more time optimizing. Red Volcano exists to give supply-side teams the intelligence they need to execute this strategy with confidence. The tools to map your inventory, verify your public signals, and understand your technology surface area reduce risk and accelerate time to value. Build the single video auction. Make it transparent, make it testable, and make it yours. The market will reward it, and your buyers will trust it.