DaisyBit is a compressed binary information which can be passed throughout the online advertising ecosystem (through OpenRTB specification) to transfer the consent status of the user visiting a website.
Example of a DaisyBit – 11111110111110010100110011011111001010110.
IAB Europe developed the GDPR Consent Framework to help publishers and Adtech companies (third-parties) deal with the consent process. The ultimate goal is to make everyone in the ecosystem ‘GDPR Compliant’.
DaisyBit is a part of the GDPR Consent Framework. It facilitates one of the important aspects of the framework i.e., passing the user’s consent through the chain.
What information is converted into DaisyBit?
In one word – Consent. A user’s consent is converted into a DaisyBit. If a publisher has a dozen purposes and vendors which can track the user and target ads, then the user can provide consent for each vendor and purpose, individually.
Here’s what we mean (Oversimplified Example):
Purpose 1 – Consent given – 1
Purpose 2 – No Consent given – 0
Vendor 1 – No consent given – 0
Vendor 2 – Consent given – 1
Vendor 3 – Consent given – 1
DaisyBit generated – 10011. This DaisyBit is passed down to the ecosystem through OpenRTB specification.
What does the purpose mean?
It’s the reason behind the collection of the users’ data. That is, Targeting ads, tracking web sessions, etc.
Who are the vendors?
IAB Europe is maintaining a dynamic list of vendors (Processors and Controllers) called ‘Global Vendor List’. An entity from the list is a vendor and a publisher can use the list as a basis for disclosure and consent requests.
How will DaisyBit help publishers to determine whether a user is opted out or not?
If the user opts in, the consent status will be 1. Else, 0. If the user hasn’t given any consent or the user is a first time visitor, then there will no cookie containing the DaisyBit. Therefore, the user is prompted for consent.
Cookie! So the solution is vulnerable to cookie clearing?
You’re right. Preferred vendors, purposes, and consent preferences will be gone, once the user clears cookies. The consent should be re-obtained from the user. Thus, the IAB Europe plans to develop more reliable storage methods in the future.
Can a Vendor see the consent status of other vendors?
The OpenRTB request will contain the DaisyBit which will allow the vendor to see the consent status of other vendors and publisher.
However, a vendor can’t see the purposes and disclosures of other vendors and publishers. Only CMPs can read the status and disclosures associated with a domain.
Does ‘DaisyBit’ work in any app?
No, the framework isn’t supporting any mobile apps yet.
“The current solution works for web-based apps, but not native apps. An SDK is being discussed and is required as an add-on to this solution and will be made available to app builders by individual CMPs.”
– IAB Europe.
Update: IAB Tech Lab & IAB Europe released tech specifications for Mobile In-app Framework recently and now, it is open for Feedback.
How is the DaisyBit distributed?
Consent Management Platforms (CMPs) will be responsible for the distribution. And, vendors have to update on their side to receive the DaisyBit.
“This will be done with a call to one or more of the standardized JS API functions. Each vendor or SSP will need to update their own code to use the API to check preferred vendors, purposes, and consent when their system receives a call.”
– IAB Europe.
The Way Forward
There wasn’t a wide-adoption of the framework yet. A few premium publishers have taken steps to enforce the framework with an in-house CMPs (Axel Springer and Schibsted). Mid-market and small publishers are still striving to settle on a solution.
Google limiting its ‘Funding Choices’ to share consent with just 12 Adtech vendors further amplifies the confusion. Most publishers couldn’t decide a side to rely on.
Industry experts say this will add a new layer to the landscape and agitate the adtech vendors (especially DSPs and trackers).
Note: We’ll update the article continuously to help you better understand the framework.