Feature Enhancement: Conversion Uplift by Journeys

All of our clients derive significantly higher conversions compared to standalone campaigns using Journeys. But how do you benchmark these conversions? In our quest to highlight the contribution of your Journeys towards your business objectives, we now show percentage uplift in conversion from Journeys. This uplift will be benchmarked on the conversions from control group.

The conversion uplift from a Journey is calculated by comparing the following:

  1. Journey conversions: Percentage of users who received any of the Journey campaigns and then converted.
  2. Journey control group conversions: Percentage of users who were part of the control group (eligible to receive any of the Journey campaigns but did not receive) and converted.


What does this mean?

To understand this in more detail, we will first have to understand how Journey control groups work.

Control groups for Journeys are defined for the whole Journey, not for individual campaigns of the Journey.

Users in control group enter the Journey and traverse the blocks for which they are eligible. This behaviour is same as that for non control group users. Differentiation happens when control group users reach any of the Action blocks responsible for sending a message (Send Email / Send SMS / Send Push / Show In-App Message / Show Web Message / Send Web Push). They move ahead in the Journey without the message being sent to them. They might still end up performing the conversion event, in which case this conversion is added to the control group conversion count.

This is a fair comparison since the control group users are also following the exact same Journey as non control group users. This is important because there might be blocks in the Journey which change the user’s attributes, call APIs, or wait for a particular event before sending messages. Which makes it important to compare control group users and non control group users using both Journey and user contexts.

How is this approach better?

To put all of this into context, let’s look at how we had implemented the conversion uplift calculation prior to this update. Previously, control group users did not enter the Journey at all. The comparison for conversions was unfair in this case because:

  1. Control group users not entering the Journey meant that we were taking into account conversions for all users in the control group, while we should be taking into account only for the ones who are eligible to receive the messages for a fair comparison. Eligible users are the ones who reach at least one of the message Action blocks in the Journey.
  2. All of the control group users were getting a lot of time to complete conversion since the conversion deadline was based on the time when Journey ends.
  3. If the Journey included Flow Control blocks (Wait for some time / Wait for an Event / Wait for a Date), then non control group users could be in the Journey for days whereas users in control group who did conversion event would get out of the Journey and later enter it again, which would further mess up the uplift numbers.

These issues have been corrected now by

  1. Making control group users enter the Journey but not sending them messages when they reach the message Action blocks.
  2. Then comparing their conversions with non control group users.

Try out our this feature and tell us what you think of it! Or request a demo from our Success team to learn more about WebEngage!

Monthly Product Updates: July 2018

We have made a bunch of additions to WebEngage in July 2018. Here’s a consolidated list below:

CSV Uploads in Specific Users Trigger Block in Journeys

You can now upload CSV files to trigger a journey for a specific set of users. Previously, you had to copy paste the user IDs in order to trigger the journey for these users. The new update makes it easy for you to upload a list of users.

Trigger Journey for Users ‘In’ a Segment in the Segment Trigger Block

Journeys can now be triggered for users who are already in a segment in addition to the users who enter or exit a segment. Previously, journeys could be triggered only for users who enter or exit a segment.

New Exit Triggers in Journeys

You can add two more types of exit triggers to journeys: (1) When user enter or exits a particular segment (2) When a user’s profile attribute changes eg. exit journey for a user whose category changes from Silver to Gold. Previously, exit triggers only covered specific events done by a user.

Test Campaign Functionality in Journeys

Campaigns created through journeys previously did not include the Test Campaign functionality where you can send the campaign to an internal test segment. This functionality is now available for campaigns created through journeys also.

Specific User Preview for Emails & In-app in Campaigns & Journeys

The Specific User Preview functionality that enables you to see the actual message that a user would receive (where personalization tokens are replaced by actual values) is now available for Email and In-app campaigns as well. Previously, this functionality was available only for Push, SMS and Web Push channels.

Send Campaigns in User Time Zone

You can now choose to send one-time campaigns in the time zone that the user is in. You can find this feature in the When tab of the campaign creation process, when you go to One-time > Delivery = Later. This functionality will be made available for recurring campaigns as well this week.

System Events as Conversion Event in Campaigns & Journeys

You can now also choose the following system events: App Upgraded, User Login, Session Started as conversion event for campaigns and journeys. Previously, only custom events were available to track conversions.

Segment Edit & Create in Campaigns & Journeys

You can now create ad-hoc segments in the Audience tab of the campaign creation process and also in Is in Segment yellow condition block in journeys. You can also edit any segment from these pages directly instead of going to the segment creation page.

Personalization Search Box in Personalization Menu in Campaigns & Journeys

