 Okay, so I'm Vishy and I'll be talking to you about ClearTrip's mobile web experience. I have to start with a confession and I have to apologize to Praneet and Rudy and Vidya and all the organizers here because the content of our presentation has taken a complete U-turn since yesterday morning. Unfortunately, yesterday morning there was a meeting and we took a call that we will be joining the likes of Minthra and Flipkart in shutting down mobile web. And yes, you guys in this room are the first to hear about it. So that sort of changed the content of the entire presentation and now the agenda is very simple. I'll talk to you about the ClearTrip journey on mobile web and of course I would be remiss if I don't walk you through the rationale of why we've taken this decision. So that's what we'll talk about. Okay? I'm just kidding. Come on guys. We are not shutting down mobile web, not today, not anytime soon. Okay? And the first point on our agenda. I never said never. Never say never. Never say never. Not anytime soon and I'll walk you through why that is the case. Okay? So the first point is why ClearTrip is not shutting down mobile web. We'll then talk about user behavior on mobile web, what we are seeing on mobile web is different from the apps and from desktop. We'll talk about how we are using mobile web to acquire new customers and why it's important to do so. We'll talk a bit about using mobile web as a testing ground for new features and again a bit about the why. And finally we'll take a look at the future, what mobile web will look like maybe two years from today or it needs to look like and so on. Right? So first of all, why mobile web? Mobile web is and continues to be integral to ClearTrip's plans when it comes to mobile. Okay? 50% of all our traffic is coming from mobile devices today. 50%. And of that mobile device traffic as much as 46% is coming on mobile web. So if you look at it, 23% of all traffic to ClearTrip is today coming on mobile web. And yeah, this is a huge percentage, right? But it would be meaningless if that trend is decreasing, if the traffic on mobile web over time is decreasing. But I'm happy to report that is not the case. Right? In the last 12 months and in the last 18 months mobile web has been going up, up and only up. Okay? So this slide shows you the search trends on mobile web since April 2014 to March 2015. The blue line is flights. The yellow line which looks like green here is hotels. It's only going in one direction. Right? This is searches. The same is the case with bookings. Bookings as well. Both for flights and hotels it's going up. In fact, mobile web today contributes 20% of all mobile bookings that we get for ClearTrip. Right? So in a nutshell, this is what it is, right? It's a significant share of searches and bookings. That share is not decreasing. It's actually increasing. And the traffic itself is increasing. And that's why mobile web is and continues to be important. But it's more than the data, right? It's, for us, it's a bit about the philosophy as well. We care about our users and we believe that we travel is a need-based service. And ClearTrip needs to be wherever and whenever our users need us to be. Right? So that's why our users are on mobile web. A significant percentage of them are. And that's why we will continue to focus on mobile web and continue to offer new experiences. In fact, just this week, we've completely revamped our mobile website. So the experience you see now, which internally we call Tuxedo, is now much better than what you were seeing last week. And it's in line with our desktop experience, right? So that's why mobile web. Now let's look at user behavior, right? So one of the, I mean, like I said, travel is a need-based service. And one of the key metrics for user behavior is last-minute bookings, right? When you need to book, you need to book. And many times that happens at the last minute. So the way we track last-minute behavior is by looking at the difference between the date on which you've booked and the date when you're traveling, okay? So if you're booking today, morning to fly tonight, the difference is zero. If you're booking today to fly tomorrow, the difference is one. If you're booking today to fly next Friday, the difference is seven and so on and so forth. So this slide shows you that difference for Android app, iOS app, and mobile web for flights and for hotels. Now, one thing we note is that for, I mean, for travel as a whole, we see more pronounced last-minute booking behavior on mobile compared to desktop. So people tend to book last minute more on mobile than on desktop. And within mobile, what these slides show you is that mobile web shows a much more pronounced last-minute behavior than Android app and iOS app, right? So for mobile web, as many as 26% of all flight bookings are for today, travel today or tomorrow. And for hotels, it's as much as 46%, right? 44%. So it's mobile web, essentially, is our most need-based channel for a need-based service, right? And that's why it's so important. When our users really need to book, they need to book right now. And if they are on the move, they are on mobile data, or they don't have storage in their device, we don't want to leave them stranded. We will allow them to book on mobile web, right? The other interesting thing to note is the average booking size by platform, right? So again, this slide shows the average booking size for domestic air, international air and hotels. Now, in flights, we all know it's a simple rule of thumb. The later you book, the more expensive the ticket is, correct? So that's what you see here. Because an overwhelming percentage of bookings on mobile web are last-minute bookings, the average booking size on mobile web is higher than both iOS and Android apps. But the behavior is slightly different for hotels. Yes, there are more last-minute bookings, but the target audience, the customers who are booking hotels on mobile web are different. And they tend to be first-time users, so they tend to not book very expensive hotels, or they tend to book for shorter stays, which is why for hotels, the average booking size on mobile web is significantly smaller than on the apps. And this is further borne out if you look at the kind of hotel bookings we are getting on mobile web, right? We are on the apps, we get as many as 34% of our bookings for four and five-star hotels. But on mobile web, that percentage is just shy of a quarter of the bookings. So a very different kind of customer as well on mobile web compared to on the apps. So in summary, user behavior. So we already talked about the last-minute booking behavior, right? Most need-based channel of a need-based service. But another kind of user behavior that we see is sort of infrequent use, casual searches, first-time visitors to Clear Trip, maybe shopping around, comparing prices between two, three travel websites. So they'll come, they'll do a couple of searches, probably won't book, which is why we see a lot of casual searches and few bookings. And this is what drives down the conversion of mobile web compared to the apps. And we define conversion as the number of bookings divided by the number of searches. So for mobile web, the conversion is usually in the range of 20 to 30% compared to the apps. And of course, I already talked about booking size high in flights because users tend to book last-minute low in hotels because users are usually first-time users or booking different kinds of hotels, right? So that's with respect to user behavior. Let me talk a bit about mobile web for user acquisition. I'll start with why this is important, right? So we already talked about the huge percentage of traffic that is coming for Clear Trip on mobile web. The other thing to note is that of the traffic that is coming to mobile web, 40% of that traffic is new users, right? Across time periods. This is across the last two quarters, which is a significantly higher percentage of new visitors as compared to the apps. Now, on apps, retention is high, but the percentage of traffic, percentage of new users is lower. So this is, in itself, is a very important metric because that means this is your primary channel for new traffic, new user acquisition, right? And of course, a huge percentage of that, this traffic is coming from search engines like Google, right? And where do those people land? They land on your SEO pages. And when they land on your SEO pages, there's a choice you have. You can either take them to a crappy, non-mobile-optimized SEO page, in which case they will remove you from the consideration set immediately and never come back again. Or you can realize that, okay, this is static content. It's not very interactive. So there's not too much effort involved in mobile-optimizing this content. And if you do that, and if you give them a good mobile experience on the SEO pages, which is the first experience they are having with your brands on a mobile device, then there's a much higher probability that they'll stick to you when it comes to mobile devices. And that's exactly what we are seeing. So here are a few examples of our SEO pages. So the first one here, the first two, actually, if you search for hotels in Goa on Google, the second or third link will be a clear trip link. And if you tap on that link, this is the page you come to. This is a not very dynamic content page, which is basically a list of hotels in Goa. It starts with, it gives you a nice little upsell here, which incentivizes you to download the app. It lets you start a search. It gives you the phone number if you want to book on the phone. And yeah, it's not, it doesn't look as good as the app. But the objective is it needs to meet a certain minimum standard of user experience, and that it does. Similarly, if you search for flights from New Delhi to Bangalore, the first clear trip link that you see will bring you to this page. This page shows you a nice little fair calendar here, which is showing for the next 30 days, what is the lowest fair every day for New Delhi to Bangalore flights. If you tap on any of the dates, it'll immediately trigger a search for New Delhi to Bangalore on that date. And of course, if you scroll further down, you'll get things like flight schedules, frequently asked questions, and so on and so forth. So like I said, it's about maintaining a minimum threshold of user experience and making sure you don't, you are not chucked out of the consideration set completely when a user has the first experience with your mobile site. Of course, once users come to your mobile, so for example, SEO pages, and then they trigger a search, they go to your actual mobile site where all the options are there. Then it's your responsibility to convert them to the apps. And I'll talk a bit later why it's important to do so. But in order to convert them to the apps, we've tried a bunch of different options, what we call upsells, some of you might call banners. And trust me, we've tried big banners, we've tried small banners, we've tried pretty banners, we've tried ugly banners, we've tried intrusive banners, we've tried non-intrusive banners. All of them have their pros and cons. What we are using today is what I like to call money banners. And we all know money talks, right? So this banner is very simple. Download the ClayTrip app and you'll get 250 rupees off on your first booking irrespective of what product you're booking. And guess what? It works. We are getting a bunch of downloads from this. And the other thing we noticed is when you use money banners, the size or the prettiness of the banner suddenly stops mattering. So that's what's happening here. So we're getting a nice little bunch of organic downloads from these money banners here. So like I said, so mobile web for acquisition, right? It's the gateway to your mobile experience. When a new user is coming from a search engine, or they are searching for either your brand or for a travel-related keyword, this is the first experience of your brand on a mobile device. If this is crappy, first impressions last a lifetime. You will fall out of the consideration set right there and then. And this is the best source of organic user acquisition for apps because there's intent. They are searching on Google either for your brand or for a travel-related keyword. They are mobile. They're already on a mobile device. And they are brand aware. They are coming through Google. They've clicked on a clear-trip link. So by definition, when they reach your page, they are already aware of your brand. It's your responsibility to make the most of these users. New features on mobile web. So this is an interesting case because I know some, like, the context right now is interesting. Some people are shutting down their mobile sites. Others, even if they are not shutting down, they are kind of getting the step-child treatment. And in fact, if you've noticed in the agenda, that's what I've called mobile. It's mobile web. It's mobile step-child. So we try not to do so. So for example, one of the use cases here is high-traffic pages. So there's something called a train calendar, which I'll show you in a bit. This train calendar ranks very high on SEO. And believe it or not, up to 25% to 30% of all clear-trip traffic comes to this page alone. So imagine if a third of all our traffic is coming to a single page, and if that page is not mobile optimized, imagine what impression we are creating on the users. You can also use mobile web as a testing ground for new features. It doesn't take a lot of effort when you're launching something on desktop. You can concurrently launch it on mobile web. Its release cycles are much shorter on web. You can release weekly or daily or fortnightly or whatever. But on apps, usually the release cycles are four to six weeks. So it makes sense to launch features on mobile web just when you're launching them on desktop. And you get a nice little insight into how mobile users will respond to these features. And at clear-trip, we pride ourselves on being mobile first before mobile first was even a thing. For example, in October 2010, five years ago, we launched what is called Express Checkout. And we launched it only on our mobile site. It was launched on the mobile site before it ever made its appearance on a desktop as Expressway. Three years ago in 2012, we launched Quickies. We launched it concurrently on desktop and mobile web. This is last-minute bookings, last-minute hotel bookings. And a few weeks ago, we launched Train Running Status. This, again, is actually not on desktop at all. You won't be able to find it on clear-trip's desktop site. But you will be able to. Now it's in the apps where it was launched on mobile web much long before it was launched in the apps. So that's what we are talking about. And this is Train's Calendar. So what Train's Calendar is is very simple. You enter a source and a destination station. And say, for example, in this case, you're saying Bangalore to Chennai. It will tell you for all the trains between that go from Bangalore to Chennai, for the next two weeks, what is the availability on each day. It's a brilliant use case, gets a ton of traffic for us. And this is what it looks on desktop. And this is what it looks on mobile. So it works. It just works. And now, in fact, it's on the apps as well. It was on mobile web long before it was on the apps. And similarly, we have a bunch of pages which are train information pages, train schedules, when a train runs, what is its schedule, and so on. And this is actually a work in progress right now. Ultimately, this is what we want to do. On mobile web, our train section should look something like this, where all of our trains use cases are serviced from a single step. So that's about new features on mobile. Like I said, low effort, low maintenance, user experience is not compromised. And the idea is to get users accustomed to new features on mobile web and then convert to app. Now, this is interesting. Here's where I'll give you a slightly contrary view point. Now, yes, it is important to serve all need-based use cases on mobile web. If a user needs to book a flight, he should be able to do so right there and then. But for some of the use cases, for example, if you want to reschedule a flight, or if you want to check in for a flight that is already booked, one of the things that we want to try out is to disable these features on mobile web and ask users that if you want to use this, you know what? You should download our app. It's a great user experience. And it'll let you do all this and more. So what you're doing here is you are taking the slightly more advanced use cases that are used by the more sophisticated users. And you are asking them that if you want to use this, you should really download our app. It's selective disabling of some mobile web features in order to make sure that users get to experience our app as well. But yeah, you need to be very careful, very choosy, in which use cases you do this. For example, if I say, yes, you can book flights and hotels on our mobile web. But if you want to book trains, you need to download our app. Then a lot of you in this room will not be happy. So that's something to take care of. That's pretty much it. Like I said, I'll be brief. So the gist, what are we talking about? The first thing, really, is for us to understand what mobile web is good at and what it's not good at. Mobile web is good at acquiring traffic. But there's a reason it's called traffic. Whenever you talk about web, whether it's desktop or mobile, you talk in terms of traffic. You talk in terms of visitors. You never talk in terms of users. You know why? Because this traffic, even when it lands on your website, you don't own it. Let's be very careful. The only company that can claim to own this traffic is Google. You don't own this traffic. That is why the quality of traffic is always an issue. If you want to convert traffic to users, it's best to convert them to the apps. Yes, it's very good to test new features. And yes, you get a high percentage of new visitors on mobile web. But the flip side of that is that retention is poor. You will not probably get the same users coming to mobile web again and again. Because the people who are coming here are coming only when there is a need, not when they want to. Yes, it's low effort and low maintenance, but it's also low engagement. And that's because right now, mobile web cannot compete with the performance or the user experience that a native app can offer. So I qualify this with the word native. That's the operative word here. If your app is just a bunch of web views, then this does not hold true. But yeah, if your app is a native app, then yes, you can offer a much better user experience on mobile web than you can on the apps. So where does this lead us to? Where is mobile web heading in an app world? It's an app world. And let me qualify that statement in an app world. Why is it an app world? Seven months ago, I was blessed with a baby daughter. I know the average age in this room is much younger than mine, but bear with me here. So now she started moving around. And trust me, when babies move, they move. But what is happening is she's already started gravitating towards the iPhones and the iPads that she sees lying around. She sees us using. We try not to use them too often in front of her, but she's already started gravitating towards those. In a couple of months time, she'll start using the iPad or the iPhone. And when she starts using an iPad for the first time, guess what she will use when she first picks it up? She will open an app. She will open an app. It might be a game. It might be a music app or whatever. She'll open an app. When she's bored with that app, guess where she'll go to find another app? She will go to the app store. Because she knows that's where that goes to look for new apps. And so she'll go to the app store. So it'll become a cycle. She downloads an app. She goes to the app store. That's her world. That's the internet for her. Yes, sooner or later, she'll probably join a Facebook to social network. Or she may not want to join the social network that her parents are on, in which case she might join some new fangled social network like LO. Of course, she'll find me there as well, because I'm two steps ahead of her. So yes, she'll join a social network. She'll see links that her friends are sharing. And she'll tap on that link. You'd think, OK, now she'll come to know that there is something called mobile web, but she won't. Because that link also will open within the Facebook app. The point I'm trying to make is it'll be a long, long time before she even becomes aware in her consciousness that there is something called a browser and there's something called mobile web. For us, when we were growing up, there was this brilliant, amazing thing called the internet. And the portal to that internet for us was either a crappy internet explorer or a brilliant Netscape navigator. For her, the portal to that internet is an iPhone and an app store. Yes, someday she will come to know that there is something called a browser when I'll tell her. And I'll tell her this is where you enter the name of the website to visit a site. And then probably she'll ask me, but dad, why do you need to visit a site? Why don't you just get an app? That's where the next generation is headed. In three to four years, the next generation won't even know that there is something called mobile web. So we need to be, I'm not saying the usage will completely be obliterated, but we need to be cognizant of where things are going. And that's why in this kind of a world, mobile web needs to understand that the way to coexist is by complimenting apps, not trying to compete with them. You need to understand that there are want-based use cases, there are impulse-driven use cases for which apps are very good. There are need-based use cases when you just have to do something, and if you don't have the app, you'll search on Google. And at that time, you need to serve the needs of the user in mobile web, right? You need to be where the user is. That's our philosophy at least. You need to open the gates for mobile users. If mobile users are visiting your brand page for the first time, they need to see something that is not crappy, and that's what I call opening the gates. And once you open the gates, once they are inside the gates, converting them to the apps is your responsibility. You need to acquire users, not traffic, because you never acquire traffic. It's never yours, right? And finally, apps can also play a better role in app engagement. Mobile web can play a better role, right? There can be much heavier use of deep links to apps. They can coexist, right? And there can be, like I said, value-added features can be offered from apps only instead of mobile web, right? I'd like to finish with some thoughts on how everyone in this room, you know, all of us I think can do a better job of selling mobile web as well, right? It's, there are use cases, there are situations where mobile web is genuinely superior to apps. For example, if I'm on an edge network, it doesn't take any data. If I have a smartphone where I'm running low on storage, it requires zero storage, right? If I am, there's a reason why all the car manufacturers don't have apps of their own, because you don't buy a car every day or every week or even every month or even every year. It does not make sense for them to have apps because you will never keep those apps on your phone. You might install it once when you're looking for a new app, but you'll delete it as soon as your purchase is done, right? That's why car makers have mobile web, not apps. And in fact, many of them don't have mobile web also, which is an entirely different story. Like I said, a mobile web can intelligently be used as parts of apps. It can also be used as entire apps, although we don't recommend it, but we know, all of us know, that there are some brands that are doing that, right? True A-B testing. I posit that true A-B testing is only possible on the web, not on apps. Yes, there are a bunch of SDKs available, but if you've tried using a couple of those SDKs, trust me, it is no cakewalk, right? Moving a button from top to bottom is not what I call A-B testing. A-B testing is offering one experience to one set of users and a different experience to a different set of users. That today, it's either impossible or very, very hard to do in apps. So hard that it's not worthwhile, right? And finally, I think as proponents of mobile web, we can do better at helping users create shortcuts or launchers. This whole paradigm of opening a browser, either going to Google or entering the URL to open a website is going to become archaic very soon, right? So I think we need to do a better job on our websites to ensure that the users who are coming here can create quick launchers. Again, these launchers don't take any time to download. They are not dependent on the speed of my data network. They don't take any storage. Those are things that we need to educate users on, right? So yeah. This is how I think we can get better at selling mobile apps. And that's pretty much it from me. Thank you. APPLAUSE Hey, Vishy. So could you elaborate a little more on the last point where you said that true A-B testing is only possible when it comes to the mobile web? Do you have any sample cases in mind where you saw that doing A-B testing on a mobile app was probably the worst thing you would have done? So where I'm coming from, yes, I have used cases in my mind. Unfortunately, I can't share many of those with you. But yeah, where I'm coming from is we've recently, for the past couple of months, we've been struggling to integrate A-B, so-called A-B testing STKs into our app, right? Now some of these STKs require you to predict what are the things that you would want to A-B test and pre-program those things into their STK. So pre-program events for every little UI element that you want. So it's basically replicating your entire in-app analytics infrastructure. And then whatever UI elements are already events are configured for them, only those you can A-B test. But my problem is I cannot predict with 100% confidence what I might want to A-B test three months from today. And if I decide to A-B test something and the event for that is not configured already, then I need to push an update anyway. So it defeats the whole purpose. If I need to push an update before running an A-B test, it defeats the purpose, because the time taken is just so long. That's one. There are other kinds of use cases, which are just, I mean, I want to offer a completely different experience, for example. So for example, we call it the book flow. When you've searched for a flight, you've selected for a flight, you've selected a flight. Once you've selected a flight till the payment stage, that's called the book flow. It's a four-step flow. I want to offer users a completely different experience for these four steps. The only thing to do here is to have these four screens plus the variance of the other flow built inside the app, for which as well, if I've not predicted this in advance, I need to push an update. That is one. The other thing is if I start replicating screens like this, it increases the size of my app, which in turn increases the chance of my app being uninstalled. That's where I'm coming from. It's just much, much simpler to do on web. So I'd just like to say a couple of things. One thing, I really appreciate all the data that you're willing to share with us, all the analytics, because I'm sure all of that is very valuable and it's not generally something that we get to see. And you may not get to see a lot of that in the presentation that you get from it, but anyway. And also one interesting thing that I saw compared to previous talk. So one of the things I saw that you've done with your mobile site is you have kept it simple and you have let it stay a website and not try to make it look like a crappy app. It looks like a website. It behaves like a website. And so there is no confusion there. I know what it is and what it works. So I didn't really have a question for you. Just wanted to point that out. And I just say that that was very interesting. Thank you so much. That compliment actually goes to the three or four gentlemen sitting here who are part of our design team. And they are the ones who make everything look as good as it does, right? But thank you. Hi, Vishy. Hi. So you started off by saying you want to be the app wherever the customers need it, whenever the customers need it, right? That's what you started off with. And then probably also mentioned that it's not a great user experience when a person has to download an app in not that great network conditions and things like that. I want to understand how is it a great experience if a person has to download the app if I have to make a last minute change in the booking? I'm not saying it's a great experience. So why would you consider blocking that feature at all? Even think of considering blocking that feature. Does that help in a good experience? Or is it after a point of time you don't care about the experience, now the business? We have to move towards the business. OK, so you have to understand, I know everyone in this room cares about user experience and design. I do, too, coming from ClearTrip. But you have to understand that sometimes you need to make calls that are in the interest of the business. I'm not going to tell you that that is a better user experience than if you were able to do that right there on the web. What I'm saying is for non, yes, maybe rescheduling was not a very good example there. Because again, that is a need-based use case. If you need to reschedule now, you need to reschedule now. But so that's what I'm saying. That's the internal discussion that you need to do. That if it's not a need-based use case, if it will not piss off users. For example, you need to check in. Now there are 48 hours to check in. In fact, our check in works in a different way. You can check in any time after you've booked. So if that is the use case, then there's no compromise to be made. You don't have to check in right now. We are telling you, yes, if you want to check in, you can download the app. You don't need to download it right now when you're on mobile data. You can download it when you go home when you're on Wi-Fi. So point taken. I'm not saying one is better than the other. I'm saying that's a call that needs to be taken carefully so that, yes, the needs of the business are satisfied, but also the customer experience is not compromised. All right, fair enough. So the thing that I really liked before that, at least I find that to be the quote of the day when you said that the money banners, when they're there, doesn't matter whether the design is good or not or anything like that. So if you're talking about incentivizing people to upgrade to an app, I find that to be fair, a totally fair thing. But if you're saying that I'll throttle a feature, I'll let you not do it, that's like blackmail. Just a comment. OK, agreed. Point taken. Thanks.