一句话总结

如何让 TinyPilot 的销售保持可持续？

亮点

• TinyPilot 营收创下 7.4 万美元的历史新高。
• 我正在探索软件授权的最佳方案。
• 我仍在寻找一个能让我真正喜欢的 Web 框架。

目标完成度

每个月初，我都会定下当月想要完成的目标。以下是本月目标的完成情况：

创建可独立安装的 TinyPilot tar 包

• 结果：已完成可用的 tar 包
• 评分：A

TinyPilot 的安装流程随着时间推移变得越来越复杂。它需要从多个代码仓库拉取代码，还依赖大量第三方组件，理清这些依赖关系也变得愈发困难。

我们正在重构安装流程，把所有内容整合到单个 tar 包中。这样就能把所有依赖集中到一个清晰的位置。目前我们正在将免费版 TinyPilot 迁移到新的更新系统，随后也会迁移 TinyPilot Pro。

完成关于 TinyPilot 网站改版的长篇博文初稿

• 结果：已完成初稿
• 评分：A

我本以为写这篇博文会很轻松，因为在之前的每月回顾里已经写过很多相关经历，但长篇博文的写作风格完全不同，所以大部分内容仍需重写。初稿有 5200 字，大约是我平时文章的两倍，正在设法精简。

将付费搜索广告的 ROAS 提升至 2.0

• 结果：ROAS 从 1.79 提升至 1.99
• 评分：A

与 TinyPilot 合作的数字营销自由职业者将广告支出回报率提升到了 1.99。我估算，每投入 1 美元广告费，大约能赚到 0.55 美元的利润。

遗憾的是，并不能简单地把广告预算翻倍就让销量翻倍，因为想要占据更高的搜索展示份额，成本也会随之上升。尽管如此，我对目前的表现已经很满意，我们也在继续探索新的营销渠道。

TinyPilot 数据一览

这是 TinyPilot 创下 最高（更新：第二高，见下方说明）营收的月份。而更令人兴奋的是，6 月本身其实平淡无奇。

以往所有创纪录的月份都与某些一次性事件有关，比如新品发布或获得好评。但 6 月实际上就是平平淡淡、什么特别的事都没发生的一个月。而这恰恰是好事！这说明我们无需依赖外部事件来推动销售，现有做法本身就是可复制的。

网站访客数相比上月有所下降，但只是因为 5 月受上一篇博文影响出现了异常偏高。总体访问量仍显著高于第一季度。我把访客的增长归功于新的营销活动。

TinyPilot Pro 用户如何验证授权？

我一直希望 TinyPilot 的软件本身就能实现自给自足，而不是完全依赖新硬件的销售。用户购买 TinyPilot 硬件时会免费获得我们的高级软件，但在一定期限之后，需要有一种付费方式来支撑后续的软件维护。

早在 2020 年 12 月，我就发布了付费版本 TinyPilot Pro。最初计划上线时就加入授权密钥校验，但我搁置了这个功能，心想等到 2021 年底首批授权开始到期时再做也不迟。

如今 18 个月过去了，TinyPilot Pro 依然不会校验用户的授权是否有效。我估计约有三分之一用户的授权已经过期，只是自己还没意识到。

我计划在用户升级到最新版本时加入有效授权检查。这样，如果用户对当前版本满意，就可以一直用下去；如果想用最新功能，就需要在首年授权到期后为软件更新付费。

要校验用户是否有权下载最新更新，我需要一种方式，让用户能向更新服务器证明自己拥有有效的 TinyPilot Pro 授权。

以下是正在考虑的几种方案：

设备 ID

TinyPilot 运行在树莓派上，每台树莓派都有一个硬件序列号，可以这样获取：

$ cat /proc/cpuinfo | grep Serial | cut -d ' ' -f 2
10000000ecf8821b

我们可以在向客户发货前记录每台树莓派的设备 ID。用户尝试升级时，只需检查其设备 ID 是否已预先登记，再据此激活。

