GDPR and AdMob - is an app not allowed to show any ads at all until an EEA-based user gives consent?

[Lucas]

The Google rendered consent form here prompts the user to pay for an ads-free version if they don't give consent for personalised or non-personalised ads.  I know that 3rd option is customisable.

However what if the user chooses not to buy the ads-free version or make an in-app purchase to disable ads?  AdMob doesn't seem to allow the option of showing ads without any cookie at all.  So...

Q: Does this mean an app using AdMob is not allowed to show any ads to a user in the EEA unless or until they give consent?

But then if I can't show ads at all then what's the point of ever showing ads to any user in the EEA? There's no incentive for them to give consent in this case, especially as the GDPR says there should be no negative consequences for not giving consent! Closing the app or denying features probably constitutes a negative consequence. I don't know how often a user can be bugged to give consent before that becomes a 'negative consequence' too.  AdMob needs to provide a GDPR-compliant way of showing ads to users in the EEA.

[FrankyLS]

Closing the app or denying features probably constitutes a negative consequence.

I don't think so.

The user is informed about that the free version is only free because it is showing ads. That implies that it cannot be free without ads. And that is the choice the user actually has in that dialog: Pay or give that damn consent :-).

I noticed an advantage in that Consent SDK dialog: The users getting remindet that a paid version without ads exists so it gets bought much more than before^^.  

[Lucas]

Hi FrankyLS

- "I don't think so." - Do you mean that, like me, you don't believe an app is allowed to show ads through AdMob before the user's given consent either?

To be honest I was hoping someone working for Google AdMob would reply to give the official position on this.  I don't see how AdMob can be used to show ads without the user's consent unless or until AdMob offers the ability to serve ads that either don't use cookies at all; or at least ones that comply with GDPR (i.e., don't involve the collection of 'personal data').

I have also asked for clarification about this directly by giving my feedback on the help page at https://developers.google.com/admob/android/eu-consent but the page hasn't been updated since then. Nor have I heard back from Google.

I take your point about the advantage you noticed but you still have to decide whether or not to show ads in your free app before the user's given consent.  My app is free but offers removal of ads as an in-app purchase.  But if they don't give consent then they won't need to make that purchase if I can't show the ads anyway!  I'm just left with the option of bugging them every now and then for consent.

Thanks, Lucas.

[FrankyLS]

No! It was a bit confusing, because a quote is gone for some reason. Sorry. I edited my previous post by re-adding that quote.

You have to collect the consent. After that, you can request and display the ads. :-)

There is a callback where the user's choice is passed to. Instead of redirecting the user to the paid version, let him do the in-app purchase.

The user has 3 choices:

- Display personalized ads

- Display unpersonalized ads

- Do the in-app purchase now

As long as there is no way to exit that process somewhere without any action, there is no unpaid ad-free version ;-).

[Lucas]

Thanks for clarifying.  I think we're agreed, then, that ads can't be shown through AdMob to an EEA-based user until that user gives consent.

So if they cancel the consent dialog or choose not to make the in-app purchase after they've chosen that 3rd option, then you can't show any ads to that user. And this could go on for ages until they've given consent or made the in-app purchase.  That's what I mean.

Ah - I've just seen your last sentence: "As long as there is no way to exit that process somewhere without any action"

- I don't think that's possible, or even desirable really. Users should be able to cancel an in-app purchase for example. You can't force them to buy something:).

So all I have to figure out now is how often and when in my app to pester the EEA-based user for consent... I certainly don't want to do it on app startup. That would be a terrible experience for a new user!

[FrankyLS]

You actually don't force the user to buy something.

You clarify in the beginning that the app is free by showing ads. As I already said, the user has the choice between those ads or an in-app purchase. Only if he deny the consent he has to do the purchase instead. If he gives consent, he can use the free version of your app without any payment.

You need to code it so, that the user can't bypass the dialog without selecting one of the three options.

If he cancels the in-app purchase, he will return to the consent dialog.

If you look to other app you will see that this behavior became common practice. And if you look to the buttons of the dialog, you see, that it was been made for this approach. ;-)

Look at this: https://developers.google.com/admob/android/eu-consent

Here you see an example dialog containing the three choices.

The user can't dismiss that dialog without any choice. There is no "x" or back-button to skip it.

The only way to don't pick a choice is to close the app by pressing the home button.

I is nothing else than a paywall with an additional with-ads-but-free-option.

[mobileadssdk-a...@google.com]

Hi Lucas,

In answer to your question, it is up to you.  The third option (ad free) is optional, you do not have to show it.

