If you want your iPhone app (or any other product for that matter) to succeed, you'll need to market it. In this post I'll describe the different forms or promotion and advertising we used for 3D Bookshelf, currently in the top 100 Paid Apps in the US App Store. It's also currently the #1 Paid Book app in the US App Store (among others) and featured in "What's Hot" on iTunes.
The Basics
There are some obvious points to note about marketing your app successfully.
You've all heard this before, but I'll say it again. A nice app icon is an absolute requirement. We spent about 2.5 weeks designing the icon for 3D Bookshelf and continued to refine it throughout development.
Also, there must be something special about your app. For 3D Bookshelf we aimed pretty high, stating up front that we had created the world's first fully 3D eBook reader. We didn't copy the page turn animations from existing eBook apps and so on. Instead we focused on producing something that we hoped would 'wow' people when they ran the app. From the feedback we have been getting, it looks like we have succeeded in achieving this.
Aside from the two points already mentioned there are other basic points worth describing. Here are the basic aspects of our marketing strategy for 3D Bookshelf.
It all started with the domain name.
Domain Name and Web Site
We registered 3DBookshelf.com as soon as we decided that was the name for our eBook app. Having the domain name for your product is a big help when it comes to presenting a quality brand. This isn't always easy to arrange, since domain names (at least the good ones) can be hard to get hold of.
~ 3D Bookshelf ~
Robin Hood Edition
Free Download!
3D Bookshelf - Robin Hood Edition uses the world's first fully 3D eBook engine.
Download it for free now!
We put a lot of effort into the 3D Bookshelf site. Our goal was to keep it simple and consistent with the overall look of the app itself in addition to making it as welcoming as possible. Also, the site was created with a series of configurable switches. So, as soon as the app appeared on the App Store, we just flicked a switch and all of the relevant links and images appeared. Likewise, when we announced the competition, we flicked another switch and that aspect of the site became visible and so on.
Most of the traffic we get appears to be coming directly from the 3D Bookshelf product page on iTunes. The daily hit count correlates consistently with the daily sales. For example, on the 27th of Feb we saw around 172 visits from the US along with 1226 sales in that territory alone. The ratio of hits to sales has been consistent for the last few weeks. We're able to predict our daily sales to a good degree of accuracy based on the site analytics from the previous day.
Blogging
From the very beginning of the project, we made a concerted effort to blog about the production process. As soon as we had the app prototype running and content for the web site, we had enough good quality material to use for blog posts and screencasts. This also helped keep us focused on the goal. Each of the posts was submitted to various aggregators like iPhonekicks.com and DZone.com to further promote them. The post on the behind-the-scenes screencast pulled in a huge spike of traffic (around 800%). It was at this point we got our first sense of how the market would react to the product. Here is a list of the development blog posts.
Press Release Sites
We wrote an initial draft of the press release early on and refined it throughout the development of the project. The press release was based on a standard template and we made sure to keep it as clear as possible and include all of the main points regarding the app. You can read it here.
We then identified about 40 highly ranked global and local press release submission sites. This list grew throughout the development of the project. As soon as the app appeared on the App Store we emailed the press release to each site we had enumerated.
Review Sites
We identified around 80 blog/forum/review sites and sent preview details to each. We used Alexa to order the sites, submitting to the highest ranking ones first. We prepared screenshots, icons, a promotional video and other marketing materials such as a company overview and a product overview document. This became our press pack.
We were reviewed by several app review sites. In general the reviews were very, very positive. Quotes from these reviews were added to the iTunes app description text along with the 3D Bookshelf web site.
We arranged to have 3D Bookshelf reviewed on the Daily App Show. This site is run by Jerad Hill, who provides an interesting take on reviews. Rather than deliver his own view on the apps he features, he presents the app in a general way by showing the viewer how the app is used and what it's all about. This allows the viewer to make up their own mind. The videos he produces are pushed out to several channels including YouTube. Like most good app review sites, the Daily App Show gets a lot of review requests, so my advice would be to try and organize your review as early as you can. This will help get you some good exposure as close to your release as possible. There is also a small charge, but it's quite reasonable.
Competition Sites
To kick-start interest in the app release, we ran a small competition. We identified around 30 competition promotion sites and as soon as we announced our competition, we fired the details to each of these.
What's After The Basics?
With the above basics in place, we focused on a way to generate as much exposure as possible around the release date. We used Google Ads to get the ball rolling with this, but we didn't advertise 3D Bookshelf.
Google Ads
We ran a small advertising campaign with Google Ads for our first iPhone app, Gravity Wave. Although we noticed a large spike in traffic to the Gravity Wave site at the start of the campaign, our sales only increased very marginally.
There are many different ways to approach using Google Ads to promote iPhone apps. The simplest is to just advertise the app directly in each advert. The hope here is that each click on the Google Ad will result in a single sale of your app. That's the best case scenario and in reality this approach is more likely to give a 10% return from what I've heard from other developers. That is, for every 10 clicks on your Google Ad, you'll get one sale. This implies that you'll need to cap your CPC (Cost Per Click) bids at a value that is less that the amount on money you'll make on each sale. For example, if your app sells for one dollar, and your share of that is 70 cents, you'll only make a profit from advertising if each click costs no more than 69 cent. This doesn't account for various taxes or the fact that 9 out of 10 clicks wont produce a sale, so you'll have to lower your maximum CPC bid even more assuming a 10% return.
Given the figures above, it seems that a straight-forward approach to using Google Ads to advertise an iPhone app is not going to provide a reasonable return, unless the sale price of your app is significantly greater than the maximum CPC bid you're prepared to pay.
On the other hand, the potential loss shown in the figures above may still be worthwhile. For example, if the approach above is used to build sales momentum, this could cause your app to rise in the charts. If it gets listed high enough, the momentum generated may well be enough to sustain further sales due to dramatically increased exposure on the App Store. At this point, you could stop using Google Ads and let the sales momentum take over. If the app begins to drop off the charts, you could consider turning your Google Ads back on to try and build more interest in the app.
Slingshot Marketing, What's That?
The approach we chose to use was based on our experience so far with Google Ads, and from observations of alternative forms of advertising. We knew that using Google Ads could definitely increase traffic to our product site. We also knew it would be difficult to target only consumers that were highly likely to buy our product. So we decided that instead of using Google Ads to advertise our product directly, we would use it to advertise something we knew everyone visiting our site would be interested in, a competition to win a brand new Apple iPad.
To enter, each participant was required to tweet a promotional message. It's this promotional message that advertised our product. We developed a simple Twitter competition service hosted on our VPS and published details of how to win an Apple iPad by first, following us on twitter and then second, tweeting a competition message.
We then prepared a Google Ads campaign to advertise the competition rather than our product. Assuming 10% of the consumers visiting our site entered the competition (and possibly purchased 3D Bookshelf) we had the further prospect of anywhere from 10 to 100 or maybe more times that again in viral twitter advertising.
The idea was to use the huge momentum built up by Apple and the iPad announcement to help advertise our own product and hope this would slingshot us in to the charts.
This advertising campaign was run in the US and UK only. And thankfully, within a day of starting the campaign we had appeared in the book chart in both of these territories. We instantly started climbing the charts, covering 30-40 places a day until we hit the top 20 in the US Paid Book chart. We peaked at around #3 in the UK Paid Book chart. Not long after this we started to appear in the Paid Book chart in many other territories.
The total spend on Google Ads was 300 euro (around $400 US). That's less than our current average daily revenue by about $100.
What's Hot? 3D Bookshelf!
The exposure we had generated had helped get us to a place in the charts that people started to take notice. And not just any people. A major hardware vendor approached us asking if we would be interested in porting the app to their platform. And, of course, Apple decided to feature us in the "What's Hot" section of iTunes in several territories, including the US. Below is our sales graph for February.
Notice on the 16th, things really started to take off. Within hours of being featured in "What's Hot" we hit #1 in the US App Store Paid Book chart. A few days later, we hit the top 100 Paid Apps in the US App Store. We're currently around #79 in the overall Paid chart, which gives us between approximately 900 and 1400 downloads a day, with the weekends bringing in the highest sales figures. Below are the sales figures for the last 7 days in February.
So how do you get featured in "What's Hot"? This is the million dollar question. As far as we know, getting a slot in "What's Hot" is down to your app standing out from the crowd in one way or another (no surprise there). As I mentioned above, this was something we were aiming for with 3D Bookshelf. Thankfully, it worked for us.
Update - Since I posted this article, we've been featured in "New and Noteworthy" in the Australian and New Zealand App Stores. Shortly afterwards, we entered the Top 100 Paid Apps in both territories (currently #70 and #74 respectively). 3D Bookshelf has also been featured in "What's Hot" in the South Korean App Store.
Regular Updates
From the day the app was released we've been working on updates in response to user reviews on the App Store. We've already released two and we're about to release a third. We've added social connectivity to the app so you can let your friends know what you're reading or how you're progressing with a book, on both Twitter and Facebook. We're hoping to see an increase in sales due to the exposure generated by people posting their progress on their Walls in Facebook, or to their timelines on Twitter.
We have many more updates planned with some very cool new features and many more books.
This commitment to updating the app has been very well received by users and we fully intend to support the app well into the foreseeable future. Providing regular app updates is a great way to keep genuine interest in the app alive.
Until Next Time
It's been around a month since we released 3D Bookshelf. In that time, we've sold over 16,000 copies of the app. If we notice anything interesting with the numbers over the coming weeks, we'll post the details here.
As always, for more updates you can follow us on Twitter!
As soon as 3D Bookshelf is released, we're planning on running a small promotional competition on twitter. In this post, I'll briefly describe the architecture we put in place for managing the competition and providing a real-time view of the number of people who are participating.
Overview
~ 3D Bookshelf ~
3D Bookshelf is the world's first fully 3D eBook Reader. Available now on the AppStore for iPhone & iPod touch!
There are many different ways to run a competition on twitter. Some companies have used hashtags to draw attention to their brand. Others use retweets to put their brand message in front of their followers' followers virally. Each method has pros and cons associated with it.
For example, the hashtags method can work well because it allows the participant to tweet what they want so long as they include the hashtag. On the other hand, it means that a valid participant may well be tweeting about the competition owners' brand in a negative way.
The approach we're favoring at the moment is to require each participant to follow us and then tweet a specific competition message.
Management
Regardless of the competition method, participants must be identified and remembered so that at the end of the competition each participant has a fair chance of being chosen as the winner (or one of the winners). For the type of competition we're favoring we have two choices. We can use the twitter search API to identify participants, or we can use the mentions timeline.
Using the twitter search API appears to be the best choice at first. It is subject to some limitations regarding the volume of results you can expect to receive. It is also subject to some date range restrictions. However, if it is polled often enough (within the rate limitations), these restrictions shouldn't be a problem.
Using the mentions timeline is slightly more complicated in that you are required to implement a little more management code, but it offers more reliability in helping enumerate valid participants.
The reason the search API is less reliable is due to a known issue with the API. Apparently, this issue does not affect the mentions timeline. As described on the twitter web site, "if you post an @reply to a specific user, these will be delivered to that user. If we're not experiencing issues, your account is public, your tweets have been posted for more than 24 hours, and you're still not listed, your tweets have most likely been filtered out of our search index for quality reasons."
Implementation
To manage the twitter competition, we wrote a simple service that polls the mentions timeline and harvests valid participants. It remembers the last maximum TweetId encountered and only requests tweets back as far as this TweetId on subsequent requests. It also honors the rate limiting guidelines.
For each valid participant, we fire the participant details to a very simple local web service for storage in a database. The 3D Bookshelf website then requests the number of participants from this web service.
We deliberately decoupled the database access from the web site and service so that both of these components can talk a simpler language to the web service. This simplified both the web site and the service and also meant we only ended up with one ORM cache running behind the web service. It also made system testing and unit testing shorter and simpler.
Strategy
Having a reliable engine in the car is only half the battle. We're learning as we go so we're not sure what to expect, but we do know that without a good map for directions we wont get very far. In a follow up post, I'll describe the strategy we're working on to push the 3D Bookshelf twitter competition as far as we can.
Check back soon for more. Or, you can sign up to my RSS feed or follow me on twitter for updates.
Developing software costs money so it's important to make sure everyone on your team is moving towards a clear, shared goal to avoid wasted effort. There are many approaches to achieving your goal, and over the course of the last 20 years the software industry has seen them all.
~ 3D Bookshelf ~
3D Bookshelf is the world's first fully 3D eBook Reader. Available now on the AppStore for iPhone & iPod touch!
Having spent a year researching Agile development (Scrum), followed by a year using it, I've seen the results of this approach first hand. In short, when you couple experience with a simple approach to estimation and tracking and add a capable Scrum master to manage impediments, your chances of successfully guiding a team to a goal, on schedule are very good.
You may have noticed the word 'experience' above is emphasized. This is very deliberate because this is where agile development (and Scrum) breaks down, and this is why agile can be the wrong choice when developing certain types of iPhone apps.
So what is it about certain types of iPhone apps (and a certain level of experience) that makes Agile the wrong choice?
Two things.
- Often the goal of your team will be to add some magic to your iPhone app. This might be a 60 fps Doom renderer. Even with a well written spec, the actual final details of this magic may be unknown until well into the project. This may be because without prior experience writing an app just like the one you're working on, research is required. The results of research (and time required) are very, very difficult to estimate.
-
Some types of software development (like server side development) generally consist of well defined goals. The server receives A, stores B and returns C. An experienced developer can take this spec and provide a good task break down with estimates that will likely hold true. With most of the iPhone apps we've worked on, the same type of spec is usually present, with one added requirement. Quality. Achieving the required quality level usually means iterating over a project until a general consensus deems the app at a quality level ready for launch.
Point 2 could mean putting a beta in the hands of a sample audience and then responding to comments and requests that could dramatically increase the quality of you app. This is also very difficult to estimate and could mean a significant re-write if the quality of your app is of the utmost importance.
Having said all of this, it is possible to use Agile to a high degree, when developing high quality iPhone apps. For 3D Bookshelf, we identified the areas requiring research and scheduled them up front. This takes point 1 out of the equation. We accepted that we would spend a certain amount of time researching our options. This involved the production of a proof of concept prototype. We didn't know how long this would take. To keep things real, we did put a limit on the amount of time we could invest in this stage of the project. In the end, we got through it much quicker than anticipated, but we couldn't have known that in advance. With that out of the way, most of the rest of the project became very straight-forward to estimate and schedule.
Agile developers reading this are probably thinking, hold on, if you've put a time limit on the research task, surely this fits with Agile or Scrum. The answer is no. The results at the end of this stage could have an explosive effect on the rest of the project. For example, we could have tried to produce 3d Model content for the 3D Book system (and a lot of it) before we found out that it was much much simpler to produce a real-time engine to create the 3D Books. That's potentially a lot of wasted effort both in terms of management and content production.
There are other aspects to this project that were inherently suited to Agile development. These included the Twitter competition service, the web site and preparation of most of the content and tool updates.
The last few weeks were set aside for polish. That's where we are right now. We've said goodbye to schedules. That takes care of point 2. We're no longer trying to track this using Agile techniques. We know we're close to the end of the project. We know we can get to a quality level we'll be happy to release at. When will that be? We don't know yet.
Again, to be realistic we have set a limit to this. We can't throw infinite time at the project and expect to make any kind of financial return. All I can say is we'll release between now and that cut-off date.
We've successfully applied the approach above before, to a previous iPhone project (a custom app for a high profile UK artist). Based on some initial research we produced a sprint task breakdown that came to 120 man hours. These tasks were completed in 131 man hours, only 11 hours over the estimate. Not bad considering the research involved (an advanced OpenGL renderer) and change requests. In the end we added a further 20 hours of polish at the request of our client. At all points in the project we had a good clear understanding of where we were in terms of the overall schedule.
Conclusion
Agile software development becomes quite powerful when it is coupled with experience and familiarity with the project domain. This is the guide we use for deciding when, and when not to use it.
Check back soon for more. Or, you can sign up to my RSS feed or follow me on twitter for updates!
For the last year, I've been using SCRUM at Pocket Kings here in Dublin. Although I finish up at Pocket Kings on the 28th of this month, I fully intend to continue using SCRUM for my own projects at Ideal Binary.
~ 3D Bookshelf ~
3D Bookshelf is the world's first fully 3D eBook Reader. Available now on the AppStore for iPhone & iPod touch!
Version One is the SCRUM tool I've been using at Pocket Kings so that's what I'm familiar with. Once up and running it's relatively straightforward to use. It is an enterprise level tool though and if all you need is to track your own work (and not that of a team or group of teams), it may be overkill setting it up and hosting it.
My requirements are pretty simple. Essentially, I want a way to store my task estimates and also track my progress from the beginning to the end of each sprint. I also want to be able to get visual feedback (a Burndown chart) so that I can see how accurate my estimates are, and to what degree discovered tasks are entering the sprint, if at all.
Tracking discovered tasks can help identify improvements that can be made with future estimates. Also, being able to show a client discovered tasks on a Burndown graph can help them understand what can cause a project to overrun a due date, or why they may need to consider removing a feature if they want the project to be completed on time.
My team lead at Pocket Kings showed me how to get started implementing a simple system that can provide this with none other than Google Docs.
What I've implemented here is somewhat different from what I was shown, but it provides me with everything I need. Below is a snapshot of the spreadsheet with data from a hypothetical sprint. One quick point about this hypothetical data - in general I try to produce task estimates that are around one to two hours in duration. If I find I've estimated a task at more that this, I like to break it up into smaller tasks. For demo purposes, I haven't broken up the large tasks into smaller ones.
Anyway, to set the spreadsheet up, you enter a start date and an end date. Then you enter your tasks along with the task estimates. After this all you have to do is update the details of each task on a daily basis just like Version One. The formulas take care of the rest.
As you can see, below each task there are three rows. These are used to track changes in details relating to the task. These are:
- Estimated Remaining - This is the estimate for remaining work to get this task finished.
- Effort - The effort made to complete work that was planned for this task.
- Discovered Effort - The effort made to complete work that was not planned for this task.
Discovered Effort may be used to track required work that we simply didn't anticipate or it may be used to track feature creep. This happens when we or the client decide to add functionality during a sprint that wasn't planned. This isn't necessarily a bad thing, so long as it is understood that there is a cost associated with it.
Data from the rows described above are gathered from each task and totals are presented at the top of the spreadsheet. It's these totals that we use to produce the Burndown graph.
The Burndown graph for our hypothetical data is shown above. You can see we're a few days from the end of the sprint. Our Estimated Remaining work is burning down and is inline with the Target Burndown. You can also see we've hit some discovered tasks on the 4th and 7th day of the sprint. Regardless, visible effort is being made and we're burning down nicely. This sprint looks good.
The above system is relatively simple. I'll most likely end up installing Version One when my tracking requirements become more complex. The reason I'm using Google Docs and not Microsoft Excel is that I work with both Apple and PC platforms and it's nice to be able to access this stuff in an easy consistent way no matter what platform I'm using. Google Docs lacks some features present in Excel, but there are no show-stoppers here. Google Docs is also free.
I'm very impressed with what can be achieved with Google Docs.
