Listener ID Management

The Triton "Listener ID" allows the Triton Digital platform to measure listenership and to respect frequency caps, which can, for example, prevent an unwanted pre-roll from launching if the listener re-connects within five minutes of connecting. Not using these features, or not using them correctly, decreases the value of your inventory to buyers.

Triton Digital supports the specific types of Listener IDs that are described in Parameters > Listener Identification.

Listener ID Parameter

Triton Digital automatically generates a Listener ID, but this is overridden when explicitly providing the Listener ID (lsid) parameter.

The Listener ID parameter is formatted as a prefix describing the type, a colon, and the value of the Listener ID:

<type>:<id>

For example:

idfa:AEBE52E7-03EE-455A-B3C4-E57283966239

This would result in the following parameter:

lsid=idfa:AEBE52E7-03EE-455A-B3C4-E57283966239

For more information on the lsid parameter, see Parameters > Listener Information.

Addressability

The Listener ID parameter prefix is needed order to correctly target "addressable" (smart) impressions in Yield-Op. For example:

• lsid=idfa:AEBE52E7-03EE-455A-B3C4-E57283966239 will target addressable impressions.

• lsid=AEBE52E7-03EE-455A-B3C4-E57283966239 will not target addressable impressions.

Sending Multiple Types of IDs

Some devices may support multiple user/device identifiers. You can include multiple listener IDs in the query, but Triton’s measurement and frequency capping features are only enabled on the one specified in the lsid parameter in the formula lsid=<type>:<id>.

Respecting Users' Opt-out

Mobile users have the right to opt out of tracking for advertising purposes. This is usually handled in the device's operating system. For example:

• iOS: Limit Ad Tracking;

• Android: Opt out of interest-based advertising;

It is your responsibility to ensure that a user's choice to opt-out of tracking is respected.

If the user has selected these options, do not send the idfa, gaid, or other Device Advertising IDs. In this case you can, however, use the app Listener ID to pseudonymously track the listener's duration to ensure frequency caps are respected. Ideally, the app Listener ID should persist between streaming sessions. If that isn't possible it should at least persist for the duration of the listening session in order to enable the value-added features (frequency caps, unique listener measurement, etc.).

Apple Identifier for Advertising (idfa)

On iOS and iPadOS devices, use the ASIdentifierManager API to retrieve the IDFA, as follows:

NSString *idfaString = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

Note that the user can opt-out from sharing their IDFA, so the application must handle cases where this ID is not available. In these cases, the application should fall back to app-generated IDs.

Google Advertising ID (gaid)

This is the Google advertising identifier for Android devices as retrieved from Google Play services. Documentation on retrieving and using this ID is available from: https://developers.google.com/android/reference/com/google/android/gms/ads/identifier/package-summary

Note that the user can opt-out from sharing their device's Advertising ID, so the application must handle cases where the ID is not available. In these cases, the application should fall back to cookies or app-generated IDs.

App-generated ID

For applications that cannot use Advertising IDs (either due to lack of platform support, or because of user opt-out) and are unable to support cookie-based IDs, it is possible for the application to generate its own Listener ID.

An App-generated Listener ID is a Type 4 GUID, as defined by the IETF standard RFC4122 (http://www.ietf.org/rfc/rfc4122.txt) and encoded as a lowercase character string (e.g., 550e8400-e29b-41d4-a716-446655440000).

Once generated, the App-generated Listener ID can be preserved and reused, at a minimum for the duration of a listening session. It only needs to persist across a single session to enable frequency capping within the session, but allowing it to persist for longer enables cross-session frequency capping and better unique-listener calculations. Be sure to work within your privacy policy and all applicable laws and regulations when using App-generated Listener IDs.

Cookie-based IDs

Web browser-based players use cookie-based IDs. (Mobile app players should use one of the Device Advertising ID types instead.)

The cookie value’s format follows the IETF standard RFC4122 (http://www.ietf.org/rfc/rfc4122.txt) and is encoded as a lowercase character string (e.g., 550e8400-e29b-41d4-a716-446655440000).

When a player connects for the first time it won’t have a Listener/Advertising ID, so the Triton Digital platform assigns one to it. The cookie Advertising ID is sent back to the player, which should save it and reuse it in subsequent connections. For Web-based players, the Web browser does this automatically. Custom player applications, however, might need to implement their own cookie handling.

Hybrid Players

Players that use various Triton Digital services (e.g., streaming and on-demand ads) must use the same Listener ID for all cases. Otherwise, some things like frequency caps and analytics will be affected and might not work as intended.