Reporting Players POPs with Broadsign Air

Since the third-party players “poll” (that is, request playlists) at irregular intervals, the third-party player itself is responsible for reporting POPs.

When there is a one-to-one relationship between the Broadsign Air player and the Broadsign Control “player” registered for it, no additional work is needed. Each confirmed playback results in a single POP.

When a venue consists of multiple third-party players represented by a single player registration in Broadsign Control Administrator to play the exact same thing while using Broadsign Air to provide synchronized playlists, the POPs are handled differently. As each third-party player confirms playback, Broadsign Control Administrator accumulates the individual confirmations server-side, based on the optional screen_identifiers submitted with the playback confirmation. When all the third-party players confirm playback, Broadsign Control Administrator issues a POP that includes the screen multiplier.

For example:

  • In a venue with 20 players, each player independently reports its playback, in near real-time.
  • In the current model, each player counts for 1/20th of a POP, with some rounding.
  • A threshold is defined: 80% of expected players checking in equals to 1 confirmed POP. For information on how to configure the threshold, see Configure the POP Threshold.
  • Aggregation is server-side, with POP submission as soon as the threshold is exceeded.
  • A venue is modeled in Broadsign Control as a single player with multiple monitors (player.nscreens).

In that case, the multiple physical players will each have their own screen_identifier for the same player_identifier. Broadsign Air uses their screen_identifier to properly count playback confirmations until the POP threshold is reached. Once enough players have checked-in with their confirmations to meet this threshold, then the corresponding item will count as a Broadsign Control Proof-of-Play.