Quick demo of OneSignal's core features.
OneSignal's Support Engineer, Jon Fishman, goes over how you can make the most of OneSignal's robust features. The transcript of the webinar can be found below.
Jon: All right, everybody, my name is Jon. I am a support engineer at OneSignal.
Today, we're going to go over the OneSignal platform, do a dive into the products, how to use it. Certain things I'll go into more depth than others. We have other videos on certain things like segments and other webinars dedicated to in-app messaging and things like that. So, I won't go over too much of those, but I would like to highlight a couple of things like the A/B testing feature and automated messages.
So, without further ado, we'll get started. If you have any questions, feel free to post them in the chat or in the Q and A, and then I'll answer them towards the end of the session.
So, once you log in and create a onesignal.com account, you'll see a page very similar to this. Someone says there's a lot of feedback. Is everybody experiencing feedback? Is that better? Maybe no. I hear no feedback. Okay. Well, Jody, I'm sorry if there's an issue. I'll do my best to control it, but it seems others are not having issues. So, I'm just going to try to continue here.
But once you log into your OneSignal dashboard, you'll see a page very similar to this. These are all your OneSignal apps. So, OneSignal app basically houses your websites and mobile apps together under a single app ID. So, generally, if you have multiple websites or if you have like production versus staging and testing environments, you'll want to separate OneSignal apps for each of those different things. So, if you have two different Android apps, you would have two different OneSignal app IDs. If you have a website like mysite.com and then maybe like a subdomain.mysite.com, those would also need separate OneSignal apps.
And then you'll see some basic stats over here. Most of it is pretty self-explanatory. Once you click into the app, you will see an overview of the app data. So, subscribed users, this is how many devices have actually opted in to push notifications.
For web and iOS, the user needs to select ALLOW on the native prompt. IOs does have provisional notifications, so they don't actually have to do that if you have provisional notifications set up. But in most cases, you'll want to get users to opt-in. Android mobile apps subscribed users happen when they download and open the app for the first time.
Monthly active, this is actually just an estimate on how many devices are active every month based on your total users. So, it's not an exact number of how many devices are actually using your app or website every single month. It's just an estimate based off of total users, which is subscribed plus unsubscribed devices.
Here you'll see a graph on the total users. You can change that by platform. So, if I wanted to see how many iOS users I've received in the past day, month or year, you can toggle those. You can also see it by Chrome, Firefox, and Safari.
Revoked is actually an interesting metric. This is how many devices have subscribed to your app or website at one point. And then they unsubscribe, but continue to use the app or website. For mobile apps, this happens if they go into the app settings and then turn off notifications and then continue then open the app later and continue to use the app. For web, this is if they actually unsubscribed using either the OneSignal bell or custom link prompts. Or in both cases, we have this method called "set subscription", which will actually unsubscribe the device from OneSignal. It does not unsubscribe or subscribe a device from APNS or FCM directly. The set subscription method only unsubscribes them from OneSignal if they've been subscribed already. Maybe that's a little bit too much into the weeds right now. But if you had, just we’re curious about that.
The next thing I'd like to do is go into the audience section. So, here you'll see all the different segments that you can create with OneSignal. I won't go into too much about segments because I have a lot of videos on this already in our documentation under the Segments Guide, but I do want to highlight a couple of things about the data that OneSignal collects in the all-users tab.
So, OneSignal collects a lot of data automatically for you. You can actually toggle this data here and see all the different things you can select. I'll just have everything open right now. So, for a channel, this is if they're a push or email subscriber. We do separate push and email subscribers because if somebody were to unsubscribe from the website or mobile app for push but they provided you their email, then you can still send them emails and possibly get them to re-subscribe or at least continue communication with those users.
OneSignal doesn't automatically collect email. You would send that to us from our SDK or through our API or even through our dashboard. You can actually manually add emails or import emails by CSV.
So, we clicked the channel, we clicked if they're subscribed or not subscribed. The last time they were active, this is the last time that they actually used the app or website with the OneSignal SDK initialized.
First Session is the first time that they interacted with your app or website with the OneSignal SDK initialized. Generally, this is the first time the user subscribes to the websites. But for mobile apps, this is the first time they downloaded or updated the app with the OneSignal SDK active. It's also the first time that the email record was created or sent to us.
We track devices. We track sessions. A session is how many times they've opened the app from a fresh start or have been in the app for at least 30 seconds or website.
App Version, this is sent to us from your Android app [07:35 inaudible] or your Xcode build number.
Country, this is detected by the IP address. So, whatever IP address we detect from the device, that's what we set as the country that the IP is from.
We also detect the actual IP address. If you do not want the IP addresses collected, we can turn them off for you so we can disable and prevent tracking of the actual IP address being saved on our servers.
SDK Version, this is the version of the OneSignal SDK being used in the app or website.
Rooted, this is just if the Android device is rooted.
Location Points, this is also not collected automatically unless you have location tracking turned on and the user agreed to it. This is generally only for mobile apps. You can detect location through tags on web if you want. There's a guide on how to do that in our documentation.
If your app is detecting location but you don't want to send it to OneSignal, you can also turn that off as well.
Usage Duration, this is how many seconds in total the user has had the mobile app open. So, if I had the app open for a minute yesterday and then five minutes today, the usage duration would be six minutes in seconds total here.
Language Code, we do detect the device or browser language. So, if that changes and then the user interacts with the app or website, it will be updated.
Player ID, this is the OneSignal generated ID for each device. You have no control over creating the player ID. It is created automatically. Each device will get a unique player ID. So, if you have maybe an iOS app, an Android app and a website, all three of them, if you're subscribed or create a player record, they will each have separate player IDs. So, you could either collect those through our SDK and then send them to your database if you wanted to target users directly. Or when the user logs in, you can actually fetch your own database or CRM ID and add it to the user with our external user ID method. It's called the "set external user ID".
So, basically, a user logs in to your app or website, you contact your server, you get all their information, like their email or pictures or whatever you collect, and then you can actually add that external user ID to the device. So, if I had multiple devices as a single user, they could all be tied to a single external user ID and you can target them with push notifications by that external user ID. You just need to send this to us using our SDK or through our API.
Segments, this is just a list of the segments that the devices currently in.
Tags are the ability to set custom key-value pair of data to users. The key and value can be a string or integer data. It cannot be array data. So, string or integer data, you can use that to create segments. You can use this for tag variable substitution. So, if I wanted to collect all my user's names and then I wanted to say like, "Hey, username, how are you?" or "Hey, username, you have a new update," you can actually put that in the notification. And instead of username, it would actually show up whatever the tag is. You can set default values as well. So, if you wanted to customize notifications or put custom data in the notifications, please see our notification personalization docs for how to do that.
You can also set time operators, so a UNIX timestamp, and that will actually detect how long it's been since that tag has been added, which provides a lot of cool functionality like abandoned carts and things like that. We have guides on time operators and Abandoned Cart Guide for more details on that.
Email, this is only for the email records. If you wanted to tie an email to a push record, you would do that with tags.
The push token is basically the authorization token from Google or Apple that says that this device is capable or authenticated to receive notifications.
A couple of other things from this page, you can actually sort by the different segments that you have created already. If I were to change segments, if I had this segment selected, just so you saw, I clicked on the numbers here, that will actually open up the all-users page but based on the segment.
I can actually export all this data. So, this is available on free and paid plans. You can export the user data. Whatever columns you see visible currently, those are the columns that will be exported to your email. So, if I wanted just a certain value or only a couple of columns, I can remove the ones I don't want.
Also, you can delete users. So, for example, in this segment, these are devices that haven't used my app and/or website in over six months. So, if I don't want these devices anymore, I can go ahead and delete them. Any device that you delete, if it's web, they clear their browser cache and return to the site, then they will get recreated. If it's a mobile app, if they just simply open the app again, they'll get recreated, just so you're aware.
Also, if you're on a paid plan, you can actually import user tags and external user ID to devices. So, if you're currently tracking external user IDs and/or player ID on your backend and you have a bunch of tags or attributes that you want to add to the user, you can actually send us a CSV of those data based on the external user ID or player ID or both and we'll update the records in OneSignal based on that CSV.
One more thing to highlight is the option to add test users. So, let's say you're looking for your device and you find it based on the device and maybe the IP address or maybe other tags that you're using or if you're logging the player ID to your dashboard, to your console, you can then find your device and say, "Oh, here's my device," and add test users. And then this is my Jon device. And now I can just send myself test notifications. Great. So, that is all I'm going to go over for this page.
The next thing to a highlight is that, with all this data, you can create segments. Please see our segments guide for a lot more insight into that. Once you create all that, you can now send messages from the dashboard. You can send push notifications emails if you have emails set up. Currently, OneSignal supports email integration with SendGrid, Mandrill, and Mailgun. And then if you have mobile apps, you can actually send in-app messages. We have some great guides on in-app message creation in other webinars and other videos in our documentation. So, I won't get into that too much today.
But for push, it's like new push. Here I define my audience so I can target a segment. If I want to target all my subscribed user segments, I can add multiple segments. So, basically, I want to target my active users and my iOS users maybe. If I had users that were in both segments, so basically, all my iOS users, but then also I had some iOS users inside the active user segment, they won't get duplicate notifications. They'll just get one notification, even if they're in both segments.
But you can also exclude segments. So, maybe if I wanted to exclude my engaged users, if a user is inside these segments and these segments, they will not get the notification. So, they'll just be excluded from getting the notification.
Here I create my message. All notifications need to have this English parameter here. It doesn't have to actually be an English message. So, if you want all your notifications in Spanish or Hebrew or German or whatever language you want, you can actually just put whatever language here and all notifications will get this. So, think of English as just like default. This is just like the required one that all notifications will get.
But if you wanted to send multiple languages, maybe you did want an English message, but then also you wanted to target... let's see. I got two French speakers, one Greek, two Russians, 25 Korean that's from testing. I can just select all the ones I want. And then we won't automatically translate the message for you, but you could add the different languages, the different copies you want. And then in one of my devices, if they're French, Greek or Russian and they're in these segments not being excluded, then they'll get whatever message I put here. But if I had a Hebrew speaker or another language that's not listed here, it'll just default to English. So, they give English as just the default.
So, this is English, but really the default message. You probably put better notifications in that. Your users might not want Ladidda, but whatever works for your notifications.
You can also add your image here. So, the image will actually work across all the different platforms. The recommended image size is a 2:1 aspect ratio. That's just generally the best image format for all the different devices.
And then you can also add your Launch URL. So, the way that this works is that if I wanted my web users to go to onesignal.com, but maybe I want a deep link for my mobile app users, you would select this little checkbox here.
The Web URL, this is what we'll go to the website users.
The App URL, if a mobile app clicks a notification, they'll actually open this URL in an internet browser. If you don't want that, if you want a deep link, you could actually just remove this. And then down in the data column down here, you can add 'deepLink' key and then you can say 'profile page' or your 'activity feed' or whatever. And then basically, once the notification gets received, you can then handle capturing this data in the notification opened events of our SDK and then deep link into the activity page or deep link into whatever page you want based on the key-value pair of data here.
More details and example code on how to do that is in our deep link guide. But just to highlight what's going on here, I can now basically see all the different platforms that I have. So, if I wanted to see... This is like a general idea of what the notification looked like on Android, on iOS and then on web for Chrome on Mac. Keep in mind that Chrome on Mac doesn't actually support the big image anymore. They stopped that a while ago back in Chrome 59, I believe. Hopefully, they bring it back someday, but there's no word on that. But for Chrome on windows, it does support the big image. And then Chrome on Android, it does support web push with the big image.
Keep in mind that this isn't what the exact notification will look like. This is just a general idea. If you wanted to actually see what the actual notification will look like, it's best to send yourself a test notification, so I can select all my test devices, send to myself, and then I can just basically see what that looks like.
I have a question actually that pops up. Let me see if I can... I'll answer that towards the end.
So, going forward, we then get into the more platform-specific parameters like badges. So, Android and iOS support the little badges. Those are the red little dots with the numbers on it. You can actually set that to a specific number. So, if I wanted to be 999 if I really wanted to, I could or I could just increase by that many or 1.
You can also add sounds. So, if you wanted to have a cool, money sound if the person did a trade confirmation or like an explosion if something exploded, you can do all that.
Image or media here, so even if you add the image here, if you wanted to specify a different image for a specific platform, you can do that as well. So, maybe for iOS, you want a different image. Or for Android, you want a different image. You can absolutely do that.
With Android, most of these options are now under the Android category. You can actually set up categories in the OneSignal settings page under 'Categories' or something like that. You can actually set those up there. Or if you have categories that have programmatically, you can do that. Android has a couple of other things like sound, LED color, accent colors, and small icons. You can set those there as well.
For web, web is a little bit less customizable. You can do an icon. So, the icon is actually like a little icon you see there on the right. But like we saw earlier, you can change the image. The badge on web, this is actually for Android Chrome. Android Chrome has this little tiny, custom little badge you can use. You can actually upload that or create that, put that URL here and we'll use that. Otherwise, it's going to just default to a little bell icon. And then if you want action buttons for web, we would set those up here.
Safari, Edge, and Firefox are more limited in what they support. For additional data like we saw earlier with deep links, basically, this is any data that you want to put into the notification. So, if you're deep linking or if you wanted to tell your server to download something, you can do all that with the additional data fields. Just add those perimeters here. And then when the notification gets received or clicks, we have different event handlers that can then read the data here and then do whatever that needs to be done with that data.
Collapse ID, this is if like I add something here or whatever. If I have multiple notifications with this same thing here, then the first notification will be replaced by the second notification if it's still on a device. So, if I basically have a Collapse ID of 12, if I still have a notification previously with the Collapse ID of 12, the next notification with Collapse ID of 12 will replace it if it's still on my device. So, it's just a great way to help remove multiple notifications from the device if you don't want to have your app showing tons of notifications on the user's device at one time if they haven't clicked them yet.
Other Core Features
Priority, this is less and less helpful now that Android 8+ doesn't really use it anymore. Instead, they switched to importance, which is set through the Android category. Up here. So, you don't really need to set this. It will always default to normal on Android unless you set up a high or you set up a category with high importance. For iOS, it always defaults to high. In most cases, this is just basically like, "Do you want the notification to show if the device has low power mode or low battery?" That's generally what it's used for.
Time to Live, this is how long the notification will live on the Google and Apple servers before it is sent to your user's device. A common example is the device is offline. If I go camping or I have my device turned off for an extended period of time, Google and Apple will hold the notification for three days by default. But you can basically set this to one second. So, basically, if the device is not online when the user gets the certification, they basically will just not get it. They'll just get discarded. The longest you can set this for is 28 days, which is like 2 million something seconds. More details on that in our documentation. And then if you ever want to know where the documentation is, whenever you highlight your mouse over something, there's usually a link that you can then go to and it will tell you more information.
And then the Action Buttons here, these are for mobile apps. You can set your ID, so 'id1'. The text is what the user will see, so 'This is what user sees.' And then an icon, we can put a URL to the icon. Id1, this is basically like what you'll detect programmatically in your click handler to detect that, "Okay. They clicked button one with id1. Do whatever you need to do with that information."
The last thing to talk about here is scheduling. Delivery, this is when the notification starts to be sent from the OneSignal servers. So, if I want to send this notification two hours from now and two days from now, one and a half weeks from now, it's up to a month, so you can basically put whatever date you want here and you can validate that it's the correct time here. It's the time zone set on your operating system. So, if you change your operating system time zone, then this should change here.
And then the Per User Optimizations, this is basically 'sends the notification now' and then 'send it to all users now', or I can optimize my time zone. So, send a notification now, but only deliver the notification at 8:20 PM in each user's local time zone. If it's already past the time zone, if it's like 8:21 in my time zone, I'll actually get this at 8:20 the next day. So, it's on a 24-hour period.
Intelligent Delivery, this is based on the users viewing habits of your app or website. It's over a three-month period. So, if I use your app or website around 3:00, sometimes around 6:00, but usually around 3:00, then we'll send a notification around 3:00. If I start to more and more use the app or website around 6:00, then we'll send a notification around 6:00. It's just based off of how many times I've opened the app and what time it was over a three-month moving average.
Great. Now that that's all set up, I can save it as a draft if I want to. Then I can resend it later or I can click CONFIRM. So, it looks great. I send it. And then from there, it actually takes me to the delivery page with the message report of the information. As users start clicking the notification, I should see my stats here. I can see how many were delivered, how many were failed because they unsubscribed.
It's important to know that if a device clears their browser cache or unsubscribes from the app or uninstalls the app and either way, it does not open the app again, upon the second notification we send to the user, that's when we detect that the user's unsubscribed. So, like Google and Apple, they don't tell us that the user unsubscribed on the first notification. They tell us on the second notification. So, they mark it in their system and they don't tell us. And then on the second notification you send them, then they're like, "Oh wait, we're not going to accept this device anymore because they unsubscribed." So, we're like, "Okay, great." We'll mark that in our system as unsubscribed and then we won't send to that user anymore on the next notification.
Also, one more thing about this, Apple recently made a change where they don't tell us right away like they used to. They now wait a week and then tell us that the user unsubscribed. So, if you're testing and you're unsubscribing from notifications and you're sending yourself notifications and you're like, "Well, I unsubscribed, but it's still showing as delivered," well, if you wait a week, then Apple will finally tell us that, "Okay, this user unsubscribed." However, if you opened the app, at that point, our SDK will then detect that the user is unsubscribed and it will mark it automatically and it will also increase that revoked count we saw earlier.
Error, this means there's an error going on and we usually explain what that error is in the Settings page.
Quick chat from Romaine. "Hi, can we automatically send a push notification to users after they installed the app, like send push after day one and send push after day two, etc.?
Yup. Great question, Romaine. I'm actually going to get to that very, very shortly.
So, there are other things here. And unfortunately, this is like a demo account, so it's not super great data, but we have added the option to add outcomes. So, an outcome is basically a piece of code that you can add into your app and soon website that once it's triggered, you can then detect that this happened based off of notification or based off of influence by notification.
So, for example, let's say that I want my users to update their profile image, right? So, in my app, in the code that I have that updates the profile image, I just add basically a little snippet of code. It's like onesignal.setoutcome. And then I would call it like 'Nate's custom outcome', or I would call it like 'updated profile' or maybe they make a purchase and so update like 'purchase amount'.
So, once they perform that action and trigger that piece of code, if that occurred from a notification click, so these are clicked notification, and then perform that action, we can then attribute that outcome to a notification. If they received a notification but they didn't click the notification, but they still perform the action within a timeframe of receiving the notification, that would be an influenced. So, you can actually set the influence count by 24 hours, one hour or I think it's like 10 or 15 minutes. If I had gotten notification and I didn't click it, but I go into the app and then I perform that action, that would be an influenced open. I hope that was clear. That is a paid feature, if you're wanting that feature.
Back into the delivery page, we then see all the notifications that we've sent. Any notifications sent by our API or automated notifications, those are only kept in our system for 30 days. So, you would need to export those notifications. You can do that from the dashboard here or you can actually use our API to export notification data.
A couple of other things, since we're here, is you can actually sort notifications by all or dashboard sent or API sent, automated or test. You can actually also sort by the device type. So, if I'm looking for notifications sent to iOS users, I can select iOS and click search. And then we'll only populate notifications that were sent to iOS. They could also be sent to other platforms as well, but they must have been sent to iOS users.
A couple of other advanced things. Some people are wondering, why is content blacked out? Well, right now, you can only sort content if you select Dashboard. Not super intuitive right now, but we'll fix that soon. You can sort content by heading or the message. Content is the message. So, if I'm looking for a notification that said like Ladidda, I knew it was sent within the past week, you can set the start date and end date and click search. And then here's my 'Ladidda'.
Scheduled Messages, these are notifications that you actually put the starting time that we saw earlier. I'll show up here.
And then Outcomes, this is also if you want to just to see how all your outcomes are doing. You would add the outcomes here.
So, again, direct is like the outcome occurred due to clicking the notification and then the user performed the action. An influenced is the user performed the action within a certain time period from receiving the notification. Unattributed just means they performed the action but not from a notification within the notification time.
Great. So, there are a couple of things that I wanted to dig into a little bit deeper. We've got a little more time here. So, to dive into Romaine's question about setting up automatic notifications, what you can do with OneSignal is that once you create a segment and then once you create a template, which a template is basically just like the message part of the notification just like how the notification looks, not the segments and not the delivery time. So, basically just how the notification will look to the user. You can set those up and create many different templates. Those templates are stored here. And then basically, you just tie those different segments and templates together.
So, to try to explain better, currently, I have these four different automated messages. I have 30-day inactive. Let me just start over. Okay. So, to create an automated message, I want to send a push after the user has been active for one day. So, I create a new segment. Let’s just call it like '1 day'. And then I use my first session as less than, let's say 24 hours. So, all my devices that first opened my mobile app and/or subscribe to my website less than 24 hours ago, will call that '1 day'.
And then let's say I create a new segment for 'Day 2'. The first session is, I want to say less than 48 hours and the first session is greater than 24 hours. So, once a user has signed up, like open my mobile app or subscribe to my website after 24 hours has passed, but before 48 hours have passed, they will now be inside of this segment here. Great. So, I've got my '1 day' and 'Day 2'. It's always best to keep the naming better. Cool. I got my 'Day 1' and my 'Day 2'.
So, now I go into my templates. Templates are under messages. It's loading really fast as you can see. I'm just going to use this one and two templates that I created earlier. I think it just says like 'Test1'. Definitely make your notifications better than Test1. But just for demo purposes, that's what I got. Cool. So, I've got my one and two.
So, now I create new automatic message. I named the automatic message. So, I'll call this my 'Day 1'. I select my '1' template and then I just set my 'Day 1' segment.
Now, basically what I'm doing here is that when a user joins this segment, they'll get sent to this template and that will get sent either immediately or with intelligent delivery or with the optimized by time zone. This will be if I want my users to get it at 2:00 PM or whatever. I would suggest maybe just intelligent delivery. Well, whatever you feel more comfortable with.
For free accounts, the automated message, they get sent after a few hours. So, if you're on a free account and you want to send a notification after the user has been active for a day, basically, the way I have the segment set up is they'll get added to this segment automatically. So, between 0 and 24 hours, they're in this 'Day 1' segment. So, after a couple of hours, they'll get this notification. So, you could actually just put 'send immediately '. And then after a couple of hours, they'll get it. Currently, free accounts also support intelligent delivery. So, if you wanted to use that, you can. And then optimize by time zone is for paid-only customers at this time.
For paid accounts, automated messages, instead of after a few hours, they get sent after a couple of minutes. So, basically, I would get this notification immediately as soon as I download and open the app. So, if you're wanting to send like, "Thank you for using my app," or "Thank you for subscribing to the website," this is perfect because it'll get sent immediately after the user basically opens the app or subscribes to the site.
By default, automated messages only get sent one time. So, any users that get added to the segment, they will never get this automated message again unless you select one or both of these options. So, if I click 'the user returns to the app', this is also the same for web, if my user returns to the app or website and this is selected, they will get sent the notification again if they're still in the segment. in this case, it probably won't get sent again because they'll be out of this segment after 24 hours. But if I go to the segment, if I subscribe to the website and then I get added to the segment and I get sent the notification and then maybe later that day I returned to the segment, I will actually get this again almost immediately for paid accounts if you have this selected. So, keep that in mind.
You can also select 'X hours of elapsed'. So, if you wanted to wait 24 hours or wait a week like 168 hours. You can do that. If the user is still in this segment after this time, then they will also get sent the automated message again. You can select both of these together, but they're not like an 'and' clause. So, it's like, if the user returns to the app and they're still in the segment, they'll get it. Or if after 168 hours, the user is still in the segment, they'll get it. So, it's not like the user returns to the app and 168 hours have passed. It's if the user returned to the app or 168 hours have passed and continued to send a notification if they're still in the segment. I hope that's clear.
Great. So, I have that setup. Ignore this data there. It's going to be updated soon. But now, that's set up. I've got my 'Day 1' and then I just basically do the same thing for 'Day 2'. I just call this 'Day 2'. I do my '2'. And then I set my 'Day 2' segment. Send immediately, I don't want this to repeat. Then click CREATE.
Now, as these get sent out, I can see how they perform in my templates page. So, I can see already that this was sent three times. Nobody's clicked it. But for my other notifications, I can see they've been sent in. So, some were clicked, some were not.
You can also create email templates here, but automated messages do not support email at this time. It's only for push. So, if you create an email, you can send emails from the OneSignal dashboard or from our API, but not using our automated message feature.
Great. I'm going to finish up pretty soon, so please continue to ask your questions in the Q and A or through the chat and I'll get to them.
The last thing I just wanted to highlight real quick is just the A/B testing feature. The A/B testing feature... Thanks, Romaine. The way that this works is that it's basically a way to test two different notification copies to see how well they perform. So, just like creating a notification, you select your audience. These are the devices that are eligible to get the notification or that are sent the notification. We then create our A test. You can select a template or you can just create one on the fly. Here I'll just call this my emoji 1. So, there's my A test.
And then here's my B test. I say 'no emojis here’. Again, these are terrible notifications. Please don't send these to your users, but just for testing your demo purposes. That's that. And then you schedule it. So, this is when both the A and the B will be sent. It's not possible to actually test like sending one with intelligent delivery and sending the other with immediate or time zone. Unfortunately, that's not available at this time.
So, basically, I want to send these immediately. And the way it works is that, of my total users, the A and the B test will be sent to between 8% and 25% of your users in that segment based on how big the segment is. So, the smaller the segment, the larger the sample size. The larger the segment, the smaller the sample size. You also currently don't have an option to a split test like 50/50 - sent A to 50%, B to 50%. You also don't have control over the percentage. But these are all ideas that we're working and tweaking in our system and trying to figure out how best to create those different scenarios. But for right now, of my subscribed users, the A and the B test will be sent to 60 of them, so 30/30. I click CONFIRM. I got to name this. I'll call this my 'emoji vs text only test'. Confirm. It looks great. Cool.
These notifications have been sent. I can click the details to go in and see how they're performing over time. But these will not get resend automatically. You'll have to come back into the dashboard, into the A/B tests. Find the A/B test. Click VIEW and then send like the winner to the remaining. So, I would then go to like, okay, maybe this one got five clicks, this one got two. I can now send this to the remaining users. And then, everybody that did not get the A/B test will then... I just got it, so I clicked. It takes me to my beautiful test site. And there's my Clicked.
Message from John: Can you exclude those you tested on when you send the real winning message? Never mind, I see the answer now.
Great. Yeah. So, the A and the B test will not get sent the winning message.
Cool. That's kind of it for what I wanted to go over... Oh, just to highlight one more thing real quick. I talked about this briefly when I was sending the message. To create your Android categories, that's under settings and then messaging here. You can add your group. And then inside your group, add your category. And then here, this is all your Android settings. This is for Android mobile apps and it's also only for... Well, Android created this for Android 8+. So, this is the new standard for notifications. But whatever you set here, we will also use for Android 7 and lower. So, if you set a sound here, we'll use that custom sound for all the different Android versions.
Cool. I'm going to jump into the Q and a real quick. I see there are a couple of questions. I think I need to get out of full-screen mode maybe. There we go. Oh, I guess those were the two questions. Okay.
Alex asked: can we send a push targeting specific geo-locations like UK, Italy, et cetera?
Yes and no. For location tracking, there's a few different ways to go about it, right? So, on mobile apps, mobile apps have the ability to ask users, "Hey, can we track your location?" And users have the ability to say, "Yes," or to say "Absolutely not, go away." If they say yes, then OneSignal will start to automatically track those locations here as they move around. Depending on the location tracking setup, if the location is being tracked like every single... There's a few different location tracking options. You can track users like on iOS. You can track them when they're using the app. In special circumstances, you can track them when the app has been closed or swiped away, and then same with Android. But the user is basically in control.
So, if they turned off location tracking or if they have certain devices that will not allow location tracking when the app has been forced quit, then basically, the location points will just get updated basically at the last time that it was updated. So, our SDK will update location every about 5 to 10 minutes based on their location preferences.
So, that being said, if you have mobile application tracking turned on, you can then create a segment using location. You just specify the radius, 4990 meters around a specific latitude- longitude. So, if you wanted a specific geo-location in the UK or Italy or maybe some tourist spots or maybe around the Capitol or something like that, you can just put the latitude-longitude there and then put however many meters around that you want to track.
For web, it's not great. With web, you can ask for their location. So, you can actually prompt users for their location and they click ALLOW. Well, they have to be subscribed to actually get the location. Sorry, not a great demo. Do allow. I'm sorry, I'm just pulling up my player ID here. Go into my all users page here.
So, basically, what I have my demo set up is that I have geo-location tracking. The user had to select yes. That's OKAY on the dashboard. Google will then track the location. And then you tag the user with this data. Okay. So, here is my device and here I tagged the user with latitude and longitude. So, this is for web.
And then now in the segments, I could then create... It's kind of annoying, but you would then create tags based on... I would then do user tag. I call it 'lat'. I can do 'is greater than, let's just say 36 for demo purposes. User tag, 'lat is less than a 38'. And then you'll just do the longitude as well. User tag, 'long is greater, less than'. Yeah. So, that's how you would do that for web.
I really don't recommend doing this that way. What I would recommend is that on your app or website, if you want to track it by city and you're asking the user like, "Hey, what city are you in?" or "What's your zip code? Or anything like that, if you have an app or website that does that, as soon as the user provides that data, you can tag them with that data. So, for example, if I wanted to put on my website, like maybe search for something by a specific city, as soon as they enter that city, you can call the onesignal.sendTag and I call it like 'city'. I'm in San Mateo, so I'll just do San Mateo. Cool. Now, refresh the page and we'll see the tag city, San Mateo.
So, here sort of doing all this latitude-longitude stuff, and this will also work on mobile as well. I can do user tag, 'city is San Mateo'. So, all my users that have that city tag, they will be added here whenever they do that.
So, basically, Alex, what I'm trying to say is that there's a couple of ways to do it. One is you can turn on location tracking for the app. You can then track that location for web or for mobile. For mobile, it's a lot easier because it's provided for you the way that mobile is set up. For web, it would be done through tracking through creating a bunch of tags like that. And then you can set it that way.
The other option is that if you are tracking specific locations, you would just tag them with that data and then you can create the information based off of the city or zip code. As we kind of saw earlier with tags, if you have an integer value, you can use the greater than and less than parameters. So, if you tag the user with a certain zip code or a number, if you have different locations segmented by different numbers like maybe location 200, and you want to track all the users between 150 and 300, you can do that.
OneSignal also integrates with a company called Plot Projects, OneSignal location tracking. So, if you really want like super granular tracking of location points, basically, you can work with Plot Projects to set that up and then trigger notifications based off of a specific location set within Plot Projects to trigger.
So, I'll, I'll go ahead and throw this into the Q and A, or I'll throw it into the chat for people if they're interested. But I'm not seeing any other questions and we're almost at a time. Any last questions anybody wants to ask?
Is there a way to... Okay. I guess there are a few more chat questions. Can we exclude those you tested... Okay, answer that. Is there a way to import Firebase events into my OneSignal account for better segmentation creation or maybe a workaround to accomplish something similar? Thanks for the demo, by the way. Much appreciated. I am interested in more about apps, so I guess it will be easier.
Yeah. So, for Firebase events, there are a couple of options. One, the recommended option would be to use tags. So, within your Firebase events tracking code, you would basically throw in what I showed earlier, the send tag or send tags method. So, whenever that event in Firebase is tracked, you can track it on Firebase. And then within the same callback or within the same closure, you can then throw in the OneSignal tag event. At that point, you can then basically track that in Firebase, but then also send that as a unique tag to OneSignal.
At the same time, if you didn't want to do that, another recommended option would be to basically save your Firebase user ID to OneSignal. And then whenever you track those events... That's the tagging guide I just put in the chat. Basically, whenever you track these events in Firebase and you want to create notifications when those events occur, you can target them directly with a push. So, if I'm tracking certain events like the user visited this specific page or the user reached level 20, if you want it to then send them a notification saying, "Hey, thanks for doing this," or whatever, you can actually track the OneSignal player ID or send your Firebase user ID to OneSignal as the external user ID and then basically just use our API to trigger notifications directly. So, here is that guide as well.
But yeah, in terms of tracking specific events, those are basically the two ways to do it. One is, use our tags. The event is performed, so send that to OneSignal. Or the event is performed; you already have that in Firebase or whatever database you use. Use the OneSignal player ID or your database ID and trigger notification that way.
Okay. Alex... Interested in more in the app. Okay. Yup. The location point for the app is much, much easier. But yes, Alex, if you are tracking with the city they're in or if you are tracking the zip codes or anything like that, the other option is to use tags.
Kirk: It seems that you are recording the session. I came in late and I could...
Yeah, this session will be available for later viewing. Also, just so everybody's aware, under the OneSignal Platform are Webinar Videos. Here are all the previous webinar videos along with this one currently will be up here as well. So, I'll throw that here.
I'm going to be signing off soon. There's a bunch of links in the chat. I hope you guys find those helpful. There is also a... I see somebody raising their hand. Feel free to throw your question in the chat or the Q and A and I'll answer it. A bunch of hands being raised. Sorry, I don't know how to answer... Oh, I guess I can allow you to talk. Okay. let me try that. Michael, you're allowed to talk. Oh, I guess you're muted. Unmute. Michael, can you talk?
Michael: Yeah. Sorry, it was jumping on with the screen. I just wanted to know that if you are losing clients or followers, have you suggested some methodologies for retaining and attracting new signups?
Jon: Yeah. So, basically, if you're losing subscribers, there's a few reasons for that. Are you web or mobile or both?
Jon: So, generally, what happens on web is that if a user subscribes to your site, so I'm currently subscribed to my site, if I were to clear my history, my cache or if I go up here and I clear my cookies for the site, that user just basically immediately becomes unsubscribed. It's just like, unfortunately, that's just the way browsers are set up. However, if you have OneSignal, if you have an HTTPS site and you're set up properly, your site will then re-subscribe the user automatically. So, you can actually see here that my users actually re-subscribed. It looks like the bell is faded.
If you want to reach out to our email@example.com with your website URL, let us know and we'll just go ahead and test that for you and see if that's working. But generally, what we see when people get a lot of unsubscribed users, maybe you're sending habits, maybe you're sending too many notifications or you're sending notifications that maybe users don't necessarily like. It's best to always think about what you would like. If you would like to have ten notifications a day, then yes, send ten notifications a day. But if you wanted to only get one or two a day, maybe send in the morning and in the evening. And that's what those scheduling options are for. You can schedule maybe morning like 11:00 or 10:00 notification and then maybe like 6:00 notification.
It's also a great idea to segment your users. So, when users visit websites, depending on what kind of website you have, you probably have different topics. So, if you have a new site and you have maybe some politics or breaking news or sports or entertainment, it's always a good idea to segment your users by those different topics.
Actually, under our use cases and best practices guide, we have some code examples that you can use to auto segment your users by what page they subscribed on or how many times they visited a certain page. So, that way, you can start to see like, "Okay, well I have maybe three categories - sports, entertainment, and finance. Every time a user visits a sports page, I want to tag them with how many times they've visited that. So, my users that visit the sports page like ten times or more, they must really like my sports messages. So, I'll continue to send them sports but maybe not like the finance or entertainment options if they're not really interested in that."
So, it's always good to really start to customize your notifications based on your user's habits. I'll send that link in the chat. And then also there a notification click-through rate guide. This might also provide some insight into how to increase your clicks on your notifications as well.
Jon: Great. Anybody else who had a question? As always, feel free to reach out to us at... There's a little chat bubble here in our documentation or on our website. This will reach out to somebody on our support team. We really do our best to answer tickets as soon as possible. Usually, within 24 to 48 hours is really what we're trying to do. We do get a lot of support tickets, so please be patient with us and we will answer them as soon as possible. You can also reach out to us by email to firstname.lastname@example.org and you can reach us there as well and somebody from our team will assist you basically as soon as possible.
Thanks everybody for joining. I hope this was helpful. This will be available shortly on our documentation page for reviewing purposes. Again, that's under the OneSignal Platform and then Webinar Videos.
All right. Thanks, everybody. Have a great rest of your day.