-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
[Discussion] <amp-consent> TCFv2 Support #26229
Comments
@AmazonPublisherServices @leonardlabat @bretg @wroberts-comscore for feedback since you have dealt with CONSENT_STATE and CONSENT_STRING in AMP. @yoannOgury @PierigOgury @andresilveirah @jawadst @tla-sirdata for feedback from CMP Thank you! |
Prebid Server receives RTC calls from AMP. We find it sub-optimal to have to introspect CONSENT_STRING, which could be formatted as a TCF1.0 or CCPA string. Would it be possible to add a "CONSENT_TYPE" attribute which the CMP can add to provide a clear signal on how the string is formatted? Valid CONSENT_TYPE values could be: TCF1, TCF2, USP, etc.
Speaking for Prebid, if we had CONSENT_TYPE, we'd be happier parsing strings. We do it already in Prebid Server. In fact, we don't currently use the AMP CONSENT_STATE -- we assume that the user consent state is already encoded in the string. It's unsatisfying and won't scale well to parse the consent string with a set of rules like:
|
Thank you @bretg for the feedback. |
In non-AMP pages, there are different IAB functions in the page that serve as the interface. For GDPR, the ad tech javascript infrastructure calls window.__cmp(). For CCPA it's window.__uspapi(). So because these separate interfaces exist, it's quite clear to the ad ecosystem how to parse the results of the call. Being on the vendor end of RTC is quite different - we're not making the call to the CMP ourselves so don't have the context. FWIW - prebid.js requires that publishers turn on GDPR and USPrivacy and let it know which specific interfaces to use. e.g.
|
As a CMP first option seems attractive, it will give us more flexibility, each vendors will be able to use the exposed api or the consent string, without any specific intégration for AMP, it is the idea behind tcf implementation. On AMP side, the second option will need less engineering and is clearly more safe technically, and dealing with CONSENT_TYPE seems a good simple solution . However it will force vendors to find a solution to be able to decode consent string, with one decoder by consent string type, it could be really painful for vendors, with some performances impact. Thats why as a CMP, we prefer the first option, but the second one works also with more impacts for vendors. In all cases, we think that AMP have to keep the hand on which kind of consent string can be provided through the amp-consent. At the same level as the CONSENT_TYPE remark, it would also be useful to be able to set multiple consent signals (in case of a CMP managing multiple framework/regulation with one notice to the end user) |
Not quite sure I understand you here @PierigOgury - are you suggesting that the existence of CONSENT_TYPE makes parsing harder? My take is that each RTC vendor has to have code to parse all encodings anyhow... having metadata about the encoding format just means no guessing. |
Hi @bretg , |
Thanks all for the feedback. After more discussion, the AMP team decided Option #1 is not very practical. As @PierigOgury pointed out it requires a lot engineering resources. Also it's not technically safe because AMP is not a registered CMP. Because of this we decided to stay with the current approach (Option #2) |
Re: I only have one concern, the |
Hi, I think the fact CMPs have no control on whether to display the UI is a problem. As a reasonable solution, CMPs could add an attribute in the check endpoint's response to indicate to AMP that we want to display the UI while keeping the existing consent string. About reading consent data, it would be indeed very convenient for vendors to call the standard APIs and not have to decode consent strings. The limitation I see in the actual integration is that CMPs can only transmit a consent string (and maybe a future consent type). The main idea is to provide CMPs a way to transmit more information (at page load and after user submit), the challenge being to give enough flexibility to CMPs while keeping a standardized AMP structure. |
Talked to @jeffjose offline. We agreed that AMP can provide such |
The only concern is user experience. @micajuine-ho @jeffjose and @lannka would like to get your thoughts on the tradeoff here.
We could provide an API for CMP to pass consent data object to vendors. AMP won't store the data |
Sorry @zhouyx, are you asking me to give my thoughts about the tradeoff here ? |
@zhouyx wanted to see where the AMP support for TCF version 2 stands. i'm having trouble understanding it's progress from this thread. |
@zhouyx Having worked with many vendors in the last months on TCFv1 integration with AMP, the main piece of feedback we have is that most vendors are still unclear on how they can get access to the consent string from their AMP tags. In particular, they are struggling with two elements:
We have tried to summarize all common cases on https://developers.didomi.io/cmp/amp/consent-status-for-vendors and https://developers.didomi.io/cmp/amp/blocking-behaviors but I'd recommend improving the AMP docs for vendors on that front for the V2. Happy to help if there is a way for us to contribute to the docs. |
@cmaurersp any specific detail you need? AMP attempts to support TCF v2 as a generic TC framework as best as we can. |
What do 3rd party CMPs need to do in order to support TCF v2 at this point in time? |
If you want to integrate your CMP solution with AMP. For example
Please follow the CMP integration guideline here. https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md |
We are creating a CMP for our publishers and would like to do an integration test locally before we actually create a pull request. How can we create a full working demo? Our demo looks like the following so far:
In Dev tools I can see a iframe being created loading promptUISrc, which is the standalone CMP. No errors reported. But the iframe is hidden and only a spinner is displayed. It's probably something I missed, could someone give me a hint? |
Hi we would like to integrate our TCF v2 CMP to AMP and have some questions :
Thanks |
Hi @saraneus. Thanks for your question. Your current implementation of adding your CMP to AMP seems a little off. To integrate into AMP as a CMP, you need to follow the CMP integration guideline here. https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md After following these steps, you can test locally with a consent element similar to this (replacing
Another hint is that
should be here under your new CMP name. Please let me know if you have any further questions. |
Hi @tla-sirdata, thank you for your questions.
This is still in the works. Please refer to #27907, and we can continue the discussion there.
To integrate into AMP as a CMP, you need to follow the CMP integration guideline here. https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/integrating-consent.md
I believe you are asking if there is someway to tell if the
@zhouyx correct me if I'm wrong, but I believe we decided on 60vh restriction due to the bad UX that would be created if users were to just see a fullscreen consent dialog. However, you can use our fullscreen API to enlarge the consent dialog. |
@micajuine-ho Thanks for your answers !
I'm talking about the CMP version a publisher chooses to use. Thanks |
@tla-sirdata Thanks for the clarification. As a CMP do you anticipate that having publishers using v1 and v2 will be a common use case for you? Something that we could do would be to include a CONSENT_TYPE field within the request to the CMP (in the checkConsentHref endpoint), that could be overriden by the inline publisher, but would otherwise default to the last CONSENT_TYPE stored in local storage. I don't think we currently have a clear cut solution for this. @zhouyx for ideas/confirmation. |
Thanks for reaching out. AMP does provide TCFv2 support. https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md#does-amp-support-the-iab-tcf Not directly via the Let us know if it work for you. And if not what's missing. Thanks! |
@zhouyx the latest version of the TCF library manages to compress the 8kb string to around 1.7, so we could fit the 2k limit which is also the safe limit for URLs and which could be a good threshold for AMP, up from the 1.2kb that's in place now. Could this change be made? I remember this would be your upper limit, and I'd go for it as it would drastically reduce the edge cases. |
@Facens Thanks for the information. Is the 1.7kb the upper limit for TC string now? Could you please refer me to the IAB doc. If it's going to stay like that, then I agree with we could revisit AMP's size limit. |
@zhouyx the string has no upper limit and could grow, but since 2000 characters is what's generally considered to be the safe maximum threshold in other contexts (e.g. URLs and legacy webservers/browsers), in Tech Lab we're making all possible efforts to shrink down and stay within that limit. I was giving 1.7k as a reference because it's at the moment a size that is reached in a relatively low but significant number of cases and can be a deal breaker for some large publishers when approaching AMP. My suggestion would thus be that you increase the size all the way to 2000 chars which as you referred to previously is the max that you can get to without refactoring, particularly since there's Google's additional consent mode string to fit in too. Please let me know if we're aligned! |
Hey, we talked about using google's CLIENT_ID to sync up with our internal consent uuids. I seem to be running into a problem with CLIENT_ID being different when the amp page is hosted off the publisher website vs. off the google.com TLD. e.g. but when you go to the publishers amp page of that same content in that same browser without clearing any cookies/local storage: www.publisher.com/amp/en-us/content-video-123 i think the expected behavior would be that the client id's would be the same, so we can properly sync up the client id with our user consent uuid. but because it is different, the consent preferences of the user does not persist. What is the best way to resolve this? because when amp pages are served off the google.com TLD, the cookies arent accessible when they go to a publishers page, so we are relying on google to provide a consistent CLIENT_ID |
Havent heard from you guys in awhile, should I create a new issue for the above? |
@vyoungnyc Sorry about that. Yes, it would be appreciated if you could create a new issue, so it's easier to track/discuss. Thanks! |
@Facens wrote:
Hi. I am the product leader for TCF at IAB Tech Lab. I'm getting a lot of questions about this AMP limitation on string size. Is it possible to make the change @Facens suggested in the quoted comment above? |
@alextcone Thanks for reaching out AMP has removed the consent string size limit when the Storage API is not used. That applies when the AMP page is served directly from the publisher's origin. Regarding to the AMP viewer case, this is a known technical restriction on AMP. We have expanded the consent string size limit to as much as we can support today. I can reach out to the AMP viewer team on potentially expanding the size limit (maybe by another 50%), but that cannot solve the size limit issue either. I was told that the current size limit could fulfill 95% of all use cases. If that's still true, I am leaning towards keeping the size limit unchanged. |
The PR has been merged. |
Hi @zhouyx . I'm creating an amp-consent solution for Quantcast CMP. I have pretty much all working by now, but I have a question. I saw that you can save a consentMetadata like this:
But how is that read from the |
Hi @nicobatalla, I assume since you're using |
@nicobatalla @zhouyx |
My understanding is not all vendors/publishers will support an IAB implantations so it is good to accommodate these cases. I also don't think this change would be a large and will not have an impact on performance. |
Taking about advertising everybody SHOULD follow the IAB (International advertising bureau) and if not - you force everyone to go your way, so why not here too, rely on IAB and force everybody to use it? |
@micajuine-ho @renebaudisch Thank you guys, I'm going to be following both issues. |
@nicobatalla #30820 has been merged. |
Hi @micajuine-ho do you have any update on the lightbox flow you were intended to implement ? Thanks ! |
Hi @tla-sirdata here is the PR (#29204), and the documentation can be found here. |
@micajuine-ho oh i completely missed this out! Thanks |
Hi all! FYI, we have gotten some asks to allow for CMPs to pass in a Here is the relevant issue. (#31144) Please feel free questions or concerns to that thread :) |
Hi all! The Currently, passing in |
Hi!
Has there been implemented a solution yet? I can't find anything in the docs except expireCache. Is it possible to give more control to the CMP? Right now AMP is in control of the CMP. But in my opinion the CMP needs to be in control of when to show the popup. Only the CMP knows about changes in the vendorlist and in our case the CMP can be configured by our users to control its behaviour. But all that can't work in AMP because the iframe is not loaded. A solution where the CMP always loads and takes control of AMP through APIs (show popup, close popup, update consent) would be very helpful. It should also be possible to store meta data with the consent string, i.e. the version of the vendor list or other information. |
Hi @opencmp, this sounds reasonable, can we create a separate GH issue for it? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
The Transparency and Consent Framework (TCF) is an effort to manage user consents, and have all parties understand the users consent information from regulations like GDPR.
Consent Management Platforms (CMP) helps sites to collect and manage user consent information in the TC data format. Today AMP allows a CMP to integrate with some limitations.
The
<amp-consent>
CMP integration was designed to work with any framework that is based on a consent string format.CMP scripts are executed in an CORS iframe that’s controlled by AMP instead of included as first party script. Because AMP handles the lifecycle of the iframe, CMPs don’t have flexibility on when to show its UI, or has the ability to provide mandatory APIs for vendors to get their TC data.
What has Changed
In the past year, the IAB TCF v2.0 has been widely adopted by most vendors. Unlike a year ago when we first designed the feature, now we don’t see the necessity to support other TC framework. This allows AMP to work together with CMPs to understand the TC data and TCF v2 APIs.
With more regulations like GDPR, we are seeing the increasing complexity for site owners to manage user consents. Thus we are seeing the trend to have more CMPs come into the area. That brings a lot more feature requests and many ask for feature parity between AMP and their non-AMP integrations.
Goal
The goal of the design revise is to come up with a solution so that
Proposed solutions
Option 1
Allow CMP script to run in the background, it will still run in a CORS iframe, but it will be initiated at pageload time and always run in the background.
This is very similar to the CMP, non-AMP pages integration as much as possible.
Details
__tcfapi()
method and send postMessage to CMP iframe__tcfapiLocator
directly using postMessages.Pros:
Cons
Option 2
This is the current approach. Pass the entire TC data consent string using AMP provided APIs
Design Details
context.initialConsentValue
getConsentPolicyInfo()
methodCONSENT_STRING
macroPros
Cons
To decide if we need to change the design, we'd like to get feedback from CMPs, Ad vendors, Analytics vendors and Publishers.
We are leaning towards Option 2 (The existing option) for performance reason. If so
cc @ampproject/wg-analytics @ampproject/wg-ads
The text was updated successfully, but these errors were encountered: