Events refers to the actions your users perform on your app or website eg. purchase, add to wishlist, search etc. Events also includes other actions such as app install, app uninstall, email open, email click etc. Each such event has attributes attached to it that captures where and when the event happened (eg. event time, location, device) and also describes the event in detail (eg. for Purchase event - item category, item price etc.). You can use event-related information to understand your users better, segment them and personalize your campaigns.
Before you start the integration process, please ensure that you are consistent with the usage of event names and the attributes attached to each, across all platforms such as, Android, iOS and Website. We recommend that you create an excel sheet where you can list down all the events you want to track along with their corresponding attributes and data-types. Data-types, once defined, cannot be changed later. If WebEngage receives data in a different datatype from what was first defined, it will not be able to record this data.
Events on WebEngage are of 2 types: System and Custom.
System events are those events that are automatically captured by WebEngage (except User Login, User Logout). It also includes those events that are performed by users for the campaigns they receive through WebEngage. Here's a complete list of all the system events available in WebEngage:
When the app gets installed
When the app is upgraded
When the app crashes
When app is uninstalled
Whenever you call the login function on user login, signup etc.
Whenever you call the logout function
Whenever a new session is started. Please see the definition of session below.
When a user completes the conversion event attached to a campaign
When a device is registered successfully to receive push notifications
APNs Registration Failed
When device fails to register to receive push notifications
Push (Mobile) Sent
When mobile push notification is sent by WebEngage
Push (Web & Mobile) Queued
When a mobile push or web push campaign is queued for delivery by WebEngage to GCM or our VAPID server for any of these reasons
Push (Web) Accepted
When a web push campaign is forwarded by WebEngage for delivery by our VAPID server
Push (Web & Mobile) Rejected
When a mobile push or web push campaign is rejected by WebEngage and is not forwarded to GCM (for mobile push) or our VAPID server (for web push)
Push (Mobile) Received
When a device receives a mobile push notification successfully
Push (Web & Mobile) Dismiss
When a user dismisses a mobile push or web push notification
Push (Web & Mobile) Impression
When a user views a mobile push or web push notification
Push (Web & Mobile) Click
When a user clicks a mobile push or web push notification
Push (Mobile) Rating Submitted
When a user submits a rating for a mobile push notification rating campaign
Push (Mobile) Carousel Item Viewed
When a user views items in a mobile push notification carousel campaign
Push (Web) Registered
When a user successfully subscribes to web push after clicking “Allow” on native browser prompt
Push (Web) Unregistered
Please see the details here
Notification (On-site & In-app) Impression
When a user views an on-site notification or in-app notification
Notification (On-site & In-app) Close
When a user closes an on-site notification or in-app notification
Notification (On-site & In-app) Click
When a user clicks on an on-site notification or in-app notification
On-site Feedback View
When a user views an on-site feedback
On-site Feedback Close
When a user closes an on-site feedback
On-site Feedback Submit
When a user submits an on-site feedback
On-site Survey View
When a user views an on-site survey
On-site Survey Close
When a user closes an on-site survey
On-site Survey Complete
When a user completes an on-site survey
On-site Survey Submit
When a user submits an on-site survey
When a SMS is queued for delivery by WebEngage to the SSP for any of these reasons
When a SSP successfully accepts the SMS sent by WebEngage to the SSP for delivery to the customer
When a SSP rejects the SMS sent by WebEngage to the SSP for delivery to the customer
When a SSP successfully delivers the SMS to the customer
When a SMS fails to deliver as reported by the SSP
When a user clicks on a link in a SMS
When an email is queued for delivery by WebEngage to the ESP for any of these reasons
When a ESP successfully accepts the email sent by WebEngage to the ESP for delivery to the customer
When a ESP rejects the email sent by WebEngage to the ESP for delivery to the customer
When a ESP has received the email sent by WebEngage to the ESP for delivery to the customer
When a ESP has sent the email to the customer. Subsequently, the message may get delivered or may not (because of hard-bounces and soft-bounces).
When an email gets bounced as reported by the ESP
When the email is delivered as reported by the ESP
When a user or an email client like Gmail complains about the email (in case of phishing etc.)
Email Abuse Report
When a user marks an email as Spam
When a user subscribes again to receive email campaigns
When a user unsubscribes from all email campaigns
Email Spam Report
When a user marks an email as Spam
When a user opens an email
When a user clicks on a link in an email
Web Push Subscribe Viewed
When a user views the native browser prompt to subscribe to web push notifications
Web Push Subscribe Denied
When a user clicks "Deny" or "Block" on the native browser prompt to not subscribe to web push notifications
Web Push Subscribe Successful
When a user clicks "Allow" on the native browser prompt to subscribe to web push notifications
Web Push Subscribe Notification Viewed
When a user views the on-site notification prompt to subscribe to web push notifications
Web Push Subscribe Notification Denied
When a user clicks "Deny" or "Block" or "Not Allow" on the on-site notification prompt to not subscribe to web push notifications
Web Push Subscribe Notification Allowed
When a user clicks "Allow" on the on-site notification prompt to subscribe to web push notifications. This opens the native browser prompt that the user has to click "Allow" on to actually subscribe to receive web push notifications
For websites, session time = the time for which the user is active on your website (activity can mean any of the following - performing events like search, add to cart etc., same webpage being refreshed/reloaded, a new webpage being opened). If the user is inactive for 30 minutes then the session ends. The inactivity here can mean any of the following - (1) User is on your website but is inactive (see definition of active above), (2) User is on a different website in another tab, and (3) User is switching between tabs from another website to your website but is not performing any activity on your website. In other words, this means that session time out duration for websites is 30 minutes.
For mobile apps (iOS and Android), session time = the time for which the app is open (or in other words, app is in foreground). If the user backgrounds your app (to open another app) and doesn’t foreground your app within 15 seconds, the session will end. Or in other words, the session time out duration for apps is 15 seconds.
When user revokes access for receiving web push from the browser settings or while sending the web push, server returns a token not present error. Also, when a user logs out, we send this event (Push (Web) Unregistered) for the previously logged-in user and we send Push (Web) Registered for the new anonymous ID created.
These event are sent by you to WebEngage, based on the actions performed by your users, on your mobile app and/or website. Some examples of these events are: Purchased, Category Viewed, Searched etc. You will be able to define events according to the needs and nature of your business.
All events have attributes attached to them that capture its details. Eg. Attributes of a purchase event would include the time of event, device on which the event happened, location from where the event happened, details of the item purchased etc.
Attributes are of 2 types: System and Custom. These attributes are applicable to different event types, as follows:
- System Events: Only have system attributes
- Custom Events: Have both system and custom attributes
These are defined by WebEngage and are automatically captured as and when an event happens. You cannot overwrite these values or modify them in any way.
Here’s a complete list of system attributes defined by WebEngage:
Time when the event occurred in ISO Format
Country where the event occurred
City where the event occurred
Name of the browser on which the event occurred
Name of the OS on which the event occurred
Name of the manufacturer of the device on which the event occurred
Device model on which the event occurred
The device cellular network on which the event occurred
The version of the app on which the event occurred
The ID of the app on which the event occurred
The platform on which the event occurred - one of Android, iOS, Website
The channel (Direct, Organic Search, Social etc.) that resulted in the occurrence of the event
The UTM source of the marketing campaign that resulted in the occurrence of the event
The UTM medium of the marketing campaign that resulted in the occurrence of the event
The UTM name of the marketing campaign that resulted in the occurrence of the event
The page URL on which the event occurred (in case of website)
The screen name on which the event occurred (in case of mobile app)
The ID of a campaign that was sent through WebEngage
The ID of the variation in a campaign that was sent through WebEngage
The ID of the journey in WebEngage that the campaign is a part of
You can define custom attributes of an event depending on your business needs. For example, a Purchase event could have the following attributes: Item Name, Item Price, Currency, Category Name, Category Code.
Please take note of the following limitations when you’re creating new custom attributes:
- Values of an attribute can only be of one of the following data types:
- A customer can have a maximum of 25 custom attributes per data type for the following data types:
Date(i.e. 25 custom attributes of
Numberdata type, 25 custom attributes of
Stringdata type etc.).
- A custom event can have as many attributes of
Arraydata types as you would like with the limitation that all the values together occupy a maximum space of 16KB.
- The maximum length of an event name is 50 characters.
- The maximum length of a
Stringdata type for an attribute is 1000 characters.
- The maximum length of an attribute name is 50 characters.
- The name of your event or event attribute should not begin with
Updated about a month ago