All behavioral data points are called Events in your dashboard. And each Event can further be understood in the context of its Attributes which includes details like time, location, device details, price, quantity, and so on.

This enables you to gain in-depth insights into user interactions across your app, website, and channels. You can also leverage this data to segment users, personalize messages and configure campaign targeting.

Events

📘

The term Event refers to all the actions performed by users while interacting with your mobile apps, website and campaigns.

For example, if a user needs to click on a product to view its details, then it is advisable to track this action as the Event, Product Viewed as it brings them a step closer to making a purchase.

Events are classified into 2 categories in WebEngage:

  • System Events: Pre-defined by WebEngage, automatically tracked for platforms post intergation.
  • Custom Events: Defined by you for each platform and tracked through the respective SDKs.

Let's walk you through this.

System Events

We have pre-defined several generic actions that users can perform while interacting with your app, website and campaigns. These actions are referred to as System Event and are automatically tracked for your platforms once you integrate them with your WebEngage account.

Here's a list of all the System Events that are automatically tracked for all your users post integration:

Name on DashboardName in BackendDescription
App Installedapp_installedWhen the app is installed and launched for the first time.
App Upgradedapp_upgradedWhen the app is upgraded.
App Crashedapp_crashedWhen the app crashes.
App Uninstalledapp_uninstalledWhen app is uninstalled.
User Loginuser_logged_inWhenever you call the login function on user login, signup etc.
User Logoutuser_logged_outWhenever you call the logout function.
Session Starteduser_session_startedWhenever a new session is started by your user. (Here's what a session means in WebEngage)
Campaign Conversiongoal_accomplishWhen a user performs the Conversion Event defined for a campaign/journey.
GCM/APNs Registeredgcm_registeredWhen a device is registered successfully to receive Push Notifications.
APNs Registration Failedapns_registration_failedWhen an iOS device fails to get registered for receiving Push Notifications.
Push (Mobile) Sentgcm_notification_responseWhen a Push Notification is sent to FCM for delivery by WebEngage.
Push (Web & Mobile) Queuedpush_notification_queuedWhen a Mobile Push Notification is Queued for delivery by WebEngage to FCM. OR When a Web Push Notification is Queued for delivery to our VAPID server.
Push (Web) Acceptedpush_notification_acceptedWhen a Web Push Notification is sent to our VAPID server for delivery by WebEngage.
Push (Web & Mobile) Rejectedpush_notification_rejectedWhen a Mobile Push Notification is rejected by FCM. OR When a Web Push Notification is rejected by our VAPID server.
Push (Mobile) Receivedpush_notification_receivedWhen a device successfully receives a Mobile Push Notification.
Push (Web & Mobile) Dismisspush_notification_closeWhen a user dismisses a Mobile Push Notification or Web Push Notification.
Push (Web & Mobile) Impressionpush_notification_viewWhen our system renders a Mobile Push Notification or Web Push Notification.
Push (Web & Mobile) Clickpush_notification_clickWhen a user clicks a Mobile Push Notification or Web Push Notification.
Push (Mobile) Rating Submittedpush_notification_rating_submittedWhen a user submits a rating for a Rating-style Push Notification.
Push (Mobile) Carousel Item Viewedpush_notification_item_viewWhen a user views the images of a Carousel-style Push Notification.
Notification (On-site & In-app) Impressionnotification_viewWhen a user views an On-site Notification or an In-app Notification.
Notification (On-site & In-app) Closenotification_closeWhen a user closes an On-site Notification or an In-app Notification.
Notification (On-site & In-app) Clicknotification_clickWhen a user clicks on an On-site Notification or an In-app Notification.
On-site Feedback Viewfeedback_viewWhen a user views the On-site Feedback Widget.
On-site Feedback Closefeedback_closeWhen a user closes the On-site Feedback Widget.
On-site Feedback Submitfeedback_submitWhen a user submits Feedback through the widget.
On-site Survey Viewsurvey_viewWhen a user views an On-site Survey.
On-site Survey Closesurvey_closeWhen a user closes an On-site Survey.
On-site Survey Completesurvey_completeWhen a user completes an On-site Survey.
On-site Survey Submitsurvey_submitWhen a user submits an On-site Survey.
SMS Queuedsms_queuedWhen an SMS is Queued for delivery by WebEngage to an SSP.
SMS Acceptedsms_acceptedWhen an SSP accepts the SMS sent by WebEngage for delivery to the customer.
SMS Rejectedsms_rejectedWhen an SSP rejects the SMS sent by WebEngage for delivery to the customer.
SMS Sentsms_sentWhen an SSP send the message to your user's network provider for delivery.
SMS Failedsms_failedWhen an SSP reports delivery failure for an SMS sent to a user.
SMS Clicksms_clickWhen a user clicks on a link in a SMS.
Email Queuedemail_queuedWhen an Email is Queued for delivery by WebEngage to an ESP.
Email Acceptedemail_acceptedWhen an ESP accepts the email sent by WebEngage for delivery to the customer.
Email Rejectedemail_rejectedWhen an ESP rejects the email sent by WebEngage for delivery to the customer.
Email Processedemail_processedWhen an ESP receives the email sent by WebEngage for delivery to the customer.
Email Sentemail_sentWhen an ESP sends the email to your user. Subsequently, the message may or may not get delivered. (Due to hard-bounces and soft-bounces).
Email Bouncedemail_bounceWhen an email is bounced back from the user's inbox, as reported by the ESP.
Email Deliveredemail_deliveredWhen the email is successfully received by a user, as reported by the ESP.
Email Complaintemail_complaintWhen a user or an inbox provider like Gmail complains about the email (in case of phishing etc.).
Email Abuse Reportemail_abusereportWhen a user marks your email as Spam.
Email Resubscribeemail_resubscribeWhen a user subscribes again to receive emails from you.
Email Unsubscribeemail_unsubscribeWhen a user unsubscribes to your emails.
Email Spam Reportemail_spamWhen a user marks an email as Spam.
Email Openemail_openWhen a user opens your email.
Email Clickemail_clickWhen a user clicks on a link embedded in the email.
Push (Web) Registeredpush_notification_registered- When a user subscribes to your Web Push Notifications by clicking Allow on the native browser prompt

- When Session Starts / User Logins / User Logouts / Session Resets: Since in all these cases, the LUID changes and the WebSDK reloads, the event is fired to map the latest LUID with a valid subscription token.

- Main purpose is to map a reachable subscription token to a valid LUID / CUID.

Event originates from the end-user’s service-worker file and can be fired if the end-user is on the webpage or from the service-worker running in the background.
Push (Web) Unregisteredpush_notification_unregistered- When a user revokes Web Push permission for your site through their browser settings. (Event is fired at end-user’s service-worker file)

- When the server returns the error, token not present/ Token updates (Event is fired at end-user’s service-worker file for older tokens that get unsubscribed)

- When a user logs out of their account (Event is fired to indicate that the user is no longer reachable on the device-browser).

- When message delivery fails (Event is fired at web-push-sender-service at WebEngage’s backend for tokens that get invalidated by FCM)
Web Push Subscribe Viewedpush_notification_window_viewWhen a user views the native browser prompt that requests them to subscribe to Web Push Notifications. (Event is fired at end-user’s service-worker file)
Web Push Subscribe Deniedpush_notification_window_deniedWhen a user clicks Deny or Block on the native browser Web Push opt-in prompt.
Web Push Subscribe Successfulpush_notification_window_allowedWhen a user subscribes to your Web Push Notifications by clicking Allow on the native browser prompt.

- This should be followed by the event, Push (Web) Registered given that the end-user’s service-worker is in a healthy state.

Please Note: No. of times Push (Web) Registered is fired will always be higher than Web Push Subscribe Successful as the former is fired in addition to fresh subscriptions. In most cases, discrepancies can be traced back to an integration issue with end-user’s service-worker file.
Web Push Subscribe Notification Viewedpush_notification_prompt_viewWhen a user views the On-site Notification prompt prompt that requests for permission to display the native browser Web Push opt-in prompt.
Web Push Subscribe Notification Deniedpush_notification_prompt_deniedWhen a user clicks Deny or Block on the On-site Notification prompt requesting them to display the native browser Web Push opt-in prompt.
Web Push Subscribe Notification Allowedpush_notification_prompt_allowedWhen a user clicks Allow on the On-site Notification prompt requesting them to display the native browser Web Push opt-in prompt.
WhatsApp Sentwhatsapp_sentWhen the message is sent by WebEngage to your WSP for delivery to your user.
WhatsApp Acceptedwhatsapp_acceptedWhen the message is accepted by the WSP for delivery to the user.
WhatsApp Rejectedwhatsapp_rejectedWhen the WSP rejects the message. This could happen when the your account has exhausted its message limit and so on.
WhatsApp Failedwhatsapp_failedWhen the WSP reports delivery failure for a user.
WhatsApp Readwhatsapp_readWhen the WSP reports that the message has been 'read' or viewed by your user.
WhatsApp Clickwhatsapp_clickWhen the WSP reports that a user has clicked on a link included in the message.
WhatsApp Queuedwhatsapp_queuedWhen the WhatsApp message is Queued by WebEngage for delivery to your WSP.

🚧

Please Note

The System Events, User Login and User Logout are not automatically tracked for your users. You will need to call the respective SDK functions whenever these actions occur on your platforms. These actions are also ideal moments to identify your users. Here's how you can go about it:

Website

Android

iOS

React Native

Cordova/ Phone Gap/ Ionic

Xamarin.Android

Xamarin.iOS

Unity.Android

Unity.iOS

How Does WebEngage Define Session?

For Websites: Session timeout duration = 30 minutes

Sessions time is the amount of time for which users are 'active' on your website. Here, 'activity' could mean any of the following:

  • Performing Events like search, browse, viewing products, categories and so on.
  • Refreshing or reloading the same webpage.
  • Opening a new webpage.

If a user is detected to be 'inactive' for 30 minutes, then their on-going session is ended. Here's 'inactivity' could mean any of the following:

  • The user is on your site but has not performed any of the actions mentioned above.
  • The user has navigated to another tab.
  • The user is switching between your website and another tab but has not performed any of aforementioned actions.

For Mobile Apps (iOS & Android): Session timeout duration = 15 seconds

Session time is the amount of time for which the app is open in the device's foreground. If the user pushes your app to the background and doesn't bring it back to the foreground within 15 seconds, then their on-going session will end. If they bring it to the foreground after 15 seconds, then we'll record it as a new session.

Custom Events

Custom Events are behavioral data points that you can custom define and track for your users across your apps and website. These enable you to understand your users better and deliver contextually personalized experiences in real-time.

Depending on your business, these events could be anything like:

  • Product Page Viewed
  • Course Details Viewed
  • Susbcription Purchased
  • Video Played | Video Paused | Video Ended
  • Game Started | Game Ended
  • Checkout Started | Checkout Completed
  • Review Submitted and so on.

🚧

Sample Custom Event Templates

We've complied Custom Event templates for each industry vertical to help you get started. While the data you track for your users will vary greatly as per your business model, you can use these as a reference point.

Event Attributes

📘

Event Attributes are details attached to each Event that convey the context in which a user performed it.

For example, the attributes of a Custom Event, Order Confirmed could be Order Value, Delivery Date, Number of Items, Primary Product Category, Delivery Address, Order ID, Event Time, Device Type and so on.

Event Attributes have been classified into 2 categories in WebEngage:

Let's walk you through this:

System Attributes

These are generic details that have been predefined by us and are automatically tracked for all the System Events and your Custom Events. These data points cannot be modified by you.

Here's a list of all the System Attributes tracked for your apps and website post integration:

Name on DashboardTypeDescription
Event TimeDateTimeTime at which the event occurred (in ISO format).
CountryStringCountry from where user performed the event.
CityStringCity from where user performed the event.
Browser NameStringName of the browser on which user performed the event.
OS NameStringOperating System of the device through which user performed the event.
Device ManufacturerStringName of the device manufacturer through which user performed the event.
Device ModelStringModel of the device through which user performed the event.
CarrierStringName of the cellular network provider of the device through which user performed the event.
App VersionStringVersion of your app on which the user performed the event.
App IDStringID of your app on which the user performed the event.
PlatformStringThe platform on which user performed the event (Android/ iOS, Website).
Page URLStringThe page URL on which user performed the event. (only for website)
Screen NameStringThe screen name on which user performed the event. (only for apps)
ChannelStringThe channel (Direct, Organic Search, Social) that resulted in the occurrence of the event.
Campaign SourceStringUTM source of the marketing campaign that resulted in the occurrence of the event.
Campaign MediumStringUTM medium of the marketing campaign that resulted in the occurrence of the event.
Campaign NameStringUTM name of the marketing campaign that resulted in the occurrence of the event
Campaign IDStringID of the campaign resulted in the occurrence of the event.
Variation IDStringID of the message variation of a campaign that resulted in the occurrence of the event.
Journey IDStringID of the journey through which the campaign was sent, that resulted in the occurrence of the event.

Custom Attributes

Custom Attributes are details that can be attached to each Custom Event defined by you. You can choose to attach a maximum if 25 custom attributes of a single data type to each Custom Event to better understand each user's platform interactions and contextually engage them.

For example, if an ed-tech platform tracks course purchases as the Custom Event, Course-Enrolled then it's Custom Event Attributes would be:

  • Course Name
  • Course ID
  • Course Value
  • Course Duration
  • Number of Chapters
  • Course Category and so on.

🚧

Sample Custom Event & Attribute Templates

We've complied Custom Event & Attribute templates for each industry vertical to help you get started. While the data you track for your users will vary greatly as per your business model, you can use these as a reference point.

Tracking Custom Events & Custom Event Attributes

System Events and System Event Attributes are automatically tracked by WebEngage once you integrate a platform through our SDKs. However, you will need to specifically define and pass each Custom Event and their Custom Attributes from your various platforms to your WebEngage account.

Here are a few guidelines to help you get started:

  • Please ensure consistent usage of the names of Custom Events and their Custom Attributes across all your apps (Android, iOS) and website. Doing so will make it easier for you to segment users, personalize campaigns and configure campaign targeting in your dashboard.

  • We highly recommend that you create an excel sheet to list down:

    • The Custom Events you want to track.
    • The corresponding Custom Attributes of each Event.
    • The data type of the values you will be tracking against each Custom Attribute.
  • The first datapoint synced to WebEngage defines the data type for that event attribute. Thus, data types must be consistent with the value that you want to store against the attribute. If the data type is changed at a later date, then Custom Event Attribute data will stop flowing to your WebEngage dashboard.

    • You can create a maximum of 25 Event Attributes of each data type for a Custom Event. (ie. 25 attributes of Number data type, 25 attributes of String data type and so on).
  • Custom Event and Custom Event Attribute names are case sensitive must be less than 50 characters long. String attribute values must be less than 1000 characters long.

    • Names must not start with we_ as the term is reserved exclusively for internal use at WebEngage. Thus, to avoid data contamination for your account, such data will be ignored if used for your Custom Events.

🚧

Please Refer to the Respective SDK Functions to Track Custom Events & their Attributes

Website

Android

iOS

React Native

Cordova/ Phone Gap/ Ionic

Xamarin.Android

Xamarin.iOS

Unity.Android

Unity.iOS

(You will need to intergate the respective platforms with WebEngage before you start tracking custom events and their attributes.)