Tuesday, December 31, 2013

Interview: Understanding Vserv's AppWrapper.org SDK integration tool

Vserv.mobi recently announced the launch of AppWrapper.org, a platform for Android developers that aims to automate the integration of multiple software development kits (SDKs). The tool is designed to integrate services such as ad monetization, analytics, bug tracking and in-app purchases, allowing app developers to shorten their development time. We caught up with Binay Tiwari, Director, Global Marketing and Product, Vserv.mobi to understand the model and their plans for the platform.


Tell us a bit about AppWrapper, and specifically how independent mobile app developers can take advantage of it?
Vserv is a mobile advertising exchange and which means that we have worked with developers and publishers to partner with them on their apps and sites. As users come and use these apps and sites there’s an opportunity to show them ads and the developer has a chance to earn from those ads. That’s exactly what Vserv has enabled – monetization of apps and sites using advertising – and on the other side we have partnered with advertisers who want to reach these consumers. 
 
That’s what Vserv.mobi is about right?
Yes, that’s what Vserv.mobi is about. Now placing these ads on apps requires an SDK’s, right? Developers need to take the SDK from that ad network and integrate that into their app and that’s how ads start showing up. The developer has the opportunity to show ads to the user in real-time, which are targeted and shown based on the device, country and where users are coming from. And, when Vserv had started off we had said that this whole SDK integration process is quite tricky and it could be challenging to some developers especially independent developers who don’t generally have all the time in the world, because they focus more on creating their own app and the functionality of that app versus dealing with integration of SDK.
 
So AppWrapper started off as a way for Vserv’s advertising SDK to get enabled or the app in one click without any coding by the developer himself. So a developer would be able to choose an app, run our tool from AppWrapper and get another version of the app that now had ads enabled on it at the launch and exit of the application. So when somebody’s starting the app you see an ad and at the exit you see an ad. So think of it as a magazine cover ad and back page – that kind of an ad format.
 
So we created that quality, that underlying technology of being able to take our SDK and enable it onto an app in one click without any coding and that was the core technology that we’ve build.
 
And now you integrated other SDK’s as well which is bug tracking etc.
Correct! Somewhere in the middle we started more than just a SDK but also integrated business logic. So if somebody wants to do a try and buy version of the app. So instead of the developer struggling to add all of that business logic, we did it for them. For instance after ‘x’ number of sessions I should stop the user and ask him to pay so much amount or I should, how do I track those sessions, also I could do the subscription billing on an app, what is the billing logic etc. how do I implemented that? That had become a second evolution of AppWrapper where we had taken the SDK plus the business logic that would get into the app. And, both of these were effective for services that were earning money through us, or we were earning money through try-and-buy transactions implemented through Telcos.
 
Soon we said that this an amazing technology; why not extend it to entire ecosystem and to all our partners across the ecosystem. And that’s why we now enable multiple SDK’s across various categories using the AppWrapper and we said that you want to create this and send it as a separate independent platform that allows the developer to automatically integrate SDKs of various services and what those services. Bug-tracking was one of the first services that we put out. Monetization such as our ads, or Google Play in-app purchases is another one, being able to request the user to rate their app in the third service through another partner as well, which we called ‘user engagement’. And now we continue to look what are the other services that developers need and have to integrate and we will try get them on to the AppWrapper platform and get them enabled by the app wrapper. Within these categories too, we’re going to continue to find other providers of services and bring those on board as well. So the developer has more and more choice. Already they had the biggest names in the space – in Analytics we have Google Analytics, Flurry and Apsalar, for bug-tracking we have Bugsense and Crittercism etc. 
 
