amp-consent: Pass custom data to onUpdateHref

[heikostaab]

We would like to pass custom data via AMP's request to onUpdateHref, so that we can receive more information about the CMP's state.

This code triggers the request to onUpdateHref:

window.parent.postMessage({
            type: 'consent-response',
            info: consent.tcf,
            action: 'accept',
            consentMetadata: {
                consentStringType: 2,
                gdprApplies: true,
                additionalConsent: consent.google
            }
        }, '*');

I tried to add more properties to "consentMetadata" but with no luck.

We would appreciate if AMP could add a custom property which holds proprietary data that are sent to the url configured in onUpdateHref. Thank you!

[micajuine-ho]

Hi @opencmp, thanks for your issue report.

We would like to pass custom data via AMP's request to onUpdateHref

onUpdateHref is meant to act as a way to update your servers but not pass data back to AMP.

I tried to add more properties to "consentMetadata" but with no luck.

Currently, only specific fields are allowed to be passed in consentMetadata.

We would appreciate if AMP could add a custom property which holds proprietary data that are sent to the url configured in onUpdateHref.

What type of data are you looking to pass to onUpdateHref?

[heikostaab]

Hi @micajuine-ho
We appreciate your interest.

Our intent is to track the user's actions when surfing the CMP, i.e. was a consent string created before, which button was clicked etc. This information we could send to AMP via postMessage when accepting/rejecting consent, so that AMP can pass this information further to onUpdateHref which is a small Worker. This Worker can then store this information somewhere to be analysed later..

onUpdateHref does not need to pass data back to AMP, my explanation was a bit confusing trhere.

The idea is to do that:

window.parent.postMessage({
            type: 'consent-response',
            info: consent.tcf,
            action: 'accept',
            consentMetadata: {
                consentStringType: 2,
                gdprApplies: true,
                additionalConsent: consent.google
            },
            customMetadata: {
                buttonClicked: "accept",
                firstVisit: false
            }
        }, '*');

Why do we want to this?
We are sending tracking information via XHR when the user clicks on the "Agree" button. After clicking, the postMessage is sent and amp-consent removes the iframe immediately which cancels the XHR request, so that the tracking information is not sent. If we can solve this problem we wouldn't need to use onUpdateHref for tracking any more.

Any thoughts?

[micajuine-ho]

Since the iframe belongs to you, why not just send that custom metadata to the onUpdateHref endpoint?

i.e:

<button id='a' onclick="sendMessages()">Accept All</button>

function sendMessages() {
   sendConsentAcceptToParent();
   sendCustomMetadataToOnUpdateHref();
}

[heikostaab]

@micajuine-ho Because after accepting the consent, amp-consent immediately closes the iframe which interrupts all requests.

[micajuine-ho]

Because after accepting the consent, amp-consent immediately closes the iframe which interrupts all requests.

The iframe tells amp-consent when to close by sending an accept post message:

window.parent.postMessage(
  {
    type: 'consent-response',
    action: 'accept',
    info: /string/ /* optional */,
    consentMetadata: /object/ /* optional */,
  },
  '*'
);

So before that javascript is triggered, why not send data to the onUpdateHref endpoint?

[heikostaab]

Because there would be a delay between clicking and closing the amp-consent layer. We would like to have the layer close instantly.

[micajuine-ho]

/cc @zhouyx Do you have any ideas for this?

[zhouyx]

AMP closes the iframe immediately to avoid having iframe running in the background. Passing the customMetadata back to AMP would work, but I don't think that's a generic enough solution.
At some point, other CMP iframe will also want to run their own piece of code after the user consent has been resolved.

I'm seeing a few options here

1. As suggested, pass custom data to onUpdateHref, may need to support other CMP's special use case later.
2. Closes the iframe after a timeout. (1 second)
3. Allowing the iframe to run in the background.

Option 3 will require more discussion and review. I think maybe we can go with option 2. If so what is a good timeout value for you? @opencmp

[heikostaab]

@zhouyx I would go with Option 2 and 1 second as default timeout. This is the quickest solution and doesnt interfere with Option 1 which could still be implemented later if needed. Option 3 might just be a special case of Option 2 with the timeout set to infinite.

If you decide to implement Option 2, when will the release be available?

[zhouyx]

AMP doesn't allow cross domain iframe running in the background. But I find this a special case to make an exception for a few reasons.

1. The iframe is created by <amp-consent>, and only one such iframe is allowed.
2. The iframe doesn't always run in the background. It's a consent prompt and we're only proposing to have it run in the background for an additional of certain time.
3. User experience is better (User click -> close consent dialog -> send requests -> close iframe is better than user click -> send requests -> close consent dialog -> close iframe)

I'd like the team to review this exception before I work on the change. Once approved, the change should be trivial. The release usually takes 2 weeks.

[zhouyx]

Feedback from design review.

We agree that sending the requests in the background, and not blocking the user is best practice.
The CMP iframe is also not a strictly background iframe, because user has interacted with it before turning invisible.
The iframe will be able to run for an additional of 1 second in the background before being removed from the DOM. The team believe 1 second is a good amount because sendBeacon is now widely supported.

[zhouyx]

@opencmp the change to implement Option 2 has been merged. You should be able to test via nightly build tomorrow, and expect the change to ship to stable in 2 weeks. Thanks