Re: IAB TCF v2.0 errors detected

[Andreas]

Error "3.3" is related to user consent not being refreshed after more than a year, which is something that Google's UMP SDK should do automatically but doesn't. I gathered more detailed information about that here: https://github.com/bocops/UMP-workarounds#admob-error-33

If you want to keep using Google UMP, there's a potential workaround also on that page. You will likely not get any further help in this group. Google employees will claim that you will need to ask for consent again, but will not acknowledge that it is their own product that fails this task.

On Sunday, May 21, 2023 at 8:26:29 PM UTC+2 Ronald Dwk wrote:

There's a message on my admob dash reading "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." I downloaded the "TCF error report" which reads:

Mobile App,Ad unit,Error,Error count,Last detected date
Unknown,4408782796,3.3,160,5/19/2023
Unknown,1406617951,3.3,20,5/19/2023

I've implemented GDPR many years ago:
com.google.android.ump:user-messaging-platform:2.0.0

This is the code I've been using for years:

   public void getConsentStatus(){
        consentInformation = UserMessagingPlatform.getConsentInformation(this);
       
        ConsentRequestParameters parameters = new ConsentRequestParameters.Builder()
                .setTagForUnderAgeOfConsent(false)
                .build();

        consentInformation.requestConsentInfoUpdate(this, parameters,
                new ConsentInformation.OnConsentInfoUpdateSuccessListener() {
                    @Override
                    public void onConsentInfoUpdateSuccess() {
                        if (consentInformation.isConsentFormAvailable()) {
                            loadform();
                        }
                    }
                },
                new ConsentInformation.OnConsentInfoUpdateFailureListener() {
                    @Override
                    public void onConsentInfoUpdateFailure(FormError formError) {

                    }
                }
        );
    }

    public void loadform() {
        UserMessagingPlatform.loadConsentForm(this, new UserMessagingPlatform.OnConsentFormLoadSuccessListener() {
                    @Override
                    public void onConsentFormLoadSuccess(ConsentForm consentForm) {
                        MainActivity.this.consentForm = consentForm;

                        if (consentInformation.getConsentStatus() == ConsentInformation.ConsentStatus.UNKNOWN) {
                            consentForm.show(MainActivity.this, new ConsentForm.OnConsentFormDismissedListener() {
                                @Override
                                public void onConsentFormDismissed(FormError formError) {
                                    loadform();
                                }
                            });
                        }
                        if (consentInformation.getConsentStatus() == ConsentInformation.ConsentStatus.REQUIRED) {
                            consentForm.show(MainActivity.this, new ConsentForm.OnConsentFormDismissedListener() {
                                @Override
                                public void onConsentFormDismissed(FormError formError) {
                                    loadform();
                                }
                            });
                        }

                    }
                },
                new UserMessagingPlatform.OnConsentFormLoadFailureListener() {
                    @Override
                    public void onConsentFormLoadFailure(FormError formError) {
                        loadform();
                    }
                });

"HELP" on admob dashboard reads "Refresh this page and try again. Sorry, there was a problem with the form." so I cannot ask them for more info.

Other posts:

If you're using UMP SDK to get the consent of your users, then this should be automatically handled by the SDK, code in my apps are from here:

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

also on another post:

according to that Google group if you are using UMP SDK, and you probably are as you're using Funding Choices like me, it should be handled by the SDK itself. So nothing to worry about, if the error persist, meaning it present itself in several different days, than I fear the only way is to open a ticket with Google Admob.

[Andreas]

If you implemented this yesterday and published an app update, it is very likely that this change hasn't reached all of your users yet.

On Monday, May 22, 2023 at 2:13:42 PM UTC+2 Ronald Dwk wrote:

I already tried your suggestion yesterday "IAB TCF v2.0 errors detected" is still on my dashboard.

    public void deleteTCStringIfOutdated(Context context) {
        // IABTCF string is stored in SharedPreferences
        SharedPreferences sharedPrefs = PreferenceManager.getDefaultSharedPreferences(context);

        // get IABTCF string containing creation timestamp;
        // fall back to string encoding timestamp 0 if nothing is currently stored
        String tcString = sharedPrefs.getString("IABTCF_TCString", "AAAAAAA");

        // base64 alphabet used to store data in IABTCF string
        String base64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";

        // date is stored in digits 1..7 of the IABTCF string
        String dateSubstring = tcString.substring(1,7);

        // interpret date substring as base64-encoded integer value
        long timestamp = 0;
        for (int i = 0; i < dateSubstring.length(); i++) {
            char c = dateSubstring.charAt(i);

            int value = base64.indexOf(c);
            timestamp = timestamp * 64 + value;
        }

        // timestamp is given is deci-seconds, convert to milliseconds
        timestamp *= 100;

        // compare with current timestamp to get age in days
        long daysAgo = (System.currentTimeMillis() - timestamp) / (1000*60*60*24);

        // delete TC string if age is over a year
        if (daysAgo > 365) {
            sharedPrefs.edit().remove("IABTCF_TCString").apply();
        }
    }
}