So how simple is it really? Can a developer who is just starting off use if effectively?
Absolutely! The whole objective is to sort of make it a zero coding approach, so the developer doesn’t have to go back to his code at all – that was the premise with which we started. Obviously when you do that there are some things that you’ll be able to do and some things you will not be able to do. So given that, we don’t want to change any functionality of the app, we don’t want to break the compatibility of the app with various versions of the operating system, and also want to sort of limit the amount of size that increases of the app itself. Those are all the considerations that we have taken into the picture and as we enable these newer forms of SDKs, we’re constantly looking at making sure that what the developer is required to do on this interface is no more than just putting his user ID or choosing some settings such as checkboxes or radio buttons. The entire process is zero coding, if you look at the steps it is as simple as choosing an APK file, choosing the services that you want which is just an on-off button and if any of those services require you to look into additional settings, those will pop up for. For example, if we choose Google Analytics, then it will require you to put in your analytics ID. After this you just hit the “wrap” button. It’s almost as simple as using winzip. 
 
When choosing which SDKs to include is Vserv advertising SDK is mandatory or can that be skipped? For example if a developer just wants analytics can that be done?
Absolutely! It is not mandatory at all that somebody uses Vserv’s advertising SDKs or any of Vserv’s SDK and all. He can go and choose any of the services that are available. There are of course some rules for example if you end up choosing one analytics SDK that conflicts with another, then you’ll have to take that out and have to choose one or the other, but there is nothing from a business policy standpoint that says Vserv needs to be included. There are no limitations on that front whatsoever. And also just coming to the simplicities that might use this. Think of it as simple as using Winzip. 
 

A corollary to the previous question to the previous questions – if the advertising SDK is not mandatory, then what’s in it for Vserv?
Great question! Essentially our whole approach with AppWrapper in this new, shape and form is to put this out as an independent global platform, where a developer can come use it freely. That’s also why we choose the .org domain. The vision that we have for this tool is to eventually become a marketplace of sorts, where on one side you have the developers who are going to come and try using this platform because it simplified the whole integration process for them as well as helped them find some new services that they might not have already known about; on the other side you have the service providers who are creating these developer services, tools and so on and giving out the SDK’s to developers. When we integrate those into the AppWrapper they get two things again, one is discoverability because lot of them are new and niche so as they come this platform developers will be able to discover them, and the second is super simplified their onboarding process, right? So instead of telling the developer, ok, you’ve used my SDK and my SDK documentation and this is how you should test it and this becomes a one click approach for them to onboard a developer without even necessarily coming to the website. That’s something you know again we are pushing forward. Right now some places the developer has to also go to the provider site to register and so on. Over a period of time, we want to simplify even that process where instead of going to that website all of that would happen with the AppWrapper itself, based on the partnership sites we develop.
 
So what are your licensing norms? Take for example flurry, is there any revenue sharing right now or that’s something that you plan for future and not right now?
The core revenue that we’re looking to get out of this is when somebody uses our SDK for advertising. Essentially we’re are just one of the services on this platform and that’s how we are looking at this. We believe that there will be more developers who will use this platform when there are so many different functionalities that you can do versus just our functionality, just our ads right? 
 
Our standpoint of investing in this is like a premium model so to speak, where if devs use our SDK we earn some money at the same time we’re happy to push forward the mobile ecosystem. One of the reasons to start of Vserv itself was to look at the ways in which we can solve challenges for a developer, solve challenges for advertisers, and therefore help push this mobile ecosystem forward. We’ve already taken a ‘developers first’ approach, so we believe that a lot of developers today are new to this space and lot of them are independent and don’t have large teams. The mobile ecosystem offers them to become app entrepreneur, as we call it, and while becoming app entrepreneurs we are here to help them grow.
 
So it’s almost like seeding?
Correct!
 
But when you say “marketplace” – the marketplace tag that you are giving it – that would involve some kind of a monetary arrangement with the SDK providers right?
As of now we’re not looking at it from that perspective. It might involve co-marketing or them telling their developers that you can go and use this platform as well. So think of it as a website company is asking your for payment and you might have a form that is saying fill in your credit card name, address etc. and just next to it you might have a button that says “pay with paypal” right? So essentially we’re saying that this might become like “integrate with AppWrapper” and on the site you have the full SDK integration document. So those are the types of approaches or partnerships that we’re looking at. From the monetary standpoint right now we are focused on earning revenue from just on our own services and not necessarily from partners.
 
