Prebid.js: If both CMP and TCF2.0 APIs exist, if no valid TCF2.0 response is found, it does not fallback to CMP
Type of issue
Bug
Description
I am currently testing our CMP from https://www.consentmanager.net. Our CMP stub has both __cmp
and __tcfapi
present.
If both the __cmp
and __tcfapi
APIs are present, Prebid defaults to __tcfapi
even when no consent string is returned.
We still have v1.1 __cmp
running as we plan to switch to TCF2.0 at a later date.
Considering there is a transition period occurring, I would have expected Prebid to check __tcfapi
returns a valid response before falling back to __cmp
.
Steps to reproduce
Load the test page - agree to the CMP.
Look at the console output. Read the Bid Request object from pbjs_debug, open the first bid entry, the gdprConsent
will show apiVersion: 2
and contentString
will be undefined
.
Above there will be a getConsentData callback result
output that will show the consent data from __cmp
API with a valid consent string.
Test page
https://prebid.os.network-n.com/demo/?site=steamidfinder&pbjs_debug=true&nndebug=cmp
Expected results
Prebid should be able to determine whether a valid consent is from v1.1 or TCF2.0, and should fall back to v1.1 if no valid TCF2.0 consent is found.
Actual results
Prebid finds TCF2.0, has no valid consent signal and continues the auction without checking for v1.1.
Platform details
Version 3.14.0
Other information
No other information at this time.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17
@patmmccann Not sure i read the code correct but there is a potential second issue: It seems prebid only calls addEventListener and then waits for the response. The issue with this is, that the initial TCF v2 spec does not give a statement what addEventListerner should return as “eventStatus” property. This means a CMP is also valid if addEventListerner calls the callback with eventStatus unknown or null. If addEventListener is called after the actual event, prebid will never receive a positive signal. The issue has been addressed to the TCF working group and will be changed, but for compatibility reasons the v2CmpResponseCallback should also treat eventStatus === null and eventStatus === undefined as valid until the spec has been corrected.