My email finally was sent on admob dashboard and this was their reply:

Thank you for your email.

Google’s commitment to transparency and control means we regularly look at ways to improve the consent experience. When we do this, we’re thinking about evolving user expectations, as well as the regulatory indicators that we think will ultimately guide the broader advertising landscape.

In accordance with that commitment, later this year, we will require partners using our publisher products — Google AdSense, Ad Manager, or AdMob — to use only a Google certified  Consent Manager Platform (CMP) that integrate with  IAB Europe’s Transparency and Consent Framework (TCF) when serving ads to users in the European Economic Area or the UK. In the coming weeks, Google will make available a list of CMPs that Google has certified, and that have integrated with the TCF and meet the TCF’s specifications. We'll require that our partners use a CMP from that list . The list of Google certified CMPs will be available in our Help Center (Ad Manager, AdMob, AdSense). And further information is available in this blogpost (Ad Manager, AdMob, AdSense). 

Why we are introducing this

In 2020, we integrated our ads systems with TCF. By supporting the TCF, we build on our 2020 commitment to support industry efforts aimed at managing user transparency and consent through a standardized framework.  The decision also follows on from IAB's Europe’s announcement that TCF V2.2 has been finalized which further supports consistency in the online advertising consent experience. We anticipate others in the industry will follow with similar adjustments. 

Next Steps:

•  Google has begun the process of certifying TCF compliance by CMPs that work with our publishing partners. To ensure a smooth transition, publishers currently working with a CMP should proactively talk with their CMP provider about the certification process. For publishers seeking a new CMP partner, in the coming weeks we will make available a list of Google-certified CMPs in our HC articles (Ad Manager, AdMob, AdSense). 

 We will support your transition as you prepare for the new consent management requirements. In the meantime, please review our Help Center for further details (Ad Manager, AdMob, AdSense).

[Andreas]

I haven't seen this one before - that page has been updated within the last month, though, perhaps this is a recent addition.

