 Yeah, so a couple of disclaimers before we begin this. How did we build our app at free charge is the right way to put at it. Not what does it take to build an app at free charge. It's more about what we did when we built our app, rather than what does it take for someone out here to actually come over and build. And the other, it's not a disclaimer. It's a piece of information following Vijay's talk. I had bought a pack of Estimate Beacons and it ran for a week. So if anyone plans to buy it, just be careful about that. So yeah, heading to our talk. So if anyone's looking for a single take away from this particular talk, then sorry right now to disappoint you, there might not be a single take away. It totally depends on how you understand how this talk goes along and feel free to interrupt, feel free to, I believe there's a Q&A session after this. So feel free to approach and ask any questions on whatever we'll have a chat as. So yeah, I don't know if, how many of you have used free charge by the way? The older app, the blueish skin one, great. I mean, I wasn't expecting that but great. So quite a number of them have used it. Somewhere in August, we took a call on changing the design of our entire app. And our app had seen close to 3.5 million downloads by then. Had a pretty good rating at around 4.3 on the app store. So we still felt, you know, we saw need to change the app. So that's what the first part of the talk would be. And the second part of the talk should be, I mean rather would be more about how we used notifications within our app and how it is benefiting us to perform a few experiments post the design changes. And the third one, I mean, if only time permits, it's more Gyan than anything else. So moving to the first part of it. So as I was saying, right, this app had seen more than 3 million downloads. It had, you know, decent enough rating at around 4.3. We still went ahead and took a decision on changing the design of the app. The reasons, stats don't lie. You can, you know, you can feel happy looking at what exists on the play store. But when you actually dig in and when you look at the stats, these were the things that we were finding a lot of difficulty. I can't quote your number on the drop at the funnel. But our funnel conversion rate was pretty bad. And when you're speaking about an app which dictates a workflow, any other app, I mean, you can pick up any other e-commerce app. It's basically a workflow, right? So when you're picking up an app which dictates a workflow, funnel conversion is of paramount importance. Again, the same thing mentioned again. Conversion rates step on step were in great. And one could always attribute it to the fact that probably the app wasn't performing well. We thought we should give it a shot by changing the design paradigm of the app and look at whether it changes the conversion rate. And third and most important point, the UX principles in itself were kind of broken. So what changed majorly? The onboarding principles. I'll go about this in some time. Decision making ease in the flow. This is actually a very important point which I've seen a lot of apps missing out. So I might concentrate a little longer on this. And the third part would be how we simplified the logic for our users. So this was the first part. If you'd look at both the slides, I mean, we did a closed user group session and focus group session and all of that. I'm an engineer, by the way. So I was a part of it trying to listen out what people had to say. What we realized was the screen on the right side was what existed before. The screen on the left side is what we have right now. What we realized was people took a look at that and, you know, they were absolutely confused. In a sense that as a design paradigm, throwing out email accounts that are linked with a particular mobile is generally not done by anyone. And there is a user training, you know, I mean, for instance, if you are a power Android user, you're trained to sign in into certain apps in a particular manner. We thought by breaking the mold and making things easy. Single click here. Someone just goes ahead and clicks on, you know, the radio button right at the top or someone just clicks on create new account and we take them to a form where they can create a new account. So we thought single clicks work well. People would be interested. Surprisingly, when we looked at our data with respect to the number of installs and the number of people who opened the app to the next screen, again, can't quote a number, wasn't great. So we did a closed user group session and people were like, I mean, they couldn't even comprehend what this is all about. They didn't know what exactly would take someone to actually log into the app. So that was when we moved to the principle on the left where we clearly stuck. Actually, I could probably demo it just a sec. Can I demo it? See, out here, right? We stuck to what everyone knows, I mean, what everyone does when they seek a sign on. We went ahead and we did this. That was about it. That was the only change that we possibly did. We piggybacked on what G plus provides as a sign in option, right? The default pop-up option. And that was about it. We saw a far better conversion, so to say, on our app. Pretty surprising, but that was something which came out as a learning out of this entire exercise. So one thing I could at least hypothesize out of this entire exercise is the fact that don't try to do something cool, assuming users would understand it, since they've been trained on the 60, 70 odd apps that are there on their mobile already, stick to what they know. The other important part that we realized was, so a lot of users who were downloading free charge would download it and then try to figure out what it is all about. On-boarding as a step hence becomes extremely necessary in the case of an app again, which is as utility as free charge is, right? We wanted to just explain users what this app is all about before actually taking them forward through the workflow, which was missing in the previous one. All that we used to do was throw a splash screen and just say fastest recharge experience or something on those lines and people were clueless. So what we added was minor micro interactions, trying to make things look good, trying to explain to people what it's all about. So it's fastest recharge, safest, and your recharges get rewarded, et cetera. But one step which we deliberately, you know, we are kind of still experimenting. So maybe a couple of months down the line, if someone were to ask me a question as to how this worked, my answer could be different. But as of now, what line we took was not to stop people from logging in right at the start. We would do the on-boarding, but we'll do the on-boarding in a certain set of the screen, not throughout the, you know, just kind of cover the entire screen and do the on-boarding. So that was a call which we took. It's serving us well as of now. But then, as again, as I said, maybe a month or two down the line, if you were to ask me the same question, we'll have to figure out whether, in the meantime, I'll just log in. Can I, do we take the question and answer when she gives the 10-minute slot? Because, I mean, if I run out of time, it would be a bigger problem. Yeah, so just reiterating the same thing. Previous screen was pretty confusing for users. The general pattern for Google sign-in is to show it in a pop-up. Users are trained to that. On-boarding to explain the value prop of the app. In order to answer your question, we also instrumented that, surprisingly. But to be honest, people didn't go to the fourth screen. There was hardly an instance where they went. But yeah, they did try it. The first two screens were, you know, pretty much consumed. Last screen, not so. So the takeaway if you want to really look at one is, on-boarding, we found is necessary for apps. Again, coming purely from a stats perspective, we saw people converting better. But at the same time, don't do a wall-garden approach. If people want to log in, allow them to log in right at the start. Don't always force an on-boarding on them. And again, stick to what users know. They know it better than you sort of think. So the next part, once a person logged in, I mean, the entire motive of the app to allow someone to recharge. So this was the form which we used to show before. And we used to call it as a form or a card. And this, even by the looks of it, is too much information to probably consume at a single shot. So that was what we next addressed. I could demo it. Seems to be a problem with my login. But anyways, I'll kind of just explain it. So yeah, what we moved towards this. So at any point in time, we realized that there is only a single thing that a user should do. If you look at this particular screen, there are too many data points which a user had to consume and had to fill in. One had to fill in the mobile number, figure out whether they had to select the operator or whether the operator gets selected on their own. Figure out the amounts. I mean, as soon as the operator gets selected, there was another nice, there used to be a small thingy here which spoke about the plans that a particular recharge number. Too much of data on a single screen, bottom line. So what we did was we split it. We split the entire workflow. Now, this led to more clicks. But again, data doesn't lie, helped a better conversion at this particular point. So the way we kind of separated it out was this is more or less like the first screen where we provided an option for someone to enter a number or just pick up from their contacts. And since L speaks about, you know, and by the way, before, I probably didn't mention it when we started the talk. So this app is more on what we call it as an inspiration looking at L as a design. It's not on material design yet. It's not on material design yet. Anyway, so going back to the, you know, talk. So at that particular point in time, a user had just two things to input. One would be either select a contact from the contact picker or just punch in the number. And once that was done, we added an extra step which was absolutely mandatory for us to ensure that there are no problems with respect to failures. So in this screen, right, I haven't taken the entire screen that's cropped. What used to exist up here was prepaid, postpaid and, you know, these are multiple options. And these were necessary options in the workflow. Somehow, in the very first, you know, first few releases of our app, we went ahead and assumed that people would understand that they're selecting on a prepaid or a postpaid option at any point in time. We were proven wrong, surprisingly. So we moved to this where we made this entire piece as an integral part in the workflow. One had to select it. It led to an extra click. But again, as I said, it led to better consumer satisfaction in the sense that there were lesser failures at the end of the entire workflow. So that's a call which we took. And the other screens, I mean, you can find them out here. Someone could swipe up the plans and check it, so on and so forth. So what was actually broken in the previous app, the way we saw it, was that there were too many data points to consume at one shot and extreme repetitive text. I mean, you're suggesting mobile, you're suggesting recharge, you're suggesting recharge mobile again. So there was excessively repetitive text for someone to read through. It is good if you want to, you know, kind of stuff in a few keywords into your app so that at the end of the day, you get discovered on the Play Store. But this is not the way to do it. So we came out of it. We moved to this. You know, the takeaway, if one again, is the fact that you stick to the philosophy of click and proceed. Don't try, don't force the user to input multiple data points at one shot. Allow them to focus on doing just one job at a time. And again, don't expect users to read too much if you're building an app for short session length, which is what we intend to do. I mean, our interest is not to have a user for more than a minute or a minute and a half for an app, as opposed to probably a Flipkart or an Amazon where you want them to discover more stuff. There's nothing to discover in free charge. Just go ahead, recharge and, you know, look at your next recharge. So that's another, so if you're building an app for short session length, my personal opinion on it is that visualization becomes everything, not text. Then the third part in this particular change that we did a lot of changes in the best interest of time, I would probably just deal with a few out here. So another change that we went about doing is the offer experiences or the coupons which we give us freebies to our users. Used to be this before and it is this now. It probably is a no-brainer. I mean, I can put this question. How many of you like this actually? I can hardly see any answer. And about this, is anyone even listening? Yeah, great. Thank you. So yeah, so it's fairly straightforward, right? I mean, in the sense that there was extreme confusion again on what this does. You're speaking about giving freebies to users. At the same time, you're throwing a gamut of information out here. There's a category picker and so on and so forth. Again, boils down to the point that I was speaking about a while ago. This didn't work. We measure this by the number of coupons users pick up on a daily basis. And this is a definitive measure. We see that this thing improved by almost 6 to 7% base points overnight as soon as we released. So we're seeing more users picking up coupons, which is a good thing for us. That's the freebie which we are providing, right? So what exactly kind of changed here? One of the most important calls we took is change in the logic. Out here, we were allowing users to pick up multiple coupons of the same type. I mean, someone had to pick up a MACD coupon. We said you can go ahead and pick up four. Out here, just stop that. We said, you want a coupon? Just pick one. Move on. There are better selection. You can look up and try something else on and so forth. That surprisingly improved things for us, again. As I said, coupon often behavior improved. So take away, if any, out of this entire exercise for me was the fact that keeping aside your business priorities, look at what the user wants. The user just wanted to pick up a coupon and move on. Recharge is the more important thing for which they came into this app. A coupon should and always be just an add-on and not, you know, kind of taking the entire domain. And the other thing was here, right? The entire pickup experience was broken in sense that this people understood that it is, you know, something which people had to click on to pick a coupon. But once this was done, we threw a nice green layer. I don't have a snapshot of it right now. You have a mobile which has less than 4.0 version because we don't support the new app on less than 4.0. So if you have one of those devices, please pick it up and download it from Play Store. You'll get this one, this blue monster. So yeah, out there, what we did was we put a plus sign and a minus sign and we put something in green stating you actually are picking up these many coupons. All the CTS are colored the same. There is no distinction between CTS. Similarly, people were clicking on a thing which wasn't even a CTA and things were absolutely broken. So changed it. This was, you know, what we went ahead with. And a takeaway, if any, again, from this exercise is that simplify logic for your users, again, trying to explain them that they can pick up four coupons of the same type and move on and so on and so forth. Doesn't work from a business perspective. Yes, didn't. So simplify how to make a business flow simple yet engaging for users. And these are all cliched statements between us, but then it's good to put it forward. And graphical representation visualization always helps. I mean, just look at this. If you wanted to eat a burger, you wouldn't pick something from here. You'd probably pick it up from here. That's the visual element that you need to create. You would probably need to have some very good visual guys on board, Photoshop guys, et cetera, and we could manage. So main takeaways, there are, I mean, again, in the interest of time, many other things that we changed in the entire workflow. After this, we take our users to the payment gateway. Tons of things, again, that we changed there. But in the best interest of time, I'll kind of, you know, cut it out here, move on to the next topic. If there's anything that you would like to know about the rest of the flow, we can catch up. The next part, so we shipped it. I mean, we built all of this stuff. We shipped it. We shipped it. And we realized, you know, we were still sticking to the old notifications framework per se. By notifications framework, all that. I am a strong believer of not using a third party tool just to push in notifications. There's no disregard. There could be people here who are actually basing their businesses on that. But we went ahead and we built our own notifications framework. Understanding GCM as, it's not that tough. So we went ahead and built our own notification. And we started realizing that it was immensely powerful from what plain vanilla stuff that a lot of people do. We went on, we improvised and we realized that it's pretty powerful. So again, if there is a quandary on whether you have to use an SDK with someone provides or whether you can build it in-house. My personal take is it depends on the use case and your time. I had time and I wasn't working on the main app. So I thought why not I code for it. And if you want to build extremely flexible use cases for obvious reasons, you would have to build it on your own. You can't probably piggyback on an SDK. So this is generally the plain vanilla experience of a notification, right? It just comes into it and there's a notification. Someone says, 100 rupees, 100 talk time, refer your friends and talk time. And you click on it, probably takes to an app, any app for that matter. Goes to the app and you get to know what exactly that notification was all about. We went a step further. We built this kind of a notification which we could send in a dynamic manner. In the sense that from the server side, I can configure, I can determine what kind of a manifestation of a notification that a user should have, went ahead and built this. And this is a classic example of creating a consumer behavior confusion, so to say. For instance, out here, we were forcing the users to kind of see, kind of ask them whether they love free charge. And if they do, give us five stars, help us succeed and put a tick mark on the go to play store, kind of putting it in their mind that, you know, you love us, you want to rate us, go there by clicking on the tick mark. It was creating a consumer behavior. We saw this give us a good spike in our ratings, which I feel is valid. I mean, we're not incentivizing a user, had a good experience. So all those users who had a good experience, who transacted well, got this notification. And we saw a pretty good conversion. And we, again, track this entire funnel. So how many of them received notification? How many of them actually clicked on it? Which action they took after that so on and so forth. And we saw a good spike in our ratings. So this is something which we built very flexibly, went ahead. We realized that this might not be enough. Let's attempt to do some AB testing now. So what we did was this. The way we built the framework, you guys have an idea about GCM by any chance? You do have. Great. So what exactly happens is you're bundling everything into an intent and passing it to the app, right? And you're allowing the app to take a decision on how the eventual manifestation should happen. So when you're bundling, what we did was we just bundled a JSON with multiple parameters in it. And we pre-coded our app in order to look at those parameters and take a call. In one of these instances, the pre-coding was, let's say, one of the parameters said, whatever you get as the HTML, just embed it into a web view within your app. These were the two parameters that we added. Call it action. The action is show this notification in a web view. And the content is an HTML in itself. So what we did with that was we created multiple different formats of HTML with different behaviors. I wrote different JavaScripts and different HTML's, blah, blah, blah. Picked up a set of close to 50,000, 60,000 users, split them, and send them different kind of notifications in this scenario. And we started observing how they behave. So if we sent this, how many of them actually went ahead and clicked on the bottom? If we sent something else, what was the conversion, so on and so forth. So using notifications, we actually ended up building an AB testing framework right now. And for our further releases, we could as well go ahead and, you know, take a call on what kind of screens people would love to see by doing a test beforehand. So that's one of the flexible elements that we have done. Again, something which you might want to look at if you want to go ahead with this kind of thing. And finally, once we were done with all of those, we realized, I mean, why not do in-app messaging now? There is this cool thing, right? People say there's an out-of-the-app notification and in-app notification. End of the day, it's about how you make things manifest. So we went one step ahead and we did this. All that we are doing here is we send a GCN notification to a user, but we don't build the notification in all these scenarios. Instead, we pick up all the important parameters that we send an address on. Again, as I said, we've pre-coded a few stuff. We pick those up. We created a separate activity just for notifications so that it doesn't destroy the navigation of a user. And you're within a flow and all of a sudden you get an in-app message, right? Someone clicks on the back button. The entire flow till that point should not be destroyed. So we went ahead and built this small thing. Yeah, end of the day. The takeaway out of this second exercise that we did as a part of our new app is the fact that you can go ahead and do all of this stuff, build a GCN notification framework on your own. You can build them pretty well and you can do all your experimentation on it. At least that is what we are doing. Alternatively, you can choose an external tool. We needed immense flexibility in this sense. None of the external tools were actually providing us this flexibility. So we went ahead and we built it. And that's as far as the talk is concerned. I mean, if you really want to see how did we actually get discovered on the play store, it's a no-brainer. You have lots of money. You can push an affiliate traffic and people will download and you'll get rated higher. That's one of the things. One, a couple of things that you might want to pay heed to is ASO actually works. I mean, there is no way to put a metric to it for anyone, but from my observation, from what we did at free charge, we played around with the description, the title of the app, keywords. We went ahead and even stuffed a few keywords in the app because from what I understand when you push an app to the play store, before it actually is visible to the user, I'm assuming Google kind of decompiles it, looks at it, figures out whether it works well, so on and so forth. So if that's the case, why not leave a few keywords there? They'll pick it up. Things will work well. So one could call it as a black hat technique, but certainly not. It's a no-brainer. It depends on where you're putting the keywords. If you're doing a lot of stuffing, I really don't know. I mean, your app can get unpublished. Don't get back to me. But yeah, this is something which you can try. Other thing which we did was, so we were using an SDK which was doing the installs for stacking for us. And when you're doing all this marketing, right, a lot of people do Facebook downloads, downloads from GDN, downloads from different ad networks. You need to assign a value to that entire lifetime of the user or how they're performing on your app. So we began with using an SDK and we realized, you know, maybe it doesn't help. We built a custom install receiver. We are still pushing data to the SDK, but we built a custom install receiver. We are picking up the data on our own. We are doing our own data mining to figure out what kind of users are beneficial for us. So that's something which you need to invest in so that you can then, I mean, once you identify a user, you can market better to that user. You need to market to those users who are not, let's say, beneficial for you. Important part, if you're building a workflow transactional app, so we'll take this on you. App deep linking, as I said, leave in some nice keywords. App deep linking is absolutely necessary. We are doing that. Unfortunately, our app has a single activity, totally fragment-based. And if you wanted to put in the manifest and say, you know, I want to redirect people to multiple activities, it's not possible. That said, you can always, you know, in your own handle, you can figure out what to do and redirect people to the corresponding fragments. So this is something we have done. These things are benefiting us. Most importantly, this, you need to have money if you really want to get rated higher on the Play Store. But then the other things have also benefited. We have a metric to it. We've observed it and have benefited us pretty much. So that's about it. If you have any questions, I believe I finished on time. Not sure. Yeah. So for recharge, your top hierarchy is mobile, right? Yeah. So why, what made you switch from tab view pager to navigation for like data, data recharges and all? As I said, right? We wanted our user to perform just one action at a particular point. Now, isn't it like, let me kind of, you know, explain that. So again, you will have to depend on data for this. Our data suggested that 95% of our users are coming for a prepaid recharge. So it wasn't making any sense for us throwing in a lot of data points right at the start, asking someone to go ahead for a different recharge. That said, when someone installs the app, what we do is for the first two or three times, we open the side menu by default. The hamburger just closed. We open the side menu by default, leave it there for a good five, six seconds, so that people actually identify that these options are now lying there. It's a part of training the user. Kind of coach mark, so to say. But most of the people, I don't think they open navigation draw, because your screen is full of like, it's full. Exactly. Exactly. Which is why we train their users. We train them to realize that this can happen. In fact, we are, we are looking at another approach. So the entire screen that we are showing for the prepaid recharge, right? When someone does a horizontal swipe, we show the next possible option, which could be postpaid mobile. Planning to do that, but again, discoverability is an issue. I agree with that. That said, this call was primarily based on the data we saw. When you have 95% of our users actually opting for just one kind of recharge, I mean, one kind of operation, why not? And why MACDs, coupons are five rupees now? Unfortunately, as I said, I'm an engineer in the garb of a product guy here. I'll probably give you his number. You can speak to him. Hello. I mean, if you're getting a 50-buck thing for free, would you complain about five bucks? Hi. Yeah. Yeah, it was a nice session. And I would like to know how you are, say, I'm opting for a MACD coupon, and how you are in sync with the MACD and your app. I'm sorry. You'll be giving a coupon code to your user, right? Yeah. And how is that in sync with MACD? Well, actually, it's nothing to do with the talk, but yeah, I'll answer it. Yeah, it's a different one. What we do is, I mean, we get a pre-held inventory from our merchants. Okay. Just pick up a coupon code and give it to the user and say, use it when you are in an offline retail store. You walk up, just show the coupon, and you can use it. Oh, is it? Thank you. That's all right. Yeah. Hi. Okay. A simple question. How many people are working on the new version? How many people are working on the new version? Two and a half, if you include half of them. Okay. That was what it was. It took us around a month and a half. Could you highlight some of the technical challenges you faced? Technical challenges we faced. Lots of crashes on devices less than 4.2. The kind of animations we were doing, right? So we picked up a couple of SDKs. You know about nine-old androids. I believe Roman, you're kind of focused, right? We used that. And fortunately, we tested this time when we were releasing it. So when we tested, we realized that the crashes on devices less than 4.2 were immense, even for, you know, minor animations. I don't know if you've used that app. I suggest you do. So the micro interactions that I was showing you, right? A rocket popping up into the thingy. You will use an interpolator if I'm not wrong. That was crashing. So that was one of the biggest challenges that we faced. We built an app, assuming it would work seamlessly everywhere. It took us a couple of weeks of delay to realize that this doesn't work well on devices less than 4.2. We went ahead fixing it, and we realized that fixing it was an even more bigger pain. So we took a call. We are not going to support this app on devices less than 4.2. Again, giving a bad experience to a user doesn't make any sense. So we went ahead and took a call that we shouldn't support. Just to follow on, I think you earlier mentioned that you have only one activity in multiple fragments throughout the app. Could you explain that a little bit? Even when you create an app right now, right? I mean by default, what you get is an activity and a fragment, right? So what we have done is we have just one activity in the entire app. The app is a workflow kind of an app, right? So every workflow, let's say the recharge as a form. That's one part of the workflow. It's a fragment. The payment gateway. It's a fragment, coupons or offers, the way you call it. It's a fragment in itself. And all of them are flowing around only on one activity. Now if you were to ask me the reason as to why we did it, we really didn't want to sit around transferring intents from one activity to another. We found it to be really quick building things this way. So that was the only reason. And I believe more and more people are now being told to do something. How different can the activities in your app be? They'll all look the same, right, eventually. So certain things. I mean the top bar or the CTA right at the bottom. Fix it on the activity. Everything else, take it on the fragment. That's what we did. And there's no logical reason for it. We just developed quicker doing that. Look and feel of payment gateway as in once you go to the PG, right? Absolutely not in your control. A big mess currently. In fact, I don't know. It could help a few people here probably. Half of the net banking options probably don't even work on the default toolkit that Android provides. They themselves scream. I mean, Syndicate Bank or something, it'll be written down there. Works on IE 5.2 and above. I don't know who even has IE right now. So those things won't work. Yeah, ATL 1. It's a no-brainer again. As I said, you have money. You go by whichever way. You push and affiliate traffic or you do advertisements. Not debating that at all. But that wouldn't improve your funnel rate. Your funnel still needs to improve. For that, you need to do something else. So, yeah. That's the answer. Hi. Are you tracking the mobile usage versus your web usage? Oh, yes, we are. What tools are you using for that? Are you using just the Google Analytics or are you using any custom? Oh, you entered that. We have our in-house stuff for that again. So, yeah. We went ahead and tried Local Analytics a few eons ago, probably even tried Mixpanel. End of the day, we realized nothing works as good as your thing. See, I mean, simple thing, man. You've kind of rolled this org out four years ago. You really want to figure out who your existing users and your new users are. Today, you decide to put in an SDK and track it, right? The SDK won't tell you who your new users are. It's probably your database which will tell it. So, it makes a lot of sense for us to stay in-house, rather than actually use an extra SDK. Okay, one more question was that on the GCM, you said that you had to build your own notification part. No, I'm not saying you should. So, you're still using the GCM for pushing it. It's just that the selection of what needs to be pushed to whom users. That is what you've built. Exactly. So, the segmentation, how to target them, how should it manifest on the user screen. All of that is something which we have done. And we're piggybacking on what GCM kind of provides. Yeah. How often do you find users updating their app? So, let's say you found something gravely long with your app and you're pushing an update. How confident can you be about them updating the new app? So, for example, you said you're pre-coding some criteria for handling the notifications, right? So, let's say tomorrow you want one more use case where you want to have your app handle a new kind of notification. When you're pushing it, how confident can you be about users updating it? Because many of people don't update it. So, the entire framework which we have built until now is backward compatible. I mean, it's a JSON, right? You add a couple more parameters. If an app doesn't pick up, it doesn't pick up. So, there is always a default behavior to a notification. Everything else that we are adding on it, we ensure that it is backward compatible. So, that said, if you want to urge your users to upgrade the app, you could do a block. I mean, someone opens the app, you check out the version and you figure out, oh, he's on an older version. Throw a block and say, upgrade it. We really don't see a need for it. So, we don't do that. That depends, right? I mean, we do a stage rule a lot. So, there is no way for you to definitively state when people moved on. These things can be looked on month on month. Month on month, we see almost 60% of our users moving. 60, 65% users moving. Any plans of releasing your analytics framework and your notifications thing open source? Absolutely none because it's extremely flexible for our use case. See, again, as I said, it's use case to use case. You would know your use cases better than I do. We built something which serves our purpose. But that said, again, as I said, it's a no-brainer. It can be built. So, it's not as if it's really. I can probably explain if you don't know. I'm sorry. For our app testing, are you using any automation tools? For our app testing, none. To be honest, none. To be honest, none. We did try. Things didn't work well. So, currently none. But that doesn't mean that we wouldn't do it. Okay. Thank you. So, while deciding upon making it a fragment-based application, did you consider using other view controller libraries like Mortar? None. I'm asking this because I saw a lot of problems in fragments. What kind of problems have you seen? Life cycle of fragments. So, it totally depends on how you're handling it, right? You should allow a fragment to bind to the manager before you actually kind of... And it's about error handling. You would be better at error handling if you know what the problem is. So, check in Crashlytics. You'll know where the crashes are happening. We'll keep on fixing them if it's because of fragments crashing, let's say. So, maybe alternative to fragments you might look into Mortar. That's our library from Square. No, I know it. I mean, in fact, for our next release, we are looking at the possibility of using Picasso and Ok, HTTP for our coupon rendering, per se. So, we are trying things. That said, we found comfort in what we did. This is another thing, I mean, which I regularly see. People use a lot of stuff. But if things are working the way you expect them to work by yourself coding it, why would you want to use something else? That's the question. I wouldn't know. Someone else might. Okay, maybe. Thank you. Hello. Yeah. I've noticed that you've used a lot of graphical elements in your app. Despite that, you managed to keep the APK size to less than 3 MB. So, do you have any tips on that? Yes, and... You load it, actually. You load it when someone opens the app, if you really want to do it. So, like, network loading once? Network loading. You'll do the 9-patch anyways, right? Yeah. And 9-patch, you need to ensure that it is pretty compressed. See, as I told you, right, the reason probably our app is very light in weight is because we don't use any SDK, external SDK. The only thing that you have in it is app compact, which you can't call as an external SDK. And there's nothing else in it. So, we've kept it light with that in mind. And we will continue to do so, because people are on 2G. They want a mobile recharge. They won't be able to download a 10 MB app. It has to be 2.5 MB.