Skip to content

Saving Events

Events are actions related to a Pulsate campaign that results from the action of delivering and rendering the campaign itself, or from the User’s interaction with that campaign. These events are catalogued below.

Pulsate requires that Events are sent in batch format using the Update Users API. We recommend that you send Events to Pulsate a maximum of once every 30 seconds.

As such, it is important that you implement a storage system for capturing and persisting Pulsate Events before sending the Event to the Pulsate API.

The following considerations need to be made when designing an Event Storage solution.

  • Events are not unique in the context of a single User. A User may click on a Call to Action in a Notification more than once. All instances of this event should be captured and sent to Pulsate
  • A device may be shared by multiple Users. Thus when storing Events, you should consider the possibility that different users will take the same action on the same campaign.
  • Events should persist Browser sessions. Should a User terminate a session (i.e. by closing the browser, or navigating to an external site), the Events should be stored until such time as the User returns to the site.
  • Events are used to generated Campaign Statistics within the Pulsate environment. If Events are significantly delayed it may impact the accuracy of reporting. We suggest you design to allow Events to be sent to Pulsate even if a Session has been terminated by the User, but the Event(s) have not yet been sent to Pulsate.
  • When an Event has been successfully sent to the Pulsate API there is no longer a need to persist the Event within your system. Thus you should consider how best to remove these events from storage.

These events occurs in the context of In App Events only.

Event Name Description (When to Send)
in_app_delivery When an In App notification is received by the User’s device
in_app_error When there is an error with the In App Notification (i.e. rendering or formatting issue)
in_app_bounce When an In App notification is received by the User’s device, but is not displayed due to a permissions or user settings preventing the display of In App Notifications
in_app_impression When an In App notification is displayed to the User
in_app_dismiss When an In App notification is dismissed (click on the x to close the notification)
in_app_button_click_one When the first button (button one) of an In App Notification is clicked
in_app_button_click_two When the second button (button two) of an In App Notification is clicked
in_app_time_out When an In App is not displayed on the User’s Device as it it has expired
Event Name Description (When to Send)
card_delete When the user Deletes or Hides a Feed Item from their Feed
card_front_impression When the front of a Feed Item is viewed by the User (i.e. when it shows in the feed)
card_front_button_click_one When the first button (button one) on the front of the Feed Item is clicked
card_front_button_click_two When the second button (button two) on the front of the Feed Item is clicked
card_back_impression When the back of a Feed Item is viewed by the User
card_back_button_click_one When the first button (button one) of the back a Feed Item is clicked
card_back_button_click_two When the second button (button two) of the back a Feed Item is clicked

Custom Events are different to standard Events, and are only applicable in the context of Feed Campaigns. They use a different endpoint, which should be called immediately (unlike Events which are batched and sent after a period of time).

When you send a Custom Event to the Pulsate API, the response may contain an In App Notification. You should refer to Displaying an In App Notification for more details on how to handle this.

Event Name Description (When to Send)
Any A custom Event described as part of the Notification Object. Only applicable to the Front of a Feed Campaign