For what it's worth, calling requestConsentInfoUpdate() and then checking its ConsentStatus for REQUIRED is exactly what UMP's "Get started" guide has mentioned for years. If this really works now (and I'm having doubts after all that time ;)) without any SDK update, then it must be some server-side bug that has been silently fixed.

On Monday, May 22, 2023 at 3:02:33 PM UTC+2 Ronald Dwk wrote:

Yes, gonna give it a few days, also found this on admob website:

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

Error 3.3: The TC string last updated date was more than 13 months agoConsent must be reobtained from the user. You should call requestConsentInfoUpdate() at the start of every app session. If the TC string is expired, the UMP SDK indicates that consent must be reobtained by setting ConsentInformation.ConsentStatus to ConsentStatus.REQUIRED. If you haven't already, implement a request to load and present a new UMP form in your app.

[Mobile Ads SDK Forum Advisor]

Hello Ronald,

Thank you for reaching out to us.

Based on the initial email you provided, 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.

 

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

Thanks,
 

Mobile Ads SDK Team

[Mobile Ads SDK Forum Advisor]

Hi Andreas,

Thank you for continuously providing your insight on this thread with regard to the TCF error. If you have any other concern related to Mobile Ads SDK, just kindly let us know and we'll be happy to assist you.

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

Thanks,
 

Mobile Ads SDK Team

[astrovicApps]

Regarding the information provided here:

• Android: https://developers.google.com/admob/android/privacy/gdpr#troubleshooting
• iOS: https://developers.google.com/admob/ios/privacy/gdpr#troubleshooting

the page is updated to 2023-04-26.

It says: "If the TC string is expired, the UMP SDK indicates that consent must be reobtained by setting ConsentInformation.ConsentStatus to ConsentStatus.REQUIRED"

This is not true, or it doesn't work as it should. My apps always shows the Consent Form if ConsentInformation.ConsentStatus is ConsentStatus.REQUIRED. I always call requestConsentInfoUpdate() at the start of every app session. Despite this, I keep getting the TCF error 3.3, both on iOS and Android. 

So it is evident that something in the UMP SDK is not working as it should. And this problem continues to be reported by users, without receiving a solution.

[AstrovicApps]

From the settings page in my apps I allow users to reset their ad consents if they want to. This allows you to show the consent form again.

Since the UMP SDK doesn't work as it should, currently the only solution is to save the date on which the consent form was last filled in the app, and reset it every 13 months.

Il giorno mercoledì 24 maggio 2023 alle 22:13:25 UTC+2 Ronald Dwk ha scritto:

I forgot to mention, a interstitial ad is displayed after the splash screen:

And there you thought it was over NO here we go again ADMOB:

I received a few thousand emails and bug reports since I made all of the recent changes above, users saying the app is stuck on the splash screen so I asked for basic info such as app version and android version. I only opened a few emails, all latest versions of the apps and on android 10.  

Apart from consent form, I upgraded gradle to 8.0.1 and gms:play-services-ads:22.0.0 to gms:play-services-ads:22.1.0 that's it, luckily I have a phone running android 10 so I installed the apps from play store and yes stuck on splash but works perfectly on my phone running android 13, installing from android studio also works fine but not from apk as well, so considering the 1000's crashes on play console all related to com.google.android.gms:play-services-ads:... over the years I first downgraded to 22.0.0 and what do u know it worked perfectly.

On Wednesday, May 24, 2023 at 10:03:52 PM UTC+2 Ronald Dwk wrote:

UPDATE: So on post 6 above I posted code that I tried, it's been 3 days still no change on admob, now it's 3 ad units in the TCF error report, on admob's website it reads:

Warning: Using alternative ways of checking the consent status—such as checking a cache your app utilizes or looking for a consent string in storage—are strongly discouraged as the set of ad technology partners could have changed since the user last consented.

Basically forcing us to use their form which does not work like it supposed too.

On admob website here: 

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

Error 3.3: The TC string last updated date was more than 13 months agoConsent must be reobtained from the user. You should call requestConsentInfoUpdate() at the start of every app session. If the TC string is expired, the UMP SDK indicates that consent must be reobtained by setting ConsentInformation.ConsentStatus to ConsentStatus.REQUIRED. If you haven't already, implement a request to load and present a new UMP form in your app.

ConsentInformation.ConsentStatus 

to 

ConsentStatus.REQUIRED

I tried the above in 1 of my apps as astrovicApps said " it doesn't work as it should" 100% correct it doesn't.

From Mobile Ads SDK Forum Advisor:

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:

• Android - https://developers.google.com/admob/android/privacy#reset_consent_state

On admob website it reads:

In testing your app with the UMP SDK, you might find it helpful to reset the state of the SDK so that you can simulate a user's first install experience. The SDK provides the reset() method to do this.

consentInformation.reset();

I've implemented this a few hours ago and uploaded to play store, what  consentInformation.reset();  does is display the form every time the app is opened but that's the only option that's available to me right now, who knows when admob will release an update too com.google.android.ump:user-messaging-platform:2.0.0 or perhaps the problem is on their server side.

I've sent a notification to my users explaining why I had to do the above and as soon as the message on admob disappears I will release an update, luckily I have awesome users.

And there you thought it was over NO here we go again ADMOB:

I received a few thousand emails and bug reports since I made all of the recent changes above, users saying the app is stuck on the splash screen so I asked for basic info such as app version and android version. I only opened a few emails, all latest versions of the apps and on android 10.  

Apart from consent form, I upgraded gradle to 8.0.1 and gms:play-services-ads:22.0.0 to gms:play-services-ads:22.1.0 that's it, luckily I have a phone running android 10 so I installed the apps from play store and yes stuck on splash but works perfectly on my phone running android 13, installing from android studio also works fine but not from apk as well, so considering the 1000's crashes on play console all related to com.google.android.gms:play-services-ads:... over the years I first downgraded to 22.0.0 and what do u know it worked perfectly.

When does it end, over the last 2 month's ads where restricted in over 20 of my apps, after requesting a review EVERY restriction was removed, didn't receive any of those emails in the last 4 days but that stopped and IAB TCF v2.0 errors detected began, anyways I will update you guys if consentInformation.reset(); works.

Maybe your stats look like mine, after all the above began:

Match rate used to be a solid 98 or 99% now it's around 50 to 60% the lowest it went was 11% YES ADMOB 11%

eCPM varies but the lowest was 80 cent unbelievable I KNOW.

[Andreas]

AstrovicApps, thanks for confirming my suspicion. I, too, call requestConsentInfoUpdate() on every app startup and check if the status is REQUIRED, but that simply does not do anything - although it should, which is the core problem we're bringing up time and again for years now!

Ronald, in the code of your MainActivity you posted above, you seem to include my workaround method but not actually call it. Unless your code sample is incomplete, you should add deleteTCStringIfOutdated(this) to your onCreate method before calling getConsentStatus(), or as the first thing in that method. That workaround method accesses the date of last consent in the actual TCF string, so basically does what AstrovicApps suggests without forcing all your users through the process on every app startup.

If you want, you can additionally try replacing the line that just removes an entry from shared preferences (sharedPrefs.edit().remove("IABTCF_TCString").apply();) with the call to consentInformation.reset() that keeps being suggested by Googlers - although, seeing how that is clearly documented as something to be used in testing, I'm not sure if that is any better.

On Thursday, May 25, 2023 at 10:18:04 AM UTC+2 Ronald Dwk wrote:

I also tried: selected Custom ad partners then ticked a few boxes, when saving a pop read "do u want to re-prompt users again...." however that didn't work for me if anything more ad units where added to error report.

[Mobile Ads SDK Forum Advisor]

Hi All,

@Andreas, Thank you again for continuously providing your insight on this TCF error that publishers are encountering.

@Ronald and astrovicApps, our team mentioned that, the UMP SDK is working as intended, but if the publishers are not implementing the UMP SDK according to the documentation (https://developers.google.com/admob/ios/privacy#display-message). On every app session, the publisher should be calling requestConsentInfoUpdate: to figure out if consent needs to be given again. If the consent is out of date, the SDK will set the consentStatus (https://developers.google.com/admob/ios/privacy/api/reference/Classes/UMPConsentInformation#consentstatus) field to required, and that should prompt publishers to request and show a new UMP form.

[AstrovicApps]

I'm sorry, but it's clearly not working as it should.
I have implemented the UMP SDK as documented (https://developers.google.com/admob/android/privacy#display-message). In fact, the consent form appears correctly in each of the following cases::

1. The first time the user opens the app;
2. After manually resetting the consent state (https://developers.google.com/admob/android/privacy#reset_consent_state);
3. When I make changes to Ad partners in the Settings/GDPR section of "Privacy & messaging" of the AdMob account (https://apps.admob.com/v2/privacymessaging/gdpr/settings?pli=1).

So this proves that the implementation is correct, otherwise the consent form would never appear.

The problem occurs only after 13 months, which is why the "IAB TCF v2.0 error 3.3" appears (https://support.google.com/admob/answer/9999955?hl=en#grace-period-2).

At each session of the app, I call requestConsentInfoUpdate() (https://developers.google.com/admob/android/privacy#display-message) to check if the consent must be given again (https://developers.google.com/admob/android/privacy/api/reference/com/google/android/ump/ConsentInformation.ConsentStatus.html#REQUIRED). 

If indeed the consentStatus was changed to "REQUIRED" after 13 months, the app would show it, as it is shown correctly in the 3 cases listed above. Instead it doesn't.

[Mobile Ads SDK Forum Advisor]

Hello astrovicApps,

Thank you for the additional information.

This might be due code implementation. You can read more information on all the methods used by UMP SDK in this document: https://developers.google.com/admob/android/privacy/api/reference/com/google/android/ump/package-summary. You may also follow Ronald Dwk's implementation to see if this works for you. Feel free to reach back to us if you have further concerns or inquiries.

[Mobile Ads SDK Forum Advisor]

Hello Ronald Dwk,

Thank for providing us your implementation. Fee free to reach back to us with your update.

[AstrovicApps]

The fact that you have to resort to a workaround to check if the TC string is expired (more than 13 months have passed since the last consent) means that the UMP SDK is not able to do it. End of the story. 

The UMP SDK should do this control, and consequently set ConsentInformation.ConsentStatus to ConsentStatus.REQUIRED when I call requestConsentInfoUpdate() on app startup. 

[Andreas]

Do you care to explain why my latest on-topic message in this thread got deleted?

On Tuesday, May 30, 2023 at 10:32:18 AM UTC+2 Ronald Dwk wrote:

Update: 2 more ad units have been removed from the error list, using Andreas workaround, the other 2 methods still pending and it's been 8 days so I'm going to implement the workaround.

[Mobile Ads SDK Forum Advisor]

Hi All,

Thank you for your response.

@Andreas - We are not aware of why the latest message on this thread got deleted. Maybe the publisher who posted it deleted it also, but we didn't seem to find it in our end. 

@Ronald - We're glad to know that everything works well for you. 

@AstrovicApps - What we can recommend from our end is on every app session, you should be calling requestConsentInfoUpdate: to figure out if consent needs to be given again. If the consent is out of date, the SDK will set the consentStatus (https://developers.google.com/admob/ios/privacy/api/reference/Classes/UMPConsentInformation#consentstatus) field to required, and that should prompt publishers to request and show a new UMP form. 

[AstrovicApps]

This is what I already do. 

OK, I think it's useless to keep answering. Thanks anyway for trying to help. I hope that sooner or later someone will "really" test this SDK malfunction.

[Mobile Ads SDK Forum Advisor]

Hi AstrovicApps,

Thank you for your response. If you have any other concerns related to the Mobile Ads SDK implementation, just kindly let us know so we can assist you the best we can.

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

You may reach out to product team (via this link: https://support.google.com/admob/thread/new?hl=en) and ask them to remove the ad unit from IAB TCF v2.0 list as it is already deleted and not being used for more than a month.

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

Thank you for your response.

As this matter is as important to us as it is to you, we deeply understand the inconvenience this situation has caused. As much as we want to provide you more assistance for the deleted ad unit, this is already out of our scope, as this happened in your account. Since you mentioned that you already reached out to the product support team and got a reply with them, we suggest that you continue and wait for their further instruction on this from their end as they are more equipped to assist you further.

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

Thank you for updating us. It seems that your post from https://support.google.com/admob/thread/221083810?hl=en&sjid=4784990860995532443-EU no longer exist. Could you share your App ID and the ad unit ID that is already deleted but you keep on getting  TCF 3.3 error for that ad unit? Once provided, I'll be raising this to a wider team to get their insight as well.

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

Thank you for your response.

Allow us to share this to the wider team to further check. However, kindly provide us also your Ad unit id affected and App ID, so our wider team can further check this in their end. Rest assured that one of our team will reach out to you. 

[mai mohamed مى محمد‎]

Jrogdwm you have any10

Onboard46

Hi1000

في الخميس، ٢٧ يوليو، ٢٠٢٣ ٦:١٨ م Ronald Dwk <rona...@gmail.com> كتب:

App ID - ca-app-pub-5429548830862354~9783118386

Banner  - ca-app-pub-5429548830862354/2391474522

Interstitial - ca-app-pub-5429548830862354/8548151666

Perhaps they can exclude these deleted ad units in future:

Deleted ad units:
ca-app-pub-5429548830862354/4230750944
ca-app-pub-5429548830862354/2177742228
ca-app-pub-5429548830862354/8928056389
ca-app-pub-5429548830862354/6129986700
ca-app-pub-5429548830862354/9732309463
ca-app-pub-5429548830862354/2069441860
ca-app-pub-5429548830862354/6774054197
ca-app-pub-5429548830862354/8028386627
ca-app-pub-5429548830862354/2885395787
ca-app-pub-5429548830862354/8069824140
ca-app-pub-5429548830862354/9806199765
ca-app-pub-5429548830862354/4476823792
ca-app-pub-5429548830862354/7670849222
ca-app-pub-5429548830862354/6356017452
ca-app-pub-5429548830862354/8861781239
ca-app-pub-5429548830862354/1899167469
ca-app-pub-5429548830862354/6026736851
ca-app-pub-5429548830862354/8017447702
ca-app-pub-5429548830862354/3546727800
ca-app-pub-5429548830862354/9818101380
ca-app-pub-5429548830862354/1827890017
ca-app-pub-5429548830862354/4716902493
ca-app-pub-5429548830862354/9358449533
ca-app-pub-5429548830862354/4765626078
ca-app-pub-5429548830862354/5378684221
ca-app-pub-5429548830862354/8344137539
ca-app-pub-5429548830862354/5021314973
ca-app-pub-5429548830862354/7793302602
ca-app-pub-5429548830862354/6321222651
ca-app-pub-5429548830862354/1013055659
ca-app-pub-5429548830862354/5237129710
ca-app-pub-5429548830862354/4728326158
ca-app-pub-5429548830862354/3104957441
ca-app-pub-5429548830862354/6152917873
ca-app-pub-5429548830862354/8170039686
ca-app-pub-5429548830862354/8078185124
ca-app-pub-5429548830862354/4993903939
ca-app-pub-5429548830862354/7321542238
ca-app-pub-5429548830862354/3526754532
ca-app-pub-5429548830862354/1751422254
ca-app-pub-5429548830862354/5452021780
ca-app-pub-5429548830862354/9589391974
ca-app-pub-5429548830862354/1847011945
ca-app-pub-5429548830862354/2721814064
ca-app-pub-5429548830862354/5167139262
ca-app-pub-5429548830862354/9291549668
ca-app-pub-5429548830862354/9246768891
ca-app-pub-5429548830862354/7644763796
ca-app-pub-5429548830862354/8766273770
ca-app-pub-5429548830862354/2200865429
ca-app-pub-1492185577403123/4684932961
ca-app-pub-1492185577403123/8241034597
ca-app-pub-1492185577403123/6522141700
ca-app-pub-5429548830862354/8890097023
ca-app-pub-5429548830862354/1777019020
ca-app-pub-5429548830862354/1687790625
ca-app-pub-5429548830862354/5472188621
ca-app-pub-5429548830862354/9549134622
ca-app-pub-5429548830862354/2283219820
ca-app-pub-5429548830862354/5736213823
ca-app-pub-5429548830862354/1637418227
ca-app-pub-5429548830862354/6750445425
ca-app-pub-5429548830862354/4205448220
ca-app-pub-5429548830862354/7158914622
ca-app-pub-5429548830862354/1112381023
ca-app-pub-5429548830862354/4065847427
ca-app-pub-5429548830862354/7019313826
ca-app-pub-5429548830862354/2449513422
ca-app-pub-5429548830862354/5402979820
ca-app-pub-5429548830862354/9833179428
ca-app-pub-5429548830862354/3786645820
ca-app-pub-5429548830862354/6740112220
ca-app-pub-5429548830862354/9693578629
ca-app-pub-5429548830862354/1458425024
ca-app-pub-5429548830862354/8283687828
ca-app-pub-5429548830862354/2457480222
ca-app-pub-5429548830862354/7482462228
ca-app-pub-5429548830862354/3955416224
ca-app-pub-5429548830862354/6056101424
ca-app-pub-5429548830862354/7179581025
ca-app-pub-5429548830862354/9155841823
ca-app-pub-5429548830862354/1213772629
ca-app-pub-5429548830862354/3094131822
ca-app-pub-5429548830862354/4431264226

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/f9da3472-388b-48aa-a9c0-6b57fadfc853n%40googlegroups.com.

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

Thank you for providing that information. If you are able to download the TCF error report in the AdMob dashboard there are two ad units that are associated with the 3.3 error:

5774309082
7807512802

It also looks like the last time these errors were detected July 25th. 

However, 3.3 errors are not so much about the ad unit as it is related to the UMP implementation. The iOS/Android SDK internally knows when to flip the consent status to REQUIRED 13 months after it has been obtained. Are you able to provide a minimum reproducible example of your code? To verify the implementation is correct. 

Thanks,
Justin 

ref:_00D1U1174p._5004Q2lKKCk:ref

[Mobile Ads SDK Forum Advisor]

To share an Android project:

If the file(s) you are looking to share are less than 25mb in total you can attach them to this case on your next reply. If you are having trouble attaching your file to this case or if your file(s) are larger than 25mb, you can share your files with me by performing the following steps:

 

1. Navigate to

https://docs.google.com/forms/d/e/1FAIpQLSfkAiXMeYP-fw1W3Z-tT9uwmATEKO5X6S-th0gR2ezdKaaqfg/viewform?usp=pp_url&entry.400550049=Mobile+Ads+SDK&entry.460850823=5004Q00002lKKCkQAO&entry.80707362=00180154

2. Fill out all fields, and attach your file(s).

3. Please reply back on this thread when you have uploaded your file(s). Please do not share this link.
 

[Mobile Ads SDK Forum Advisor]

Hi Ronald,

Thank you for that information. I'm not sure about those deleted ad units as that is out scope for this forum; however, looking at your TCF error report it appears that you have low error rates consistent with the TC String expiring for a short time before the next refresh from Funding Choices. If you are following the proper UMP SDK implementation you should be fine. 

[Mobile Ads SDK Forum Advisor]

Hello all,

To follow up, I want to clarify some misinformation on this thread.

1) The call to requestConsentInfoUpdate() is when the UMP SDK checks the TCString to evaluate it against the 13 months, and updates consent status to REQUIRED if the TCString is invalid. The current recommended implementation is to call requestConsentInfoUpdate() at the start of every session. However, if you have long app sessions, it is possible the 13 months expires mid-session, resulting in a minor amount of 3.3 errors. Additionally, on the next app session, if you start preloading ads at the same time as you check requestConsentInfoUpdate(), those requests will also give a 3.3 until requestConsentInfoUpdate() completes. This should represent a tiny fraction of overall 3.3 errors (e.g. 0.0x%) that we believe are acceptable. We are looking into raising the threshold of 3.3 errors that generates concerning-looking warnings in the AdMob UI on this.

2) If you want to recover that 0.0x%, storing the consent date in local storage and reprompting proactively after 12 months is a workaround. Doing that in the UMP SDK is an idea that's been floating around but we haven't decided to implement that yet. I would still recommend against calling consentInformation.reset() explicitly though. That method is intended to be used for testing, and by calling that, you are deleting potentially valid consent and re-prompting your users more unnecessarily.

Thanks,
Justin

ref:_00D1U1174p._5004Q2lKKCk:ref