The moment of fulfillment -- delivering the subscription customers just bought -- is a crucial point of contact between your brand and the marketplace. Google and Apple collect the customer's money and then signal us to deliver the subscription. If things break down at that point, it's trouble because we receive customer data only in aggregate form. Without visibility into who the customer is, we can't reach out to help if there's a problem with fulfillment.
Our mobile team developed a way to create multilevel redundancy, which caches data and creates an auditable trail back to the customer if anything goes wrong at the moment of fulfillment. For example, if our API were to go down during the fulfillment process, our system would automatically cache that transaction. Once the API is up and running again, the system would push that cached transaction through the fulfillment process.
4. Ensure that you can update your offers without updating your app.
One beauty of digital marketing through a website is real-time A/B testing and the ability to regularly tweak offers and pricing. With a native app, you don't have that flexibility. Changing in-app offers can require creating a new version of the app, since the new offers are usually hard-coded. Approval for new apps in the App Store takes about a week. So instead of flexible marketing in real time, you're looking at a seven-day lag.
Our solution was to avoid hard-coding any offers into the app by creating an embedded Web view that displays an HTML offer page from our servers that can test and change pricing and offers dynamically in real time. Users can't tell they're dealing with a Web page, and Apple and Google are fine with the constantly changing marketing, as long as we follow the rules and sell everything through iTunes or the Play Store.
5. Mobile-ize your monetization strategy by understanding the difference between mobile and desktop/notebook customers.
Companies' well-thought-out website monetization strategies may not translate fluidly to the mobile world. For example, one way we introduce potential users to Ancestry.com in a low-commitment way is through a 14-day free trial. If customers decide to continue on after the trial, their subscription auto-renews. Neither Google nor Apple allows this kind of process. Users pay for the subscription up front, no free trials.
Similarly, patterns of use may differ markedly between a company's website and the mobile app. We noticed that website subscribers are "low frequency/high intensity," meaning they come to Ancestry once a day or a couple of times a week, but stay and use the site for long periods of time, whereas mobile customers are "high frequency/low intensity" -- they open the app often to make discoveries and reference information, and then move on.
To address the differences between website and app, we developed alternate ways for a prospective subscriber to preview the service and make purchases in a "bite-size" manner. In the app, unlike the website, we enable users to preview any historical documents from our collection of billions of digitized records with no commitment so they can get a taste of the discoveries they will make on Ancestry.com. In addition, we highlight the single-record purchase feature I mentioned earlier to address the needs of those kicking the tires, as well as the fast-moving app users. In this way, we're working within the rules set by Apple and Google but are still giving a type of free-trial experience, which is a monetization strategy that has seemed to work for us.
There are certainly frustrations living in a mobile app universe controlled by set guidelines and standards, but in the end, the experience is a plus: Apple's and Google's structures challenge our engineers and marketers to innovate within a known structure, which is great mental and imaginative discipline.