We have added a search box in the personalization menu in the campaign creation process so that it becomes easy for you to search for an event, event attribute or user attribute when adding personalization tokens in your campaigns.

Campaign Report: Additions under More Details

We have added a few more fields under the More Details part of the campaign report page. With this change, you can now see all the options you had chosen during the campaign creation process in the campaign report page itself without necessarily going to the campaign edit page.

Campaign Actions Next to Campaign Name

You will now see a list of actions next to the campaign name when you’re editing campaigns. This will enable you to seamlessly shift from the campaign edit page to to the campaign report page and vice-versa.

Try out our new features and tell us what you think of them! Or request a demo from our Success team to learn more about WebEngage!

Feature Enhancement: Journeys

In order to help you implement real-time user lifecycle campaigns more efficiently using WebEngage Journeys, we have launched few enhancements. These are one of the most requested features for Journeys, and our goal is to streamline the Journey creation process.

Triggering Journey for Specific Users

Using the Specific Users trigger block, WebEngage Journeys allows you to upload a list of users to trigger the Journey for them. Previously, it was only feasible to add a small list of users to this block since you were required to paste the list in this block.

Now, you can upload the list of users as a CSV file to trigger the Journey for them. This allows you to add much larger lists of users conveniently using a slick new UI. This is specifically useful if you are creating these user lists using logic and data from your internal systems, in addition to using triggers based on WebEngage events, user attributes and segmentation criteria.

Triggering Journey for Users in a Segment

In addition to triggering Journeys for users entering or exiting segments, you can now also trigger them with two more segment-based criteria:

  1. Users who are in a particular segment: This will trigger the Journey for all users who are in the segment at the time of publishing the Journey.
  2. Users who are in a particular segment and others who enter it later: This will trigger the Journey for all users who are in the Journey at the time of publishing the Journey and for users who enter the segment later.

New Exit Triggers

We have added two new types of Journey Exit Triggers. Previously, you were able to specify the criteria for user exits from Journeys only based on occurrence of events. You can now make the user exit the Journey based on two more criteria:

  1. User enters or exits a particular segment: For example, you can make the user exit a Journey as soon as he/she starts making regular purchases.
  2. User’s profile attribute changes: For example, you can make the user exit an enrichment Journey when his/her tier changes from Standard to Premium.

Test Campaigns in Journeys

You can now test campaigns in Journeys just like you test standalone campaigns. Using this functionality, you can send the campaigns to an internal set of users before you publish the Journey.

Edit and Create Segments from within Journey Blocks

In addition to selecting a particular segment within Is in Segment block, you can now create it within the Journey block itself if no segment exists yet with the criteria you want to use.

Try out our new features and tell us what you think of them! Or request a demo from our Success team to learn more about these features.

New Feature: Test Your Campaigns Before You Launch Them

As part of our new and improved campaign creation experience, we have added an often-requested functionality of being able to test your campaigns with an internal set of users before you launch them.

Also bundled in this release is an enhanced Preview Message functionality. In the Message tab where you see the preview of the message you’re typing, you will now able to see an actual user preview of the message. The user preview helps you view the message as an end-user of the campaign where the personalization variables used in the campaign are replaced by the actual values for that user.

Let’s go back to the campaign creation process I had described in my previous post. Our 5-step process is now a 6-step process. As discussed above, Step 3 now comes with an enhanced preview functionality and a new Step 5 has been added to the process to help you test your campaigns. These two changes are indicated in the bolded text below.

    • Step 1: Specify the audience for the campaign
    • Step 2: Specify when the campaign has to be sent
    • Step 3: Write your message and preview it as an end-user
    • Step 4: Specify the conversion criteria
    • Step 5: Test your campaign
    • Step 6: Preview and launch the campaign

Both these functionalities help you iron out any imperfections in your campaign before you launch them. Just create as many test segments as you would like comprising of your internal members that you would like to send the test message to. Therefore, if you have a specific team responsible for sending Push notifications and In-app messages, you could have a test segment comprising of only those users and you could name it as Push & In-app Marketing Team. As soon as you complete the Test Campaign step for your Push and In-app campaigns, your team members who are a part of that segment would then receive the message. If everything looks good, go ahead and launch your campaign. Or go back to the previous Message step to edit your message.

Try out our new feature and tell us what you think of it! Or request a demo from our Success team to learn more about this feature.

Feature Enhancement: Campaign Creation

We have completely revamped the campaign creation experience to make it easy for you to create campaigns in WebEngage.

The entire campaign creation UX now follows a simple 5-step process:

  • Step 1: Specify the audience for the campaign
  • Step 2: Specify when the campaign has to be sent
  • Step 3: Write your message
  • Step 4: Specify the conversion criteria
  • Step 5: Preview and launch the campaign

