How do I set up an ad decisioning platform for direct-sold and programmatic campaigns in an OTT app?

Setting up an ad decisioning platform for an OTT app usually means building a system that can:

1. Decide whether to show an ad break
2. Choose the best campaign/creative for each slot
3. Handle both direct-sold and programmatic demand
4. Return stitched ads fast enough for streaming playback
5. Measure delivery, impressions, and pacing accurately

Here’s a practical blueprint.

---

1) Define the ad serving model

For OTT, you typically have a server-side ad insertion (SSAI) or client-side ad insertion (CSAI) setup.

SSAI is usually preferred for OTT

• Better playback experience
• Harder to block
• Works well on connected TVs and streaming devices
• More consistent ad delivery

Key decision points

You need an ad decisioning layer that can answer:

• Is the user eligible for ads?
• Which ad break is this?
• How many ad slots are available?
• Which campaigns qualify?
• Which programmatic bidders should be called?
• What is the winning ad?
• How should frequency caps, pacing, and targeting be enforced?

---

2) Split demand into direct-sold and programmatic

Direct-sold campaigns

These are guaranteed deals, typically handled with:

• Fixed priorities
• Guaranteed impressions or share of voice
• Audience targeting
• Frequency caps
• Dayparting / geo / device restrictions
• Pacing rules for delivery over time

Examples:

• Sponsorships
• PG deals
• Reserved campaigns
• House ads / promos

Programmatic campaigns

These usually include:

• Open auction
• PMP / private marketplace
• Programmatic guaranteed
• Header bidding / server-side bidding if supported

You’ll need:

• Bid request construction
• Bid response normalization
• Timeout handling
• Floor price logic
• Winner selection logic

---

3) Build the core decisioning components

A typical architecture includes:

A. Request ingestion layer

Receives ad requests from:

• OTT app / player
• SSAI stitching service
• Manifest manipulation service

Input should include:

• User/device ID
• Content metadata
• Ad break metadata
• Geo/IP
• Timestamp
• App/platform
• Consent signals
• Session info
• Playback position

B. Audience and eligibility service

Determines:

• Is the user ad-supported?
• Is consent available?
• Is the user in a target segment?
• Is the user excluded from certain campaigns?
• Are there geo restrictions?

C. Campaign management system

Stores and manages:

• Campaigns
• Creative assets
• Flight dates
• Targeting rules
• Priority
• Budget
• Pacing
• Frequency caps
• Supported devices and formats

D. Decision engine

This is the brain of the platform. It should:

• Filter eligible campaigns
• Score direct-sold campaigns
• Call programmatic bidders when needed
• Apply business rules
• Select the winning ad or ad pod composition

E. Ad delivery / stitching layer

For SSAI:

• Inserts ad media into the manifest or stream
• Generates stitched playlists
• Ensures correct ad pod duration
• Handles transcoding or mezzanine-to-delivery format mapping

F. Measurement and reporting layer

Tracks:

• Requests
• Wins
• Impressions
• Quartiles
• Clicks if applicable
• Fill rate
• Revenue
• Win rate
• Pacing status
• Frequency cap status
• Error rates

---

4) Design the decision flow

A common flow:

1. Player requests stream
2. Content playback reaches ad break
3. Ad decisioning service receives break metadata
4. Eligibility checks run
   • consent
   • audience segment
   • device type
   • geo
   • ad blockers not relevant in SSAI but still validate session integrity
5. Direct-sold campaigns are evaluated first
   • guaranteed campaigns
   • sponsorships
   • priority rules
6. If inventory remains, call programmatic demand
   • send bid request
   • wait for bids
   • evaluate floors and deal terms
7. Select winning creatives
8. Return stitched ad pod / VAST-like response
9. Log decision for billing and reporting
10. Track delivery events asynchronously

---

5) Handle ad pod logic carefully

OTT often serves ad pods of multiple spots in one break.

You need rules for:

• Pod duration matching
• Backfill if a slot is unfilled
• Competitive separation
• Category exclusions
• Advertiser exclusions
• Creative repetition avoidance
• Max ads per pod
• House ad fallback

Example:

• Break length: 120 seconds
• Pod format: 3 spots
• Direct-sold fills 60 sec
• Programmatic fills 30 sec
• 30 sec house ad or promo remains

---

6) Implement targeting and business rules

Common targeting dimensions:

• Geo
• Content genre
• Program/show
• Day/time
• Device/platform
• App version
• Age/gender segments if allowed
• Subscription status
• Viewing behavior
• Household/device graph
• Frequency cap by user/household/device

Business rules:

• Priority ordering
• Guaranteed delivery pacing
• Makegoods
• Blacklists/whitelists
• Competitive separation
• Creative rotation
• Brand safety

---

7) Programmatic integration options

For OTT, programmatic can be handled through:

• SSP integration
• Header bidding-style server calls
• VAST/VPAID-like responses depending on environment, though VPAID is mostly legacy and not ideal for OTT
• OpenRTB bid requests if you’re building your own exchange/adapter layer

Important:

• Use strict timeouts
• Normalize bidder responses
• Support creative transcoding or compatibility checks
• Make sure ad media is playable on OTT devices

---

8) Pacing and yield optimization

This is critical for direct-sold.

Pacing

Ensure guaranteed campaigns deliver evenly over time:

• Smooth pacing
• Accelerated pacing
• Spend-based or impression-based pacing

Yield

Optimize revenue by balancing:

• Guaranteed commitments
• Higher-paying programmatic demand
• Fill rate
• User experience

Typical strategy:

• Reserve impressions for direct-sold commitments
• Use programmatic to monetize excess inventory
• Use dynamic allocation if you can predict supply/demand

---

9) Measurement and billing

You need trustworthy logs for:

• Requested ad opportunities
• Eligible campaigns
• Selected creative
• Impression start/end
• Quartiles
• Completion
• Errors/failures
• Revenue attribution

For billing:

• Direct-sold: invoice on delivered impressions or completed spots as contracted
• Programmatic: reconcile with bid/win logs and impression logs

Use:

• Idempotent event logging
• Reconciliation jobs
• Fraud and anomaly detection
• Retry-safe reporting pipelines

---

10) Technical considerations for OTT

Performance

• Decisioning must be fast
• Cache campaign metadata
• Precompute segments where possible
• Use low-latency bidder adapters

Device diversity

Support:

• Roku
• Fire TV
• Apple TV
• Android TV
• Smart TVs
• Mobile OTT apps

Each has different playback and ad stitching constraints.

Latency

OTT breaks are sensitive to delay:

• Target response under a few hundred ms for cached decisions
• Programmatic timeouts often 300–1000 ms depending on architecture
• Pre-fetching or pre-decisioning helps

Privacy and consent

Ensure compliance with:

• GDPR
• CCPA/CPRA
• TCF/US privacy frameworks where relevant
• Device identifiers and consent management integration

---

11) Recommended architecture pattern

A common production setup:

• Frontend OTT app/player
• Manifest/stream service
• Ad decisioning API
• Campaign database
• Audience/identity service
• Programmatic bidding adapters
• SSAI stitching service
• Event pipeline
• Reporting warehouse

Technology examples:

• Decision engine: custom service in Go/Java/Node/Python
• Data store: Redis for fast lookups, Postgres for config, Kafka for events
• Stream processing: Flink/Spark/Beam if needed
• Warehouse: BigQuery/Snowflake/Redshift
• SSAI: custom or vendor-based

---

12) Build vs buy

Buy if you want speed

Use an ad tech vendor if:

• You need to launch quickly
• You don’t want to build SSAI and bidder integrations
• You want reporting and playback tooling out of the box

Build if you need control

Build your own if:

• You have complex direct-sold rules
• You need custom yield optimization
• You have unique data/identity logic
• You need tighter integration with your app and analytics

A hybrid approach is common:

• Buy SSAI
• Build decisioning and pacing logic
• Integrate your own programmatic adapters

---

13) Minimum viable implementation plan

Phase 1: Direct-sold only

• Campaign management UI or admin tool
• Simple decision engine
• Basic targeting and frequency capping
• SSAI integration
• Logging and reporting

Phase 2: Add programmatic

• OpenRTB/SSP integration
• Bidder adapters
• Floors and timeout management
• Winner selection
• Reconciliation

Phase 3: Optimize

• Pacing optimization
• Predictive yield management
• Advanced audience segmentation
• Creative rotation and experimentation
• A/B testing

---

14) A simple decisioning algorithm

At a high level:

1. Fetch all active campaigns for the break
2. Filter by:
   • date/time
   • geo
   • device
   • audience
   • consent
   • content restrictions
3. Rank direct-sold campaigns by:
   • priority
   • pacing gap
   • contractual guarantees
4. Reserve slots for guaranteed delivery
5. If inventory remains, request programmatic bids
6. Apply floors and deal rules
7. Select winners
8. Fill leftover slots with house ads if needed

---

15) Common pitfalls

• Not enforcing pacing, causing underdelivery
• Ignoring device compatibility for creatives
• Too many bidder calls causing latency
• Weak reconciliation between logs and billing
• Poor fallback strategy for unfilled pods
• Inconsistent user identity across devices
• Not handling consent/privacy correctly
• Overcomplicating the first version

---

16) Suggested first version architecture

If you want a practical first release:

• SSAI via vendor or internal service
• A lightweight campaign decision service
• Redis cache for active campaigns and caps
• Postgres for campaign config
• Kafka for event logging
• One or two programmatic adapters
• House ad fallback
• Basic reporting dashboard

---

If you want, I can also give you:

1. a reference architecture diagram,
2. a data model for campaigns/ad pods, or
3. a sample ad decisioning API design for OTT.