Google assumes that if you're making ad requests, then you have the consent from the user to display the type of ad that you are requesting.

We also provide the Consent SDK as a tool to gather consent, but provide you with the flexibility to implement your own GDPR compliance.

If you have further policy related questions,  I would recommend posting on the product support forum, as this is a technical forum for implementation and technical issues.

Regards

Sam

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

On 06/04/18 10:47:31 oak...@gmail.com wrote:

Thanks for clarifying.  I think we're agreed, then, that ads can't be shown through AdMob to an EEA-based user until that user gives consent.

So if they cancel the consent dialog or choose not to make the in-app purchase after they've chosen that 3rd option, then you can't show any ads to that user. And this could go on for ages until they've given consent or made the in-app purchase.  That's what I mean.

So all I have to figure out now is how often and when in my app to pester the EEA-based user for consent... I certainly don't want to do it on app startup. That would be a terrible experience for a new user:).

--

---
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-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/36edbccc-1a2d-4655-ba4d-58b301eaa725%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lucas]

Thank you, both, for your replies. Taking them both together...

@FrankyLS:

I see what you're saying but I'm not sure that, if you implement it as you describe, whether consent is 'freely given' as defined by GDPR (section 3.1 here). It's all a bit of a grey area in my opinion. However I think closing the app if they don't give consent would be a step too far.  BTW I see the consent dialog doesn't have a back button as such but I bet you could dismiss it by pressing Back (unless you deliberately disabled the Back button).

I didn't know that what you described has become common practice. In fact I haven't seen any apps ask for consent yet so I'd be interested to see examples if you can share the names of some of these apps, please.  Seeing examples will help me form my own strategy.

@Sam:

"Google assumes that if you're making ad requests, then you have the consent from the user to display the type of ad that you are requesting."

- I interpret that to mean that I do need consent before showing any ads through AdMob then.

Thanks for the link to the product support forum. I wasn't aware of that before now and I see they've got posts about GDPR. I'll check them out at some point...

Lucas.

[FrankyLS]

I'm not a lawyer. But how else it could be implemented, if unpaid and ad-free isn't an option?

All consent dialogs (from Consent SDK or selfmade) which I saw yet lead to the paid version of the application or to an in-app purchase or just closed the applicationm. Some apps (especially games and online services) combines the consent with the agreement to the entire privacy policy which you have to agree before you can run those apps.

That consent is nothing else than the agreement to a part of your privacy policy. Rejecting the agreement to a privacy policy or terms of use closed applications and services for years (or didn't leave you install them).

I don't see any way to run an application if the user rejects parts of the corresponding privacy policy.

If you are afraid of that this is against the law, what about an aggressive "fake ad" for your paid version as a placeholder (ImageView+Drawable+OnClickListener)?

[Lucas]

I'm not a lawyer either:).  And, from what I've heard lawyers don't all agree on how to comply with GDPR anyway! So what chance do us mortals have?;-)

Thanks for your observations about other apps.  If they comply with GDPR then I'm happy to follow suit.

"I don't see any way to run an application if the user rejects parts of the corresponding privacy policy."

- well, my plan was to allow the user to run the app. It wouldn't show them ads but it would pop up the consent dialog every now and then, or at various points in the app, to ask the user for their consent again.  (In a way, this is a bit like your aggressive 'fake ad' idea.)  So the user wouldn't get ads but they would be irritated by the consent dialog reappearing until they did give their consent or make the in-app purchase to disable ads.  And this policy would be consistent with many websites which prompt you to accept their cookies when you land on their page. If you ignore the prompt you have that annoying bar at the top or bottom of the web page.

And I was going to allow the user to access the same consent dialog from the app's settings so that they could change or revoke their consent at any time, as per the requirements of the GDPR.

Anyway, I really appreciate your feedback and patience! I'll check out what the product support forum says too and view other apps. But my current inclination is to do as I said above unless I can be sure closing the app doesn't violate the 'consent is freely given' requirement of the GDPR.

[FrankyLS]

It is up to you when you collect the consent and start requesting ads. If the consent dialog annoys the user by appearing multiple times, you did it the wrong way.  If you do, what the Consent SDK documentation says, the user's choice of the dialog is getting saved. Before the dialog appears only if there is no such saved choice. Remember to give an option somewhere where the dialog appears on demand so the user can change his choice every time.

If you mis-implement it, the dialog could annoy the user or there could be some escape from it (in worst case, violating law by accidentally requesting ads without consent). So code and test it carefully^^.

And that is, what I meant with the fake ad: If the user rejects and you want to let him use your free application, don't ask him again for consent and annoy the user with that fake ad :-).

[Lucas]

It is up to you when you collect the consent and start requesting ads.

- I 100% agree.

 If the consent dialog annoys the user by appearing multiple times, you did it the wrong way.  If you do, what the Consent SDK documentation says, the user's choice of the dialog is getting saved. Before the dialog appears only if there is no such saved choice.

- No, the dialog appears whenever you build a consent form and then call the show() method on it. I can do that in my app whenever I want.

Remember to give an option somewhere where the dialog appears on demand so the user can change his choice every time.

- I agree and that's also exactly what I meant when I said in my previous email about accessing the same consent dialog from the app's settings:).