• 优点
  • 对用户来说很省事——不会丢失或忘记设备 ID
• 缺点
  • 需要我们维护所有设备 ID 的记录
  • 给设备生产流程增加一道工序
  • 对于在我们开始记录设备 ID 之前就已购买的用户，仍需另寻解决方案

订单信息

目前，当客户想要下载官方 TinyPilot 镜像时，我们会要求提供订单号和购买时关联的邮箱地址：

我们可以在 TinyPilot 网页应用中沿用同样的逻辑来控制升级权限。

• 优点
  • 最大程度减少管理工作，因为无需额外维护密钥或设备 ID，现有的订单信息已经足够
  • 适用于所有老用户，因为我们已存有他们的订单信息
• 缺点
  • 终端用户并不总是清楚自己的订单信息
    • 有时是通过经销商购买，或是公司里其他人下的单
  • 每新增一个销售渠道（如 Amazon、eBay），都得为该渠道单独编写查询订单信息的代码

印刷的激活码

我们可以生成一组激活码，类似于激活 Microsoft Windows 或 Office 的方式（例如 1F9PA-V4JD5-4JPOM）。将激活码打印出来随设备附送，用户输入激活码即可证明其拥有授权。

• 优点
  • 无论用户是直接从我们这里购买，还是通过 Amazon、eBay 等渠道购买，方式都一样
• 缺点
  • 用户很容易弄丢或忽略订单里那张印有激活码的纸条
  • 对于在我们开始发放激活码之前购买的用户，仍需另寻解决方案

将授权内置于软件中

我们会为客户的设备刷写镜像，因此理论上可以在每台设备上预置一个唯一的密钥文件来授予 TinyPilot Pro 授权。

• 优点
  • 无论用户从哪个渠道购买，方式都一样
  • 用户不会丢失密钥
• 缺点
  • 实现起来极其不现实且复杂
    • 我们得为每位客户生成定制的镜像，并确保客户始终安装的是属于自己的那个镜像
  • 对于在开始内置密钥之前购买的用户，仍需另寻解决方案

组合方案

我更倾向于采用一种混合方案：尽可能使用最自动化的方式，同时为边缘情况提供更手动的备用方式：

1. 检查设备的硬件 ID 是否已预先登记。
2. 如果设备未预先登记，则提示用户输入订单号和邮箱，以便我们自动查找订单。
3. 如果通过订单号+邮箱仍无法自动找到订单，则请用户联系客服，由我们手动开通授权。

在我能想到的方案中，这一种似乎最不容易出错，也给终端用户带来的负担最小。

放弃幻想吧，踏入亚马逊卖家平台的人

很长一段时间以来，我一直在考虑把 TinyPilot 放到亚马逊上销售，因为很多人把亚马逊当作一站式网购平台。我一直有些抵触，因为注册成为亚马逊卖家听起来就又痛苦又繁琐。真正走完流程后，我可以说，比我预想的还要痛苦繁琐。

足足花了三周，我才得以在亚马逊上架产品。每隔几天，亚马逊就会告诉我需要新的审批，或是需要我就身份或产品提供新的证明。

首先，亚马逊要用我的驾照和信用卡号来验证身份。接着，我还得参加实时视频通话，手持驾照贴在脸旁并弯折驾照，以证明它不是打印件。

然后，亚马逊又以无法验证我的信用卡为由冻结了账户一天。而这张信用卡已经在亚马逊存档一年，我用它在亚马逊消费了约 5 万美元。

接着，亚马逊再次冻结账户，以便核实我是否有权使用“TinyPilot”品牌名。我向他们提供了自己是 TinyPilot, LLC 所有者的证明，并发送了产品侧面印有“TinyPilot”字样的照片。

他们说会在三天内审核，实际却花了 10 天。结论是，我的照片不足以证明“TinyPilot”已永久固定在产品上……

