[MUSIC PLAYING]
AMRIT SANJEEV: Hi, everyone.
I'm Amrit.
I'm a developer advocate at Google.
And today I want to talk about push notifications
and how internet developers are hacking to get the delivery
rates a little higher in the region.
So let me talk about one of the stats about India.
We have about 340 million plus smartphone users.
And it's growing at a 16% year-on-year growth
rate, which means that your apps have a great chance
to acquire more users and have great business in the region.
But along with this business, you have--
also comes with a lot of competition.
So there is a greater need to have a better engagement,
as well as delighting your users.
And push notifications is one of the mechanisms
a lot of developers use in order to engage your users.
When it comes a push notification delivery rates.
Some of these patterns in India actually
affect the notification delivery rates.
One of them is the user behavior.
Until recently, data plans were very expensive for us
in the region.
And people had tended to have the habit of turning off
mobile data when they are not using internet.
So when they go out of a Wi-Fi zone,
they just turned their mobile data off.
And that changes the behavior of something
like a time to live parameter for your push notification.
If you have a really short one and the person
has turned the data off during that period,
your notification never gets delivered.
Recently we had new carriers who have come in
and have reduced the data cost drastically.
And now this user behavior is slowly changing.
But it hasn't changed enough for you to ignore this change.
Secondly, we have a lot of devices with custom behavior
or custom Android bills, where your notification--
and because of battery optimization,
they kill off these notifications services.
They sometimes force close apps, which
avoids the app from ever getting the notification delivered
to it.
So that's another problem.
Your time to live parameter, if you actually
increase it by, say, from four to eight hours, you
see a drastic improvement in--
or a large improvement in notification delivery
because you might end up overlapping
with a Wi-Fi usage time.
So things like that make it very interesting.
Like in any other region, notification frequency also--
the number of notifications that are sent in to the users--
also affect.
And people do get irritated and turn off notifications
if you do it too many times.
So using collapsible keys and things like that
are very important here.
Now I want to talk about three design patterns that developers
have actually tried out for various use cases
to improve notification delivery.
One is bucketing of notifications.
This gives you a better understanding of your user base
and how people are-- how each of these buckets
actually work better for you.
Let me explain that.
The mechanism that they've developed here
is that there's a job that-- a periodic job-- that runs,
refreshes the FCM token, sends it to the server.
And when the server gets the data,
it actually keeps a user FCM token mapping along
with the recency of update.
It'll also take the time stamp of the update.
Now when you send out a campaign, what they would do
is they would split it based on recency.
Say for example, you would send your push notifications
in the first batch to all the tokens
that were updated in the last say, seven days.
Then the next batch would be to update from 7 to 31 days,
all the tokens that got updated in the last--
from seven to the 31 days.
And third batch would be 31 and above.
What this allows is that you can fine tune
each of these buckets--
the parameters for each of these buckets--
to improve notification delivery.
You also have a better understanding of who
your users--
which users would get the notification
and might react to your notification better.
And your-- and because you have a lot of tokens, which are not
updated frequently, or the users never send that update cycle,
you don't end up calculating that into your notification
delivery and miscalculating the effectiveness of push
notifications.
The second one is basically where
you have, again, a [INAUDIBLE] job that comes in.
It checks whether a notification was
delivered to the device from the last run or not.
If not, it'll go to a REST service, pull the notification,
and then display to the user.
This is fairly simple to use.
But you have to ensure that this does not excessively wake
up the device.
So this is not the most effective or efficient way
of doing things.
But still works for it.
The last one I want to call out is
data messages to the schedule.
In a case where you want to send a message like,
hey, there's a sale that's going to start at 12:00.
And you want to show the message to [INAUDIBLE] for next six
hours, you have 20% off on this device, or on this service.
Where, instead of sending it on 12:00
and hoping that most of the users would receive it,
what they will do is they will send this message
maybe two days before with the last time to live.
And they-- as a data message.
So the app would receive it.
Then based on the schedule that's within the data message,
they would schedule a job to come up
at exactly the right time and display the message
to the user, which means at 12:00 a lot more of your users
will start getting that data.
[BEEPING]
SPEAKER 1: That would be times up.
[GONG]
All right.
Thank you.
[MUSIC PLAYING]