Skip to content
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

[Master feature] Substitution variables for amp-consent #15267

Open
rudygalfi opened this Issue May 14, 2018 · 11 comments

Comments

@rudygalfi
Copy link
Contributor

rudygalfi commented May 14, 2018

This feature will enable a publisher to incorporate amp-consent related status information via AMP's substitution variable framework (originally proposed here).

  • AMP_CONSENT_STATUS(consent-name)

@rudygalfi rudygalfi added this to the New FRs milestone May 14, 2018

@rudygalfi rudygalfi added this to Feature Backlog in AMP HTML Project Roadmap via automation May 14, 2018

@lannka lannka self-assigned this May 16, 2018

@lannka

This comment has been minimized.

Copy link
Collaborator

lannka commented May 16, 2018

Tracked here #14916

Let me know if it's for different thing.

@lannka lannka closed this May 16, 2018

AMP HTML Project Roadmap automation moved this from Feature Backlog to Done May 16, 2018

@harshvcs

This comment has been minimized.

Copy link

harshvcs commented May 17, 2018

@lannka: With #14916, will there be a way for the publisher to always fire the request to a specific vendor along with the consent status (via a variable in vendor.js configuration) so that the vendor can take action on their end?

@lannka

This comment has been minimized.

Copy link
Collaborator

lannka commented May 17, 2018

Yes, as long as there is a status. The amp-analytics will be held from firing, until user accept/reject/dismiss.

@jasti jasti reopened this May 24, 2018

AMP HTML Project Roadmap automation moved this from Done to In Progress May 24, 2018

@jasti jasti added this to To do in Consent Tools May 29, 2018

@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

ampprojectbot commented Jun 5, 2018

This issue doesn't have a category which makes it harder for us to keep track of it. @lannka Please add an appropriate category.

@erwinmombay

This comment has been minimized.

Copy link
Member

erwinmombay commented Aug 21, 2018

This issue doesn't have a category which makes it harder for us to keep track of it. @zhouyx Please add an appropriate category.

3 similar comments
@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

ampprojectbot commented Sep 11, 2018

This issue doesn't have a category which makes it harder for us to keep track of it. @zhouyx Please add an appropriate category.

@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

ampprojectbot commented Sep 25, 2018

This issue doesn't have a category which makes it harder for us to keep track of it. @zhouyx Please add an appropriate category.

@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

ampprojectbot commented Oct 16, 2018

This issue doesn't have a category which makes it harder for us to keep track of it. @zhouyx Please add an appropriate category.

@zhouyx

This comment has been minimized.

Copy link
Collaborator

zhouyx commented Oct 16, 2018

I would love to understand the requirement here in terms of prioritization. We should be supporting this upon request, but not sure if the feature is still widely requested with the data-block-on-consent to block <amp-analytics>, and with the onAcceptHref and onRejectHref support. Please let me know what is the use case here, and I can go ahead and prioritize the work here.

@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

ampprojectbot commented Jan 24, 2019

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

@zhouyx

This comment has been minimized.

Copy link
Collaborator

zhouyx commented Feb 4, 2019

We will be prioritizing the work this sprint.

Design decisions:

  1. CONSENT_STATE will resolve asynchronously, which means all requests that include this macro will not be sent out until user response. The latest consent status will always be used.
    Note: The user may change their consent after the macro resolve.

  2. The CONSENT_STATE provides five supported states.

  • accepted: User accept or has accepted the consent
  • rejected: User reject or has rejected the consent
  • dismissed: User interact with the consent prompt, but no more information
  • unknown_not_required: No local user consent info found, no consent is required according to server endpoint or geoLocation
  • null: No <amp-consent> component or script on the page
  1. Consent string support will not be added. The feature to send/drop request based on consent state will not be added.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.