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

Increase CMP consent storage size #31673

Closed
janwinkler opened this issue Dec 18, 2020 · 14 comments · Fixed by #34054
Closed

Increase CMP consent storage size #31673

janwinkler opened this issue Dec 18, 2020 · 14 comments · Fixed by #34054

Comments

@janwinkler
Copy link
Contributor

This is a followup on ticket #24464:

The storage size is now increased to 1200 characters for the consent information. unfortunatelly the google additional consent information is not stored in a compressed way and therefore results in a very long string. for most publishers both (TCF v2 string and additional consent string) are important for their monetization. Hence the feature request is to

a) further increase storage size for consent information
or
b) separate storage size rules for each part (e.g. 1000 chars for tcf tcstring and 1000 chars for google add.consent string)
or
c) compress the information that is in the google additional consent string (e.g. similar to the bit-logic in TCF)

@jawadst
Copy link

jawadst commented Dec 18, 2020

+1 here from Didomi ; this is a big blocker for using additional consent on AMP

I think c is the best option (not just for AMP) but I'd assume it's outside of the AMP scope. Using a separate storage would fix the issue for now and allow for optimizations from the Google Ads side once/if they switch to a more compressed format for the AC string.

@a2intl
Copy link

a2intl commented Jan 27, 2021

+1 here from Quantcast, we're getting several publishers who are running into this issue with Choice. We're having to tell them to just turn off Google Additional Consent mode for AMP for now.

@tla-sirdata
Copy link

+1 here from Sirdata
As a workaround, we're recommending publishers to limit the Google Additional Consent providers in their CMP but it doesn't always work.
I also agree with the c) option but I think Google should be responsible for this in the first place, thus they could propose a new way to encode the AC string that we could use in all environments.

@dpetrieldn
Copy link

+1 from News UK. This is an issue for us, limiting how we monetise AMP and the vendors we have in our lists. The options above shouldn't necessarily be mutually exclusive.

@davidpmolloy
Copy link

+1 from Bauer Media. Arguments are the same as above

xavierleune added a commit to xavierleune/amphtml that referenced this issue Apr 21, 2021
The current limitation of 1200 chars is already too small for most publishers.

Here is the projection we used to update this storage:
- 1000 publishers in the global vendor list, using publisher restrictions: the size of the consent string should be of 3233 chars.
- The current additionnal consents strings, stored in the metadata field of the consent object, is 3079 chars long

This leaves an empty space of 688 chars, to the other data stored in the object.

Fixes ampproject#31673
@xavierleune
Copy link
Contributor

Hi there,

As it seems that this bug had a lot of traction from CMP and publishers (including the one I'm working for: CCM Benchmark - Le Figaro) but not much from the AMP Project, I created a pull request with a target of 7000 chars. Feel free to add a comment on the pull request to discuss the target storage length,

Thanks,

@micajuine-ho
Copy link
Contributor

HI all, sorry for the delayed response. We are actively looking for solutions to this problem. We understand that it is a very large problem for CMPs and are looking to remedy ASAP.

As for increasing the limit to 7kb, as seen from this comment #24464 (comment), it needs coordination with the viewer team or else it won't work either.

@xavierleune
Copy link
Contributor

Hi @micajuine-ho and thanks for your feedback. Can you make sure to raise the real needs up to the viewer team ? I'm sure it's a pretty small change for the team, all we need here is goodwill from Google. This issue has an impact on revenues for publishers & for Google.

@micajuine-ho
Copy link
Contributor

After chatting with the Google Viewer team, it looks like they have changed their implementation and no longer have this 2KB per domain localStorage restriction.

Therefore, I think we can remove the client-side storage restriction as long as other viewer teams are on board (@ssantosms for Bing Viewer).

We are looking to implement this change in a few weeks to give other Viewer teams time to discuss these changes and make any changes if needed.

@xavierleune
Copy link
Contributor

Thanks for the update @micajuine-ho. However, 2kb is not enough. My pull request changed the limit to 7kb. Is there anything wrong with the numbers I provided ?

@micajuine-ho
Copy link
Contributor

Hi @xavierleune, I think you might have misunderstood my comment:

it looks like they have changed their implementation and no longer have this 2KB per domain localStorage restriction.

therefore, we would remove the current client-side restriction entirely. Does that make sense?

@xavierleune
Copy link
Contributor

Yes indeed, sorry about that. That's a great news! Thanks for your help 👍

@xavierleune
Copy link
Contributor

Thanks a lot @micajuine-ho !

@xavierleune
Copy link
Contributor

Hi, for the records I don't see any errors related to the consent string storage in the viewer now :) Thanks for your help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment