Alarmy? What kind of app is that?

There's a question I've heard constantly over the five years since launching Alarmy in 2012.

5

When meeting people for the first time: "An alarm app? Isn't that pretty simple?"
When catching up with people I haven't seen in a while: "You're still doing the alarm app? Is there still stuff left to do?"

I always find myself answering these questions, thinking, "I really should write this all down someday..." Well, this time I finally decided to organize my thoughts.

First, for those who don't know Alarmy, let me give you a quick intro. Alarmy is an alarm app designed with the concept of waking users up no matter what. When the alarm rings, you absolutely must perform a specific mission—like solving math problems or shaking your phone—to dismiss it.

Among the various dismissal methods, the most powerful is the photo mission, where you have to take a picture of a registered place to dismiss the alarm. If you registered your bathroom, you literally have to walk to the bathroom to turn it off (some users even register places outside their homes).

The problem Alarmy tries to solve might seem trivial and niche, but by focusing on this exact problem, we were able to build a product that a small number of users absolutely loved early on, and then evolve it into an app that even more people enjoy. Through this experience, I strongly resonated with what YC's Sam Altman said: "It's easier to expand something that a small number of users love so that many people love it, than to make something that many people like into something that many people love." Because so many people have loved Alarmy so far, we've been able to grow well without outside investment, achieving various milestones like hitting #1 in the app store category in 97 countries and reaching 25 million downloads.

Now getting to the point, I've summarized why we've been working on an alarm app for so long and what exactly we are doing. There are many things, but I've picked out a few major ones.

1. Technical Difficulties

"What could be technically difficult about an alarm? Don't you just build it?" That's what I thought at first, and our current teammates all thought the same initially. The most important thing for an alarm app is, of course, ringing exactly on time, but this part is not as easy as you might think.

In the case of Android, countless unexpected situations arise as each manufacturer customizes their ROM. For example, with Samsung phones, system apps (e.g., Smart Manager) sometimes prevent alarms from going off, and on many phones from China or India, built-in memory cleaner apps will trigger and kill the alarm app constantly. There are many other issues as well, and to solve them, we directly import phones from numerous manufacturers to test them one by one and devise workarounds (through testing, I realized there are some truly bizarre phones in the world).

Since Android has so many different phones, let's say that's understandable. But what about iPhone? iPhones are even more ridiculous. To sound an alarm while on silent mode on an iPhone, the app must stay alive in the background. In other words, to ring the alarm in silent mode, the alarm app must be running 24 hours a day. This applies to every single alarm app except the default iOS alarm, which is why most alarm apps use various hacks (?) to keep running continuously in the background (you'll notice that alarm apps that don't do this will only vibrate in silent mode). Because of this, we have to handle a variety of issues regarding battery consumption and dealing with the app getting killed in the background, which is harder than it sounds. If I get too technical, this will get boring, so I'll try to write a detailed post about it later.

Ultimately, there aren't as many alarm apps consistently solving these technical issues as you might think, and as a result, we boast the highest rating among the top alarm apps on both the Play Store and App Store (below is a rating comparison of the top 3 alarm apps when searching for "alarm").

2. Globalization

We've been putting in various efforts to make Alarmy usable globally, and one of those is localization. Initially, we started with simple app translations through translators, but to achieve more natural phrasing and context, we've consistently been accepting user-contributed translations. To make this process efficient, we built and run an internal Alarmy translation page. We've been constantly improving it so users can participate as comfortably as possible, and after creating the translation page, we were able to draw in even more user participation.

Thanks to this, we were able to localize into many languages, and as a result, Alarmy currently supports 57 languages and boasts an 85% global user base evenly distributed across various countries.

3. Ad Optimization

Since Alarmy's main source of revenue is ads, we pay a lot of attention to ad optimization. To increase ad efficiency, we test dozens of ad networks and selectively use them after analyzing their performance. Even now, we use 10 to 20 ad networks (including S2S methods) based on efficiency, adjusting priorities every week according to performance, adding new networks, or removing existing ones. Besides that, we're testing various strategies like adjusting the refresh rate per placement, frequency cap adjustments, ad format A/B testing, and setting CPM floors considering advertisers' bid prices, comparing their efficiency. Thanks to all this, we were even featured in a MoPub (Twitter's ad platform) case study.

Also, as mentioned above, since 85% of our users are overseas, we are optimizing ad placements not just in Korea, but in various other countries globally. Especially for key countries, we contact their local ad networks to run tests, or execute the various strategies mentioned above targeted specifically at those countries. Beyond this, there are many variables to consider, and since it directly ties to monetization, precision is required, so we automate where necessary and build internal tools to handle it.

I started doing ads initially with just the basic concepts and have learned so much through trial and error up to this point. But there are still so many things left to learn and try. Ad tech really is tough.

4. A/B Testing

Would a specific button have a higher click-through rate if it were green or if it were red? Changing button colors, tweaking copy, altering the UI layout—honestly, if we set our minds to it, we could run countless A/B experiments. However, since we have to run limited experiments considering the cost involved and the expected impact of the results, we still haven't been able to validate all the hypotheses we've brainstormed.

Still, we've conducted several A/B experiments internally so far. For instance, by comparing ad formats, we increased ad efficiency (eCPM) by 15%, and by changing in-app copy, we boosted the achievement rate of a target metric by 50%.

As a simpler example, in the Play Store app listing, between
"SLEEP IF U CAN 😈#1 among top alarms" and
"SLEEP IF U CAN 😈 The most constantly used alarm in the world", which copy would people react to more and lead to a download? It's hard to know before running an experiment (the result: the latter recorded up to 7% higher downloads).

Fortunately, the Play Store lets you easily run A/B experiments on store listings (step it up, Apple). We ran dozens of Play Store A/B experiments just in the first half of 2017, and as a result, achieved conversion rate improvements like the ones below, which even got us selected as an ambassador for the Google App Excellence Program.

Many mobile apps can run store listing A/B experiments right now without much difficulty, so I highly recommend giving it a try. I plan to write a separate post about the various hypotheses and results we've worked through regarding A/B testing.
[Added: Alarmy A/B Testing Log #1]

5. CS (Customer Service)

As a service grows, communicating with users can start to feel bothersome, and you might neglect CS, thinking, "Why are they asking this?" or "We can't add every single feature they request into the app!"

But I think CS is incredibly important. Spending money on user interviews or surveys is meaningful, but the feedback that comes directly from using the service holds even greater value. By handling CS firsthand, you get a truly solid grasp of how users are using our app, what their needs are, and what they hate. That's why up until recently (for 5 years), I—the CEO—handled a vast majority of it, right down to replying to users and leaving comments (Alarmy accumulates about 1,000 star ratings and 100 emails every single day).

These CS efforts don't just help us understand user opinions; they can actually impact downloads as well. For instance, if there's a 1-star review sitting right at the top of the store reviews, it negatively affects downloads, and scenarios like the one below often happen.

In those cases, the review gets a lot of "helpful" upvotes and remains a top review for a long time, becoming a huge headache. But with Alarmy, thanks to quick responses and communication, top-ranking 1-star reviews frequently magically turn into 5-star reviews (and when that happens, we end up with a 5-star review at the top with a bunch of upvotes!).

If you actually look at Alarmy's review data (a month's worth) from the Play Console, as shown below, replying to a review bumps the star rating up by 1.4 points, whereas reviews left without a reply drop by 0.2 points.

Recently, CS became too overwhelming, so I handed it off to another teammate, but I still consider it an incredibly important task. Even if I can't reply directly, I read every single email and complaint review every day (it's not just me—the engineers also meticulously check CS every day and communicate with users).

Additionally, though I didn't mention it above, we often build the internal services our team needs ourselves from time to time. Of course, if there is a solution that perfectly fits our requirements, we use that solution, but if there's no perfect fit, we consider the long-term impact on the team and build the necessary service in-house (looking back, these self-built services ended up boosting internal team productivity and proved to be great choices in the long run).

Honestly, since the things I've mentioned are invisible to users, people on the outside might not know what exactly we do. But internally, a ton of work is constantly taking place (I think the picture below perfectly captures our situation).

This applies not just to Alarmy but to all apps: I believe there's no limit to how much you can improve the quality of an app. We've been consistently putting in the effort to do so, and as a result, we are thankfully growing by multiples every year, with so much more work still left to do.

(+ The Bookgram channel did a great job introducing our story [Watch Video])

Curious about Alarmy's future direction?

You've been building an alarm app for 10 years? What about the future?

A Successful Morning Ecosystem 🛌 🌙 ☀️

At DelightRoom, we aim to build an ecosystem that covers the entire experience from before bed to throughout the morning to create a successful morning. If you are fundraising while building a related service, or if you think there's a synergy point with Alarmy's global user base, please leave some brief information via our Google Survey 🙌

(Reference: DelightRoom makes a strategic investment in sleep brand '1/3')