Please help , ADMOB , IAB TCF v2.0 errors detected We've detected an issue on your IAB TC string

[nirha...@gmail.com]

Hello, Im sending again our issue . We plan to run Google ADS campaigns but it is pointless  until we solve this, so please help.

Everything worked fine, but suddenly we have error in ADMob Console:

IAB TCF v2.0 errors detected We've detected an issue on your IAB TC string on one or more of your sites or apps. These errors may affect your ability to serve ads to European users. A detailed report is available for you on the EU user consent page.



In Details:

Mobile App,Ad unit,Error,Error count,Last detected date

Unknown,9999657645,3.3,120,4/8/2023

Unknown,7666327715,3.3,40,4/8/2023
 
Thanks in advance

[Andreas]

Error 3.3 means that the consent string is outdated (older than 13 months) and your Consent Management Platform (CMP) should reobtain consent from your users: https://support.google.com/admob/answer/9999955?hl=en

Which CMP do you use?

[Mobile Ads SDK Forum Advisor]

Hello Nire,

Thank you for reaching out to us.

It appears you are encountering a Error 3.3. You can read more about this in this link https://support.google.com/admob/answer/9999955?hl=en#zippy=%2Cconsider-re-consenting-users-with-tc-strings-that-will-not-monetize-errors-and. The TC string last updated date was more than 13 months ago. To fix this error, the suggested action in consent management platform (CMP) is to delete the old TC string and reobtain consent. What this means is that you will need to ask your user's consent once again. You can do this by resetting the consent state:

• iOS - https://developers.google.com/admob/ump/ios/quick-start#reset_consent_state 
• Android - https://developers.google.com/admob/android/privacy#reset_consent_state

You may also determine if a message needs to be displayed:

• iOS - https://developers.google.com/admob/ios/privacy#display-message
• Android - https://developers.google.com/admob/android/privacy#display-message

After doing this, the TCF error 3.3 should be fixed. Feel free to reach back to us if you have any further inquiries.

@Andreas - Thank you for the additional information. Let us know if you have any concern with regard to Mobile Ads SDK.

Regards,

Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2kU6SG:ref

[nirha...@gmail.com]

Hello, I checked it,  Thank you very much for your support,

We use plugin EasyADS pro  for Unreal Engine for monetization, so I suppose we need to ask plugin publisher for support.

Is there any way to avoid update of apps because of our other projects and would require a lot of time to adopt to newer version of UE.

Thank you

Nire

[nirha...@gmail.com]

Hello Andreas,

 thank you for support , as I mentioned we use EasyADS pro plugin for Unreal Engine. 
The most probably we need to ask Plugin developer for help

Best Regards

[Mobile Ads SDK Forum Advisor]

Hi Nire,

Thank you for your response.

With regard to your question in avoiding updating of apps, if you're referring to the SDK version of the Mobile ads SDK, we always recommend to use the latest SDK (https://developers.google.com/admob/android/sdk) to avoid any errors that you might encounter if you're using older version. Since you're using a different plugin in your app, we suggested that you reach out to their support team to assist you further.

[nirha...@gmail.com]

Hi,

Thank you for support and advice, we contacted plugin publisher already and we will together solve this issue and eventually start running campaigns.

 Kind Regards

[Andreas]

It looks as if your plugin uses Google's Content Management Platform "UMP" ("Funding Choices"). This platform does not implement the minimum functionality required - platforms should automatically check for outdated consent and in that case reobtain consent. Google's solution does not do this, which is why this error starts appearing after about a year of use.

Their suggestion to use consentInformation.reset() is incomplete nonsense, because you (or the plugin developer) obviously can't go around and just reset every consent state it encounters - or your users would see a consent popup on every single use of the app. In order to reset the consent state only if absolutely necessary, you'd need the age of the currently stored consent - and Google's UMP doesn't offer a way to get that, either.

Some workarounds to get this to work are detailed here - you might want to forward this information to your plugin developer: https://github.com/bocops/UMP-workarounds

[nirha...@gmail.com]

Hello Andreas,

Thank you for help,

We already had conversation with plugin publisher, and we will make checking if Consent is older than 13 months than reobtain the Consent. Anyway we will check link you sent.

Kind Regards

Nirhan

[luongb...@gmail.com]

Hello Google Team,

Please let me know how to detect a TC string that is expired.
I cannot see any API for that.

[Mobile Ads SDK Forum Advisor]

Hello,

A TC string that's expired will be automatically detected when using requestConsentInfoUpdate() before loading a form. This can determine whether or not your user needs to provide consent if they hadn't done so already or if their consent has expired. You can refer to this document for more information: https://developers.google.com/admob/android/privacy#display-message.
 

This message is in relation to case "ref:_00D1U1174p._5004Q2kU6SG:ref"

