OpenRTB 2.6 Deep Dive: Native CTV Ad Pods, DurFloor Objects, and SSAI Signaling

When a Connected TV (CTV) Server-Side Ad Insertion (SSAI) stitcher intercepts an SCTE-35 splice cue signaling a 120-second commercial break, legacy OpenRTB 2.5 auction pipelines face a severe protocol mismatch: they must either fan out four to eight discrete single-impression bid requests per viewer or stuff proprietary, non-standardized JSON extensions into imp.video.ext. This structural gap between atomic web video impressions and television-style commercial breaks historically inflated Queries Per Second (QPS) across Demand-Side Platforms (DSPs), starved middle-of-pod slots of bid density, and forced Supply-Side Platforms (SSPs) to guess which combination of 15-second and 30-second spots would clear the highest yield before the auction even began.

The IAB Tech Lab OpenRTB 2.6 specification resolved this architectural bottleneck by introducing native CTV ad podding fields (poddur, maxseq, slotinpod, rqdurs, and mincpmpersec) directly inside the Video object, and release v2.6-202309 expanded that foundation by adding the DurFloor object inside Video, Audio, and Deal objects for duration-tiered floor pricing alongside the acat (allowed advertiser categories) attribute. Rather than treating a two-minute television break as an array of unrelated web banners, OpenRTB 2.6 allows the sell-side exchange to express a unified time budget, enforce non-linear CPM floors across creative durations, and pass explicit SSAI telemetry in a single HTTP request.

Across our OpenRTB 2.6 auction infrastructure, migrating CTV publishers from legacy multi-impression workarounds to native dynamic and hybrid pod signaling routinely reduces outbound DSP QPS by 60% to 75% per ad break while increasing total pod yield through knapsack-optimized duration packing. Achieving those gains in production requires a rigorous understanding of how OpenRTB 2.6 transforms the Imp object, how duration floors interact with Private Marketplace (PMP) deals, and how SSAIstitchers reconcile positional bidding with category deduplication.

Why OpenRTB 2.5 Struggled with Linear-Style CTV Ad Breaks

OpenRTB 2.5 was engineered around the atomic web page load. In that paradigm, an Imp object represents a single physical container on a Document Object Model (DOM) or a single pre-roll video opportunity bounded by minduration and maxduration. Even though OpenRTB 2.5 permitted multiple Imp objects inside a single bid request array (imp[]) and included a basic sequence integer on the Video object, the specification lacked any native mechanism to group those impressions into a shared commercial break or allocate a flexible time budget across them.

When CTV publishers and Free Ad-Supported Streaming TV (FAST) channels scaled linear-style programming, every SCTE-35 splice_insert marker triggered an ad break ranging from 60 to 180 seconds. Under OpenRTB 2.5, sell-side engineers had only two standard-compliant options to monetize a 120-second pod, and both introduced structural yield loss:

1. Sequential or Parallel Request Fan-Out: The SSAI stitcher or SSP Split-Podder generated four separate OpenRTB 2.5 bid requests (each requesting a 30-second spot) or eight separate requests (each requesting a 15-second spot) and transmitted them concurrently to participating DSPs. For a live sporting event or prime-time FAST channel with 250,000 concurrent viewers entering an ad break within the same 500-millisecond window, splitting one break into six requests multiplied outbound traffic to 1.5 million bid requests instantly. Tier-1 DSPs responded by engaging aggressive QPS throttling, dropping entire subsets of requests at the load balancer before evaluating a single bid.
2. Static Multi-Impression Arrays: The SSP sent a single OpenRTB 2.5 request containing an array of four to六 discrete Imp objects (imp[0] through imp[5]), pre-assigning a fixed duration range (minduration: 15, maxduration: 30) and a static bidfloor to each slot. Because the slots were rigidly pre-partitioned before the auction, the SSP could not dynamically trade off slot count against total duration. If the SSP pre-configured four 30-second Imp objects, a DSP holding six high-CPM 15-second creatives could only fill four slots, leaving 60 seconds of the 120-second break completely unmonetized despite abundant demand.

