How DOOH and SSP work

  • Updated on May 16, 2025
  • Published on May 15, 2025
  • 4 minute(s) reading time
Prev Next

Playing DOOH and SSP content requires the coordination of multiple components like the player, the Grassfish IXM system, the Grassfish Server, the SSP, and their databases.

DOOH and SSP management

The Grassfish system facilitates the management of DOOH and SSP bookings and playouts in the following way:

  • DOOH content is managed as internal bookings in the Grassfish system. It can be created both directly in the system and programmatically via defined interfaces.

  • The Grassfish system enables the combined delivery of internal DOOH bookings and additional advertising content from external supply-side platforms (SSPs).

  • In this case, DOOH bookings always have priority:

    • The system prioritizes DOOH spots and allocates the remaining time slots for SSP advertising content.

    • The delivery logic ensures that the campaign goals for internal bookings are achieved.

    • For example, in a scenario with 10-second spots, where a spot has a share of voice of 1/6, that spot will be systematically placed in every sixth play interval.

  • If no DOOH or SSP content is planned, the system automatically activates fallback spots from a filler playlist (standard playlist) for continuous content delivery.

  • On Linux- or Windows-based players, the DOOH add-on implements the delivery of digital advertising and enables the control of up to two displays via a server-client architecture.

  • On the Android Player, you can simply enable DOOH and SSP in the player configuration. You don’t need to install an add-on.

Workflow

The playout of DOOH and SSP spots works in the following way:

  1. During the playback of a spot and the simultaneous preloading of the next spot, the player asks the DOOHPlaybackService add-on whether it has valid DOOH or SSP spots to play next.

  2. To find out, the player add-on accesses the local UDC database which stores all DOOH spots for this player.

    DOOH spots, also called bookings, are booked in the IXM DOOH module, stored in a UDC database, and transferred to the player. This enables the player to play DOOH spots without a connection to the server.

  3. Based on the saved DOOH bookings, the player add-on now calculates the next playback.

    For example, if the player still has 60 minutes available play time and the spot lasts one minute, it has to be played ten more times. That means the spot must be played every six minutes.

  4. Once the player has calculated the next playback, the following two outcomes are possible:

Outcome 1: DOOH flow

If the player add-on found and calculated a DOOH spot for playout, it communicates this to the player which then plays the spot.

Outcome 2: SSP flow

If the player add-on didn’t find a DOOH spot for playout, it starts to look for an SSP spot instead:

  1. The add-on on the server asks the SSP connector for valid SSP spots.

  2. The SSP connector, also called AdServing API, accesses one or more external SSP providers and asks for valid SSP bookings (SSP spots):

    • No valid SSP spots available: if no SSP spots are available or if no bookings are currently valid, the SSP provider communicates this to the SSP connector. The SSP connector forwards this information to the player add-on which informs the player. The player now plays the next valid spot from its filler playlist.

    • Valid SSP spots available: if the SSP provider finds a valid spot for playout, the SSP connector uses the IXM database to check whether this spot has already been transferred to the player:

      • The spot was transmitted: the SSP connector informs the player add-on which informs player. The player can now play the spot.

      • The spot wasn’t transmitted: the file is queried from the SSP provider and made available for download to the player via IXM playlists. The downloaded SSP spot will be available at the next attempt. In the meantime, the player add-on and thus the player is informed that there is currently no valid SSP spot. The player plays filler content instead.

The following diagram shows the communication and data transfer process between the different components required for DOOH and SSP.

The diagram shows how DOOH and SSP communication works.

Reporting to the SSP

The external SSP needs to know whether SSP content has been played or not. To let the SSP know, the player communicates when an SSP spot has started and ended.

The reporting process works in the following way:

  1. When the player starts playing an SSP spot that was scheduled by the AdServing API, it informs the DOOHPlaybackService add-on.

  2. In turn, the DOOHPlaybackService add-on sends a ReportSpotStarted request to the AdServing API.

  3. The AdServing API now calls the corresponding reporting URL for the external SSP provider.

  4. Once the player has finished playing a spot that was scheduled by the AdServing API, it informs the DOOHPlaybackService add-on.

  5. In turn, the DOOHPlaybackService add-on sends a ReportSpotEnded request to the AdServing API.

  6. The AdServing API now calls the corresponding reporting URL for the external SSP provider.

Impression management

Impresssions represent the target audience (segments). There is an additional Advertima add-on on the Grassfish Player for impression management:

  • The add-on receives impression data, sorts it by number, and places it on the player accordingly.

  • The DOOHPlayback add-on integrates the impression data into LiveTags and considers it in the delivery decision.

  • Optionally, impression data can be attached to the ad request to an SSP, provided the SSP uses this information for its own decision logic. This allows the actual segments to be considered during programmatic ad booking.