一句話總結

該如何讓 TinyPilot 的銷售維持永續？

重點提要

• TinyPilot 營收創下 7.4 萬美元的歷史新高。
• 我正在思考軟體授權的最佳做法。
• 我仍在尋找一個能讓我真心喜歡的網頁框架。

目標成績

每個月月初，我都會設定當月想完成的目標。以下是這個月的達成狀況：

建立可用於安裝 TinyPilot 的獨立 tarball

• 結果：我們現在已有可運作的 tarball 套件
• 成績：A

TinyPilot 的安裝流程隨著時間變得愈來愈複雜。它會從多個儲存庫和第三方依賴套件拉取程式碼，也愈來愈難掌握這些關聯。

我們目前正透過將所有東西整合進單一 tarball 來徹底改造安裝流程。這能將所有依賴集中到清楚的位置。我們正在將免費版 TinyPilot 切換到新的更新系統，之後很快也會遷移 TinyPilot Pro。

完成一篇關於 TinyPilot 網站改版的完整長文部落格初稿

• 結果：已完成初稿
• 成績：A

我原本以為寫這篇部落格會很輕鬆，因為我在回顧文章中已經寫了很多相關經驗，但長文的寫作風格不同，所以還是得大幅重寫。初稿有 5,200 字，大約是我平常文章的兩倍長，所以我正在設法精簡。

將付費搜尋廣告的廣告投資報酬率（ROAS）提升至 2.0

• 結果：ROAS 從 1.79 提升至 1.99
• 成績：A

與 TinyPilot 合作的數位行銷接案者將廣告投資報酬率提升到 1.99。我估計每投入 1 美元的廣告費，大約能賺到 0.55 美元的利潤。

可惜的是，我沒辦法單純把廣告預算加倍就讓銷售跟著加倍，因為當你想搶下更多搜尋曝光時，成本也會跟著墊高。儘管如此，我對目前的表現還算滿意，我們也持續在探索新的行銷管道。

TinyPilot 數據

這是 TinyPilot 有史以來營收 最高（更新：次高，詳見下方說明）的一個月。而令人振奮的是，六月本身其實沒什麼特別之處。

過去所有創紀錄的月份，都和某個一次性事件有關，例如新產品發表或獲得好評。但六月實際上就是個平淡無奇的月份，沒發生任何特別的事。而這正是好消息！這代表我們可以複製現在的做法，不必仰賴外部事件來帶動銷售。

網站訪客數較上個月下滑，但只是因為五月受惠於我上一篇部落格文章而異常偏高。整體訪客數仍明顯高於第一季。我認為訪客增加要歸功於我們新的行銷活動。

TinyPilot Pro 使用者該如何證明自己的授權？

我一直希望 TinyPilot 的軟體本身就能永續經營，無論我們是否持續銷售新硬體。使用者購買 TinyPilot 硬體時會免費獲得我們的進階軟體，但過了一段時間後，必須有個付費機制來支持軟體的維護。

我在 2020 年 12 月推出了付費版 TinyPilot，稱為 TinyPilot Pro。我原本打算在推出時就加入授權金鑰驗證，但後來暫時擱置了這個功能，心想等到 2021 年底授權開始到期時再處理也不遲。

如今 18 個月過去了，TinyPilot Pro 仍然不會檢查使用者是否持有有效授權。我估計約有三分之一的使用者授權已經過期，自己卻沒發現。

我打算在使用者升級到最新版本時，加入有效授權的檢查。這樣一來，如果使用者對現有版本感到滿意，就可以一直用下去；如果想取得最新功能，就必須在最初一年授權到期後，為軟體更新付費。

為了確認使用者是否有權下載最新更新，我需要一種方式，讓使用者能向更新伺服器證明自己擁有有效的 TinyPilot Pro 授權。

以下是目前考慮的幾個方案：

裝置 ID

TinyPilot 運行於 Raspberry Pi 之上，而每台 Pi 都有一個硬體序號，可以這樣取得：

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

我們可以在銷售前先記錄每台 Pi 的裝置 ID。當使用者嘗試升級時，只要檢查其裝置 ID 是否已預先註冊，就能依此啟用。

• 優點
  • 對使用者來說很方便——不會弄丟或忘記裝置 ID
