So in my current project I have only implemented Unity Ads for monetization. I use the rewarded Ads and give the player a good amount of coins and premium currency.
So in order to prevent the player from clicking on the Ad button all the time, instead of playing to farm coins, I need to limit the available Ads per day! How can I check when a new day started to reset the counter? Should I just use a PlayerPrefs variable to save the daily seen ads?
So if you want to limit the ads to once per day, or every 24 hours, or any other time frame, simply save the last time you played an add use that to check if the player is allowed to watch another ad (for example by automatically playing it once the time is up, or by greying the button out, or by showing a timer, or …)
If you want a specific number of ads per day, count the numper per day upwards and dont allow watching any more if the user hits the cap, then when the next day comes reset the counter to 0.
Doesn’t your ad provider limit number of advertisings available for 1 user? I’ve used one popular ad provider before and it say no more ads available after watching few videos, 3-7 usually, and after some times new videos becomes available again.
Yes but still this way the player can watch, lets say 10 ads in a row, and get all the rewards in no time. Would be better to limit the rewarded ads to 5 and make them available every 2 or 3 times a new game started (it is an endless runner).
The rest of the Ads could be banner ads or something with no reward
Yes my idea is to have limited rewarded ads per day (for example 5) and use the rest of the available ads for banners!
After the day passed the rewarded counter resets as you mentioned! Any good solution on how to check if a new day started on mobile?
The date solution should work, mobile or not. Create some struct that contains two numbers; a number representing the year, month and day, as well as the current watched ads counter. You can calculate the first number by, for example, concatenating the now.year, now.month and now.day numbers - so today would be 2019916.
When you want to check if you can play an add, first calculate the number for today again. Then compare it to the number you saved. If it’s the same (2019916), then check the counter for the ads. If it’s below max, play a video and, if successfull, increment the counter by 1. If it’s at max, do nothing.
Eventually a new day will start and the number will be different, for example 2019917 for tomorrow. At that point you set it as a new date number, reset the counter to 0, play an ad and increment the counter by 1 if the ad was played successfully.
If the system is already capped for some amount of ads per day, i’d honestly go with that tho. Couldnt you simply adjust your rewards to fit the amount of videos players can watch? Or do you intentionally plan on decreasing the amounts of videos a player can/has to watch per day, simply because you dont want to annoy them?
From what I know, rewarded videos and playable ads are today most profitable ad monetization, while banners almost not working those days. So not allowing videos in exchange for banners may significant lower your income. Still you idea is good in terms of retention. If you’d allow players watch only 1-5 ads/hour they will be back another hour and another just to get the reward. And eventually will play few sessions just because their attention already attracted to your app. Also I believe you should leave rewarded videos in places like wath video to resurrect or to double game reward always enabled. What I said above applies only to rewarded ad available in game menu, not those what appears from time to time based on gameplay events.
As for implementation, it is quite easy. Add a today date and time in UTC format to player prefs. Add played ads counter there. Now when player presses watch video button you can check this. If counter is less than MaxVideosConstant then show video and increment counter. If couter is more or equals MaxVideosConstant value, then check timestamp. If X hours (1 for instance) has passed, incement the timestamp by X and reset videos count to 0. Otherwise, show player a message how much time he needs to wait before video becomes available on the button or wherever.
You can check current time against previously saved value. For saving values, use playerprefs. For getting current date time, theres an issue with unity and datetime class on mobile, check this thread https://discussions.unity.com/t/674301 , it has been fixed in recent unity version, there’s a list.
There is a problem with this approach. You always need to check the date first. Using the above approach, the user can actually watch nearly twice as many videos in one hour, assuming he only watched one in the previous hour. Example:
Let’s say hour 13 the user watches 1 video, the maxCount is 5. He waits an hour, so it’s hour 14 now. However, we dont check for that since the counter is below max, so the user gets to watch 4 videos. Now we check the time, see that it’s 14, increment the timestamp and reset the counter, enabling the user to watch 5 more videos, for a total of 9 this hour.
While he did not get to watch more than 2*5 videos over 2 hours, it’s probably not the desired behavior.
Checking the date first prevents this, as described in my post above.
Of course, this may actually be the desired behavior, i just thought i’d mention it.
Thank you so much for the help! I have to think about the best way to implement the idea in order to keep players interested in the rewards every couple of hours. I will store the values in the PlayerPrefs since they are not so much important as the progress data which will be saved using playstore saved games function
Be careful with playerprefs, as someone could simply clear the data and then relog in or simply switch to another device to play more ads.
In one of our games, we save this data to our backend (we use playfab for this one) and it is downloaded at the start of the game with the timestamp, then we can use that to resume our time limit before ads open up again. Or, if they are in game still, the timer runs it’s course.