How does Vserv collaborate with app developers?
In our traditional ad network or ad exchange business, we partner with the app developer, help them understand the opportunity to earn through this monetization model and advertising as a monetization model helps them to get into it significantly. So we work with developers to show the potential and then deliver that advertising revenue to them, and also help them continue to grow by talking about their success, highlighting the success stories of our developer partners from around the world. We also partner with things that help build the ecosystem, so one of the thing that we did was partner with IMEI for the apps fest - a hackathon where we give away cash prizes for developers.
 
The IMEI initiative was one such initiative. We have done it with the Nokia Student Developers program as well. We have been partnered with them by which we go to educational institutes and talk about how developers you can earn money from a global audience. 
 
Another offer that we are running successfully is what we call our developers dollars program. We attend a lot of industry events. I think last year we attended 75 globally – that’s more than one and half a week. At these conferences and meetups we connect with developers in whom we see potential. Somebody who is looking at making a great app, or has made a great app and is struggling at monetization, we actually give out what we call “developer dollars” to them. Where on a regular dollar you have the serial number our developer dollars have a code. When somebody uses that code he gets the extra hundred dollars on his account when he starts earning with us. It’s just a small sweetener or a push for them to start or get started on this journey of not just making apps for the fun sake but also making this into a potential business and therefore becoming an app entrepreneur going forward. One of the other initiatives is ‘Developer of the week’ which we’ve been running for over a year now. So there are I think 60-70 of them on it now. Basically every week we talk about a developer on this blog – how he started his journey of developing apps, what was that passion that drove him to do that and how they were able to monetize this into a business. The very first developer story was this guy Venkat from a small town called ‘Trichi’. He talked about how he had just started making apps as part of the Nokia Developers program, and the very first app he made was during the ‘Anna Hazare‘ movement. He felt that people on the streets didn’t have a way to communicate each other and find each other and talk to each other, so he created an app called ‘Lokpal Messenger’. This enabled people who were as a part of this movement to communicate with each other. We started working together with him and he created couple of other apps, start monetizing with us. I think he was working with us about three months before he was finishing his engineering college and, as he was exiting his engineering he got an offer from one of the top three IT services firms in India, but the offer letter that he had, versus the revenue that he was making with us, the multiple was fifteen times. So in essence he was earning fifteen times more than the best job offer that he got through his engineering college. 
 
What advice would you have for budding app developers in the country?
My advice is very, very simple – people who can code today (the new literacy as they call it)  have a really tremendous opportunity to become app entrepreneurs, to become folks who create products that millions of people across the world will use. If you look at other entrepreneurship versus app entrepreneurship, then there are three things that really differentiate it. First is very simple that the amount of capital that you require to start off on your app entrepreneurship journey apart from knowing how to code is essentially a laptop, right? That’s pretty much the modern capital that you require, which is already there. The second thing is that the time it takes to create an app versus another software on the PC, web or some other kind of technology, has sort of become simpler and faster. So lower capital and faster time to market. And then once you have the product ready, the opportunity to do a distribution of that globally and not just in the locality that in you are based in or city or India, but globally. The last is obviously partners who let you earn such as ours which is made for advertising. Nothing’s more exciting than having millions of people use your product, right? So, that’s an amazing opportunity that a developer has in India as well as globally. My is don’t go miss this amazing opportunity.
 
What kind of apps should budding app developers think about building? 
You know going by that approach will only lead you so far. I think what a developer needs to do is what is he passionate about. Build an app that either solves the problem that he is kind of seeing in the world and wants to solve, or do something that gives him joy or make it seem fun for him. Build your app journey with something that you are passionate about, whether it is about solving a problem or something that gives you joy and entertainment, but stay true to what you are bringing uniquely into the system.
 

No comments:

Post a Comment