TCF error 3.3

[Lakshman Chilukuri]

I have started getting the tcf error 3.3 recently which to my knowledge is related to consent status not being refreshed every 13 months. 

In UMP I call the ConsentInformation.getConsentStatus() in every session. Shouldnt this API take care of rolling over the consent status every 13 months. Is my intervention required? 

Thanks

[Mobile Ads SDK Forum Advisor]

Hello Lakshman,

 

Thank you for reaching out to us.

 

With regards to your concern, yes. Your intervention is required. You are required by IAB TCF policy to remind users about their consent choices at least once every 13 months. If the consent decision is more than 13 months old, the TC string will no longer be considered valid by Google and Google will not serve ads to that user. We suggest that the CMP should delete the old TC string and reobtain consent.

 

If you wish to learn more about this, you can refer to our guide.

 

Regards,

Zoilo Isagani Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2hxUr9:ref

[Lakshman Chilukuri]

Thank you for your response. But how do I get information on when the consent was last given? Thanks.

[Mobile Ads SDK Forum Advisor]

Hello Lakshman,

 

With regards to your concern, have you tried Troubleshooting TCF v2.0 implementation or setting up Privacy & messaging? If not yet, I would recommend to check that troubleshooting article that might be able to help you remove this error in your account. In addition to that, I've seen this forum thread related to your concern, and one publisher shared there a possible fix on this error. Kindly note that policy error is out of our scope. What we can recommend is to try reaching out to the Product Support Team.

 

If you have any further inquiries, feel free to reach out to us.

[Andreas]

Zoilo,

I did not share "a possible fix on this error", but a workaround for your constantly failing system. Suggesting that "the CMP should delete the old TC string and reobtain consent" if it is your CMP that fails to do the very thing that you are suggesting is the weirdest thing I've heard a Googler say in quite a while.

[Mobile Ads SDK Forum Advisor]

Hello Andreas,

 

Thank you for your valuable feedback and we appreciate your contributions to the forum. As we mentioned mostly to the publisher, the error 3.3 is already out of our scope. What we can only provide are the Troubleshooting TCF v2.0 implementation or setting up Privacy & messaging, and by reaching out to the Product Support Team.

[Andreas]

Zoilo,

the "User Messaging Platform SDK" is a CMP product developed and published by Google as part of its AdMob outing. You can read about all of it here, and it is very obvious from the URL that it is, in fact, a logical part of AdMob: https://developers.google.com/admob/ump/android/quick-start

How can it be "out of your scope" as Google representatives in a forum that is supposed to be useful for "Google Mobile Ads SDK Developers" to talk about one part of your AdMob outing?

What other points of contact do you offer to get in contact with actual Googlers about actual shortcomings of Google products? I wouldn't count the last resource you linked as such, because it is clearly labeled as asking "the community".

[Mobile Ads SDK Forum Advisor]

Hi Andreas,

I work along with Zoilo. Let me do the best I can to assist you in this.

As per your concern with the UMP SDK, it is indeed that was part of the Mobile Ads SDK (AdMob or Ad manager) developer doc, but please do note that this is a different SDK. The Mobile Ads SDK utilizes the UMP SDK to get the consent of your users. However, it does not mean that it is totally out of scope to our team. Thank you for pointing this out to.

Moving on to the TCF error 3.3 that you're having, the suggested action is CMP should delete the old TC string and reobtain consent. What it means is that you will need to ask your user's consent once again. You can do this by resetting the consent state. Unfortunately, the SDK does not expose the information on when the consent was last given to your user, so you would need to implement a storage inside of your app that will track when was the consent was given (with consent status OBTAIN), then trigger the resent consent when it is past the configured date (let's say 13 months as per this troubleshooting guide).

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2hxUr9:ref

[Andreas]

Teejay,

now that we've established that it is indeed a Google product that doesn't work as developers expect - and that responsibility for that product lies somewhere in the Mobile Ads branch of Google - can we perhaps get a feature request forwarded to the relevant Google team?

1. Google UMP is a "Consent Management Platform".

2. Managing consent includes reobtaining consent after 13 months, as mandated by the actual TCF legalese.

3. Google UMP should include functionality that checks whether consent needs to be reobtained on each startup - and if this is the case, do this automatically as soon as possible.

4. If this cannot be added to Google UMP, at least documentation should be properly updated with what Google UMP can (and mostly can not) do, instead of having us second-guess for now approaching three years.

[Mobile Ads SDK Forum Advisor]

Hello Andreas,

 

We thank you and appreciate your valuable input. We will now be forwarding your concerns to the wider team for request to UMP. You may keep an eye to our blog for any future updates on this.

 

Regards,

Zoilo Isagani Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2hxUr9:ref

[Lakshman Chilukuri]

I am not at all feeling comfortable with this whole approach. I am sure this must be trivial for G to fix. I am loosing revenue every day and I don't know how to go ahead. The other option is to not use UMP at all.

[Mobile Ads SDK Forum Advisor]

Hello Lakshman,

 

Currently, Troubleshooting TCF v2.0 implementation is the only approach that is available. We understand your concerns and we're working on improving this. As suggested by Andreas, we have submitted this as a Feature Request. You may keep an eye to our blog for any future updates on this.

[Andreas]

Hi Lakshman,

you are completely right about your concerns. This is something that is affecting many of us negatively, and is easily fixable on Google's end if they would just get some intern to work on it for an afternoon. Realistically, though, you shouldn't expect any changes soon. Google UMP hasn't been updated in now over 2.5 years, and we've been discussing this exact AdMob error "3.3" on this forum for probably half a year without any changes. I've personally heard their line about "keeping an eye on the blog" more than once as well.

If you realistically can, you should probably stop using UMP and instead adopt some other solution.

If you can't and are looking for a workaround (or at least need something for the short term, before being able to implement something else), my solution that has been referenced above is to decipher the date of consent in one of the configuration strings stored in shared preferences by UMP, and just delete the whole string if that date is older than a year, hopefully giving you enough time before reaching the 13 months threshold.

You can find working solutions for Android, both Kotlin and Java, here: https://github.com/bocops/UMP-workarounds/tree/main/detect_outdated_consent. I can't provide anything for other platforms, but the code should be relatively straightforward to understand. The code is licensed under CC0, so you can just copy whatever you need and run with it, no attribution necessary. :)