• 缺點
  • 需要我們持續追蹤所有裝置 ID
  • 在裝置製造流程中多一道手續
  • 對於在我們開始記錄裝置 ID 之前購買的使用者，仍需另尋解決方案

訂單資訊

目前，當顧客想下載官方 TinyPilot 磁碟映像檔時，我們會要求提供訂單編號以及購買時使用的電子郵件地址：

我們可以在 TinyPilot 網頁應用程式中沿用同樣的邏輯來管控升級。

• 優點
  • 不需額外記錄金鑰或裝置 ID，因為我們本來就已儲存訂單資訊，可減少管理工作
  • 適用於所有舊客戶，因為我們已有他們的訂單資料
• 缺點
  • 終端使用者不一定知道自己的訂單資訊
    • 有時他們是透過經銷商購買，或是由公司內其他人代為採購
  • 每新增一個銷售管道（例如 Amazon、eBay），就得針對該管道撰寫專門的程式碼來查詢訂單資訊

印製的啟用金鑰

我們可以產生一組啟用金鑰，類似啟用 Microsoft Windows 或 Office 的方式（例如 1F9PA-V4JD5-4JPOM）。金鑰可以印出來並隨裝置附上，使用者輸入該金鑰即可證明擁有授權。

• 優點
  • 無論使用者是直接向我們購買，還是透過 Amazon、eBay 等管道購買，運作方式都相同。
• 缺點
  • 使用者很容易弄丟或忽略訂單中附的那張紙本金鑰
  • 對於在我們開始發放啟用金鑰前購買的使用者，仍需另尋解決方案

內建於軟體中的授權

我們會將映像檔燒錄到客戶的裝置上，所以理論上可以在每台客戶裝置上放置一個獨特的金鑰檔案來授予 TinyPilot Pro 授權。

• 優點
  • 無論使用者透過何種管道購買，運作方式都相同。
  • 使用者不會弄丟金鑰
• 缺點
  • 實作上極不切實際且非常複雜
    • 我們得為每位客戶產生客製化的磁碟映像檔，並確保客戶永遠安裝的是屬於自己的那一個映像檔
  • 對於在我們開始內建啟用金鑰前購買的使用者，仍需另尋解決方案

綜合方案

我比較傾向採用混合式做法，盡可能使用最自動化的方式，並在遇到邊緣案例時退回較手動的方式：

1. 檢查裝置的硬體 ID 是否已預先註冊。
2. 若裝置未預先註冊，則請使用者輸入訂單編號與電子郵件，讓我們自動查找訂單。
3. 若無法透過訂單編號＋電子郵件自動找到訂單，則請使用者來信聯繫客服，讓我們手動開通授權。

在我想得到的選項中，這個做法似乎最不容易出錯，也讓終端使用者需要做的事最少。

放棄一切希望吧，踏進 Amazon 賣家市集的人們

很長一段時間以來，我一直考慮在 Amazon 上銷售 TinyPilot，因為許多人把 Amazon 當作一站式購物的首選。我之所以遲遲沒有行動，是因為成為 Amazon 賣家的註冊流程看起來就很痛苦又繁瑣。而在實際走過一遍後，我可以說，它比我想像的還要更痛苦、更繁瑣。

我花了三週才終於能在 Amazon 上架產品。每隔幾天，Amazon 就告訴我需要新的審核，或是要我證明身分或產品的某些資訊。

首先，Amazon 要用我的駕照和信用卡號驗證身分。接著，我還得在一場即時視訊通話中，手持駕照放在臉前並彎折它，以證明那不是列印出來的複印本。

然後，Amazon 因為無法驗證我的信用卡而凍結帳號一天。這張信用卡已經在 Amazon 上留存一年，我用它向 Amazon 採購了約 5 萬美元的商品。

接著，Amazon 又凍結我的帳號，以便驗證我是否有權使用「TinyPilot」這個品牌名稱。我向他們出示了我是 TinyPilot, LLC 擁有者的證明，並寄送了產品側面印有「TinyPilot」字樣的照片。

他們說會在三天內審核，但實際上花了 10 天。結論是我的照片不足以證明「TinyPilot」是永久固定在產品上的……

於是我寄了更聚焦於品牌名稱的新照片，他們這才終於核准了產品。

