On an AMP page that uses <amp-ad> and <amp-consent> component to manage GDPR consent, we would like to have the ability to block rtc calls and serve npa ads when an EU user accepts to opt-in into data tracking.
Currently the way <amp-ad> and <amp-consent> are working is:
- Accept: full ads + rtc calls on
- Unknown: npa + rtc calls off
- Reject: npa + rtc calls off
The way we would like it to work is:
- Accept: npa ads + rtc calls off (when explicitly giving some extra config flag to serve npa ads with rtc calls off)
- Unknown: npa + rtc calls off
- Reject: npa + rtc calls off
The reason we want to do that it's because for GDPR the solution that best fit us as per our legal team recommendations was that when an EU user's preference is accepted we should serve npa ads and the header bidders should be off. We enable our header bidders through rtc calls so that's why we want to have the ability to shut down rtc calls on an accepted consent preference.
So far the way we serve npa ads is through the data-npa-on-unknown-consent="true" flag on <amp-ad> meaning that when the EU user has unknown or rejected consent it would serve npa ads. We also have the data-block-on-consent flag set to default on <amp-ad>.
The solution we propose is to have some additional config flags on <amp-ad> that allow us to set npa ads and turn off rtc calls explicitly when the user give the accept preference to <amp-consent> .
One of the alternatives we considered was set the data-block-on-consent flag for <amp-ad> to _auto_reject so no matter what preference the user had, we were expecting that for the <amp-ad> component it would be auto-rejected and npa ads and rtc calls would be off. But when testing that approach it didn't work that way, when we expressed the accepted preference it served full ads + rtc calls on.
None.
Hi @jpolanco91, sounds like you want to serve npa ad and turn rtc off regardless of the amp-consent decision.
Can I ask if you would need the consent prompt UI or the <amp-consent> component?
Hi @zhouyx, thanks for replying. We need both promptUI and <amp-consent> component because we use the user's consent decision for the tracking part in <amp-analytics> config url. We append that consent decision through the CONSENT_STATE macro so the internal API we use to provide tracking config for AMP pages, can provide the user's tracking based on the user's decision.
I see. That makes sense. In that case I agree _auto_reject doesn't work.
I see two solutions to this, one provided by the <amp-ad> and the other provided by the <amp-consent>
data-npa=true option, when specified always serve non personalized ad.Pro: Easy to configure. Also allow serving non personalized ad without <amp-consent> component.
Con: Not able to customize the npa setting based on the geolocation.
Or
<amp-ad> versus <amp-analytics>. A granular consent decision could potentially help here.@lannka @micajuine-ho would like to get your idea on this.
Since npa is an ad specific request. We could have the ad provide an data-npa=true option, when specified always serve non personalized ad.
With this solution, amp-consent would be used purely for the amp-analytics macro to determine the type of user tracking done, and npa ads would always be served via the data-npa=true option. Does this sound right @jpolanco91?
@micajuine-ho yes sounds good to me. So this mean that we would be combining data-npa-on-unknown-consent="true" and data-npa=true for the case I explained above or just data-npa=true ?
@jpolanco91 Will get to prioritizing this work soon.
Edit: /cc @ampproject/wg-ads Do you think this is a valid request to warrant a new data-npa=... attribute?
@micajuine-ho Thanks. Let me know if any questions/updates
Discussed offline with the ads team; they like the idea. I will begin to work on a doc to flesh out the idea.
@micajuine-ho great. Do we have a sense of the timing on this ?
Not quite, I will keep you updated with the progress.
@micajuine-ho thanks
Hi @jpolanco91, am I correct in assuming that there's no case in which you would want some ads on the page to be NPA and other ads to not be NPA?
@micajuine-ho yes your assumption is correct. And sorry for the late reply I was out of office for a week.
Hi @micajuine-ho - I am working alongside Juan on this issue. Can you provide us with an update please?
Hi @kelseyjohnson8 and @jpolanco91, sorry for the delay. I have created a doc for this feature and I am still getting feedback. I will share it here once it's in a good state.
Thanks @micajuine-ho ! Erwin M on the AMP Slack Project said to ask you when you are doing the design review, so that @jpolanco91 and I can attend and give feedback in person. Can we coordinate that when you are ready?
I have not signed up for design review yet. By next week will have the document in a good place to share it and get your feedback.
@kelseyjohnson8 @jpolanco91 Hi there, iiuc, for your pages, you would always like this feature regardless of the location of the user. Is this assumption correct, and if so do you see a use case in the future where you would only want this feature in select geolocations?
Also, I'd like to discuss the design with you this week. Can you email me at [email protected] to set up some time on our calendars?
@micajuine-ho my understanding so far is that the feature should work regardless of the user's location, at least with GDPR (EU). However I'll consult with @kelseyjohnson8 to see if there are future regulations that might require the ability of activating this on selected countries
@micajuine-ho Confirming what Juan said. We want the feature to be built in a way that it could potentially be used with anyone! We don't want to limit it to a specific geolocation.
@micajuine-ho And I'm emailing you now to set up time. Thanks!