If you mis-implement it, the dialog could annoy the user or there could be some escape from it (in worst case, violating law by accidentally requesting ads without consent). So code and test it carefully^^.

- The whole point is I want to annoy the user who doesn't give consent by presenting the consent dialog every so often.  Hopefully they will at some point either give consent or purchase 'disable ads'.  Alternatively they can simply choose to ignore the consent dialog if they wish, in return for not seeing any ads.  If I don't annoy them at all then they have no incentive to purchase 'disable ads'. But if I annoy them too much by showing the consent form too often, or by closing the app, then that could be interpreted as not allowing the user to give their consent freely. So it will be a tricky balancing act to get right.

Here are some quotes I've copied from section 3.1 of the GDPR here. I've highlighted some bits in red.

The element “free” implies real choice and control for data subjects. As a general rule, the GDPR
prescribes that if the data subject has no real choice, feels compelled to consent or will endure
negative consequences if they do not consent, then consent will not be valid. If consent is bundled
up as a non-negotiable part of terms and conditions it is presumed not to have been freely given.
Accordingly, consent will not be considered to be free if the data subject is unable to refuse or
withdraw his or her consent without detriment.

Then, a bit further on...

In general terms, any element of inappropriate pressure or influence upon the data subject (which

may be manifested in many different ways) which prevents a data subject from exercising their free

will, shall render the consent invalid.

[Example 1]
A mobile app for photo editing asks its users to have their GPS localisation activated for the use of its services.
The app also tells its users it will use the collected data for behavioural advertising purposes. Neither geo-
localisation or online behavioural advertising are necessary for the provision of the photo editing service and
go beyond the delivery of the core service provided. Since users cannot use the app without consenting to these
purposes, the consent cannot be considered as being freely given.

So, if I implement it my way, users will still be able to use my app if they don't give consent (because I won't be closing the app or denying them access to any features). But I will show the consent form every now and then unless or until they give consent or make the in-app purchase to disable ads.

[Liran Barsisa]

Say, if the user hasn't seen the ad-consent UI yet, and we initialize ads and even try to show them (meaning we might get limited ads), and then later show the ad-consent UI and the user changes it, does Admob and others automatically change to handle it (meaning switching to personalized/non-personalized ads)  ?

Also

[Mobile Ads SDK Forum Advisor]

Hi Liran Barsisa,

Thank you for contacting the Mobile Ads SDK support team.

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.!5004Q02r2tJB:ref"

Thanks,
 

Mobile Ads SDK Team

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thanks for your question. As soon as consent is gathered and/or changed, the TC string is written to local storage per the IAB spec. The Google Mobile Ads SDK reads the TC string on every ad request so it will automatically handle this. Feel free to try this out in our Native example. 

Thanks,
Justin

ref:!00D1U01174p.!5004Q02r2tJB:ref

[Liran Barsisa]

1. Your link to the sample actually doesn't show it. There I can see it requests ads only after consent was granted.

Are you saying that after each time the ad-consent dialog appears, we should request a new ad on every native-ad place?

2. Why is the sample of UMP saying we should initialize the ads SDK only after the ad-consent?

I can see the same thing in the link you've provided, of when "initializeMobileAdsSdk" is called, which calls "MobileAds.initialize". 
We can initialize it right away, and just request ads later, no? Meaning this function can be called right in the beginning, no?

3. Native ads aren't automatic at all. Only banner ads are. 

There is sadly no wrapper for native ads that manages its states automatically. We have to implement it all by ourselves.

And sadly Admob still can't show real ads for all cases (limited ads and non-personalized ads). It has ads to show only for the case of personalized ads.

Will you please provide some open sourced wrapper for native ads? One that handles all the various configurations of it, handles the various states, automatically refreshes, etc... ? With options of preloading before showing, automatic release after some time if not used, etc... Now we got this ad-consent on the way too.

