Chapter 2

Monetizing and Marketing Your App

In This Chapter

check1 Charging money for your app

check1 Not charging for your app (if that’s your thing)

check1 Increasing your app’s downloads

The Honeymooners aired from 1955 to 1956 on the CBS television network in the United States. Comedian Jackie Gleason played Ralph Kramden, a bus driver living in a small Brooklyn, New York, apartment with his wife, Alice. (In earlier sketches, actress Pert Kelton had played the role of Alice. But Kelton was blacklisted by McCarthy’s House Committee on Un-American Activities, so actress Audrey Meadows assumed the role of Alice.)

One of Ralph Kramden’s fatal flaws was his affinity for get-rich-quick schemes. In a hilarious Honeymooners episode, Ralph and his buddy Ed Norton (played by Art Carney) did a live television infomercial for their Handy Housewife Helper gadgets. (Visit https://www.youtube.com/watch?v=xPq_lgtidbQ to check it out.) Ralph’s sudden stage fright made him stumble and shake instead of effectively showing off his product.

While I’m on the subject of getting rich quickly, I can segue seamlessly to the subject of making money from your Android app.

Choosing a Revenue Model

In the old days (whenever they were), making money was simple. You provided either a product or a service. You charged a certain amount per unit for the product (more than it cost you to acquire that unit), or you charged a certain amount per hour for the service. If you charged $10 for one widget, then you charged $20 for two widgets. You didn’t overthink the process because information didn’t spread very quickly or very far. If you had an interesting twist on the sales of your goods or services, very few people would know about it.

Along came the phenomenon known as advertising. The more effectively you advertised, the more products or services you sold. (I know it’s difficult to believe, but some advertisements made false claims about the things they were selling!) There were also sales promotions. An article entitled “History of Sales Promotion” (www.englisharticles.info/2011/07/05/history-of-sales-promotion ) identifies the first such promotion as a penny-off coupon. The C. W. Post Company issued the coupon for Grape Nuts cereal in 1895. No longer was the amount of money you earned strictly proportional to the number of units people wanted to buy. The amount depended on psychological factors (which you, the seller, could influence) and on variations in pricing (which you could determine).

The information age has companies whose revenue streams resemble labyrinths. One company spends millions to create software, and then gives away the software so that other companies will buy its consulting services. Another company gives away all of its services but collects data on the use of those services and sells the data to other companies. Company A makes money by advertising Company B which, in turn, makes money by advertising Company A.

When you first think about profiting from your app, you might think “Either I sell the app and make money or I give the app way for free and make no money at all.” That’s not the way it works. Not at all.

This section describes the many ways that you can profit from the distribution of your Android app. Unfortunately, the section doesn’t contain any “here’s-exactly-what’s-right-for-you” advice. There’s no single, one-size-fits-all revenue model. Many models are better for some kinds of apps and worse for other kinds of apps. Some models are best for the country you live in, but not for other countries. I can try to classify apps into certain categories based on their ideal revenue models, but the boundaries between categories are thin, and the criteria for placing apps’ categories are subtle. You have to think about your own app and decide which model (or which combination of models) is best for you.

Charging for your app

You can set a price for your app. If you publish on Google’s Play Store or Amazon’s Appstore, you pay a 30 percent commission. That’s not bad considering that Google paid seven billion dollars to app developers between February 2014 and February 2015. (See www.theverge.com/google/2015/2/26/8112475/google-play-android-app-store-ads-sponsored-search.)

If you decide to charge for your app, what price should you set?* The following sections offer you some advice.

Consider the competition, including the free competition

Check other apps with functionality that’s similar to your app. Look at the prices for those apps. Ask yourself where your app fits in. Does your app have more features? Does your app present a smoother user experience? If so, you can charge a bit more. If not, you better lower your asking price. If you find free apps that do what your app does, ask yourself why a user would choose your paid alternative.

Use psychological pricing

Studies have shown that, as far as consumers are concerned, whole numbers aren’t equidistant from one another. In a consumer’s mind, the price $0.99 is much less than the price $1.00. Here in the United States, I can’t remember ever seeing a gasoline price that didn’t end in nine-tenths of a cent per gallon. This phenomenon, where prices are best set a bit less than a round number, is known as odd pricing.

Odd pricing is just one form of psychological pricing. Another psychological pricing principle is that users don’t like spending amounts that seem to be strange or arbitrary. What do you think if you’re asked to pay $1.04 for something? Why are you being asked to pay four extra cents?

Vary your price

On Google Play Store, you can’t turn a free app into a paid app. But there’s no rule about increasing or decreasing the price of a paid app.

There are two competing strategies for evolving your pricing, and you might want to use a combination of these strategies.

  • Start high; eventually go lower.

    If your app has little or no competition, you can start high. Attract users who think of themselves as high rollers, and get the highest price from these users that you can get.

    As a variation on this strategy, consider premium pricing. With premium pricing, you intentionally set a high price in order to convince users that you have a high-quality app. (Of course, if you try this trick, you better not disappoint your users. You must maintain the perception of high quality. If your app is truly a high-quality app, you have a leg up.)

    If you start with a high price, your sales eventually slow down. This can happen because you’ve found all the people who are willing to pay the higher price, or because other developers have started undercutting your price. One way or another, you can lower your price.

    And then, there’s the competing strategy …

  • Start low; eventually go higher.

    Start by undercutting the competition. Then, when you’ve developed a good reputation, raise the price of your app.

If your app is popular (so popular that people might notice a change in price), you should consider the timing of your change. Decrease the price when the change will be noticed. (For example, if your app has a seasonal aspect, lower the price very conspicuously as that season’s purchases rev up.) Increase the price in small increments when users are least likely to notice. Alternatively, you can coordinate price changes with other changes. You can increase the price when you release a new version with new features. Or, when you increase the price of one of your apps, you can announce loudly that you’re decreasing the price of another app.

Look for statistics and other hard data

“… if you torture the data enough, nature will always confess …”

(from “How Should Economists Choose?” by Ronald H. Coase)

A chart posted at www.appbrain.com/stats/free-and-paid-android-applications indicates that, on Google Play Store, about half of all free apps have fewer than 500 downloads. Compare this with the paid apps where between 80 percent and 90 percent of all apps have fewer than 500 downloads. Interestingly, for paid apps, these percentages don’t vary directly in proportion to price.

  • For apps priced less than one dollar and for apps priced more than ten dollars, about 90 percent have fewer than 500 downloads.
  • For apps in the middle (apps priced between $2.50 and $5.00), the percentage of apps with fewer than 500 downloads drops to a more comfortable 80 percent.

There’s some aspect of psychological pricing that’s operating favorably in the $2.50 to $5.00 range. You might not understand why this happens (and in fact, I don’t know why it happens). Even so, the fact that there’s a sweet spot between $2.50 and $5.00 is worth noting.

One way or another, it never hurts to search for statistics. Trends change, so look for pages that are updated frequently. Be skeptical of facts and figures from years gone by.

When you look for hard data, lots of good things happen. At best, you learn that your preconceived notions about app pricing are wrong and that you should modify your pricing strategy. At the very least, you become aware that what you intend to do isn’t backed up by the facts. So you keep doing what you intend to do, but you do it with your eyes wide open.

tip Search the web for information about pricing strategies. You’ll find a lot of good reading there. If you want a one-stop shopping stats page, pay a visit to http://mobiforge.com/research-analysis/global-mobile-statistics-2014-home-all-latest-stats-mobile-web-apps-marketing-advertising-subscriber.

Offering an extended free trial

Google Play buyers can return an app within two hours for a full refund. If you want the trial period to last longer, you have to outfit your app. One way to do it is to have the app record the time when it was first launched and compare this to the current system time. Of course, saving this information in SharedPreferences isn’t foolproof. A user with some programming skill can hack the scheme and can share this hack with others. (Once your app has been hacked, there’s no going back. You can’t track down all sources of illicit information and stop them in their tracks. Bad information spreads very quickly. No matter what you do, a tip about hacking your app will be available online forever.)

Instead of storing times and dates on the user’s device, you can send this information to a server along with the device’s identification number. Have the app check that server regularly. Like the SharedPreferences scheme, this server-based scheme isn’t foolproof. But storing times and dates on a server is harder to crack than storing information on the user’s device.

technicalstuff On a phone, you get the device’s identification number by calling the TelephonyManager class’s getDeviceId method. For a device that’s not a phone, you can ask for the Settings.Secure.ANDROID_ID field.

Another way to implement a many-day trial period is to create two apps with two different licensing arrangements. The free trial app’s license expires in 30 days. But as the trial app breathes its dying breath, it reminds the user to visit the Play Store and purchase the paid app.

If you don’t like maintaining two separate apps, you can cut the cake in a different place. Create one app that implements both the trial version and the full version. Distribute this app freely. But as part of this dual-version app’s logic, have the app check the user’s device for the presence of a second, paid app. The second app does nothing except either exist or not exist on a user’s device. If the second app exists, the dual-version app behaves like the full version. But if the second app doesn’t exist, the dual-version app behaves like the trial version.

One way or another, the Play Store’s app licensing tools are more reliable than most home-grown date-checking techniques. Using licensing to police the trial period is a good idea.

crossreference For a few words on the Play Store’s app licensing tricks, see Chapter 1 in this minibook.

Freemium apps

A mobile app with a paid-only revenue model is rare indeed. By one count, there were ten times as many free apps as paid apps in 2013. (See and www.statista.com/statistics/241587/number-of-free-mobile-app-downloads-worldwide and www.statista.com/statistics/241589/number-of-paid-mobile-app-downloads-worldwide.)

In the freemium revenue model, one useful version of your app serves as advertising for an even more useful version. This form of advertising has several advantages over more traditional advertising modes.

  • The advertising is well-targeted.

    People who install your free version are potential buyers for your paid version.

  • It directly demonstrates your app’s benefits.

    Instead of reading about your app, or hearing about your app, users experience your app.

  • It’s repetitive without being annoying.

    A potential customer probably uses the free version on a regular basis.

  • It can be inexpensive.

    You incur an expense when you create the app, and you have to create the app anyway. But after you’ve published the app, the marginal cost of each free download is almost nothing. (This assumes that you don’t offer services for each active user. Yes, the free users might find bugs, and fixing the bugs takes your time and effort. But the effort you spend fixing these bugs doesn’t count as an advertising expense. You’d be fixing these bugs no matter who found them.)

  • It enhances your reputation.

    This one is a “biggie.” With conventional advertising, you can come off as a snake oil salesman. But with a free version of your app, you’re a benevolent developer (a benevolent developer who might occasionally ask for well-deserved remuneration). Think back to the last few times you upgraded from free to premium. For me, it wasn’t because I needed the enhanced features. Instead it was because, through repeated use of the app, I had formed a certain respect for the originator.

As with several other revenue models, the main question is “how much?” In the freemium model, which parts of your app do you give away for free? Which parts do you keep for the paid version? As usual, there’s no prepackaged answer. But there are some general strategies:

  • Divide your users into two categories — the high-rollers and the not-so-high-rollers.

    The high-rollers might be the corporate users; the others are individuals. The high-rollers need premium features and have the resources to pay for those features. The others don’t. Which features of your app appeal primarily to the high-rollers? Put those features in the premium version.

  • If you don’t incur a cost each time someone uses a particular feature, give that feature away for free. If you incur an ongoing cost, charge for that feature.

    An app on a phone or a tablet can do only so much work. Maybe, to implement certain features, your app ships work out to a server. Access to the server costs money, and the amount of money depends on the workload. The more people use these costly features, the more revenue you must have. (Otherwise, you’ll go broke.) So tie the price of the app to the use of these features. The app’s premium version includes these costly features; the app’s free version doesn’t.

  • If volume usage is relevant for your app, create a soft paywall.

    A hard paywall is an all-or-nothing restriction on the use of a resource. But with a soft paywall, users get 500 wha’cha’ma’call’its for free each month. Users who need more than 500 wha’cha’ma’call’its each month buy a recurring subscription. You can change the number when you see the need. But when you do, be aware of the impression you make on your existing users (both the free users and the paid users).

    crossreference For some good reading about recurring subscriptions, see this chapter’s “Subscription pricing” section.

  • Advertise or nag in the free version.

    If the previous approaches are like carrots, this approach is like a stick. With this approach, you entice users to pay for your app by putting something undesirable in the free version. Unfortunately, Android has no emitUnpleasantOdor method. So, for the undesirable feature, most developers advertise or nag.

    Nagging involves displaying a pop-up alert box reminding the user to buy the retail version. You decide how often you want the pop-up to appear, and what the user must do in order to dismiss it.

    The advertising option has a few advantages over the nagging option. For one thing, advertising can be unobtrusive. (Who ever heard of unobtrusive nagging?) When advertising is unobtrusive, users tend not to associate it with the app or with the developer. So, with advertising, your image remains largely untarnished. And let’s not forget — advertising can bring you some revenue while you wait for users to purchase your app’s full version.

  • (Not recommended) In the free app, include only enough functionality to demonstrate the paid app’s usefulness.

    Apps that involve saving data tend to use this strategy. With the free version, you put the app through its paces. You examine the results to see the how effectively the app does its job, but you can’t save the results. The user is disappointed because, in the final analysis, the free app is nothing but a tease.

    With this approach, you undermine some of the freemium model’s advantages. For one thing, you lose the repetition advantage. A potential user tries your app once to find out if it’s worth buying. Months later, when the need for your app arises in a more serious context, the user has forgotten about your app and finds another app in its place.

    More importantly, this approach ignores the benefits of customer loyalty. Instead of impressing users with your generosity, you annoy users with your stinginess. You lead a user to the brink of success. But then, at the last minute, you confront the user with a mean-spirited roadblock. Whether you think of your app this way or not isn’t relevant. What’s relevant is that users feel this way.

    If you have a killer app, and all you need to do is assure users that your app can perform its supposedly herculean tasks, then this approach is for you. Otherwise, you should avoid using it.

For most apps, the percentage of free-version users who become paid-version users is in the single digits. But that’s okay, because free users aren’t “deadbeat” users. Free users form an important part of your marketing ecosystem. They help spread the word about your app. If your app has any social aspects, the more users you have (free or paid), the better. And if anyone checks your app’s usage statistics, free users count. So, by all means, give the free users access to your app’s essential features.

Selling things with your app

Google’s Play Store and Amazon’s Appstore differ on the kinds of things you can sell. With Amazon’s Appstore, you can sell physical goods. (Amazon has never been squeamish about shipping physical items.) On Google Play, you can sell only digital content. So, if you publish a game, and you want to sell action figures of the game’s characters, you have to use Amazon’s Appstore. (You can sell action figures for a game on Google’s Play Store. You just can’t embed the purchase as a feature of the game.)

To set up in-app billing, you make additions to your app’s code. You create a service, a broadcast receiver, an AIDL file, and some other stuff. You add a permission in the app’s AndroidManifest.xml file:

<uses-permission

      android:name="com.android.vending.BILLING" />

 

On Google’s Developer Console, you visit the in-app billing pages. You select the kind of billing you want for your app.

crossreference For help getting to the Play Store’s Developer Console, refer to Chapter 1 in this minibook.

  • Managed product: The Play Store manages this one-time sale.
  • Unmanaged product: You manage this sale.
  • Subscription: The Play Store manages this recurring sale. (See the next section.)

In the Developer Console, you give the product a name (a title). You enter a description and you specify the price. You can accept the default conversions into other countries' prices, or you can name your own local prices.

The Play Store can manage the billing for your product, but the Play Store doesn’t deliver content. Delivery of the purchased content is up to you.

ontheweb For some of the gory details about in-app billing, visit http://developer.android.com/guide/market/billing/billing_integrate.html.

Subscription pricing

Some apps require care and feeding when they run. They consume data that needs to be updated periodically, or they consume services that you must provide. For apps of this kind, subscriptions might be appropriate.

A subscription charges the user repeatedly. As an app’s developer, you get to choose what “repeatedly” means. The options are monthly, yearly, and seasonal. (The seasonal option is like the yearly option, except that renewal occurs only during a certain part of the year — a part that you specify with start and end dates.)

If your app’s content requires regular refreshing, the subscription model is worth your consideration. You can build up a steady income flow, and that’s worth a lot.

remember Subscription pricing works only if your content requires it. I’ve seen apps with artificially imposed subscription policies (having the app self-destruct after a certain period of time). Apps of this kind work well for big business clients, but they have little appeal for individual users.

ontheweb For more information on subscription billing through the Play Store, visit https://developer.android.com/google/play/billing/billing_subscriptions.html.

Earning revenue from advertising

There was probably a time when you had to jump through hoops before you could display ads inside your app. You’d find people who wanted to advertise their goods or services, write code to display their ads, strike up an agreement on the price for your advertising, and so on. Nowadays, it’s not difficult at all. It’s a smooth-running assembly line.

In this section, I outline the steps you need to take in order to display ads in your app. I don’t provide much detail because the details change frequently. Instead, this section’s outline describes what you can expect to do when you dive into the advertising game. Google’s AdMob facility handles all the nitty-gritty details, and the AdMob web pages guide you through every step of the process.

Here’s the outline:

  1. Visit https://apps.admob.com/admob/signup.
  2. Sign in with a Google account.

    You can use the same account that you use when you sign in to the Play Store’s Developer Console.

  3. Enter the required information about yourself.

    Don’t worry. It’s not too much information.

  4. Click a Monetize New App button, or something like that.

    When you do, you see a page where you enter the name of your app. AdMob finds your app on the Play Store.

  5. Enter some information about the ads that you want to display.

    How do you want the ads to appear? The choices are banner or interstitial.

    • A banner ad appears as a small band somewhere on the app’s screen.

      A banner ad can appear or disappear any time during the run of your app.

    • An interstitial ad takes up a large part of the device’s screen.

      An interstitial ad shows up only when the user won’t be terribly annoyed by the ad’s appearance. For example, if your app is a game, you might code your app so that an interstitial ad appears only between rounds.

    If you’re familiar with time/space tradeoffs, you’ll recognize where the two types of ads fit in. A banner ad consumes very little space but can appear almost anytime. An interstitial ad consumes less time in order to gain some space.

    In this step, you also specify the refresh rate for ads, and some other things.

    tip The refresh rate is the amount of time that each ad remains on the user’s screen (before being replaced by another ad). Research shows that a rate of 60 seconds or longer works best.

    At some point, the web page displays an ad unit ID. This ad unit ID number goes into your app’s code. When a user runs your app, the app sends this ID number to the AdMob servers. The more the AdMob servers receive your ID, the more money you earn.

  6. Make a note of your ad unit ID.

    Meanwhile, back on your development computer …

  7. Use the Android SDK Manager to install the Google Repository.

    You’ll find the Google Repository entry in the Android SDK Manager’s Extras category.

  8. Add stuff to your project’s files.

    Here are a few of the things you do:

    • You put your ad unit ID in the strings.xml file.

      This identifies your app so you can earn money for displaying ads.

    • You put a com.google.android.gms.ads.AdView element in your activity’s layout.

      This element can display ads.

    • You add code to your app’s activity.

      The code loads ads into your layout’s AdView widget. For a banner ad with AdMob, the code is pretty simple:

      AdView adView = (AdView) findViewById(R.id.adView);

      AdRequest = new AdRequest.Builder().build();

      adView.loadAd(adRequest);

    ontheweb Visit https://developers.google.com/mobile-ads-sdk/docs/admob/android/quick-start for all the details.

When your app goes live, the amount that you earn varies from one advertiser to the next. In most cases, the amount hangs on a “cost per something or other” measure. Here are a few possibilities:

  • CPC: Cost per click

    Your payment depends on the number of users who click on the ad in your app.

  • CPM: Cost per thousand impressions

    An impression is the appearance of an ad on a user’s screen. A single impression isn’t very impressive. So for every thousand ads that appear, you get paid.

  • CPA: Cost per action

    You earn money whenever a user performs a certain action. What constitutes an action depends on the advertiser. Examples of actions are clicks, sales, and registrations.

One way or another, advertising is a relatively low-maintenance way to earn some money for publishing your app.

Variations on in-app advertising

Your app is a place where others can advertise. Given that fact, there are dozens of ways you can tweak the advertising model. If your app complements an existing company’s business, get the company to sponsor your app. You can meld references to the company’s products and services into your app’s interface. If you do it tastefully, users don’t feel that they’re being pressured. (This isn’t a new idea. In the earliest days of U.S. television, shows integrated ads into their regular scripts. George and Gracie would move seamlessly from a kitchen comedy routine to a minute-long discussion of Carnation Evaporated Milk.)

Incentivized advertising is another option. With this option, advertisers reward users who perform certain actions within your app. For example, your app stores and displays recipes. For every ten recipes that the user completes, the app rewards the user with a coupon for cooking utensils. The advertiser gets the business, the user gets the goods, you get the revenue, and your app gets used. Everyone wins.

Both sponsorship and incentivized advertising are very well targeted. You’re not promoting automobiles for ten year olds or weight-lifting equipment for me and my fellow college professors. Instead, you’re riding a wave. It’s a synergy wave between your app’s theme and a company’s wares.

Donationware

If you’re not trying to earn a fortune, but you’d like some spare change from your most loyal users, try this strategy. Use in-app billing as in the “Selling things with your app” section. But instead of delivering a product, deliver a “thank you.”

The rate of return will be very small. But I’ve done some donating for my favorite apps. So for all the apps that have ever been published, the return rate isn’t zero.

Offering your app for free

You might argue against my decision to put this “absolutely free” subsection inside the “Choosing a Revenue Model” section. But let’s face it — for a novice developer, “absolutely free” is a choice worth considering. For one thing, a free app attracts more users than a paid app. With your free app, you can start building your reputation among users. This reputation might be for you as a developer, or for the apps in your ongoing development plans. Besides, when you publish your first app, you learn a lot about the process. That’s worth something even if it’s not monetary.

Revenue or no revenue, an unmeasurable benefit is derived from giving freely to the community. When you think about publishing apps, don’t forget about giving.

Getting paid to develop apps for others

Don’t forget about this option. Find a local business or a big company. Write code or design user interfaces. Create the artwork for apps. Do what you do best and leave the rest to the business moguls.

Marketing Your Application

Imagine trying to find your friend at a gathering that has one million attendees. It’s not easy, is it? Take the scenario one step further. The other person isn’t your friend. You’re looking for anyone with gray hair, blue eyes, and who weighs less than 150 pounds. What are your chances of finding my Uncle Eric?

Now imagine that you’re not at a social gathering. You’re surfing on Google’s Play Store, and the Play Store has more than a million apps. You narrow your search to find a trivia quiz game. At first, the Play Store displays the top dozen trivia quiz games, so newly posted games aren’t included. You widen the search by clicking the page’s See More button. After the Play Store displays its first 300 trivia quiz apps, you stop clicking the See More button. What are the chances that you’ll land on Jane Q. Novice’s new app?

These stories aren’t meant to discourage you. They’re meant to remind you that your app doesn’t market itself. Here are some ways for you to market your app:

  • Create a website.

    Use search engine optimization (SEO) techniques to get your site noticed.

  • Contact the press.

    This includes traditional journalists, but it also includes reviewers and bloggers. The worst they can say is “I’m not interested in writing about this.” If they offer to write about your app for a fee, you can always say “no.”

  • Use social media.

    You know the sites: Facebook, Twitter, Pinterest, Instagram. Post regularly to build up a following.

  • Add social features to your app.

    Nothing says “Try this app” like a post made directly from the app. You can also build loyalty by having users post to one another within the app.

  • Create your own blog or podcast.

    This requires work, but it can pay off bigtime.

  • Pay for advertising.

    Through AdMob, you can have other apps display ads for your app. If you don’t mind spending some money, you can set up a regular paid ad campaign. But you can advertise for free in a house ad campaign.

    When you allocate advertising space to promote your own wares, you’re creating a house ad. AdMob doesn’t charge for this kind of advertising. You create a house ad to promote one of your apps within another of your apps. Alternatively, by agreement with another developer, you can advertise your app in the other developer’s app (and vice versa).

  • Update your app regularly (as a marketing strategy).

    An update can call attention to your app. A study by BI Intelligence (www.businessinsider.com/app-update-strategy-and-statistics-2015-1 ) found a positive correlation between the frequency of updates and user’s ratings. That’s good news.

  • Get help from Google’s Play Store.

    The Play Store has a page with the title “Optimization Tips.” This page analyzes your app and lists things that you’ve done (and haven’t done) to enhance your app’s visibility. For example, with one of my apps, the page reminds me to design for tablets. I should add custom drawables for tablet screen densities, and upload at least one screenshot for 7-inch and 10-inch tablets. Google’s research shows that apps customized for tablets monetize ten times as much as apps designed with only phones in mind.

Brick Breaker Master: An app marketing case study

The epistolary novel has a long and noble history. In Rousseau’s Julie, or The New Heloise, two lovers pass letters back and forth. Goethe’s The Sorrows of Young Werther is a collection of letters from Werther to his friend William. Shelly’s Frankenstein includes a sea captain’s letters. More recently, such notables as Stephen King, Gary Shteyngart, and Daniel Handler (writing as Lemony Snicket) have featured diaries, news articles, and letters written by their novels' characters.

As far as I know, this section is the first use of the epistolary style in a For Dummies book.

I can’t claim full credit for this accomplishment. The interchange that’s documented here is mostly real. It’s a bunch of excerpts from an email conversation between me and a reader. In these email messages, the reader (Daniel Levesque) does most of the heavy lifting. All I do is ask the right questions. I’ve trimmed some paragraphs to keep it relevant, and this book’s copy editor will probably make some useful changes. Otherwise, the words that you see here are true and unadorned.

From: Daniel Levesque

To: Barry Burd

February 25, 2013

Good morning Barry.

I’m about to finish the book Beginning Programming with Java For Dummies. Then I will start later this week Java For Dummies

From: Barry Burd

To: Daniel Levesque

February 25, 2013

Daniel,

I’m glad that you’re enjoying my books. Have you noticed the last name of the project editor? (When your email arrived, I thought he was contacting me.) …

From: Daniel Levesque

To: Barry Burd

February 25, 2013

Yes I saw his name when I bought the book …

Many emails later …

From: Daniel Levesque

To: Barry Burd

August 14, 2013

Hi Barry,

A while ago you helped me with a couple of questions when I was reading your Java and Android books For Dummies. After all this “study,” I finally published my first game!

Many emails later …

From: Daniel Levesque

To: Barry Burd

June 12, 2014

Hello Barry,

I just published my second Android game of 2014: “Space Garbage!” The goal of the game is very simple: survive in space while avoiding the floating objects!

Many emails later …

From: Daniel Levesque

To: Barry Burd

February 1, 2015

Hi Barry,

I thought I would let you know that I just released my first game of 2015. It is my very first game using a game engine, and I am quite happy with the result. The game is currently number 20 in the Google Play “Top New Paid” category!!!

Check it out when you have a minute: http://play.google.com/store/apps/details?id=com.d14studios.brickbreakermaster

Best regards,

Daniel Levesque

From: Barry Burd

To: Daniel Levesque

February 3, 2015

Daniel,

I’d love for you to send me some tips on your getting to the number 20 spot. I’m revising my Android All-in-One book, and I’d like to quote you in the chapter on publishing apps. Do you have any advice for up-and-coming developers?

Barry

From: Daniel Levesque

To: Barry Burd

February 4, 2015

Hi Barry,

It’s very difficult to do any marketing when you have a very small team or if you work on your own. Here’s what I did with Brick Breaker Master to promote installs:

I figured out that Google uses some kind of algorithm to rank “new paid apps” and “new free apps,” so I tried to generate several installs EVERY day for the first month.

I sent a message to my 200+ LinkedIn contacts asking them to install the game and give me a good rating (not sure how many actually did it).

I built a new App page on Facebook and asked all my family members and friends to “share” the page with their contacts (I figure that I probably got 50 shares through this, although the potential was more like 500).

I sent messages to my followers on Twitter every three days with a screenshot of one of the game levels (I didn’t tweet too often — didn’t want my followers to get upset and then unfollow me).

I updated my website as soon as I published the game on Google Play and on the Amazon Marketplace.

I submitted a summary of the game to the top ten Android review sites with the hope that they would publish a free review (most of them have an automated reply saying that they receive too many requests to guarantee a review but that for $100 they will … you get the picture). I didn’t want to spend $1,000 for ten reviews without knowing in advance what rating they would give my game! Unless you know for sure that you have a knock-out app, this approach is very risky.

I hope this will help with your chapter in the book.

Best regards,

Daniel

From: Barry Burd

To: Daniel Levesque

February 4, 2015

Thank you, Daniel

Barry

Notes

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.238.82.77