Amphtml: Support <amp-analytics> vendors to get consent status

[jasti]

Currently only amp-ad vendors are able to get consent status and we should allow analytics vendors to also know about the consent status so the analytics vendors can customize how they treat the user's consent action.

CC @lannka @rudygalfi

Master Issue: #13716

[harshvcs]

I have a question about this new feature. Will this be supported via an amp-pixel? Meaning, would it allow to include a new variable that reflects the consent status through the amp pixel? Will something like this work:

<amp-pixel src="https://foo.com/pixel?pid=PAGE_VIEW_ID&consent=NEW_CONSENT_VARIABLE"></amp-pixel>

[jasti]

I'm not sure that would be useful because the point of making the consent status available is to allow the vendor (amp-ad/ analytics) to decide if they even need to make the request. Setting consent state of amp-pixel would be too late because the request would have been made already.
CC @lannka

[harshvcs]

Thanks for the clarification! The feature will allow the publisher's amp-analytics/amp-ad implementation on their page to receive the consent value through some means (possibly a new attribute?) and based on that decide whether to fire the requests. Considering that, I am assuming there are two possible scenarios once this feature is out:

• If the feature is applied, it either fires the request(s) or doesn't fire them based on the consent.
• If the feature is not used, the requests will be fired irrespective of the chosen consent.

Can the feature allow one more scenario where the request is always fired allowing inclusion of a consent status through a variable with possible values being not-set, yes and no? These values can be expanded in future with purpose based consent. This gives flexibility to the vendor to obfuscate or discard the client information based on the specific consent status. This is where I was going with my question about amp-pixel as well.

[lannka]

Can the feature allow one more scenario where the request is always fired allowing inclusion of a consent status through a variable with possible values being not-set, yes and no?

Yes. This is how amp-ad right now is integrated. The request is blocked by the consent prompt, but once resolved, it will send request with the consent state.

We are considering to bring similar behavior to amp-analytics, but not amp-pixel, as amp-pixel is a built-in and lightweight extension. Any complicated business logic will be only available in amp-analytics.

[hikaru90]

Hi everyone,
so currently amp-consent blocks amp-analytics elements with the attribute data-block-on-consent and would require a page-reload to fire a pageview, right? Will this feature resolve this issue?

[rudygalfi]

@lannka @zhouyx For @hikaru90's question, can you clarify if the amp-analytics request gets queued up until the user accepts the consent or is it dropped if consent is not available when the request wants to be fired?

My understanding of this issue is that it's not meant to directly address timing of when the requests are fired. Rather, this issue is tracking having the infrastructure in AMP for analytics vendor integrations (those specified in vendors.js) to incorporate consent-based logic.

@harshvcs I believe you're proposing a new set of functionality. I filed #15267 to track it.

[zhouyx]

@hikaru90 Current amp-analytics requests will be dropped if consent is not available. pageview trigger won't require a page-reload. click trigger will be broken on the other hand.

[hikaru90]

Sorry @zhouyx, i didn't quite understand. Do you mean that:

• Currently all amp-analytics requests will be dropped if user-consent wasn't given beforehand? So whatever I do, a user visiting my site will have to reload the page after giving consent?
• And after this feature is implemented, the pageview trigger will work but the click trigger won't?

[zhouyx]

@hikaru90 Sorry for not being clearly.

How we implement amp-consent blocking behaviors is that amp-analytics will be blocked until user accept consent. All requests before user consent will be delayed or dropped. Trigger like pageview will be delayed while triggers like click will be dropped.

You won't need to worry about pageview trigger and that's the current behavior. Please let us know if this doesn't work for you. Thanks.

[harshvcs]

My understanding of this issue is that it's not meant to directly address timing of when the requests are fired. Rather, this issue is tracking having the infrastructure in AMP for analytics vendor integrations (those specified in vendors.js) to incorporate consent-based logic.
@harshvcs I believe you're proposing a new set of functionality. I filed #15267 to track it.

@rudygalfi That is correct. My request is not related to the timing of eventually receiving consent in the presence of data-block-on-consent attribute. The purpose is actually to allow the publisher to not use the consent attribute at all for a specific vendor so that the measurements are always fired. But, because of the capability of the proposed feature in #15267, the vendor can still get the consent status by updating the configuration in vendor.js, and act upon it. Thanks for creating a new issue to clarify this.

[hikaru90]

Thank you @zhouyx. Your explanation helped me a lot!
While working on my site I kept using the "Update Consent" Button from the postPromptUI because it is so conveniently placed on the bottom left side of the viewport. After reading what you wrote, I realized that it isn't a good idea to fire a pageview-request on an updated consent.

[jasti]

There was a bit of confusion while discussing, so just clarifying that this feature is meant to let amp-analytics vendors decide how they want to treat a user's consent action and this feature will provide a new substitution variable with the user's consent state that can be substituted on outgoing URLs being triggered from amp-pixel and amp-analytics.

[ampprojectbot]

This issue hasn't been updated in awhile. @zhouyx Do you have any updates?

[ampprojectbot]

This issue hasn't been updated in awhile. @zhouyx Do you have any updates?

[zhouyx]

Work has been merged and shipped.

[jacquelynwax-nytimes]

@jasti I see this work has long been completed and closed. We load a remote configuration in our <amp-analytics> element. We want to get consent state to the service that returns the tracking config to AMP, so that it can omit certain trackers from the returned config based on consent status. It's unclear to me whether the feature discussed here is meant to enable us to do that? If so, is there any documentation available about how to do it? (For example, our service returns a config for tracking events to GA and our in-house tracking system. We'd like the config returned by our service to, for example, exclude GA from the returned config but include our in-house tracking service for a user who has rejected consent.) Is this possible?

[zhouyx]

Could you try embed the CONSENT_STATE macro in the remote url. For example
<amp-analytics config="https://yourendpoint.com?analytics&consent=CONSENT_STATE">

[jacquelynwax-nytimes]

Hi @zhouyx. Many thanks for the response. We've tried embedding the CONSENT_STATE macro in the remote url, but it doesn't resolve. My read of documentation on <amp-analytics> was that CONSENT_STATE was available only in requests configured to fire in the in the config object (which in our case is fetched via the remote url), as you illustrated in your example here https://github.com/zhouyx/amphtml/blob/master/examples/amp-consent/amp-consent-client.html#L128.

[zhouyx]

Hello @jacquelynwax-nytimes
Thanks for reporting this, it helped us locate an issue with the remote url. Some macros are not resolved correctly in the remote url, and it has been fixed by #28174.
You should be able to see the fix and pass the resolved CONSENT_STATE value in two weeks. Thanks

[jacquelynwax-nytimes]

@zhouyx That's wonderful news! Many thanks.