新的問題是，如果你搜尋「tinypilot」，TinyPilot 根本不會出現在搜尋結果中：

這特別詭異，因為 Amazon 自己的自動完成建議明明全都與我的產品有關：

甚至搜尋「tinypilot kvm over ip」，我的產品也要到第二或第三頁才會出現。

我最後乾脆在 Amazon 上買了廣告，才終於帶來前幾筆銷售。

我希望最艱難的上架階段已經過去，所以我會繼續經營下去，看看隨著在 Amazon 上累積評價，是否能帶動銷售成長。

Amazon 的客人是截然不同的族群

Amazon 客人的期待，似乎與直接在 TinyPilot 官網購買的客人有著極大的不同。

第一位透過 Amazon 下單的客人傳訊息要求「請用 UPS 2-day 出貨」，但我們並未提供 UPS 運送。我回覆了客人的訊息，卻不確定下一步該怎麼做。該取消訂單並冒著被 Amazon 處罰的風險？還是等客人回覆，卻可能因出貨延遲而被 Amazon 處罰？我最後等了一天都沒收到回覆便取消了訂單。之後那位客人又下了同樣的訂單，我們就用 USPS 出貨，也沒再聽到抱怨。

幾天後，另一位 Amazon 客人傳訊說她對產品還沒送達感到「非常失望」，因為她多付了 10 美元選擇快速運送。我查詢物流追蹤，發現我們已經透過 USPS Priority 提早一天出貨，只是 USPS 配送延誤了。這顯然不是我們能控制的，但我懷疑客人並不清楚向第三方賣家購買，與直接向擁有自家配送車隊的 Amazon 購買有何不同。

我們偶爾也會收到直接下單客人的類似抱怨，但頻率遠不及在 Amazon 上看到的那麼高。

仍在尋找讓人喜愛的網頁框架

如同我在上次更新中提到的，我正在重建WanderJest，這是一個用來尋找現場喜劇表演的工具，我在疫情初期暫停了它。

在多年嘗試使用 Angular 和 Vue 等 SPA 框架後，我正以 Go + VanillaJS + SQLite 這種「回歸基本」的技術堆疊重寫 WanderJest。Chris Ferdinandi 在他的文章 〈SPAs were a mistake.〉 中，精準說出了我的部分挫折。

我比過去嘗試過的任何網頁框架都更喜歡現在的技術堆疊，但我仍然稱不上熱愛它。我大部分時間都花在把東西黏合起來的瑣碎工作上。

舉例來說，為了讓使用者能在 WanderJest 上建立包含照片、簡介以及其他社群網路連結的個人檔案，我需要：

1. 建立讓使用者建立與編輯個人檔案的網頁表單
2. 建立用於接收使用者提交資料的伺服器端端點
3. 建立用來表示個人檔案資訊的資料模型
4. 撰寫序列化／反序列化程式碼，以便在資料儲存區中存取資料
5. 撰寫用於在資料儲存區中新增與讀取資料的 SQL 查詢
6. 建立用於呈現個人檔案資訊的網頁介面

這比我用過的其他框架步驟更少，但這些事真的很無聊。

Phoenix LiveView 已經在我的待試清單上待了一年。這是 fly.io 那群酷炫的人正熱衷的技術。Phoenix 的部分承諾就是能自動化我上面列出的許多重複性工作。Chris McCord 做了一個很棒的示範，用 Phoenix 在 15 分鐘內打造出一個基本的 Twitter 分身。

同時，我也擔心自己抱持「別人的草地總是比較綠」的心態，不斷在不同框架之間跳來跳去，卻沒有把任何一套技術堆疊真正學透。也許一個不錯的折衷是 Ruby on Rails，我認為它的開發體驗與 Phoenix 相似，但周邊生態系更為成熟。

總結

完成了什麼？

• 開始在 Amazon 上銷售 TinyPilot
• 完成一篇全新長文部落格文章的初稿
• 完成 TinyPilot 安裝套件的產生流程

經驗教訓

• Amazon 賣家市集比看起來還要更惱人。

下個月的目標

• 確定 TinyPilot 授權管理的最終方案。
• 將 TinyPilot Community 遷移至次世代更新系統。
• 發布關於 TinyPilot 網站改版的部落格文章。