于是，我重新发送了更聚焦于品牌名的照片，这才终于通过审核。

新问题是，在亚马逊搜索“tinypilot”时，TinyPilot 根本不会出现在搜索结果中：

更奇怪的是，亚马逊自己的自动补全建议却全都明确指向我的产品：

即便是搜索“tinypilot kvm over ip”，我的产品也要翻到第二或第三页才出现。

最后我只好在亚马逊上投放广告，这才带来了最初的几笔销售。

希望最艰难的上架阶段已经过去，我会坚持下去，看看随着在亚马逊上积累评价，销量是否会有所增长。

亚马逊的顾客是另一个物种

在亚马逊上购买的顾客，其预期似乎与直接在 TinyPilot 官网购买的顾客大相径庭。

第一位通过亚马逊下单的顾客留言要求“用 UPS 2 日达发货”，但我们并不提供 UPS 配送。我回复了留言，却不知下一步该怎么做。是取消订单并冒着被亚马逊处罚的风险？还是等顾客回复却可能因延迟发货被处罚？我最终等了一天未获回复后取消了订单。随后该顾客又下了同样的订单，我们便用 USPS 发货，也没有再收到投诉。

几天后，另一位亚马逊顾客发来消息，说她对产品还没送达“非常失望”，因为她付了 10 美元加急运费。我查看物流发现，我们已通过 USPS Priority 提前一天发货，只是 USPS 配送延误了。这显然非我们所能控制，但我怀疑顾客并不清楚从第三方卖家购买和直接从拥有自有配送体系的亚马逊购买之间的区别。

直接下单的顾客有时也会有类似投诉，但频率远不及在亚马逊上看到的那么高。

仍在寻找让我心动的 Web 框架

正如我在上次更新中提到的，我正在重建 WanderJest——一个用于发现现场喜剧演出的工具，该项目在疫情初期被我搁置了。

在尝试了 Angular、Vue 等 SPA 框架多年后，我正用 Go + VanillaJS + SQLite 这一“回归基础”的技术栈重写 WanderJest。Chris Ferdinandi 在他的文章 “SPAs were a mistake.” 中，道出了我的不少困扰。

我比以往尝试过的任何 Web 框架都更喜欢现在的技术栈，但仍谈不上热爱。大部分时间都花在了枯燥的胶水式整合工作上。

例如，为了让用户能在 WanderJest 上创建包含照片、简介和社交网络链接的个人资料，我需要：

1. 创建用于创建和编辑个人资料的网页表单
2. 创建用于接收用户提交的服务端接口
3. 创建用于表示个人资料信息的数据模型
4. 编写用于在数据存储中读写数据的序列化/反序列化代码
5. 编写用于向数据存储插入和检索数据的 SQL 查询
6. 创建用于渲染个人资料信息的网页界面

这比我用过的其他框架步骤要少，但这些活真的很枯燥。

Phoenix LiveView 已经在我的关注清单上待了一年。这正是 fly.io 那些酷炫家伙们热衷的东西。Phoenix 的部分卖点就是能自动化上面列出的许多重复性任务。Chris McCord 做过一个很棒的演示，用 Phoenix 在 15 分钟内构建了一个简易的 Twitter 克隆。

与此同时，我也担心自己陷入“这山望着那山高”的心态，不断在不同框架间跳来跳去，却没有把任何一个技术栈真正学精。也许一个折中的选择是 Ruby on Rails，我觉得它的开发者体验与 Phoenix 相似，但生态更为成熟。

收尾

完成了什么？

• 开始在亚马逊上销售 TinyPilot
• 完成了一篇全新长篇博文的初稿
• 完成了 TinyPilot 安装包的生成流程

经验教训

• 亚马逊卖家平台比看起来还要令人不快。

下月目标

• 确定 TinyPilot 授权管理的最终方案。
• 将 TinyPilot Community 迁移至新一代更新系统。
• 发布关于 TinyPilot 网站改版的博文。