Thanks,

 

Mobile Ads SDK Team

[Liran Barsisa]

The normal flow of `requestConsentInfoUpdate` is quite slow, so using a cached result and act accordingly is better.

Can you please show how to fetch the expiration date, so that we would use the cached result till then (or some time before)?

Someone told me to check here but not sure if this works well, and this function seems to also delete it as it claims there is a bug on the SDK of not handling it properly :
https://github.com/bocops/UMP-workarounds/blob/main/detect_outdated_consent/android/kotlin/detect_outdated_consent.kt

https://github.com/bocops/UMP-workarounds/tree/main?tab=readme-ov-file#:~:text=It%20is%20the,log%20an%20error.

Better yet, can you please make requestConsentInfoUpdate use the cached result instead of being so slow, and also make it use Context and not Activity, to allow doing it in the background (including Service) ?

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for getting back to us.

We regret the inconvenience caused. I understand that your query is related to Google's UMP consent policy. I would recommend reaching out to the Product support team as they are better equipped to address your concern. Please note that we can only assist with technical queries/concerns related to the Mobile Ads SDK.

This message is in relation to case "ref:!00D1U01174p.!5004Q02kU6SG:ref"

Thanks,
 

Mobile Ads SDK Team

[Liran Barsisa]

The SDK doesn't have those things, though. It's more of a request to change the SDK to handle caching automatically and/or offer to do it manually.

Here, created it there still:

https://support.google.com/admob/thread/248419165

[Andreas]

The link contains a workaround for a different bug of Google's UMP SDK, which led to "outdated" consent not being detected and thus the consent dialog never being shown again, which in turn led to no ads being displayed after about 13 months since the app was installed on a device. This is why the last line deletes the TCString, to force the consent dialog to be shown again.

In your case, you should not delete the TCString, but the rest of the logic might still work for you. If you reverse the last clause like this:

if (daysAgo < X) {
    // consent is less than X days old and should still be valid - do nothing
} else {

    // request consent info update only if consent is at least X days old

}

I say "might", because it is not completely clear to me how Google will detect actual usage of a CMP, which they claim will become mandatory in January next year. If it is sufficient for UMP to be initialized without any further calls, this should work. If it is necessary for requestConsentInfoUpdate() to be called on each app startup, this could be considered a lack of CMP use, which again will likely lead to no ads being displayed.

I agree that this is functionality that should be a part of the original SDK itself, and not something individual developers should have to spend time on.

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for reaching out to us.

I will check with our team regarding your query and one of my team members will reach out to you once we have an update on this. Meanwhile, your patience is highly appreciated.

This message is in relation to case "ref:!00D1U01174p.!5004Q02kU6SG:ref"

Thanks,
 

Mobile Ads SDK Team

 

[Liran Barsisa]

I think the best thing is to have these changes:

1. All functions to use Context and not force to use Activity, as it's too restricting about where we can query, and also cause memory leaks. One of the errors callbacks is actually happening when the Activity is destroyed, which is weird.

For UI, offer better classes of your own instead of the weird loadAndShowConsentFormIfRequired, meaning any of these : View/Dialog/Fragment/DialogFragment/Activity.

2. All query functions (canRequestAds and getPrivacyOptionsRequirementStatus, for example, and others too) should automatically use cached results till expired. Also should handle expiration properly instead of us needing to check out workaround/hacks to reach flags, that aren't documented on the normal flow at all.

This should reduce loading time to minimal.

3. Initialization of Admob (or any other ad-network) should not depend on when we get results as this could take some time (and it takes time to load ads already). It should be able to check out the results automatically and load new ads automatically based on current situation as it's changing. 
This will let ads to become available even before consent is checked, so things can work in an async way.

We could also set a minimal delay time for Admob to give up on the result, to be initialized automatically after this time (unless the consent UI is shown).

[Mobile Ads SDK Forum Advisor]

Hi Liran,

I have filed a feature request for the use of a Context over an Activity. Thank you for your recommendation.

Nick

ref:!00D1U01174p.!5004Q02kU6SG:ref

[Liran Barsisa]

Thank you.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Once `requestConsentInfoUpdate` is called `canRequestAds` can be called immediately and will include the on device status. 

See https://developers.google.com/admob/android/privacy

This is also called out on our get started video https://developers.google.com/admob/android/privacy

Hope this helps,

[Liran Barsisa]

This I already know.
The problem is later, that each time the app gets restarted (process is killed and starting again), there is no way to get the cached result quickly, let alone without Activity.

According to my tests, loading the result takes up to 3 more seconds.

If we had a way to just read from cache (and have it reliable and with expiration support), it would be in a split of a second instead, and wouldn't need an Activity either (why requestConsentInfoUpdate even needs an Activity, doesn't even have a UI...).