Push notifications are important. Especially in chat. The timeliness of the notifications could be the decider for how engaging a conversation ends up being. Check out our handy guide to understand why push notifications are important and how they can be used. The guide also contains some tips for sending relevant and useful push notifications.
Sendbird provides chat as an integrated part of our customers’ services. As our customers range over various industries, the use cases also vary from simple 1-on-1 based chatting to large group chats, to marketing push notifications. To streamline the process of keeping the users engaged through push notifications, Sendbird now provides the push notification testing tool on the dashboard. Read the launch announcement here.
Push notifications with Sendbird
The end-user experience for push may appear quite simple. A user sends a message, and the recipient receives the push – if intended.
For this seemingly simple procedure, there are multiple components involved. Customers must allow Sendbird to send push notifications on behalf of their applications. Users must register their device with Sendbird through customer’s applications. Once the configuration is completed, Sendbird will request the push providers – i.e. Firebase Cloud Messaging for Android devices, Apple Push Notification service for iOS devices – to send the push notification to respective devices.
In the whole stream of components to get through, Sendbird’s messaging service allows various configurations and conditions for push notifications such that our customers can engineer the best user experience for their users. Push preferences are available at application-level, user-level, and at channel-level.
On top of the flexibility with push notifications, reliability and scalab ility must be guaranteed. Sendbird’s architecture is designed to maintain its availability, accounting for possible unavailability of the push providers and the fluctuating needs for push notifications due to the huge spectrum of use cases. The main messaging service takes care of the messages and decisions on to whom push notifications should be sent to, and it delegates the job to push-dedicated microservice that operate serverlessly, and asynchronously.
Struggling with misconfigurations
As customers try out Sendbird and wire up push notifications for their applications, it is possible that there is a misconfiguration – whether it be device registration, or provider certificate registration.
This is where things can get tricky and frustrating. Due to the nature of having multiple third party components involved and the complex control flow, it is not easy to identify the causes when there is a misconfiguration for push notifications. If a push notification does not arrive when it is expected, our customer must wonder: are the user-level settings the problem, or is the device not hooked up with Sendbird? Or is there a user-device mismatch?
Such unresolved uncertainty can not only slow down the integration of Sendbird’s chat as a whole, but also results in lack of confidence in shipping the final integration to the end users. To clear out the uncertainties and provide confidence, Sendbird now provides the push notification testing tool.
Fire away with Sendbird
The push notification testing tool focuses on three major things. One, giving direct feedback on the current push related set-up, with user, device, and push provider. Two, delivering the error codes from push providers when push requests are rejected from the push providers. Three, giving the device the intended “ding” on the device, by bypassing all the user-level and channel-level push preferences to confirm there are no issues with the set-up.
The tool required some new data and control pathways dedicated for testing. Since the architecture separates push from the main service, there was a need to trace the responses from asynchronous push requests. So a separate, trackable form of datastore that holds the responses from the push providers was introduced for this purpose. Then, to chase after for the result, the tool polls for the result of asynchronous push in a controlled manner. Combined with the bypass for push preferences, the customer can easily figure out the errors for the misconfiguration through the testing tool on the dashboard.
Once all the errors are dusted, there will be a “ding” to the device and the push integration is ready to go!