-
Notifications
You must be signed in to change notification settings - Fork 41
Clarification on event status #37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
At prebid we're struggling with this as well; we're assuming, as many of our publishers are implementing this way, that cmp display status will always be visible in the United States, as the opt out button will always be available on the page. Since useractioncomplete doesn't really have an equivalent; we're simply using status loaded and proceeding with an auction. I think your assumptions make sense in an opt in regime, but not in the US I think display status should have a new indicator that distinguishes visible and should wait from visible don't wait |
@patmmccann Does it mean we need a forth and/or independent status? Something like cmpOutOutLinkStatus = "unknown/notApplicable/visible/notVisible"? |
exactly
there is no way :( I'm not sure at all the best way forward, I look forward to the discussion |
I think it'd be wise to separate the idea of "cmp is visible" from "user is being prompted" - or be explicit that "visible" means the latter, as the implementation examples seem to suggest. |
cmpDisplayStatus = 'onpage' could be a new display status? |
"onpage" woulnt be sufficient or? e.g. if you have both (opt out link and notice layer), would it then be cmpDisplayStatus = "onpage+visible" or would there be two events right after each other? |
My preference, as a Prebid developer, would be a separate flag that indicates whether the user needs to take action (which was the I am not interested at all in the visibility of the CMP - all I need to know is, is the user likely to change consent in the next few seconds? |
I am having trouble finding the code section, but I thought this was illegal, that opt out and notice most be adjacent and in the same layer. |
@patmmccann What do you mean with "illegal"? unwanted by the gpp spec or unwanted by CCPA/PEPIDA/GDPR/whatever? |
unwanted by California law |
just re-read your comment. i think we mean two different thinks: with "opt out link" i meant the "do not sell my personal data" link (the link that opens/shows the opt-out page), not the link that performs the actual opt out. basically the question is whether we want to separate between the four states: a) the "potential" to see the notice (by having the do-not-sell-link on the page, some websites seem to see this as sufficient and do not show any overlay/notice unless you click that link) as for the "illegal": |
The latest proposal is now that we have event listeners in GPP (see #55 ); we can mirror the eventStatus codes from TCF v2 spec. This means that a page can signal with eventStatus 'useractioncomplete' that an auction is 'ready to go' in say California, even though cmpDisplayStatus may remain 'visible'. 'tcloaded' could become 'gpploaded' See eventStatus codes from TCF at https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20CMP%20API%20v2.md#addeventlistener |
Hi, IABTechLab/iabgpp-es repository seems to already use TCF v2 events behavior, can I trust it ? |
@thcolin-bricks no, the naming & logic is not final yet |
Resolves issue InteractiveAdvertisingBureau#37
Under TCF EU the event status tcloaded / useractioncomplete were used to determine when the end of the user activity is reached. With the current GPP events, there seems to be no similar thing. Can one assume that the following is correct?
TCF "tcloaded" equals to GPP's:
cmpStatus = "loaded" + cmpDisplayStatus = "disabled"
TCF "cmpuishown" equals to GPP's:
cmpStatus = "loaded" + cmpDisplayStatus = "visible"
TCF "useractioncomplete" equals to GPP's:
cmpStatus = "loaded" + cmpDisplayStatus = "hidden"
Especially the last case seems not to be 100% accurate since there are case when the CMP is loaded but the interface is not yet loaded (but will load in a few moments).
In order to make it more clear, I'd propose to update the Ping Status Codes and separate the codes of cmpDIsplayStatus into:
The text was updated successfully, but these errors were encountered: