Rewarded ads: server-side callback not called if user is briefly offline

[Elena]

There are rewarded ads in my Android app. There is a server-side verification (SSV) callback set up. Everything is working if the user has a stable network connection: ads are showing, the callback is called, user gets a reward. However, if the user's internet is unstable, the following happens - I can reproduce it on my own device if I'm quick with the "flight mode" button:

0. The user has a working internet connection.

1. The app loads the ad, initialises it, waiting to show.

2. The user clicks on the "get reward" button. The ad starts to play. All is well so far.

3. The user's connection goes offline briefly.

4. The ad finishes to play, the OnUserEarnedRewardListener::onUserEarnedReward callback is called, the user gets the reward.

5. The user's connection is restored.

6. The SSV callback is never called after that. The reward therefore can never be validated and it seems to the server as if the user did something fradulent.

I was following this instruction: https://developers.google.com/admob/android/rewarded?hl=en-US.

My code to set the SSV parameters in the Android app:

​ServerSideVerificationOptions options = new ServerSideVerificationOptions

.Builder()
.setCustomData(customData)
.setUserId(userId)
.build();
mRewardedAd.setServerSideVerificationOptions(options);

The logs that I added to every step show that the impression has been recorded. The logs in the app are exactly the same as if the user had been online all the time; so I doubt if there is a problem with my implementation - although, of course, it is possible.

It seems like a bug to me that admob doesn't send the SSV callback in such a case. Is there no retry in the android admob library to retry whatever it does if the user is briefly offline?

How can I deal with this problem and get the SSV callbacks even if the user's internet connection is patchy?

Thank you in advance for your reply!

[Mobile Ads SDK Forum Advisor]

Hi Elena,

Thank you for reporting this to us. Could you please provide the following as well via reply privately to author option as well?

• AdMob Ad unit ID
• Rewarded ad unit

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

Hi Teejay,

Thank you for your quick reply. I have just replied with the info you asked for.

I also sent you some info about 2 times I watched the ad: once when I went offline in the middle of it (and reproduced the problem: no SSV callback) and once when I was online all the time (and the SSV callback went through). I hope this will help you pinpoint the problem.

Please let me know if you need more info. I really hope you can help me understand what's going wrong. Perhaps there is a problem in my code or environment, I will be super grateful if you could help me solve this.

Thank you very much.

[Mobile Ads SDK Forum Advisor]

Hi Elena,

 

Thank you for providing the requested information. However, for us to further investigate this behavior you've experienced, can you provide us with a Charles log of the issue privately? Being that SSV is dependent on a network request from another server, we need to verify that this connection is working correctly. You can follow the instructions for collecting this data. Kindly provide us also a screen recording of your replication as additional information for our investigation. You can provide the following details via Reply privately to author option or directly provide it to the link below.

 

• https://developers.google.com/admob/android/charles
• https://developers.google.com/admob/android/network-tracing

 

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=5004Q00002g1T6JQAU&entry.80707362=00156536

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.

 

Regards,

Princess Pamela Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

Hello,

I have just submitted the files, I hope it helps. Please let me know if you have any more questions.

Thank you!

[Mobile Ads SDK Forum Advisor]

Hi Elena,

Thank you for providing the requested details. However, as per checking with your Charles log, it appears that the SSL Proxy was not turned on and thus, no traffic data were gathered (please see attached screenshot). With this, could you please follow this guide (specifically to number 4 instruction) and provide to us again the Charles log again? Kindly send it using the steps provided by my colleague on this thread.

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

Oh, I am sorry about that, I must have missed a whole chunk of instructions.

I have uploaded a new set of files, maybe second time's the charm:).

Thanks!

[Mobile Ads SDK Forum Advisor]

Hi Elena,

 

Thank you for providing the requested information. However, the newly provided Charles log and the previously provided are still the same which is doesn't capture any request as it seems that the SSL proxy is not enable and the other error is that the certificate is unknown. As my colleague mentioned, can you confirm if you're able to follow this guide (specifically to number 4 instruction)? In addition to that, you may check below some guide that one of my previous colleague used in capturing Charles Log. Kindly try it again as this is needed for us to further check the behavior you reported on the server side. You can provide the following details via Reply privately to author option or directly provide it to the link below.

 

A Charles log is a saved session in the Charles app, you can go to File-> Save Session.

 

This is what to do on a MAC to capture SSL traffic from a device to a Charles log:

• Run the app that is set up to show SSL traffic while the device is connected to the computer and the Charles app is running on the computer
• The wifi network of the device has a manual proxy set the way Charles shows when clicking on 'Help->SSL Proxying->Install Charles Root Certificate on a mobile device or a remote browser'.
• Make sure that “enable debug logging for ads” is enabled under, privacy -> ads, in your device or emulator (only applicable for Android)
• Charles is set to show plain text SSL requests and responses for all locations, you can look up how to do this in Charles help.
• You can run a sample from Android studio to the connected device.

 

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=5004Q00002g1T6JQAU&entry.80707362=00156536

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.

 

Regards,

Princess Pamela Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

I know what happened. The emulator reset all settings when I was restarting it to switch between running separately (to set up the proxy) and running inside Android studio (as I usually run it). Sorry about that.

I have attached new logs again, and included the logcat output (single record of all 3 sessions) as well. I hope this will help.

[Mobile Ads SDK Forum Advisor]

Hi Elena,

Thank you for your patience and continuously providing our request. However, I'm afraid that the Charles that you provided still didn't capture the network traffic due to SSL proxy configuration on your end (please see attached screenshot). The charles proxy is a vital information for us to investigate your use case further. You may also want to check this article which contains detailed information on capturing network traffic using Charles log. Once done, kindly provide the chls files to us once again, so we could validate it on our end.

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

Hello,

In your screenshot you are looking at try_2, and this morning I've uploaded try_3 files - could you please take a look at those? I.e. `try_3_session_3_failure__wifi_off.chls`. For the proxy settings in Charles, I've set host and port to *:*, so there is a lot of traffic captured, including probably unrelated requests.

I don't see any "ssl proxying not enabled" requests in try 3, so I still have hope for those =).

I apologize again for sending you so many incorrect files. If try_3 f are still invalid, I'm ready to try again, even though I'm not entirely sure what else could go wrong.

Have you tried to reproduce on your side using the videos I provided?

[Elena]

I've just submitted try_3 files again, just in case they didn't go through last time. Please take a look at them. Thank you for your patience!

[Mobile Ads SDK Forum Advisor]

Hi Elena,

 

Thank you for your response.

 

Upon checking, it seems that it doesn't include the network traffic for AdMob. The network traffic should contain either of the following:

• AdMob request URL - https://googleads.g.doubleclick.net/mads/gma
• Ad Manager request URL - https://pubads.g.doubleclick.net/gampad/ads

Let me share this to the wider team to further assist you on your concern for the SSV as well as the capturing of the Charles Log. Rest assured that one of our team will reach out to you.

 

Regards,

Princess Pamela Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2g1T6J:ref

[Mobile Ads SDK Forum Advisor]

Hi Elena,

Thank you for providing that information. The Charles logs you sent are still missing the information we need to further diagnose the issue. However, what you experiencing with the internet connectivity/ssv callback is the intended behavior. There is no retry logic from our SDK to ping the server so that is why you are seeing the `OnUserEarnedRewardListener::onUserEarnedReward` callback but nothing from the server. I have filed a feature request on your behalf and forwarded to the Android SDK team.

As far as https://developers.google.com/admob/android/rewarded?hl=en-US, that snippet has no bearing on the SSV callback. That snippets just adds the ability to include extra parameters. 

A Charles valid log (I've attached an example what the logs should look like) would be helpful in confirming the behavior but the issue itself is currently intended. If the user's internet connection is "patchy" the expectation is the SSV callback should still occur as long as the connection is not absent as with Airplane mode. 

Thanks,
Justin

ref:_00D1U1174p._5004Q2g1T6J:ref

[Elena]

Hello Justin,

Thank you for your reply.

I think that all requests are recorded in the log, but instead of the hostname it shows the IP address. I don't really know why, there is probably a setting in Charles somewhere. I see requests to my own server also with an IP address.

However, what you are saying about the "intended logic" sounds very surprising to me. This is not mentioned in any documentation I read, and is not how I would expect server callbacks to work. Your documentation says there are retries in case my SSV callback is unavailable (five times in one-second intervals) and nothing about this problem we are discussing. The current implementation makes server validation absolutely useless if there is no guaranteed delivery. How can I validate that the user did indeed watch the ad and got the reward and not just sends a request to my server if the callback is not guaranteed to be called?

Also, I am, of course, not familiar with your architecture, but why is the mobile app SDK calling the SSV callback? I am not sure I understand you correctly, but this is the only explanation I could think of that depends on the phone connectivity? If this is true, it would also be super easy to make fraudulent requests.

Previously, I assumed that the mobile app registers the "ad watched" event with the AdMob server, and then the AdMob server calls the SSV callback. This approach would make more sense. But then either the SSV callback is disconnected from the "ad watched" event (why would it be?) or the "ad watched" event is not being registered at all if the phone has a patchy connection.

Thank you for creating a ticket with your team. I hope you will solve it soon and change the "at most once" logic to "at least once".

[Mobile Ads SDK Forum Advisor]

Hi Elena,

Thank you for your questions. The retry logic you are mentioning is delegated server-side, not the Google Mobile Ads SDK. It is the responsibility of the Google Mobile Ads SDK to determine when to begin the SSV flow. A patchy connection is acceptable for the SDK to begin the SSV flow, it is an absolute no connection (such as airplane mode) that may result in an unexpected experience. The feature request previously filed has been forwarded to the Android SDK team.