Beyond rigid slot partitioning, OpenRTB 2.5 created a severe duplicate-bidding pathology across multi-impression requests. Because DSPs lacked a standardized podid attribute to recognize that imp[0], imp[1], imp[2], and imp[3] belonged to the exact same continuous television break on a single household screen, bidder algorithms frequently evaluated each Imp independently. A DSP would return the exact same creative ID (crid) and advertiser domain (adomain) with a $24.00 CPM bid across all four slots.

When the SSP's post-auction clearing engine enforced basic competitive separation (preventing the same brand from running four times back-to-back in a single break), it had to discard three of the four winning bids from that DSP. Unless the SSP solicited deep multi-bid arrays per Imp from every seat and ran complex fallback cascading, discarding those duplicate bids left empty slots inside the VAST pod, forcing the SSAI stitcher to insert slate or zero-revenue house promos.

Finally, OpenRTB 2.5 provided only a single scalar imp.bidfloor attribute per impression. In a CTV environment where inventory is finite and measured in seconds of linear break time, a scalar floor is economically broken. If an SSP set imp.bidfloor: 15.00 on an Imp allowing minduration: 15 and maxduration: 60, a DSP could legally win the auction with a $15.05 CPM bid on a 60-second creative. That single 60-second spot consumed half of a two-minute break for $15.05, preempting four 15-second spots that could have cleared at $12.00 each ($48.00 combined yield for the same 60 seconds of screen time). Without native per-second or duration-bracketed floor structures, publishers had to split durations into separate deal IDs or duplicate Imp objects, further compounding QPS bloat.

The Imp Object Transformation in OpenRTB 2.6

OpenRTB 2.6 eliminates the artificial one-to-one coupling between an Imp object and a single video creative. Instead, the specification upgrades imp.video so an individual Imp can represent either a single structured slot within a named pod or an entire multi-slot commercial break governed by a time budget and a maximum sequence cap.

This architectural evolution shifts pod construction from a pre-auction guessing game to a post-bid optimization problem. By communicating the physical constraints of the commercial break directly to the buy-side bidder inside a single Imp object, our CTV monetization suite enables DSPs to evaluate all eligible campaigns in their index, diversify their own brand categories across the break, and return multiple distinct bids in the seatbid.bid[] array referencing that single imp.id.

Pod Signaling Dimension	OpenRTB 2.5 Workaround	OpenRTB 2.6 Native Implementation	Operational & Yield Impact
Break Grouping	Custom imp.video.ext.pod_id or implicit assumption across imp[]	imp.video.podid (String)	Explicit grouping across structured and hybrid Imp objects; prevents duplicate cross-slot bidding.
Time Budget Allocation	Rigid pre-sliced minduration / maxduration per Imp	imp.video.poddur (Integer, seconds) + maxseq (Integer)	Enables dynamic knapsack solving across 15s, 30s, and 60s bids within a single Imp.
Exact Allowed Durations	Continuous range (minduration: 15, maxduration: 30 allows 23s ads)	imp.video.rqdurs (Integer array, e.g., [15, 30, 60])	Prevents stitcher transcode failures caused by non-standard intermediate creative lengths.
Positional Targeting	imp.video.sequence (1-indexed ordinal slot only)	imp.video.slotinpod and bid.slotinpod (0, 1, 2, -1)	Allows buyers to bid a premium specifically for First, Last, or First/Last pod positions.
Duration-Aware Pricing	Single flat imp.bidfloor regardless of creative length	mincpmpersec (Float) and durfloors[] (DurFloor objects)	Protects inventory yield per second; enforces tiered floors for 60s vs. 15s spots.
SSAI Execution Context	Opaque or passed via proprietary ext flags	imp.ssai (0 to 3 enum)	Gives DSPs deterministic visibility into server-side stitching vs. client-side beaconing.

