Introducing Conversion Tracking: To Know Which Half of Your Marketing is “Wasted”

“Half the money I spend on advertising is wasted; the trouble is, I don’t know which half.”- John Wanamaker (wiki).

Although the intrinsic perception among businesses is that if you are doing marketing then it’s certainly going to help your revenue, the reality is otherwise. Your marketing can work both ways. It can match your expectation and positively impact your KPIs. But on the flipside, it can also hurt your conversion and take your KPIs downstream.

So far it was difficult for you to identify the campaigns that were acting as the latter kind on the WebEngage dashboard, the ones wherein you were uselessly investing your effort and money. But that would be the case no more because now we have released “Conversion Tracking“.

With WebEngage’s Conversion Tracking you would now be able to quantify the true impact a campaign is making on your business, both positively and negatively.

Let’s understand how to setup conversion tracking:

  1. First, the preliminary task- create your campaign and set the rules.
  2. Once you are through ‘rules’ you would now be given a choice to set conversion tracking.
  3. Upon clicking ‘Yes’ you would now be faced with three feeds- a)Event b)Control group and c)Deadline

‘Event’ is the particular action that you want to track on your website or app, like cart_abandonment (read more about events here). In the above step, it is being used as a condition for goal. So if the campaign is able to influence user into performing the action (which is to trigger account_create event) then conversion against the campaign is going to be recorded.

Deadline- is the period from the day message is delivered within which the conversion will be tracked. It can also be called the conversion window.

Now, what is a Control Group?

‘Control group’ is the special set of users who, despite being part of the segment, are not treated with the campaign but, and it’s very important, their conversion is tracked. It is basically a neutral group which is created only to gauge the metrics of the users who did not receive any message. Why we do that? Let’s see.

By setting up a control group(CG) you would be able to measure the conversion of the users who were treated with your campaign against the users who weren’t. This would essentially let you know the true impact of your campaign.

For instance, in this case, we have set the CG as 20% and event as account_create. So if my stats, by the time conversion deadline ends, show that CG users created more account than the users who received my message, then my whole campaign idea was a farce. Likewise, if the activity group wins then I would know what variant of my messaging achieves the most success.

Once you are done setting up the campaign this is how the stats would look like:

In this case, the control group conversion is 20%- 5% lesser than the campaign’s conversion, implying that our campaign has worked.

Now that we are through setting up conversion tracking the question arises how would attribute conversion if there are multiple campaigns triggering the same event.

Attribution modeling

Case 1- When you create multiple campaigns within the same channel to achieve a common goal

Multiple variants in a single channel

Suppose you are creating 3 different email campaigns for different segments to trigger a common event, say cart_checkout. Now let’s say user engages with all the three messages and gets converted. In that case, to which campaign would the conversion be attributed?

Here WebEngage system by default adopts ‘deepest then latest’ attribution modeling.

What is ‘deepest then latest’?

WebEngage system records and compares the following three actions of the user along with their timestamp to attribute conversion.

      1. Click
      2. View
      3. Sent

The actions have precedence in the following order:

Click > View > Sent

So if campaign A, B, C are triggering the same event as goal then the system is going to credit conversion to the one which got ‘clicked’ among all of them. If none get clicked then it is going to credit the one which got ‘viewed’ and likewise it would drill down to ‘sent’. Basically, the preference would for the campaign receiving the relatively highest priority action within the conversion deadline(Deepest of “Deepest then Latest”)

But what happens if both campaign A and B get clicked and conversion happens. As in, how do you attribute conversion if the combination of campaigns receives the same action?

In such case, the system would check the recency(Latest of “Deepest then Latest”)

For instance, if both campaign A and B get clicked, then the credit would be given to the one which was clicked most recently from when the event was triggered (conversion happened).

First precedence to the action and then to the recency- Deepest then Latest.

Case 2- When you create multiple campaigns across multiple channels to achieve a common goal.

Multiple campaigns across multiple channels

Suppose there are campaigns across multiple channels (push, email, web etc.) which are linked to the same event. Then, how do you attribute?

The answer is- same as above.

The system basically has no preference for any channel and it scores each of them equally from the conversion perspective. So in case multiple campaigns across multiple channels are trying to achieve the same goal, the system, regardless of the channel, would attribute conversion the same way like it would do for multiple variants or multiple same channel campaigns.

The same principle of “deepest then latest: would apply here as well just as it did in the previous case.


      1. If the top performing variant puts behind the others only by a close margin than accentuate the corresponding change and observe the result.
      2. Skip creating the control group for alerts type messages where you want your messaging to reach everyone.
      3. More than often there are types of messaging which are meant for a particular channel and running it in a different channel doesn’t yield any significant outcome. Basically, there are some messages which only resonates with a particular channel and not with the rest. With ‘conversion tracking’ if a message is not showing signs of success with a particular channel, try testing it with a different one. Compare the metrics across multiple channels and zero in the one where it sticks the most.
      4. Avoid creating control groups for smaller segments. Metrics for smaller segments are driven equally by chance and user behavior since the sample size is way too small. Creating control group for such segments are not going to give any conclusive insights into the factors that affect your conversion. So avoid creating control groups for them.

