Transactional notifications to designated recipients
Push notifications are excellent for so-called “transactional” notifications. Transactional notifications are also called “triggered” messages, as they are triggered by a specific action or event and are sent to targeted recipients. They are usually generated automatically by the shop or CRM system, for example in the case of registration confirmations, order or booking confirmations, appointment reminders, shipping notifications, malfunction messages, birthday greetings and post-purchase offers. These types of messages enjoy high open rates because they are expected by the user and contain important information.
Sending these messages via web and mobile push offers several advantages. Compared to email, the advantage is that the message appears directly on the recipient’s screen and is not in danger of being lost in the mailbox. This is of immense importance, especially for very time-critical information such as delay alerts. In addition, push sending is usually much cheaper than SMS and also reaches desktop users.
If sending is to be triggered by a certain activity of the user on the website, the corresponding automatism can be created directly in Signalize. If the trigger information can be found in another system, such as the CRM or merchandise management system, the dispatch of the transactional notification can be triggered from there and transferred to Signalize via an interface.
Caution:
Push notifications cannot be used for sending messages back and forth. They can, however, be used for messages such as “You have a new message in your inbox”.
HOW TO SEND TRANSACTIONAL PUSHES VIA THIRD PARTY SYSTEMS
1. Matching recipients
a. Via the Signalize recipient ID
In Signalize, each recipient is assigned an individual pseudonymous recipient ID. The recipient ID corresponds to the Signalize or etracker cookie ID et_coid. To read this, the JavaScript function et_signalize.getClientId() is available.
The function can now be stored in the CRM system, for example, in order to send push notifications to individual recipients using this Signalize recipient ID.
The Signalize recipient ID can change for various reasons. Therefore, we recommend that you transfer the user ID used in the CRM system to Signalize on the website.
b. Using your own user ID (recommended)
In order to be able to send a 1:1 message to one or more selected recipients with a user ID from the CRM system, this user ID must be communicated to Signalize on the website.
The transfer can take place both as a GET parameter for the URL (e.g. as a link from e-mail newsletters) and via a code parameter (e.g. when logging in).
The transfer via the GET parameter in the URL takes place via et_exid. A transfer can therefore look like this, for example:
https://etracker.com/?et_exid=someID
If the new parameter is to be transferred via a parameter in the tracking code, this is done via the parameter var et_exid=”someID”. This could look like this, for example:
var et_exid = “someID”;
2. Sending the message
To send a message to a specific recipient, the Signalize API provides a suitable call. The Signalize API can be connected directly to the desired system to send the notification. Alternatively, the connection can be made via the Zapier plug-in, provided that a connection of the third-party solution to Zapier exists.
The technical description of the interface for sending messages including transactional notifications can be found here: https://docs.signalize.com/
3. Querying the registration status for push messages
To check whether a visitor is signed up for push messages, the following functions are available:
With await et_signalize.getSubscriptionStatus() the current status can be queried asyncronously. The following values are possible as a result: granted (subscribed), denied (rejected) and default (has not yet been asked).
If only the opt-in via the own domain was used on the website, the function et_signalize.getNativeSubscriptionStatus() can also be used.
Compared to getSubscriptionStatus, this function is synchronous and avoids further network traffic.
If the status is to be queried independently of the reloaded Signalize code, the status can be read directly in the Notification.permission object. However, it must be ensured that the browser supports this.
Notice:
The et_signalize object is not always defined and its existence should be checked beforehand. The relevant JS code is reloaded asynchronously and is not displayed in older or incompatible browsers.