Dynamic Ad Pods vs. Structured vs. Hybrid Pods

OpenRTB 2.6 formalizes three distinct ad pod topologies: Structured Pods, Dynamic Pods, and Hybrid Pods. Selecting the right topology depends on the publisher's direct-sold sponsorship commitments, the capabilities of the downstream SSAI stitcher, and the OpenRTB 2.6 parsing maturity of connected DSPs.

In a Structured Pod, the SSP represents every individual commercial slot in the break as its own discrete Imp object within the imp[] array, binding them together with a shared imp.video.podid string and ordering them via imp.video.sequence (or slotinpod). Each Imp carries its own specific duration constraints (minduration/maxduration or rqdurs) and its own slot-specific floor price. Conversely, in a Dynamic Pod, the entire commercial break is collapsed into a single Imp object. Instead of pre-slicing the break into fixed slots, the Imp declares the total duration of the break via poddur (for example, 120 seconds) and the maximum number of ads allowed via maxseq (for example, 6 ads), leaving the exact combination of creative lengths open to auction competition.

A Hybrid Pod combines the deterministic positional control of a Structured Pod with the yield elasticity of a Dynamic Pod inside the same bid request. In a typical CTV implementation, a publisher may want to isolate the highly coveted first slot (or both the first and last bumper slots) to enforce specialized PMP deals or premium positional floors, while pooling the remaining middle duration of the break into a flexible dynamic container. To execute a Hybrid Pod, the bid request includes one structured Imp object with slotinpod: 1 (First position, fixed at 30 seconds) and a second dynamic Imp object with poddur: 90 and maxseq: 4 that shares the exact same podid.

Configuring podid, poddur, and maxseq

When constructing Dynamic or Hybrid pods, four fields inside the Video object govern the physical geometry of the break:

• podid (String): A unique identifier assigned by the publisher or SSP to a specific commercial break instance. When multiple Imp objects share the same podid (as in Structured or Hybrid pods), DSPs know those impressions represent mutually exclusive time slices within the same continuous viewing interruption.
• poddur (Integer): Specifies the total duration in seconds of the dynamic pod represented by this Imp. If poddur is present, the Imp is evaluated as a dynamic container rather than a single spot.
• maxseq (Integer): Defines the ceiling on how many individual video ads can be stitched into the dynamic pod. For example, setting poddur: 90 and maxseq: 4 tells the DSP that the pod can accept three 30-second ads (3 ads, 90 seconds), two 30-second ads and two 15-second ads (4 ads, 90 seconds), or four 15-second ads (4 ads, 60 seconds), but never five or six 15-second ads. This parameter is critical for protecting viewer experience and adhering to broadcast standards on ad frequency per break.
• rqdurs (Integer Array): An array of exact integer durations in seconds (such as [15, 30, 60]) permitted inside the pod. In legacy OpenRTB 2.5, setting minduration: 15 and maxduration: 60 legally permitted a DSP to return a 22-second or 47-second direct-response creative. For SSAI systems that pre-segment HLS/DASH manifests along strict 15-second GOP (Group of Pictures) boundaries, odd-duration creatives cause slate padding or buffer underruns. When rqdurs is populated, minduration and maxduration are omitted, and DSPs must only return creatives matching the exact integers in the array.

The following production OpenRTB 2.6 snippet demonstrates a Hybrid Pod configuration for a 120-second commercial break (podid: "scte35-break-88412"). The first Imp (imp-slot-alpha) isolates a structured 30-second opening position (slotinpod: 1), while the second Imp (imp-pod-rem) exposes the remaining 90 seconds as a Dynamic Pod accepting up to four creatives of 15, 30, or 60 seconds:

{
  "id": "req-ctv-hybrid-902104",
  "tmax": 350,
  "imp": [
    {
      "id": "imp-slot-alpha",
      "ssai": 2,
      "bidfloor": 24.00,
      "bidfloorcur": "USD",
      "video": {
        "mimes": ["video/mp4", "application/x-mpegURL"],
        "minduration": 30,
        "maxduration": 30,
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "startdelay": 0,
        "plcmt": 1,
        "linearity": 1,
        "podid": "scte35-break-88412",
        "slotinpod": 1
      }
    },
    {
      "id": "imp-pod-rem",
      "ssai": 2,
      "bidfloor": 12.00,
      "bidfloorcur": "USD",
      "video": {
        "mimes": ["video/mp4", "application/x-mpegURL"],
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "startdelay": 0,
        "plcmt": 1,
        "linearity": 1,
        "podid": "scte35-break-88412",
        "poddur": 90,
        "maxseq": 4,
        "rqdurs": [15, 30, 60],
        "mincpmpersec": 0.65
      }
    }
  ]
}

Slot-in-Pod (slotinpod) Bidding Mechanics: First, Last, or Any

Viewer attention during a television ad break follows a U-shaped curve: brand recall and completion rates peak during the very first spot (immediately following the content splice) and rise again during the final spot (as viewers return their attention to the screen anticipating the resumption of programming). OpenRTB 2.6 captures this economic premium through the slotinpod attribute, which conforms to the IAB Ad Pod Slot Position enumeration:

• 0 (Any): No positional guarantee or requirement; the ad may be stitched anywhere within the pod.
• 1 (First): The very first ad stitched at the opening boundary of the pod.
• 2 (Last): The final ad stitched immediately prior to returning to program content.
• -1 (First or Last): Either the opening or closing bookend position of the pod.

Crucially, slotinpod operates bidirectionally across the request and response lifecycle across our supported CTV video ad formats:

1. In the Bid Request (imp.video.slotinpod and deal.video.slotinpod): When used inside a Structured or Hybrid pod Imp, imp.video.slotinpod declares that the impression guarantees a specific bookend position. When used inside a Dynamic Pod Imp, setting imp.video.slotinpod: -1 signals to DSPs that both the first and last positions within that dynamic container are open for positional bidding (whereas in our Hybrid example above, since imp-slot-alpha already claimed slotinpod: 1, imp-pod-rem could set slotinpod: 2 to signal that only the last position of the overall break remains available inside the dynamic portion).
2. In the Bid Response (seatbid.bid.slotinpod): When a DSP responds to a Dynamic Pod Imp, it can return multiple bids in seatbid.bid[] referencing that single impid. If an advertiser requires the first position, the DSP sets bid.slotinpod: 1 on that specific bid object (often accompanied by a higher CPM). If the SSP's pod assembly engine cannot place that bid in the first slot (because another DSP submitted a higher-yielding bid for position 1), the SSP must disqualify the losing positional bid rather than relegating it to a middle slot, preserving the buyer's strict positional contract.

CPM Per Second (mincpmpersec) and the New DurFloor Object (v2.6-202309+)

In a Dynamic Pod where a single Imp accepts 15-second, 30-second, and 60-second ads simultaneously, a single static imp.bidfloor cannot protect publisher yield. OpenRTB 2.6 initially addressed this by introducing mincpmpersec (minimum CPM per second), a floating-point attribute supported on both imp.video and imp.pmp.deals[].

When mincpmpersec is set to 0.65, the effective floor price scales linearly with the dur (duration) of the bid returned by the DSP:

• A 15-second bid must meet or exceed 15 * $0.65 = $9.75 CPM.
• A 30-second bid must meet or exceed 30 * $0.65 = $19.50 CPM.
• A 60-second bid must meet or exceed 60 * $0.65 = $39.00 CPM.