It has become quite a lot of work to handle native ads properly. 

[Mobile Ads SDK Forum Advisor]

Hi Liran,

I only shared the Native sample as an arbitrary example because it has a refresh button in the sample. Feel free to experiment with it.

1. I am not saying that. Please read my previous answer. "The Google Mobile Ads SDK reads the TC string on every ad request..." this means that when you make your next ad request after consent has been gathered/updated, the ad request will be treated accordingly. 

2. If you have to initialize the Google Mobile Ads SDK on app launch, that is fine but not something we recommend for implementation purposes. 

3. Thanks for your feedback on native ads. 

[Liran Barsisa]

1. So you say that it should use the latest information automatically, and that the sample doesn't show it and needs to be modified to show it. 
Meaning this condition needs to be removed, so that no matter what, the requesting of a new ad shouldn't be conditioned by the status of ad-consent:

https://github.com/googleads/googleads-mobile-android-examples/blob/main/kotlin/admob/NativeAdvancedExample/app/src/main/java/com/google/android/gms/example/nativeadvancedexample/MainActivity.kt#L84C11-L84C54

    mainActivityBinding.refreshButton.setOnClickListener {
      if (googleMobileAdsConsentManager.canRequestAds) {
        refreshAd()
      }
    }

Sadly though, Admob doesn't really support for a long time the situation of limited-ads (no-consent), causing no-fill errors, and as I heard even non-personal ads are hard to reach.

Any good news about this? 

2. That's actually against what the documentation says for MobileAds.initialize:
"Initializes the Google Mobile Ads SDK.
Call this method as early as possible after the app launches to reduce latency on the session's first ad request.
If this method is not called, the first ad request automatically initializes the Google Mobile Ads SDK"

Why shouldn't we call it before requesting the ad-consent ? We can call it right when we know that ads will probably be needed to be shown, regardless of what later we find about ad-consent. For example, if the user hasn't purchased premium-package, we will call this function as soon as possible, just as written on the docs. It's also quite safe , as the call itself is done automatically anyway when requesting a new ad.

The sample you've linked to is the opposite. It calls inside "initializeMobileAdsSdk" to both MobileAds.initialize and refreshAd , making it the call to MobileAds.initialize a not-needed call at all (because it's called automatically , as written on the docs).

You also said that on every call to request a new ad, it already checks what it needs.

It's safe to do it on the UI thread, right? That's what is done on all samples, and there is no mention of running it on a different thread.

Speaking of documentation, for some reason the IDE doesn't show it on one computer, and shows it fine on another. No idea why as both have same environment and dependencies.

3. Thank you.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

1. I'm only saying what my previous answer says. Please read it carefully. "As soon as consent is gathered and/or changed, the TC string is written to local storage per the IAB spec. The Google Mobile Ads SDK reads the TC string on every ad request so it will automatically handle this." Our samples do not need to be modified to showcase this. 

2. See my previous answer. "If you have to initialize the Google Mobile Ads SDK on app launch, that is fine but not something we recommend for implementation purposes." Please read it carefully. Yes the documentation is correct but as a best practice we recommend explicitly calling MobileAds.initialize. If by "it on the UI thread" you're referring to initializing the SDK it is strongly recommended to call this methods on the main thread. 

[Liran Barsisa]

1. In order to prove in the sample the the SDK does that, you need to request an ad regardless of what has been done with the ad-consent, because it should check the TC string already on its own, doesn't need you to check anything else. 

Before the ad-consent, it will notice the TC string doesn't exist, and therefore use only limited ads.

2. I don't understand. You say it's best to do it as in the docs, as soon as possible, from app launch, so this means it shouldn't be related to ad-consent. App launch means we can even do this in Application.onCreate, or when we see that ads should probably be eventually shown.

What do you mean " for implementation purposes"... This isn't written on the docs and I don't understand what you mean by that either.

If you think that initialization using  MobileAds.initialize shouldn't be this way, please update the documentation and write there that it should be done only after ad-consent says it's ok.

Currently it doesn't mention it at all, and so it should always be fine to call it even without ad-consent being used at all, no matter if it's  " for implementation purposes" or not. 

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thanks for your feedback. The Google Mobile Ads SDK and UMP SDK are independent products. When using the UMP SDK, this is what we recommend. 

[Liran Barsisa]

So talk with one another and have better docs instead of telling me about you being split. 

Doesn't make sense that you say something (and have a sample of it) that contradicts the official docs of Admob.