2016 in review: My second year as a full-time indie app developer
For me, 2016 definitely started on a high. During December 2015, the sales and ad revenues had set new records for my business, driven by massive downloads across the portfolio. In that one month I had 2.6 million downloads, with 140K on Christmas day alone.
A year later, as 2017 kicks off I look back and feel frustrated that I’ve not really achieved the growth I expected. Downloads in December 2016 were ‘only’ 1.7M, and revenue was down as well. In order for me to understand why (and hopefully do better in 2017) I’m writing this retrospective.
(Edit: The followup to this post, called “Charting a course for 2017”, is now published)
Moving around
Move #1. In January I moved my workplace out of the bedroom and into my own office space. It was great to have a dedicated place to work, outside of the home, and I spent a fair bit of time on the actual move and kitting out the office with storage, furniture and a beer fridge.
Move #2. In March we decided to relocate 500km to the southwest of Sweden. We tried finding a house to buy in the new town, but didn’t manage to buy one in time, so we rented an apartment and moved there in July. My workspace was once again at home.
Move #3. Shortly after moving in to the apartment, I found an office to rent. I moved my workspace out of the apartment.
Move #4. In September, we bought a house and moved in.
For each move, since I am self-employed I would spend several working days (at least) packing/unpacking instead of growing my business. In retrospect, I spent way too many days like this.
Note to self: Using work time to do personal stuff makes life easier, but in the long run it will come back and bite me due to lost productivity.
Tools and technology
When I was actually working, I spent a great deal of time on building my own tools. Sales and ad revenue were high, so it felt like a good time to improve workflows rather than build new apps. The main tool I built (on top of the awesome Fastlane) was my metadata manager, where I can handle all my localizations and uploads. I use it for all my uploads these days, but do not (yet) actively and regularly use it to optimize my metadata.
I also blew a disturbingly large amount of money on Tableau, a data visualization tool which I feed with downloads and revenue data pulled from App Annie’s API. Alas, I don’t spend nearly enough time using Tableau to warrant the price.
Note to self: Building and buying tools can certainly make life easier, but only if I set aside the time to use them fully. If not, save the time and cash and do some ‘real’ work.
Conferences
During the first half of 2016, while not moving or building technology, I also attended two single-day conferences. The first was TheKidsWantMobile in Berlin. The talks were good, mostly, and I left with a handful of concrete ideas, insights and thoughts. I met a handful of interesting people too, and some vendors including Kidoz, an ad-network (more on them later). The total cost was around 650 Euro (expensive conference ticket) and three business days (comfortable travel arrangements).
The second conference was Google’s free London event for their Family category partners. The event was well-organized, the talks were good, and the venue awesome. The main difference this time was that I was a speaker, on the topic of how to optimize Android apps for organic growth. It became very obvious that as a speaker you have a much greater networking opportunity compared with a regular attendee. I met some of the people from Berlin, re-enforcing the relationship, as well as some who I had previously only talked to online. The total cost was around 500 Euro and five business days (including preparing the talk). I walked away with a Pixel tablet and a Chromecast as thank-you gifts for being a speaker.
Note to self: As a speaker, I save money on conference fees and improve my networking possibilities, but the price to pay is that I need to spend time preparing my talk — and worrying about delivering it.
In terms of app-related efforts, I mainly worked on my existing portfolio with new monetization and experimental features.
New monetization
At the Berlin conference mentioned above I met representatives from Kidoz, an ad-network with COPPA-compliant ads. After a bit of persuasion on their side, I decided to try them out in some of my Google apps. I particularly like their ‘panel’ ad-unit, which is an always-on-screen popup that you can expand at will. It fits particularly well with the level selection screen that I have in many of my apps, and isn’t overly intrusive. It starts up as a closed tab and users can ignore it if they will, as opposed to sudden interstitials popping up. If the press the tab, it pops up to fill 25% of the screen.
Before implementing the panel ad, I had a freemium model. The majority of the content was locked, but the user could try a few free puzzles and unlock the rest with an IAP if they liked what they saw. Now, with the panel ad, I essentially switch monetization model from IAP to ad-supported. All content is now unlocked, and the only purpose of the IAP is to remove the ads the user finds them inconvenient.
At first I was worried about cannibalization, that the new ad revenue would not compensate for the IAP revenue drop. I’ve only just now done an analysis of the performance of switching models, and the results look promising. Without being overly scientific, comparing the same period in 2016 and 2015 it seems that the a) revenue per download is about double when using Kidoz + IAP to remove ads and b) ratings are better too.
Since December ECPMs are usually very high, I did a quick sanity check using the Dino Scratch October numbers and the results were about the same. Of course, your mileage may vary.
In addition to replacing my freemium model with Kidoz panel ads, I’ve also deployed them as a secondary ad network in my already ad-supported games. There, they increase the revenue at no risk of cannibalizing an IAP.
Note to self: Ads, when done ‘properly’, can be a win-win scenario — users seem happier and I make more money.
Experimental stuff: Downloadable content
When working on features for my puzzle games started thinking about how I could keep users engaged for longer. I had a look at other puzzle games, and saw how they offer downloadable puzzle-packs for sale. Since I have a dozen or so different photo puzzles, could I not do something similar? So, if a user downloads my insect puzzles, they could then within that app download the cat bundle, play some more puzzles, then the horse bundle, and so on.
The motivation for this was was that the user generate more revenue by a) being exposed to more ad impressions while playing and b) watching a rewarded video for every bundle they wanted to download.
In the image below, the center image starts the game you actually downloaded, while the surrounding thumbnails lets you download new themed puzzle bundles.
For the rewarded video, I currently use Supersonic. Due to restrictions in the Supersonic plugin for the framework I use (Corona SDK), I can’t use mediation. To host the bundles of images for download, I use Amazon Web Services (AWS), with Cloudfront caching for accelerated content delivery.
On average, in December users were downloading around 22K bundles / 90 GB daily, for a grand total of 2.8 terabytes of data that month. The cost of delivering that data was $235, but unfortunately the revenue from the rewarded video was only $150.
I still find the idea promising, and will try switching the ad network used for rewarded video. I could also disable Cloudfront caching, and have the files download slower to the users, at reduced cost to me. However, ultimately it could be that users simply do not wish to engage with the video at that point, since their actual intent at that time is to play a puzzle.
Note to self: I could probably have spent much less time building a proof of concept that showed the same results, rather than doing a full roll-out. But then again, the jury is still out on this one.
Experimental stuff: In-house A/B testing
I’ve written before about how changing an app icon drove downloads through the roof. That time, I just went by gut instinct. However, doing icon A/B testing for a live app in Google Play is easy. You set up your variants, and you see which variant drives more installs. But a) the majority of the users who visit the page won’t install the app, b) you need to have a reasonable number of daily downloads for the app, which means that if the app is brand new or simply not that popular, you have to wait a long time to collect enough samples and c) if the app is not yet released you can’t use Google Play A/B testing at all.
Now, I have a custom cross-promotion system in all my apps, a page where I show all the apps that the user has not already installed. The configuration, and any required image assets, are downloaded automatically.
What if I did the A/B testing myself, in that page? It has around 200K impressions daily, and drives a lot of traffic, in particular to apps with poor organic discovery. I could A/B test click-through on that page rather setting up A/B tests in Google Play, and hopefully get results very quickly.
I’ve recently partially rolled out support for this feature and can setup experiments dynamically. But haven’t yet figured out how to statistically analyze the data that I get back (number of clicks on each variant). A bit ass-backwards, I suppose.
Note to self: Maybe I should spend less time working on ‘cool’ technology and more time making new and improved apps, which actually drives revenue?
That’s all, folks. With the retrospective in place, time to use the notes to self, look ahead and plan for a kick-ass 2017. Stay tuned for the plan in the next week or so :)
