Wake-up call: Two years in, Google’s UMP still barely works!
AndreasB
Google’s UMP 1.0.0 was released in July 2020. There was a random major version bump to 2.0.0 in July 2021, with this second release not really adding anything of value and definitely not fixing any of the issues many people seem to have with it. (https://developers.google.com/admob/ump/android/release-notes)
Google’s UMP is supposed to “support publishers in meeting their duties under” Google’s own EU User Consent Policy (https://developers.google.com/admob/ump/android/quick-start). While it may be true that adding this UMP solution to one’s app leads to “met duties” from a purely legal standpoint, I’d say that Google as a main ad vendor should have an interest in actually supporting publishers not only in meeting legal duties - that is just the bare minimum - but also in being successful with their ad-driven app. UMP definitely does not do this:
First, there is no API for developers to easily check whether ads (and of what type, personalized or non-personalized) will be shown to any given user. There’s ConsentInformation.ConsentStatus, but the possible values are neither here nor there, with the description for OBTAINED explicitly stating as much: “Personalized vs non-personalized undefined.” (https://developers.google.com/admob/ump/android/api/reference/com/google/android/ump/ConsentInformation.ConsentStatus).
This means that, in order to find out what ads, if any, a user might see while using the app, developers have to resort to manually checking IABTCF_ strings in SharedPreferences like cavemen, like so: https://stackoverflow.com/questions/69307205/mandatory-consent-for-admob-user-messaging-platform
Second, it is too easy for users to opt out of seeing any ads, even if that isn’t their goal: When the consent form pops up, tap consent. Then, bring up the consent form again (developers are advised to allow users to change their consent). At this point, every sane person would assume that they are actually presented with their current consent status as previously defined by themselves - but this is not the case. Instead, they are presented with a blank form that is configured to opt them out of even non-personalized ads if they just confirm those standard settings. Even while acknowledging that it needs to be possible and easy for users to revoke any previously given consent, I don’t see why this needs to be the default setting when “revoking consent” isn’t even the user’s intent. There is no API to show a consent form populated with the current consent information, for the use case of “changing but not revoking consent”, but there should be!
Third, it is practically impossible for users to manually configure their consent form to get to a state where ads will be served. In order to do so, users would not only need to activate the first option presented to them in the dialog (“Store and/or access information on a device”), plus two more for personalized ads, but would then also need to scroll past 19(!) additional switches on 15 different cards, then tap “Vendor preferences”, then scroll through an arbitrarily long and unsorted list of hundreds of vendors each with two more switches, and activate exactly those the developer wants to use.
The chances are slim to none that any given user can be bothered to do this, or to actually remember the detailed instructions necessary to complete this process even if those were explicitly mentioned in advance.
What would need to exist instead is a set of simple buttons with text like “Allow all ads”, “Allow non-personalized ads”, basically similar to the legacy dialog shown here: https://developers.google.com/admob/android/eu-consent#collect-consent
That developer page already had enough legalese to get you, Google, out of harm's way in case that this dialog would not be sufficient in a certain situation - but I’m sure that, if you found out by now that it definitely isn’t, there would still exist some middle ground between the simplicity of the legacy solution and the sheer insanity of the current one.
Fourth, it is apparently not even possible to give up and configure AdMob to just serve non-personalized ads in any case. I would have expected the in-app consent form to display text other than “APPNAME asks for your consent to use your personal data to: Personalized ads and content [...]” after changing to non-personalized ads - but this text still gets displayed, and other parts of the AdMob console even state that “You’ve enabled non-personalized ads in settings, but apps with GDPR messages can show personalized ads”. It seems as if the only way out would be to not display a “GDPR message” in the first place - but then, the aforementioned EU User Consent Policy explicitly states that we need to get user consent even for non-personalized ads. Ignoring that would be futile anyway, because AdMob’s help page explicitly claims that “if consent is missing for Google for Purpose 1 in the TC string, Google will drop the ad request and no ads will be served.” - and if we’ve not gone through some sort of GDPR message like the one UMP provides, where would the valid TC strings come from in the first place? (https://support.google.com/admob/answer/9760862?hl=en&ref_topic=9756841#table)
In the end, every time a developer fails to implement user consent in a way that allows at least non-personalized ads, not only that developer suffers, but Google’s whole business model of on the one hand showing some ads to some people, and on the other hand having a mobile platform full of useful apps that are mostly free, suffers as well.
So, can we expect any of that to change in the foreseeable future, or has Google as a whole just given up?
Wishlist for UMP 3.0.0:
ConsentInformation.ConsentStatus needs to have values like OBTAINED_FULL (personalized ads can be shown) and OBTAINED_NON_PERSONALIZED_ONLY (only non-personalized ads can be shown.
ConsentForm.show() needs to get an optional third parameter, allowing it to bring up both an empty consent form as well as one filled with previously defined consent information, to allow for the clearly different use cases of either “changing” or “revoking” consent to both be accessible in an app.
ConsentForm.showSimplified() needs to exist, presenting some actual human-decipherable options instead of the avalanche of switches on cards that is presented via the current consent form. Bonus points if one of these options can be configured by the developer, for example to lead to an in-app purchase as an alternative.
Mobile Ads SDK Forum Advisor
Thank you so much for your feedback. I’ve captured your feedback and forwarded it to the UMP team, who will mark a priority of reviewing it and seeing how your feedback aligns with their current roadmap and how they might be able to integrate it into planning. We appreciate you taking the time to share your thoughts!
Regards,
Justin
ref:_00D1U1174p._5004Q2d1bJh:ref