Some loss in ad rev is nothing compared to EU fines looming. Unity ads has no such stupid restrictions and is GPDR compliant. It’s what I use and the ecpms are much higher than admob assuming you set up a decent waterfall.
Indeed, Unity Ads is an option. The Solar2d plugin doesn’t support banners? Would be a great addition.
Also EU could pressure other ad networks to do the same in the future, Google is the first because it is the most afraid to get sued.
Regadless, the Admob plugin needs a way to check if the consent is given. This link shows how:
https://itnext.io/android-admob-consent-with-ump-personalized-or-non-personalized-ads-in-eea-3592e192ec90
@Scott_Harrison, can it be done?
1 Like
One more problem. I advanced the date on my device to after Jan 16 and the behavior changes. It will automatically try to load the UMP upon calling getConsentFormStatus() (???) and fail, then all calls will get formStatus=unavailable and consentStatus=unknown. If this behavior persists it means you can’t show the dialog and will lose all revenue from EU.
@Scott_Harrison can you confirm if this is something from your implementation or an Admob bug?
As of now this UMP API is to unstale to be used, and unsless this changes the admob plugin is dead. Another option is to implement one of the 3rd party certified Consent management platforms
Re: the date-issue I wouldn’t be surprised if the behavior from their side is currently undefined, but worth asking them.
I have a separate issue. Despite tagging my requests as childSafe and designedForFamilies the UMP SDK sends the Advertising ID to https://fundingchoicesmessages.google.com/. And I get rejected by Google Play.
This forum post describes the issue: https://groups.google.com/g/google-admob-ads-sdk/c/R8ls5sgCYKI
The solution is supposedly to tag consent requests with tag_for_under_age_of_consent (Tag an ad request for EEA, the UK, and Switzerland users for restricted data processing - Google AdMob Help)
But despite doing that Google says I’m transmitting the ad id.
The nuclear option is to remove the permission from the manifest but that will affect all users and probably tank the revenue completely.
Just realized you can check the consent result with plain lua code, no need for internal plugin access
local canShowPersonalizedAds = function()
local function hasAttribute(input, index)
if (input == nil) then return false end
return #input >= index and string.sub(input, index, index) == "1"
end
local function hasConsentFor(indexes, purposeConsent, hasVendorConsent)
for i = 1, #indexes do
if not hasAttribute(purposeConsent, indexes[i]) then
printl("hasConsent denied for purpose #" .. indexes[i] )
return false
end
end
return hasVendorConsent
end
local function hasConsentOrLegitimateInterestFor(indexes, purposeConsent, purposeLI, hasVendorConsent, hasVendorLI)
for i = 1, #indexes do
local purposeAndVendorLI = hasAttribute(purposeLI, indexes[i]) and hasVendorLI
local purposeConsentAndVendorConsent = hasAttribute(purposeConsent, indexes[i]) and hasVendorConsent
local isOk = purposeAndVendorLI or purposeConsentAndVendorConsent
if not isOk then
printl("hasConsentOrLegitimateInterestFor: denied for #" .. indexes[i])
return false
end
end
return true
end
local purposeConsent = system.getPreference( "app", "IABTCF_PurposeConsents", "string")
local vendorConsent = system.getPreference( "app", "IABTCF_VendorConsents","string")
local vendorLI = system.getPreference( "app", "IABTCF_VendorLegitimateInterests","string")
local purposeLI = system.getPreference( "app", "IABTCF_PurposeLegitimateInterests","string")
local googleId = 755
local hasGoogleVendorConsent = hasAttribute(vendorConsent, googleId)
local hasGoogleVendorLI = hasAttribute(vendorLI, googleId)
local hasConsent1 = hasConsentFor({1, 3, 4}, purposeConsent, hasGoogleVendorConsent)
local hasConsent2 = hasConsentOrLegitimateInterestFor({2, 7, 9, 10}, purposeConsent, purposeLI, hasGoogleVendorConsent, hasGoogleVendorLI)
return hasConsent1 and hasConsent2
end
If anyone finds a flaw feel free to comment.
Still the weird behavior when you change the date on the device, though, which looks more like a bug than intentional action by Admob
Have not yet tried this, but is for sure concerning. @Scott_Harrison is there a way we can make this available on the plugin. As designed for families apps will be not updatable because of this. From what I’m seeing in the link
https://groups.google.com/g/google-admob-ads-sdk/c/R8ls5sgCYKI 1
It requires
UMP SDK 2.1.0 and [tagging user under age of consent via the isTagForUnderAgeOfConsent API]
I just seen the docs, Solar2D Documentation — Plugins | AdMob | updateConsentForm
Did you set the underage=true and does it make a difference in our case?
I set underage but am currently investigating if it needs to be set at a different position in the init / load sequence
Apologies for unstructured feedback. It appears that setting underage actually causes the form status to remain unavailable.
In my current implementation the form shows up as expected when I set underage false. By toggling underage true, the form does not show up. Makes sense functionality-wise, since the user (child) would not understand the form.
What complicates matters a bit is that I can’t reproduce the transmission of the Ad ID which Google claims is sent to the URL mentioned above, whether or not I set underage. At least I can’t find it in the device log.
It is possible (but not likely) that the build I sent to Google Play had underage = false. So I can submit a new build with underage = true and see if they reject me again. But at this point I’m wondering whether I should just remove the Ad ID from the manifest and scrap the whole UMP/CMP system, since apps for kids in DFF should anyway not send the Ad ID when you set the required flags (see Comply with Google Play’s Families Policy using AdMob - Google AdMob Help)
Realized that AdMob might still require the CMP system, so my next attempted build will be:
- Underage true. CMP will not show form, but shows consent obtained anyway (?)
- Disable the Ad ID in the manifest
Actually @perflubron starting api33 you do need to declare ad_id and designed for family section apps must not use it. You need to remove it in manifest
2 Likes
The build passed:
- Underage true. CMP will not show form, but shows consent obtained
- Disable the Ad ID in the manifest
NB: Had console warning in publishing overview that manifest did not include Ad ID (picked up from new version), but if I tried to change the declaration saying that I did not use the Ad ID then it would not let me submit (bcs current/live version had it). Solution was to force the update (button to ignore the warning) and then when 100% rollout it was possible to change the declaration.
Have digressed from the topic but perhaps someone finds it relevant
Sorry for ignorance, but that ID is the one that must be entered into the parameter “testDeviceIdentifiers”? and how to get it?
admob.updateConsentForm({ underage= true , debug={ geography = "EEA" , testDeviceIdentifiers={ "Your-Device-Hash" } } })
Has anyone managed to display the consent form in their app.
I have it showing from both my iOS app and my android app, So far the consent rate is not bad.
| Date | Operating system | EEA & UK traffic rate | GDPR consent rate |
|---|---|---|---|
| 2023-11-04 | iOS | 13.07% | 100.00% |
| 2023-11-04 | Android | 3.23% | 100.00% |
| 2023-11-03 | iOS | 8.65% | 66.67% |
| 2023-11-03 | Android | 0.00% | 0.00% |
| 2023-11-02 | iOS | 9.31% | 80.00% |
| 2023-11-02 | Android | 0.00% | 0.00% |
| 2023-11-01 | iOS | 12.68% | 100.00% |
| 2023-11-01 | Android | 3.13% | 0.00% |
| 2023-10-31 | iOS | 6.33% | 0.00% |
| 2023-10-31 | Android | 1.64% | 0.00% |
| 2023-10-30 | iOS | 9.84% | 100.00% |
| 2023-10-30 | Android | 17.65% | 100.00% |
| 2023-10-29 | iOS | 6.49% | 80.00% |
| 2023-10-29 | Android | 0.00% | 0.00% |
| 2023-10-28 | iOS | 8.78% | 80.00% |
| 2023-10-28 | Android | 0.00% | 100.00% |
| 2023-10-27 | iOS | 8.79% | 100.00% |
| 2023-10-26 | iOS | 11.96% | 100.00% |
| 2023-10-25 | iOS | 9.30% | 50.00% |
| 2023-10-24 | iOS | 6.71% | 80.00% |
| 2023-10-24 | Android | 0.00% | 0.00% |
| 2023-10-23 | iOS | 9.94% | 100.00% |
| 2023-10-22 | iOS | 9.64% | 87.50% |
| 2023-10-22 | Android | 33.33% | 100.00% |
1 Like
Regarding the device hash, you need to check the logs once you call updateConsentForm
Another option is to use VPN
1 Like
Yeah, I’ve managed to implement it in several games. The docs seem to still be in their rough, original form, which doesn’t include all necessary details.
To get the consent form to appear, you need to:
- Set up the consent management message for your apps over at your AdMob profile.
- Require the plugin via
local admob = require( "plugin.admob" )(make sure you’ve set it up in your build.settings as well). - Initialize the plugin, via init.
- Upon successly init, you need to first updateConsentForm.
- Then, after a delay, you can getConsentFormStatus.
You can set up the delay in various ways. You could, for instance, fire a timer in the ad listener’s “init” phase after updating the consent form, or you could initialise the plugin when the app starts and get the form status before trying to show your first ad.
I’ll go update the docs to a proper form later this week. I have a few other Solar2D (and non-Solar2D) tasks that I need to sort out first.
3 Likes
I have a feeling it’s most likely a matter of a couple of frames, but you shouldn’t try calling it in any tight loops.
In the projects where I’ve set it up, the delay is either in the hundreds of milliseconds or before ads would be shown, which can take quite a while, but then the consent form also doesn’t bother the user unless the play long enough to get ads.
1 Like