(We shall keep updating this list)

That’s about it people. Please try these features out and share your feedback either in the comment or

Improve Web Push Subscriptions Using Targeted Opt-in Prompts

If you ask a room full of mobile marketers- what’s the most powerful engagement channel they have, the unanimous response would be- push notification.

Yes, the ability to push messages to the user’s device when he is not actively using your app was a critical mobile feature that was missing from the web. So, when web push was first introduced by Google for Chrome in early 2015, it witnessed enormous adoption by marketers, especially from the publishing industry.

What makes Web Push the new Retention Marketing favorite?

We have covered this in detail in our blog on WebEngage Monk. I will add the gist here.

  1. It’s easy to set up
  2. It kills the need to launch an app just to be able to send notifications to the user.
  3. It doesn’t carry the risk of ending up in the spam folder or blocked by ad blockers.
  4. It can be targeted to an enormous degree natively or by a third party targeting engine (like WebEngage).

However, to be able to send notifications, a web-app has to take explicit permission from the user via an opt-in prompt as shown below.


Web push’s opt-in prompt cannot be invoked once user ‘denies’ it

Now, amidst the immense potential that browser push presents to marketers, it also comes with a challenging drawback. I have discussed them below:

Push API gives only three options to users to engage with the prompt:

  • Default– When the user ignores by pressing ‘escape’ or by canceling the notification
  • Granted– When the user clicks on ‘Allow’
  • Denied– When the user clicks on ‘Block’


However, the catch is that once the user clicks on ‘block’, browser API doesn’t allow you to launch the opt-in prompt again similar to iOS permission dialog box which cannot be invoked again once the user clicks on ‘Don’t Allow’.

Now, for the user to reverse his decision, he has to go through a complex UI and allow notification manually, the probability of which is the guess of any pragmatist. So, technically a user clicking on ‘block’ entails that you lose the channel of web push forever to engage with him.

Now how to crack this? Do the right thing. Send targeted opt-in.

Why companies are not implementing targeted opt-in?

It’s a no-brainer that a targeted opt-in would perform way better than a non-targeted one. Yet, it is very common for websites to pop opt-in prompt on the user’s face right when logs into the website. The untimely, untriggered opt-in naturally leads to high rejection rates and ultimately poor UX.

However, the publishers can only partly be blamed as almost all the standalone push notification engines don’t offer deeper segmentation capabilities. In fact, they don’t provide any option at all to target your opt-in on the dashboard. Segmentation is not their primary USP.

What these engines essentially do ,instead of providing targeting capabilities, is provide an API which lets you write a script to create targeting rules yourself. (not all of them do this either)

So, in order to layer your opt-in with any rule, you have to write the script yourself which entails involving dev team, tiresome deployment phases and annoying need to write a script for every rule you want to create.

Introducing ‘Opt-in Rules’

At WebEngage, we introduced some new features for web push that would allow our clients to target their opt-in prompt in the most efficient manner possible. Using those features, a marketer would be able to ask for permission for web-push from the user when he is most likely to say yes.


Let me walk you through the targeting options one by one:

1. On specific pages

This allows you to target your user when he lands on a specified URL. Via this option, you would be able to ask for permission only on those pages where the likelihood of user allowing is the most. For instance, nudging users

  • For promotional notifications when he is on checkout completion page.  


Note- You can do launch the prompt both ways. Either, you can you launch it directly on the checkout page or, you can layer it with a pre-permission dialog box. We went with the former way in this case.  

  • For blog updates when the user lands on help page and so on and so forth.
  • For product updates when the user is on the product search page.  

2. Time delay

Time on page is an indicator of the user’s engagement level with the website (obviously not the only one). So, this targeting option allows you to fire the prompt when a user spends a certain amount of time on the page. This option, when coupled with the previous one, can create very powerful use-cases which could enormously increase the probability of user opting in. For instance

  • Targeting users who have spent more than 2 minutes on the product page.
  • Nudging users for blog updates who has spent more than 150 seconds on help domain.

3. On scroll

This allows you to fire the prompt when a user scrolls the specified percentage of the page. This can be extremely useful to the single page web apps or websites with infinite scroll functionality, which are mostly SaaS and news websites respectively.

Again, WebEngage allows you to couple any of the aforementioned rules and the one below to create a customized rule.

4. On event

Events are the actions performed on the website- either by the user such as ‘add to cart’ or by the system such as “tracking user’s inactivity on check-out page”.

By using events as a behavioral trigger, you can conceptualize infinite ways to nudge your users for web-push. You can fire the prompt upon the completion of any critical event that increases the likelihood to allow. For instance,

  • You would able show opt-in to user when he submits a subscriber form


  • When the user creates an account on the platform.
  • When the user adds more than x items in the wishlist. 

And there could be countless such use-cases, varying from industry to industry, with a solid assurance that the opt-in rates are going to be high.

That’s all. Please try these features out and share your feedback either in the comment or