Hey raft, thank you for the amazing updates on this feature! I’m extremely excited to implement these into my game.
However, I can’t seem to find in the documentation or in this thread how I would be able to get a list/array of the roblox users who have opted in to notifications. I wouldn’t want to be sending notifications to users who aren’t opted in would I?
Is there a way to see check if a user is opted in?
Currently, to notify players about certain time-sensitive events, such as daily rewards, it seems necessary to run a background server to continuously scan the datastores which is very much a nuisance.
It would be incredibly beneficial if we could specify a ‘publish time’ within the payload to specify how long from now the notification should be published to the player.
If the player enters the experience within the ‘publish time’, the publishing of the notification should be cancelled.
Could look something like this:
local userNotification = {
payload = {
messageId = id,
type = "MOMENT"
publishTime = {
Days = <number>,
Minutes = <number>
}
}
}
local result = OCUserNotification.createUserNotification(recipientPlayerID, userNotification)
We’re excited to share that we will be relaxing the max limit of notifications to 1 per day per user for each experience. Previously, the frequency limit was 1 notification per 3 days per user for each experience. We hope this update provides you with more agency to engage and retain your users. For more details, please see our post on this update.
I attempted to send notifications to 100 players at once and got throttled, however with a delay of 1 between each prompt, I haven’t ran into issues so far, and I sent about ~200.
[500]
UNEXPECTED_ERROR
Too many requests to Open Cloud.
It would still be nice if we could get an official statement though, the documentation is pretty lacking and I had to find some things out on my own
(like status code 429 meaning the user is on notification cooldown, and 400 meaning that they don’t have notifications enabled)
[429]
RESOURCE_EXHAUSTED
You can only send 1 notification per recipient every 3 days.
For testing, use the universe owner user id as recipient to skip the check.
[400]
FAILED_PRECONDITION
User XXXXXXXXX391 is not opted in to receive notifications
for your experience 5538027221.
Unfortunately I have not been able to verify that there is or isn’t a limit. I did find out that there is no limit for sending notifications to yourself though.
What code are you using to send these notifications en-masse like that? I am wondering since the game I would like to do this on has quite a lot of players that I would have to send this out to, and I am wondering how you get a list of those users, if you aren’t using something like DataStores.
Hi Dapale there’s no limit on how many notifications you can send per week.
There are limits based on rules below though:
Each recipient must be eligible to receive the notification from your experience. Otherwise an error (e.g. 400) will be returned
Each recipient has per experience and aggregated daily limit. The notification won’t be delivered (returning 429 error) when limit is exceeded
There’s a generic API requests per second (RPS) limit to prevent one single client from overloading the system. We don’t publish the limit but as long as you have very basic pacing (e.g. limit to <100 request per second) the requests should go through.
It’s possible to build your own notification scheduler using MemoryStore sorted maps with some creative thinking. My best guess is scheduling will release in a future version of notifications, and is why there has been no comment from Roblox on it.
I think this won’t close at November 15th. do not worry about the end date. Roblox Studio will be so old at the end date. 2024-07-23T05:00:00Z→9999-05-31T06:00:00Z. You should prepare for nofications that say that your experince is bugging. and prepare for elsewhere nofications!
Is there any chance for a proper server-sided way to determine whether a user has enabled notifications or is eligible to enable them for a particular experience? Relaying such checks on an error message in my opinion is very impractical therefore the ExperienceNotificationService should be extended to the server side.