Closed goncalosilva-appgeneration closed 11 months ago
It looks like CPM has changed version format from 2 to 3 and this is the first character, that is why C
became D
. But I think the format for TCF v2.2 has not been changed, it still should be 2
and what is changing is policy version to 4 see the doc here
Exactly, I thought I was going insane here. All the sources I looked at didn't mention changes for the "core version" in TCF v2.2 (the C/D characters).
With the exception of the invalid "core version", the rest of the encoded information is consistent with selecting "Consent All" on the form. It doesn't seem to be missing anything
I will close this bug report and reach out to the Google UMP team. Thanks for the help!
I will close this bug report and reach out to the Google UMP team.
Hi @goncalosilva-appgeneration, I'm facing the same issue with tcString not being decoded. Do you have any feedback from Google UMP ? Thanks.
Hi @LagoonProject and @goncalosilva-appgeneration I have this issue as well (the new "D" character in tcf v2.2 with the google ump). Is there any progress on this?
I assume the workaround there is simply to update the lead letter from "D" to "C", @sevriugin, right?
Thanks in advance
Gonçalo has posted this issue on the Google AdMob Developer forum: https://groups.google.com/g/google-admob-ads-sdk/c/BbrnlqAxev8
The thread has only got a text block answer so far from the moderators.
I had just replied all there to clarify that this affects all platforms and all users of Google UMP and needs to be investigated and fixed ASAP, but my message has just got deleted.
I've opened a support ticket via the AdMob help center now.
@martinpraznovskypp, just replace the lead letter from "D" to "C".
@LagoonProject I don't have feedback from Google yet.
Although the issue is very obvious, I sent them an Android Studio sample through the AdMob Developer form and described the issue in detail - it's not showing yet because it's pending approval.
But I'm starting to doubt they're going to fix this in a short amount of time. I'm not even sure their internal dev team knows about this.
I've got a response to my support ticket from AdMob support today, they're investigating the issue.
oh god what a mess :-(
I've got a response to my support ticket from AdMob support today, they're investigating the issue.
Unfortunately they just bounced it as SEP: https://groups.google.com/g/google-admob-ads-sdk/c/BbrnlqAxev8/m/X6TcGdP3AQAJ
@nhc-motosumo Yeah, forget the developer forum. I've found a way to open a real support ticket through the AdMob help center. After that I've got an email, that they're investigating it. Received no further updates after that so far though.
AdMob support now says the issue has been fixed, the invalid consent strings should be automatically invalidated and the affected users will be prompted for consent again. So far, I was able to confirm this on one of our sites.
I can also confirm this, just received the v2.2 form and it generated a valid consent string.
Good news, thanks a lot, guys 🔥
Awesome! Thanks for following up on this :pray:
Version 1.0.0
Module (core, cmpapi, cli, stub, or testing) core
Describe with reproduction steps – What is the expected behavior?
I got the string above after using Google UMP on Android, and reading the resulting TCString from local storage. Strangely enough, if I change the first characters from DP1 to CP1, parsing occurs without issues. Is this a new format? I can't find information about it anywhere.