Consent Handling

Owned by Patrick Jähnichen (Unlicensed)
Last updated: May 24, 2020
4 min read

This page gives an overview over how we handle the GDPR and privacy related issues within our products.

General setting

We provide a means of video content monetization to our publisher partners, both instream as well as outstream (in combination with our own content videos).

In both cases we rely on the consent that is given by the user to the publisher, we then act according to this consent and forward it to our SSP partners who consequently do the same downstream the supply chain. We do not collect/request user consent directly.

In the following, we describe the integration setting that we run currently with our partners.

Consent

Obtaining Consent

There are two ways of obtaining consent that we use:

  1. In tag based integrations and header bidding setups, we rely on the TCF2.0 compliant user consent string that is passed to us via the appropriate request parameter fields (GET parameter in tag based integrations, gdprConsent field in the bidder request for header bidding integrations). We evaluate the consent string, adapt our behavior accordingly and pass it on to the respective demand partners for their perusal.

  2. In situations where our own tech-stack is integrated with the publisher, we rely on our partners to utilize an IAB TCF2.0 compliant consent management platform (CMP) that exposes the proper JavaScript API to gain access to the consent information as collected from the website user.
    We will automatically extract the user consent and will proceed as in point 1.

Basic functionality - Content delivery

For our basic functionality of delivering content videos, no consent whatsoever is needed. There are no information/cookies that are stored on the client side nor any actions on our side that require user consent.

Marketing

The consent required for marketing options depends on the specific integration that we run with our publisher partners.

In general, we require consent for the following purposes:

  • Purpose 1: we store a randomized and anonymous user-specific identifier (UUID) in a cookie on the client side, no personal information whatsoever are contained within that cookie and we are not able to reconstruct a connection to a physical subject at any given stage

  • Purpose 2: for basic ad selection we will use the stored UUID cookie for capping the frequency, a user is presented a given ad; also, we will use the content of the current surroundings to identify the context the placement is located in

  • Purposes 7 and 8: we measure both ad and content performance, optimize demand (and content where applicable) delivery according to these measurements and report performance to both publishers and advertisers

  • Purpose 9: for the purpose of gaining audience insights, we combine market research data and panel audience information with insights about the content/context of the current website to derive content based target audience predictions

  • Purpose 10: all collected measurement data will continuously enter our machine learning models and algorithms to allow an ongoing learning process and ultimately a user independent, content-based targeting option

We claim legitimate interest for purposes 2, 7 and 8 and require consent for purposes 1, 9 and 10.

In addition, we claim legitimate interest for special purposes 1 and 2:

  • Special Purpose 1: to ensure security, prevent ad fraud and for debug purposes we collect and measure additional events like timeout behavior, viewability metrics, error statistics etc. The statistics gathered under this special purpose are solely used for identifying and fixing software bugs and to ensure overall operability of our systems (not to improve our products in any way).

  • Special Purpose 2: to enable users to see and interact with content and/or ads we receive and respond to publisher sites' requests, send ad requests and receive ad responses from demand partners and deliver back to the requesting IP address. This includes logging of ad/content delivery without storing any user specific data.

Header Bidding

In case of header bidding integrations, ad calls to our demand partners are not made from the client but from the server side within our product ecosystem. For our buying partners to successfully bid on inventory (for programmatic advertising), DPSs in almost all cases require a user ID to be included in the bid request.

As the ad call does not originate from the client side, potential buyers do not have access to user information they might have previously stored with client. In order to mitigate this, we use our own UUID ID cookie (as stored under Purpose 1 above), match it with demand partner UUIDs and maintain cookie ID matching tables. To this end we require user consent for Purposes 3 and 4 (creating a personalized ads profile and selecting ads based on that profile). Although we do not create personal user profiles on these grounds, we are part of the buyers' process in doing so.

Legitimate interest assessments

In addition to the above consent handling requirements and procedures, we document the conducted legitimate interest assessments and their outcomes in the following. To review our assessment, click on the respective link.