DIRECTV · Engineering case study

Connecting streaming playback
to advertising revenue.

Ad integration across live and video-on-demand experiences, working with Yospace and FreeWheel.

Dynamic ad insertionLive streamingVODYospaceFreeWheel

My role at DIRECTV

I was hired by DIRECTV to handle advertising integration. My work covered live streaming and video on demand (VOD), working with Yospace and FreeWheel to connect the viewing experience with the advertising delivery workflow.

This sits at the intersection of video playback and ad technology: the content needs to keep playing, while commercial opportunities need to become decisioned, delivered, and measurable ad impressions. The integration connects those requirements rather than treating advertising as a separate feature bolted onto the player.

The core challenge: make advertising work within the stream without losing sight of the viewer’s experience.

How dynamic ad insertion works

Dynamic ad insertion (DAI) selects advertising for a particular playback opportunity instead of permanently embedding the same commercial in every copy of the content. Server-side ad insertion (SSAI) is one way to deliver those decisions: an insertion service assembles the stream’s content and ad segments before the player consumes them.

Yospace provides stream insertion technology for live and VOD. FreeWheel supplies ad-serving and decisioning capabilities. The simplified workflow below explains their roles; it is an industry model, not a disclosure of DIRECTV’s internal architecture.

01 · Playback sessionPlayer requests a stream with eligible session context.
02 · Ad decisionAd server selects an eligible ad pod for the break.
03 · Stream insertionInsertion service assembles ad and content segments.
04 · MeasurementPlayback events support delivery reporting.

A typical decision request describes the content, playback mode, ad opportunity, and permitted targeting context. The ad server evaluates campaign eligibility and business rules, then returns creative information and tracking instructions. VAST (Video Ad Serving Template) is a standard format for communicating video ad metadata, media assets, and tracking information.

In an SSAI workflow, creatives must be compatible with the stream’s delivery formats and renditions. A personalized manifest points playback at the appropriate content and advertising segments. HLS and MPEG-DASH are common adaptive streaming protocols in this space.

Two playback models, different constraints

ConcernLiveVOD
Break timingFollows the live feed and signaled opportunities; SCTE-35 cues are common in broadcast workflows.Follows known pre-roll, mid-roll, or post-roll opportunities on the asset timeline.
Decision windowTime-sensitive: ad decisions and media preparation must fit the available break window.Some decisions can be prepared before the player reaches the break.
Playback behaviorJoin-in-progress, live-edge playback, and returning to the program require attention.Seeking, resume, and replay need explicit ad-policy handling.
FallbackKeep the feed valid when demand or creative delivery fails.Maintain a valid playback timeline when a break cannot be filled.

My work spanned both live and VOD ad integration. The table describes common engineering considerations in those environments; it does not claim a particular cue format, player, or fallback policy was used in my DIRECTV implementation.

What the integration looks like in code

The examples below show the shape of the problem: creating an ad-enabled playback session and handling measurement. They are illustrative JavaScript, not production DIRECTV code, Yospace SDK calls, or FreeWheel endpoint specifications.

1. Request an ad-enabled playback session

A useful integration boundary keeps vendor credentials and ad-policy decisions on the backend. The frontend asks for playback; the backend’s vendor adapter creates the appropriate session and returns a playable manifest.

Illustrative, simplified code explaining the implementation pattern. This is not a copy of private production source.

// Illustrative application contract; not a vendor API.
async function startPlayback({ contentId, mode, consent }) {
  const response = await fetch("/api/playback-sessions", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      contentId,
      mode, // "live" or "vod"
      advertisingConsent: consent
    })
  });

  if (!response.ok) {
    throw new Error("Playback session could not be created");
  }

  const { manifestUrl } = await response.json();
  // The player adapter supports HLS or DASH as appropriate.
  await playerAdapter.load(manifestUrl);
}

This makes the integration boundary explicit: the player consumes a playback resource, while backend adapters handle provider-specific authentication, session context, and ad configuration. A production system also needs entitlement checks and a controlled policy for failed ad decisions.

2. Normalize ad measurement events

Measurement must distinguish an ad being requested or included in a manifest from an ad actually being played. Depending on the integration, reporting may combine insertion-service signals with player-side confirmation.

Illustrative, simplified code explaining the implementation pattern. This is not a copy of private production source.

// Illustrative player telemetry, not billable-impression logic.
const observedEvents = new Set();

async function recordAdEvent(event) {
  const key = [
    event.sessionId,
    event.adPlaybackInstanceId,
    event.type // impression, firstQuartile, midpoint, etc.
  ].join(":");

  if (observedEvents.has(key)) return;

  const response = await fetch("/api/ad-events", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ ...event, idempotencyKey: key })
  });

  if (!response.ok) throw new Error("Telemetry not accepted");
  observedEvents.add(key);
}

The in-memory set only reduces duplicates in one client instance. Durable deduplication, vendor-approved beacon ownership, retry handling, and reconciliation belong in the wider reporting design. Client and server trackers should not both fire the same vendor event without an explicit measurement contract.

Turning ad opportunities into monetization

The business value of this integration is a working path from an available commercial break to delivered advertising. Ad decisioning makes inventory usable by campaigns; insertion makes the selected creative playable; measurement gives ad operations the delivery evidence needed for reporting and reconciliation.

Reported business context
Over $10 million / month

Monthly advertising revenue at DIRECTV, as reported from my experience. This figure is not independently verified here and is not presented as revenue solely attributable to my individual work.

My contribution was in ad integration across live and VOD, the delivery layer supporting that broader monetization operation. Revenue also depends on audience scale, sell-through, campaign demand, pricing, and the work of sales and ad operations teams.

A useful directional model is revenue ≈ billable impressions ÷ 1,000 × effective CPM. It explains why reliable ad delivery and trustworthy measurement matter, but it is not a reconstruction of DIRECTV’s contracts or revenue calculation.

The engineering takeaway

Streaming ad integration is more than displaying a commercial. It connects a player session, an ad-decisioning system, timed media delivery, and a measurement workflow. Working across live and VOD means understanding each boundary and how a failure in one can affect both playback and monetization.

At DIRECTV, I brought that engineering focus to advertising integration with Yospace and FreeWheel.