We’ve already seen in a previous blog post how easy it is to set up public web app notifications using the Notific.io PHP SDK. So now would be a good time to talk about the parameters that you can use to modify the behavior of the notifications you send out. These can be used to modify the timing and behavior of the messages, which can be combined in different ways to suit your campaign. Let’s take a look at what these parameters are and how you might use them in real-world scenarios.
Notific.io Web App Notifications Parameters
status
This first parameter deals with the visibility of web app notifications. It is a boolean type that you can toggle to determine whether or not visitors on your website will see the notification. Every system needs an on/off button, and that’s what the ‘status’ parameter lets you do with each notification on Notific.io.
type
There are five broad categories of notifications that you can send using Notific.io: general, info, success, warning, and danger (denoted as 1, 2, 3, 4, and 5 respectively). This string parameter conveys what kind of notification you’re about to send. For example, a message you send after signing up is a success notification. One sent about an expiring trial would be a warning notification.
Content Parameters
title
Possibly the most important aspect of your notification is its title. This is where you have the chance to grab the attention of users with something compelling. All web app notifications must have the ‘title’ parameter because it’s important to let your audience know what each message is about.
body
Obviously, you can also put text in the body of the notification. This is where you explain things in greater detail (but not too much), and what action, if any, you want your audience to take. You don’t have to use the ‘body’ parameter. Instead, you can use the next one on the list.
url
Instead of defining some text that would go in the body of web app notifications, you can have it open a webpage in a new browser tab. This new tab would presumably contain your message to the user, which is why the notification wouldn’t necessarily require a body. Imagine a scenario in which you send a notification about an abandoned cart. You could use ‘url’ to link to the checkout page with the items that had already been added to the cart.
Temporal Web App Notification Parameters
published_at
So, you would like to schedule a notification? The published_at parameter lets you do just that by passing a date and time at which a notification is sent to users.
new_till
Sometimes you might want a notification to go out of circulation after a certain date and time even if users haven’t accessed it. Such time-sensitive communications can be automatically marked as read using the ‘new_till’ parameter. These are especially useful for things like discounts that run in a particular season, news updates, and so on.
active_till
Same thing as the previous parameter, except in this case the notification will not be visible to anybody after a set date and time.
delay
Usability practices dictate that you give users some time before hitting them with messaging that isn’t central to the product. You can use the ‘delay’ parameter to set the duration of time (in seconds) after which a notification will pop up on a user’s screen.
Read Next
