How Zivame used Web Push and Onsite notification to increase their conversion by 20%

Estimated Reading Time : 2 Mins | Knocks : 692
Customer Profile

Zivame is one of the India’s largest lingerie marketplace functioning in both online and offline space. Founded in 2011, the company has so far raised $46 million in venture capital and currently caters to 1.5 million+ active users on their online properties. Initially, the company was totally into online retailing but forayed into physical space in mid-2016.

During the time of publishing this post, Zivame had 22 open physical stores spread across India and they are planning to cross 100 by next year.

The Objective

Drop-off from the product page is a ubiquitous challenge across all e-commerce businesses. Users come to the platform, search, visit a product page or a couple of them, and then exit without making a transaction.

Now, Zivame did not want to live with the wildly optimistic hope that, once having exited the website, users would return on their own and make the purchase.

However, the problem is that bulk of MAU for any e-commerce business, which is not totally app-based, is anonymous. You could target known users via mobile or email, but for anonymous ones, the only medium at our disposal is onsite messaging.

Now, creating a personalized, engaging experience, via onsite messaging is easier said than being done. Tying the behavioral history of the user across web and mobile, and incorporating it in your messaging in a live setting is supremely difficult.

So, Zivame used WebEngage ‘Journey Designer’ to address it.

The WebEngage Effect

Zivame created a Journey that targeted anonymous users, who dropped off from the product page, via two channels:

  1. Onsite notification
  2. Web Push

The lifetime of the journey is 4 days.

If you found it hard to make sense of the above journey, following is the simple whiteboard diagram.

The Journey first checks, for 30 minutes, whether or not the user converts organically, post viewing the product page. If she doesn’t, then the journey triggers a message. The message is to be sent via Web Push – so it checks for the user’s reachability on the channel. If the user is not reachable on Web Push (has disabled web push notifications manually), then the journey triggers an onsite notification.

A highly personalised on-site notification is then triggered by WebEngage using attributes from the user’s behavioural history (viewed_product event) and her profile details. (see the full Journey) For example, let’s assume that the user viewed Puma Running Pants. Thus, the user will be prompted with the notification shown below –

While you’re at it, here’s the backend view of the click-through-rate performance of the personalised on-site notification:

Now, if the user doesn’t convert post viewing the notification, then a series of web push notifications will be triggered by the journey. Each web push message will carry a highly personalised copy, with an intent to make the user purchase the product that she has viewed.

So, if she doesn’t purchase post viewing the first notification, then she is nudged with the following web push.

If she yet doesn’t convert, then the Journey triggers this:

This is the final one and we end the journey whether or not user converts because we cannot risk getting unsubscribed. (once the user unsubscribes we lose web push as a channel forever)

Each notification is timed at the gap of 2-3 days so that the user doesn’t feel bombarded.

The Result

The journey led to uplift of 20% in the conversion.

As it is apparent from the journey, 32.7k users converted on their own without any intervention whatsoever.

With the effect of Journey designer, 6408 more users converted, which is 19.6% of 32.7k. In other words, Journey Designer led to 19.6% uplift in conversion. (Follow the marker in the Journey to see the number of users who converted via Web push 1 and Web push 2.)

If you multiply this uplift with Zivame’s AOV then it amounts to millions extra to the Zivame’s topline. Now, this Journey has been running for less than a month so it looks like there’s a lot of money on the table for Zivame to grab. And mind you, this is just one such journey.

Rate This Post
Average Rating : 3, Total Rating : 2
  • Manish Anand

    So we are assuming here that user ‘opted’ in for web push. Plus dun get the on-site messaging part in the first step. There the assumption is that the user has returned back to the website. Correct??

  • Hi Manish,
    User is prompted with onsite notification if he has not subscribed to web push. For those users, the journey end right there.

    If he has however subscribed to web push then the Journey follows. Check the rest of the journey.

    Coming to your second question, if you check the second block in the Journey, there is a delay condition of 30 minutes. That means that if the order is not successful within 30 minutes post product page view, the journey will be triggered. So, the user may be in the same session or ‘returns’ to site within 30 minutes, the journey doesn’t care. It will prompt right at the 30th minute via web push or onsite depending on the user’s reachability. For onsite, the site should be open, for web push the browser.

    Please let me know if this doesn’t satisfactorily answers your question. Would be glad to explain further.

  • Dhwani Shah

    Hi,
    A very insightful article.
    But leaves me with a huge doubt. Well, if he is a new user who has not signed up with Zivame, can you still pick their First Name? No right? And based on the scenario mentioned above -“However, the problem is that bulk of MAU for any e-commerce business, which is not totally app-based, is anonymous. You could target known users via mobile or email, but for anonymous ones, the only medium at our disposal is onsite messaging.”

    How were you able to take their first name if they were anonymous users?

  • Excellent observation, Dhwani.

    What I meant there was that Onsite messaging is a good medium to engage anonymous users. However, this notification is shown to both anonymous and known users. If his name is saved then the first.name token would be rendered in the notification, else it would be simply blank and appear as “Hi , will you get lucky….” (comma placement is grammatically wrong now and they should ideally put else condition)

    The most important personalization component is the [product viewed].custom[product name] token which would appear no matter the user is known or anonymous.

    I should re-work on the para you pointed. Thanks and let me know if this didn’t make sense.