Also bundled with this release is the ability to create a single campaign for sending push notifications and in-app messages for both Android and iOS. Previously, you had to create two separate campaigns if you wanted to reach out to both your Android and iOS user base. This, of course, was not the most optimal experience we would have liked our users to have.

Anyway, let’s come back to why we decided to revamp the campaign creation experience.

Our larger objective behind this change was to make the campaign creation process more natural. Think about it – when you have to send an email to someone, how do you generally go about it? You first think of who you’re going to send that email to and then you compose the message. If you do not feel like sending the message at that moment, you will perhaps save the message in your drafts folder or schedule the email to be sent at a later date. Similarly, when you want to create a marketing campaign, you have a fair idea of who the campaign has to be sent to. Therefore, in the new experience, we first ask you to specify the audience of the campaign. You then specify when you want to send the campaign. Once you’ve specified the audience and when you want to send the campaign, you then compose the message you want to send to this audience. You might also want to track the uplift that the campaign brings to your business. Therefore, we then ask you to specify the conversion criteria and enable a control group as an optional penultimate step. In the last step, you will be able to check all the details of the campaign before you launch it.

With this new campaign creation experience, we are taking our first steps towards a multi-channel unified campaign creation experience. Wouldn’t it be great if you could just specify the message details and images to be used in a campaign and WebEngage could then automatically create campaigns for you across various channels like Push, In-app, SMS, On-site, Web Push, Email, Facebook, Google etc.? Well, watch this space for more details. 🙂

Try out our new feature and tell us what you think of it! Or request a demo from our Success team to learn more about this feature.

How WebEngage Helps You Comply With GDPR

The European Union General Data Protection Regulation (GDPR) takes effect starting May 25, 2018. It is the greatest regulatory change in data privacy in the last 20 years, and will strengthen the security and protection of personal data for people residing within the member states of the European Union.

The most prominent feature of the GDPR, apart from its stringent stipulations, is its applicability to not just entities in the EU but those outside it as well. Any entity that processes personal data of an EU resident will fall within the ambit of the GDPR. In keeping with our commitment to the highest standards of privacy and security, WebEngage is ready for the GDPR. But that’s not all. As the core user engagement engine of your business, WebEngage is also committed to making it easier for you to comply with the GDPR by making tools and features available for you to use. We will support our customers in two main ways:

  • Executing an updated Data Processing Agreement (DPA)
  • New product capabilities which help you be compliant with GDPR requirements when your users request you to delete, suppress, update or export their data.


Our commitment to data security and privacy

If your business supplies goods or services to EU residents, or decides when, why and how user data is collected and processed, you’re considered a data controller. As a WebEngage customer, you likely perform one of the above activities and are a data controller under the GDPR. One of your requirements as a data controller is to only work with GDPR compliant data processors.

Businesses or vendors that process data on behalf of data controllers are considered as data processors. As a retention marketing platform that assists you in collecting and processing end-user information, WebEngage is considered as a data processor. As an independent platform that requires businesses like you to provide us with certain information about yourself before you can use our platform, WebEngage is considered as a controller. We are therefore ready for the GDPR as both.

Here are the initiatives for personal data protection that WebEngage is committed to, as one of your data processors:

  • Executing a Data Processing Agreement: Personal data of users is going to be processed as per the terms mentioned in the Data Processing Agreement.
  • Secure data transfer and storage outside the EU: Transfers of personal data outside the European Economic Area (EEA) are permitted as long as certain safeguards apply. WebEngage will protect any data originating from EEA in line with the principles laid out in the GDPR.
  • Pseudonymisation of all personal information: Personal information of users is always processed by WebEngage in such a manner that the personal data can no longer be attributed to a specific user without the use of additional information.
  • Technical and organizational security measures: WebEngage secures your data in transit, backups, and at rest using best-in-class encryption standards.
  • Processing data according to controller instructions: WebEngage only processes personal data as per instructions from its customers, the controllers.
  • Prompt data breach notifications: WebEngage will promptly inform you of any incidents involving breaches of your users’ data, along with necessary details pertaining to the same.


How we enable our customers to be GDPR compliant

If you collect data of EU residents (either by yourself or with the assistance of other data processors), you are likely considered a data controller. We are rolling out features that will help you comply with your users’ requests to exercise their rights as defined by the GDPR, thus assisting you in compliance as well.

