复盘我的首个盈利 Side Project

摘要:两个 Android 开发从 0 到 1 开发出一款工具应用并上架国内市场,盈利过万元的故事。

Idea 的诞生

2018 年初我在北京一家互联网公司任职 Android 技术专家,带领一个客户端开发团队。我有个前同事——以下称为乔峰——当时在另一家以产品打法凶猛著称,加班也不含糊的公司做 Android 研发工作。我们经常讨论各种 app idea,寻思业余时间做个 side project。正好那时答题很火,有天我在网上看到有程序员写了一个辅助答题的命令行工具发布到 GitHub 上,很多人关注。它是用 adb 命令截屏然后 OCR,再用搜索引擎匹配答案,原理很简单。我心想这样搜索出来的答案准确率不可能很高,没法靠这个去答题得奖金。过了几天我突然意识到,虽然准确率不高,没法凭此去赢答题活动的大奖,但是对普通用户来说,有这么一个工具辅助提高胜率,仍然有价值,甚至可能为此付费。我立刻和乔峰说,要不做一个辅助答题的 app。我们快速讨论了一下这里面涉及的技术,认为完全可行,当即决定启动。

第一行代码到上线

根据 Git 记录,乔峰在一个周六提交了第一行代码。从第一次提交到上线,我们用了 15 天。虽然 Android 应用开发我们是老手,但这是我们第一次脱离公司的基础设施,在国内市场独立发布一款 app。第一版硬编码支持了六个当时有答题活动的应用,用户在答题时可以通过悬浮窗查看推荐答案。没有用户登录体系,没有自己的后端接口,唯一直接发起的网络请求是调用百度搜索结果页。应用内升级和崩溃搜集靠免费的 Bugly。关于页面只留了一个客服 QQ。在酷安上架。[1]

快速迭代

第一版很粗糙,上线后开始迭代。我们很快添加了答题活动时间轴,修复各种 bug 提高稳定性,把支持应用做成了下发配置。配置是个 JSON 文件,放在 GitHub 静态网页上。上线约三周后我们才在关于页面放了一个 QQ 群,吸收热心用户进群获取反馈。事后证明这个群的作用很大。

差点放弃

我们迭代了一段时间,QQ 群也进来了一些用户。但是此时我们动摇了,犹豫是否继续做下去。原因是不确定这东西是否有价值,未来是否能够盈利。我们在 QQ 群里发起了一个投票,询问用户觉得我们的产品怎么样,是否希望我们继续开发。大约只有十个人投了票,但有点意外的是大部分用户觉得产品用处很大,要求继续开发。这给了我们很大的动力,我们决定继续做。现在看当时那些用户格外宽容,原因之一是产品当时完全免费。从实际角度讲,激励开发者的有两件事:一是产品有盈利,持续产生收入;二是虽然不盈利,但是有用户用,有用户叫好。

打通支付渠道

我们决定继续做。考虑到工具应用的特点,我们没有使用广告变现,而想走应用内付费这条路。付费就需要接入支付渠道。最常见的应用内微信支付、支付宝支付个人无法申请,需要有公司。国内主流市场都开始要求软件著作权,对上架某些分类的应用也要求公司资质。在第一版上线两个月后,我们拿到了公司营业执照。然后去银行开户,因为没经验中间浪费了一些时间,等到最后接入支付宝又过去了两个多月。在接入支付前靠捐赠和开通 QQ 群付费入群有了一点收入。先后接入支付宝、微信支付后便关闭了其他收费渠道。此时答题热度已经衰退。在调整了首充价格和做了一些优化之后,不再更新。一直到现在每月能产生约 200 元被动收入。

技术细节

这款产品的核心功能是在用户参与答题时,尽可能实时获取到题干和选项文本,调用搜索引擎,根据搜索结果推荐答案。早期我们使用系统 AccessibilityService 获取题干和选项。此方案的优点是速度快,缺点是需要单独适配每一款应用。适配工作量巨大而且应用升级后可能需要重新适配。并且两种情况下无法获取:一、答题界面是网页;二、开发者专门调用相关 API 禁用了辅助服务。随着时间的推移我们发现越来越多的应用开始禁用辅助服务。不得已我们变更了方案,改为使用系统 MediaProjection API 截屏然后调用 OCR 服务识别出文本。获取文本方案的调整伴随着交互的调整,使用流程变得比原来复杂。我们使用的百度文字识别服务,免费账户的 QPS 为 10。看着已经不低了,但是我们的使用场景存在天然的高并发——大部分答题活动在整点同时开始。即使很少的用户数仍然会超过额定 QPS,导致识别失败从而无法获得推荐答案。[1]

后端使用阿里云,由一个 ECS 加 RDS 组成。ECS 上跑 Golang 写的应用程序,RDS 使用 MySql。最后迭代的结果,用户使用微信登录后,服务器下发百度密钥,端上调用百度 API 识别出文本后再调用搜索引擎接口。用户可以购买时长或者次数。时长好处理,次数需要设计一个能够容错的上报方案。这个方案要能够处理单次使用、本地缓存、上报失败重试、 有失败请求待上报时用户又购买更多次数等情况。一个简单的与后端同步的原子计数器不能满足这些要求。最后的方案完美解决了上述问题并且足够简单。[1]

思考

答题是 2018 年初的热点。热点的特征是来的快去的也快。下图是『答题』的百度搜索指数。

trend

可以看到指数从2018年1月开始几乎直线攀升到最高峰近 4000 点,然后迅速回落。围绕热点快速推出产品抢占市场,获取大量流量并变现,是一种常见的商业套路,俗称『蹭热点』。蹭热点的产品,速度是第一位。我们的产品上线、迭代速度还算可以。但是因为没有注册过公司,等到接入支付,热度已消退,流量红利丧失殆尽。如果快速接入支付,收入估计至少翻倍,因为流量高一个数量级。

有很多开发者想做自己的产品,真正做出盈利产品[2]的人少之又少。从在公司上班给公司做产品盈利,到自己做产品盈利,中间似乎隔着一条鸿沟。如何跨越?这中间作为开发者最需要补齐的是『用户思维』。从用户的角度去想问题。首先要让你的产品触达尽可能多的用户。差不多的实现原理,做一个命令行工具发布到 GitHub 上,和做一个应用发布到市场,前者只能触达开发者,后者触达的是所有智能手机用户。其次要想办法了解你的用户。我们的产品用户大多在三线以下城市,因为一二线城市的人太忙,没空参与答题。而且这些用户大部分并不熟悉互联网。前期没有服务器的时候,我们的应用需要用户自己注册百度账号才能使用 OCR。然后我们发现很多用户完成不了这个步骤。有些用户连注册百度要填的电子邮箱是什么都不知道,对这个东西没概念。此时我才深刻理解为什么微信默认不提供电子邮箱登录。作为国民级应用,门槛必须尽可能低,你会发短信就会用微信。要求邮箱就是把过亿用户拒之门外。

注释

  1. 红字内容打赏后可见。免费部分已包含核心内容。如想查看全部内容满足自己的好奇心,请打赏支持。打赏后可提问。已打赏请登录
  2. 盈利不是评判产品成功的唯一标准,具体见我这篇博客
打赏作者