While mincpmpersec prevented 60-second creatives from clearing at 15-second prices, sell-side yield analysts quickly encountered a market friction: CTV demand elasticity is non-linear. In real-world broadcast and programmatic CTV buying, a 30-second spot rarely commands exactly double the gross CPM of a 15-second spot; historically, 15-second spots trade at 65% to 75% of the 30-second rate. If a publisher sets mincpmpersec: 0.80 to achieve a $12.00 floor on 15-second ads, the implied $24.00 floor on 30-second ads and $48.00 floor on 60-second ads may choke off highly desirable 30-second demand that clears at $19.00. Conversely, lowering mincpmpersec to 0.60 to let $18.00 30-second ads clear drops the 15-second floor to $9.00, eroding short-form yield.

To solve non-linear duration pricing, OpenRTB v2.6-202309 introduced the DurFloor object (durfloors[] array) inside Video, Audio, and Deal objects. Each DurFloor object contains three fields:

• mindur (Integer): Minimum duration boundary of the pricing tier in seconds (inclusive).
• maxdur (Integer): Maximum duration boundary of the pricing tier in seconds (inclusive).
• bidfloor (Float): The minimum clearing price (expressed in imp.bidfloorcur or deal.bidfloorcur) required for any creative falling within the [mindur, maxdur] bracket.

With durfloors, an SSP can define a concave or convex step-function floor curve tailored to empirical bid density at each duration tier, and override those open-exchange tiers within specific PMP deals:

{
  "id": "imp-dynamic-pod-v26-202309",
  "ssai": 3,
  "bidfloor": 10.00,
  "bidfloorcur": "USD",
  "video": {
    "mimes": ["video/mp4"],
    "protocols": [7, 8, 11, 12],
    "w": 1920,
    "h": 1080,
    "plcmt": 1,
    "linearity": 1,
    "podid": "fast-ch-44-break-19",
    "poddur": 120,
    "maxseq": 5,
    "rqdurs": [15, 30, 60],
    "mincpmpersec": 0.50,
    "durfloors": [
      { "mindur": 1,  "maxdur": 15, "bidfloor": 13.50 },
      { "mindur": 16, "maxdur": 30, "bidfloor": 21.00 },
      { "mindur": 31, "maxdur": 60, "bidfloor": 38.00 }
    ]
  },
  "pmp": {
    "private_auction": 0,
    "deals": [
      {
        "id": "SKY-CTV-AUTO-PMP-771",
        "at": 1,
        "bidfloor": 18.00,
        "bidfloorcur": "USD",
        "durfloors": [
          { "mindur": 15, "maxdur": 15, "bidfloor": 18.00 },
          { "mindur": 30, "maxdur": 30, "bidfloor": 26.00 }
        ]
      }
    ]
  }
}

When evaluating bid responses against this payload, the SSP auction validator follows a strict precedence hierarchy:

1. If the bid matches a dealid, the validator checks deal.durfloors for a bracket matching bid.dur. If no bracket matches, it falls back to deal.mincpmpersec * bid.dur, and finally to deal.bidfloor.
2. For open-auction bids (or when deal-level duration floors are absent), the validator checks imp.video.durfloors for a bracket matching bid.dur.
3. For backward compatibility with DSPs running early OpenRTB 2.6 parsers (pre-202309) that do not yet ingest durfloors, populating a baseline mincpmpersec alongside durfloors ensures older bidders still receive duration-scaled floor guidance rather than defaulting to the base imp.bidfloor.

Signaling Server-Side Ad Insertion and Allowed Categories (acat)

In CTV environments, creative stitching and tracking verification rarely execute purely inside a client-side browser context. Whether a publisher uses Google Ad Manager (GAM 360) Dynamic Ad Insertion (DAI), an independent cloud stitcher, or a hybrid client-server SDK on Roku (RAF), Apple tvOS, Samsung Tizen, or LG webOS, DSPs need deterministic signaling regarding where the VAST XML is parsed and which network entity fires the impression and quartile beacons.

OpenRTB 2.6 standardizes this telemetry via the imp.ssai integer attribute:

• 0: Unknown SSAI status.
• 1: All client-side (the client device requests the VAST tag, fetches the media file, and fires all tracking pixels directly from the household IP).
• 2: Assets stitched server-side, tracking pixels fired client-side. The SSAI proxy fetches the VAST response and transcodes/stitches the media segments into the master HLS/DASH manifest on the server, but delivers the tracking beacon metadata to a client-side SDK (such as the Google IMA/PAL SDK or Roku RAF) so impression and quartile beacons fire directly from the viewer's device IP and User-Agent.
• 3: All server-side. Both manifest stitching and VAST tracking pixel execution occur from the SSAI data center IP range on behalf of the client device.

Passing an accurate imp.ssai flag (specifically 2 vs. 3) is vital for preventing false-positive Invalid Traffic (IVT) filtration at the DSP and third-party verification layer. When imp.ssai: 3 is declared, tier-1 DSPs expect the subsequent VAST impression HTTP GET requests to originate from known SSAI cloud CIDR blocks and carry forwarded device headers (X-Forwarded-For, X-Device-IP, and X-Device-User-Agent) matching the device.ip, device.ipv6, and device.ua declared in the OpenRTB bid request. Conversely, when a publisher integrates a client-side verification dispatch layer and declares imp.ssai: 2, DSPs prioritize those impressions because client-originated beacons eliminate server-side proxy spoofing vectors.

Alongside SSAI transparency, OpenRTB v2.6-202309 introduced the acat (Allowed Advertiser Categories) string array on the root BidRequest and inside the Deal object. Historically, OpenRTB only supported bcat (Blocked Advertiser Categories). While bcat works well when a publisher wants to exclude a handful of sensitive verticals, CTV programmatic curation frequently operates in reverse: a publisher or SSP creates a vertical-specific PMP deal (for example, an Automotive-only sponsorship pod during a motorsport broadcast or a QSR-only deal) or enforces a strict co-op sponsorship rule where only specific IAB Content Taxonomy categories are eligible to bid.

Before v2.6-202309, restricting a deal to a single category via bcat required passing an array of hundreds of blocked IAB taxonomy strings in every single bid request, bloating payload sizes by several kilobytes. With acat, the SSP simply declares the exact taxonomy codes permitted on the deal (using the taxonomy version specified in cattax, such as cattax: 1 for IAB Content Category Taxonomy 1.0 or cattax: 3 for Ad Product Taxonomy 2.0):

{
  "id": "req-ctv-curated-deal-551",
  "cattax": 1,
  "bcat": ["IAB25", "IAB26"],
  "imp": [
    {
      "id": "imp-pod-1",
      "ssai": 2,
      "video": {
        "podid": "live-motorsport-break-04",
        "poddur": 60,
        "maxseq": 2,
        "rqdurs": [30]
      },
      "pmp": {
        "private_auction": 1,
        "deals": [
          {
            "id": "SKY-AUTO-EXCLUSIVE-2026",
            "bidfloor": 28.00,
            "acat": ["IAB2", "IAB2-1", "IAB2-2"]
          }
        ]
      }
    }
  ]
}

Competitive Separation and Category Deduplication Across a Single Pod

Transmitting a compliant OpenRTB 2.6 bid request is only the first half of the CTV podding lifecycle; the SSP's auction engine must then ingest the multi-bid responses (seatbid.bid[]) from all participating DSPs and solve a constrained combinatorial optimization problem within the auction timeout budget (tmax, typically 300ms to 450ms for CTV).

When DSPs respond to a Dynamic Pod (imp-pod-rem with poddur: 90, maxseq: 4), a single DSP seat is permitted and encouraged to return multiple Bid objects targeting that same impid, provided each bid carries a distinct id, creative duration (bid.dur), advertiser domain (bid.adomain), and IAB category (bid.cat). Across ten participating DSPs, the SSP may collect 25 to 40 valid bids of varying durations (15s, 30s, 60s), positional constraints (bid.slotinpod), and clearing prices.