New Product Capabilities

  • Delete user data: You will be able to honor your users’ requests related to the right to erasure (right to be forgotten) by creating an erasure request using our REST API. Creating the the erasure request for a particular user ID will delete all the user data stored by WebEngage – both user profile (containing the user’s personal information) and events, including campaign and conversion data, if any. Also, any data which is received by WebEngage in the future and associated with this user ID will not be stored.
  • Restrict user data processing: You can restrict the processing of user profile data for the users who exercise their right to object (the various rights to halt certain processing) or the right to restrict processing (the right to restriction) by creating a restriction request using our REST API. All processing will stop for restricted users: WebEngage will not store incoming data, no campaigns will be sent to such users and no new segments could be created with such users.
  • Export user data: Users have the right to access and view all data pertaining to them (right to access, right to data portability). You can obtain user profile and events data by creating a portability request using our REST API.
  • Rectify user data: The GDPR empowers users to have the data controller correct personal data concerning them which is inaccurate or incomplete (right to rectification). You can modify user profile data using the /users REST API call for any user ID.

Apart from the above capabilities, WebEngage will also allow you to manage the GDPR requests raised by you:

We have summarized here the rights of end users and how WebEngage helps you comply with their requests corresponding to these rights. You can use a tool like Postman to make the API calls mentioned in the section above.

We look forward to ensuring compliance with the GDPR and continuing our engagement with all our customers.

Join Pankaj Gautam and Madhav Rangrass for an exclusive webinar on June 12 to learn more about how WebEngage is 100% GDPR Compliant. Save your spot now!


New Feature: Download List of Users

Things have been quiet around here for a while because we have been working on a few major releases scheduled to happen in the next few weeks.

However, there is one oft-requested feature that we have made live today. You can now download the list of users in any segment or any campaign from WebEngage. Through this functionality, you can now export the list of users for any segment on WebEngage as a CSV file. In this CSV file, WebEngage will provide all the information it has about your known and unknown users. Interested in downloading the list of ALL your users – head over to the Users > List of Users page and click on the download button. Similarly, in the Campaign > List of Users section, you will now able to download all the details of how your users have interacted with your campaign. Eg. Download the CSV file of all the users who opened one of your email campaigns.

You can use this data to better understand your users by analyzing this data in your systems or in Microsoft Excel / Google Sheets. You could also use this CSV data to feed into some of the other systems you have such as advertising, retargeting, data warehousing systems etc.

Try out our new feature and tell us what you think of it! Or request a demo from our Success team to learn more about this feature.

New Feature: Advanced Data Management

We have released a new feature today that solves a few teething issues that marketers and developers often face when sending users and events data from their apps and website to a 3rd party solution like Segment.com, Mixpanel, WebEngage etc.

At WebEngage, we have routinely come across issues such as data type of a particular attribute of an event not being uniform across different sources such as website, Android app, iOS app etc. Too often we find that a particular source eg. an Android app has defined Attribute X as Boolean whereas another source eg. Website has defined the same Attribute X as Number. Which data type is correct? And how do you even go about tracking such integration issues after you have already onboarded? Given that the code base for your apps and website is updated frequently, it is highly possible that a developer might inadvertently change the data type of some attribute or even worse, completely stop sending that attribute or that event from that source. Unfortunately, these scenarios happen often.

We’ve been wanting to build a solution to this problem for a really long time. In addition to the customer delight, this feature also brings a lot of joy to our customer success teams who in the past have had to scramble to resolve these issues with customers. With our new release today, you will be able to track in-depth the status of the data about your users and events that you’re sending to us from your website, mobile apps and REST API. You can also change the data type of attribute in WebEngage and you can also stop tracking certain attributes and events. 

Somebody changed the data type of an attribute in your apps or website? We’ll proactively show you which attribute from which source (website, Android app, iOS app, REST API) is the cause of this problem.

Never sent data for an event or an attribute from a particular source to WebEngage? We’ll proactively show you the status of integration of each of the sources for each of your events and attributes.

Accidentally changed your code such that your sources are not sending an event or an attribute to WebEngage anymore? We’ll proactively show you which attributes and events are being successfully tracked and which ones are stale (last received more than 7 days ago).

Want to stop tracking a particular event or a particular attribute that you’re sending to WebEngage? You can now do so from the WebEngage dashboard.

Want to change the data type of an attribute you’re already sending to WebEngage so that in future, attributes get ingested in the changed data type? Head over to your WebEngage dashboard and make the necessary change to the data type of the attribute.

In summary, WebEngage will now proactively inform you in real-time whether there are any issues in the data we receive about your users and events from your apps and website, so that you can then take the necessary corrective action quickly. In addition, you will also be able to stop/start tracking events and attributes and also change the data type of attributes. 

Try out our new feature and tell us what you think of it! Or request a demo from our Success team to learn more about this feature.