Q: For data limited to a specific advertiser’s use, Oath is considered a processor. For any other data licensed for broader use, Oath is a controller. Does this mean that any data should be pushed to only one seat/one client?

A: Generally, Oath will only enter into a processor relationship on a one-by-one basis with a specific advertiser client (legal entity).If the advertiser operates in more than one seat or account there is no problem. We would avoid a situation where an advertiser comes to us and wants to use our DMP to re-distribute data to unrelated third parties.

Parameter names

Q: Provider does not have the direct relationship to the end-user. The publishers whose data we aggregate do. We require that the publisher manages the user consent. Some publishers will be collecting the audience data under consent and some under legitimate interest. For our publisher running consent - will you be participating in the IAB framework?

A: Yes, Oath is participating in the IAB framework. We are using IAB bits for our euconsent parameter values - Storage and access of information and Personalization.

Q: We would ask any of our publishers to also include consent for Oath. For publishers running under legitimate interest - how are these handled with the outlined parameters?

A: Oath will still need consent for the following AIB parameters - Storage and access of information and Personalisation If a publisher claims legitimate interest for everything and does not get consent from a user for Oath, we cannot accept this data. If they include the parameters and right values, it means the publisher got consent for Oath and we can process the data.

Q: For the data transfer, a data provider should include the euconsent values if they have the consent, rather than Oath received consent from that user?

A: Euconsent values are for Oath consent. A data provider should gather consent for Oath. Oath needs consent to process data on a EU user in co-controller scenarios.

Q: Are data providers expected to send the euconsent values if Oath has consent or if the provider has consent?

A: For cookie-sync, provider doesn’t need to determine if we have consent in the IAB string. Oath will decode the IAB string when we get it to determine if we have consent.

Audience Transfer

Q: If Oath is controller, we need to send the IAB strings, only if Oath, not provider has consent on that user, correct? Meaning, we will need to collect the IAB consent string, look up whether Oath has consent or not, and store that on the provider profile. We will then pass this along in the data transfer?

A: That is correct. For data transfer we require provider to confirm Oath has consent for the IAB purposes prior to sending data. If Oath does not have consent, provider should not send the data.

User Sync

Q: We need to pass along Oath consent, not provider consent, correct? Meaning, we will need to read the IAB consent string, look up whether Oath has consent or not, and if so, convert that to ‘storage and access of information and personalisation’ in the sync pixel.

A: They just need to pass the IAB string through the IAB protocol and we will decode the consent string to determine if Oath has consent. Note that the IAB protocol doesn’t exactly cover data transfers through DataX. This is why for DataX we came up with a consent protocol that is similar to the IAB framework but relies on partners to ensure they only send data when Oath has consent. The IAB protocol does explicitly cover cookie-syncing so we’re OK decoding the IAB string ourselves. This is why we have two different positions on DataX vs cookie-syncing.