To construct the winning VAST 4.3 pod response without violating television broadcast standards, the SSP executes a four-stage pod assembly pipeline:

1. Brand Safety, Category, and Floor Validation: Every candidate bid is validated against the publisher's floor curve (durfloors or mincpmpersec) based on its declared bid.dur. Simultaneously, the SSP filters out any bid violating bcat, badv, or deal-level acat rules. At Sky Boosts, this validation layer strictly enforces our 100% Google-friendly and HUMAN / Pixalate IVT-clean inventory policy: we monetize mainstream, brand-safe inventory and demand only, automatically rejecting any bid or creative associated with alcohol, gambling, adult content, tobacco, or unverified domains before pod assembly begins.
2. Effective Yield Normalization: Because a $20.00 CPM bid for a 15-second spot and a $35.00 CPM bid for a 30-second spot both represent a gross price per thousand impressions (not per second), the knapsack solver converts each valid bid's clearing price into its Effective Value Per Second (bid.price / bid.dur) while tracking its absolute revenue contribution (bid.price) toward the total pod yield.
3. Constrained 0-1 Multiple-Choice Knapsack Solving: The solver selects a subset of bids $S$ that maximizes total gross pod revenue $\sum_{i \in S} \text{price}_i$ subject to five hard constraints:
   • Time Budget Constraint: $\sum_{i \in S} \text{dur}_i \le \text{poddur}$ (total duration cannot exceed the break length).
   • Sequence Cap Constraint: $|S| \le \text{maxseq}$ (total spot count cannot exceed the maximum allowed slots).
   • Domain Deduplication: For all distinct bids $i, j \in S$, $\text{adomain}_i \cap \text{adomain}_j = \emptyset$ (the same advertiser cannot appear twice in the same pod).
   • Competitive Category Separation: For all distinct bids $i, j \in S$, $\text{cat}_i \cap \text{cat}_j = \emptyset$ at the configured taxonomy depth (for example, preventing two competing automotive manufacturers or two competing wireless carriers from running inside the same 90-second break).
   • Positional Satisfaction: At most one bid with slotinpod: 1 is assigned to sequence 1, at most one bid with slotinpod: 2 is assigned to the final sequence $|S|$, and any bid with slotinpod: -1 must occupy either sequence 1 or sequence $|S|$.
4. VAST 4.3 Pod Serialization: Once the optimal conflict-free subset $S$ is selected and ordered (sequence="1" through sequence="|S|"), the SSP wraps the winning VAST <Ad> nodes into a single multi-ad VAST 4.3 XML document (or returns the ordered winning bids to the SSAI stitcher/Prebid Server layer), injecting standardized <AdVerifications> and pod loss notifications (lurl) for any bids dropped due to category collision (OpenRTB Loss Reason Code 103 or 205).

For CTV publishers, FAST channel operators, and SSAI engineering teams upgrading their programmatic stack, capturing the full yield potential of OpenRTB 2.6 requires executing three concrete operational steps:

• Consolidate Multi-Imp Fan-Outs into Dynamic or Hybrid Pods: Replace legacy OpenRTB 2.5 slot-splitting with native podid, poddur, maxseq, and rqdurs signaling to eliminate DSP QPS throttling and allow 15-second, 30-second, and 60-second creatives to compete dynamically within a unified time budget.
• Deploy durfloors Alongside mincpmpersec: Configure v2.6-202309 DurFloor arrays on both open-exchange Video objects and PMP Deal objects to capture the natural non-linear price premium of 15-second spots while retaining mincpmpersec as a fallback for legacy OpenRTB 2.6 bidders.
• Audit imp.ssai and Forwarded Device Headers: Ensure your SSAI stitcher or Prebid Server instance accurately declares imp.ssai: 2 (for client-beaconing architectures) or imp.ssai: 3 (for full server-side execution) with synchronized X-Device-* HTTP headers, protecting fill rates and ensuring seamless settlement on reliable Net-30 and Net-60 payment terms.