建立開發者生態系統策略#
打造一個可擴展、設計良好的 API 是好的起步，但如果你希望開發者實際使用它，光是「發布」遠遠不夠。「只要你做出來，他們就會來（If you build it, they will come）」是一個常見的誤解——很多公司發布了 API，卻不明白為什麼開發者遲遲不來使用。
圍繞開發者與合作夥伴建立生態系統的專業領域稱為開發者關係（Developer Relations）。
開發者生態系統（Developer Ecosystem） 就如同自然界的生態系統，是由一群在同一個平台、技術或 API 上協作、依賴、甚至競爭的成員所組成的虛擬系統。
一些最成功的開發者生態系統具有自組織特性：
- Google / Android — 擁有龐大的開發者生態系統與社群
- iOS — 開發者積極參加聚會、彼此合作
- Microsoft — 具備多面向的開發者與合作夥伴生態系統
開發者平台與 API 已經無處不在。它們讓開發者更高效、利用現有基礎設施、並使產品和服務具備未來適應性。隨著 API 經濟持續成熟，僅僅提供一個 API 已經不夠——公司必須提供真正卓越的開發者體驗，並跟上開發者的需求。
— Romain Huet，Stripe 開發者關係負責人
開發者、開發者、開發者#
開發者能用 API 做出偉大的事情：
- 擴展與改善公司產品 — Slack 應用程式讓 Slack 變得更好
- 成為你的客戶 — Google Cloud Platform 就是好例子
- 推動平台採用 — iOS 因為擁有數百萬個 App 而變得流行
許多公司會在意識到自己不可能把所有東西都做完之後，才得出需要生態系統的結論。Microsoft 無法建立所有的 SharePoint 擴充功能；Google 和 Apple 無法自己寫完所有行動 App；Slack 也無法建立所有的 Bot 和整合。這些公司開放 API 給開發者，是為了延伸產品的價值。
另一種模式是 API 作為主要營收手段。像 Stripe 和 Cloudinary 這樣的公司，API 是業務的核心支柱——他們販售使用權或對特定交易收取費用。
開發者的定義#
本書中的「開發者」是泛稱——指那些有技術能力使用 API 的人。他們可能自稱為 IT 人員、設計師、技術導向的商務人士，或任何工程師的變體。
業餘愛好者（The Hobbyist）#
- 屬於早期採用者，但不一定以專業角度使用 API
- 從玩弄 API、建立範例、尋找邊界案例中獲得樂趣
- 通常急於採用新功能，並快速表達意見與回饋
業餘愛好者的使用案例可能不是你建構 API 的目標。如果你做了一個人臉辨識 API，業餘愛好者會拿來辨識貓狗。雖然有趣，但可能讓你浪費時間與資源在低影響力的邊緣用途上。
黑客（The Hacker）#
又稱早期採用型專業開發者或創業者，是試圖將 API 投入專業使用並從中獲利的開發者。
- 被創新所驅動，追蹤 Twitter、Medium 和 Product Hunt 尋找新技術
- 可能因為「很酷」而試玩某項技術，但始終會將其投入實際應用
- 技術能力高，通常能應對陡峭的學習曲線，不需要 SDK、除錯工具或所見即所得（WYSIWYG）工具
商務導向的技術使用者（The Business-Focused, Tech-Savvy User）#
這類使用者只關心一件事：解決他們的使用案例。他們可能不認為自己是開發者。
- 可能是用股價 API 做 Excel 計算的財務人員
- 可能是寫腳本自動化工作流程的 IT 人員
- 可能是試圖為公司建網站的商務人士
這類使用者對**破壞性變更（Breaking Changes）**極度敏感。使用 API 不是他們的日常工作，他們不會每天追蹤你的 API 動態，但仍然需要方便的工具與服務。
這類受眾對許多公司而言非常重要，因為其規模遠大於純開發者族群。如果你的目標是這群人，教育與賦能的方式必須截然不同。
專業開發者（The Professional Developer）#
- 將你的技術視為達成目標的手段
- 會基於產品適配度與成熟度來評估你的 API
- 會與競爭對手比較，選出最合適的方案
- 願意為 API 付費，因為它解決了原本難以處理的問題
- 期待新功能但不喜歡破壞性變更，因為重寫程式碼的成本很高
- 時間有限，非常重視能加速開發的工具與服務
更多類型#
開發者受眾還有很多變體：
- 企業開發者 — 為組織建立內部解決方案
- 獨立軟體供應商（ISV） — 使用你的 API 建構軟體
- 承包商 — 負責實作某個規格
- 硬體開發者、領域特定開發者（如手機遊戲開發者）等
了解你的受眾、他們想用 API 實現的使用案例，以及他們偏好的溝通方式至關重要。隨著 API 成熟，你需要更深入地理解開發者受眾及其各個區隔。
建立開發者策略#
建立一個有生產力的開發者策略有幾個基本階段：
| 階段 | 名稱 | 說明 |
|---|---|---|
| 1 | 開發者分群（Segmentation） | 確定你的受眾是誰，定義其屬性 |
| 2 | 提煉價值主張（Value Proposition） | 闡明開發者為何應使用你的 API |
| 3 | 定義開發者漏斗（Developer Funnel） | 列出開發者從不知道到成功使用的各個步驟 |
| 4 | 繪製現狀與未來狀態 | 從目前的狀態到你希望達到的目標 |
| 5 | 制定戰術（Tactics） | 規劃步驟、資源和行動，推動開發者通過漏斗 |
| 6 | 建立衡量指標（Measurements） | 驗證戰術是否有效 |
開發者分群#
是時候從對開發者類型的描述性案例，轉向更具體的定義了。問問自己：你的受眾是誰？ 以下是需要考慮的關鍵屬性：
身份認同（Identity）
開發者如何定義自己？前端？後端？全端？行動？企業？細緻的身份認同也很重要——例如 iOS 開發者常與其他 iOS 開發者在聚會和活動中互動，但與 Android 開發者的交流則較少。
開發者熟練度（Developer Proficiency）
使用你的 API 需要多高的技能門檻？有些 API（如 AR、AI 類）需要較陡峭的學習曲線；有時 API 本身簡單，但 OAuth 和安全設定卻很複雜。
偏好平台（Platform of Choice）
行動開發者與 Web 開發者截然不同，Xbox / PlayStation 遊戲開發者也與雲端後端開發者大相逕庭。開發者傾向以平台來定義自己——理解這一點有助於你在他們所在的地方與他們互動。
偏好的開發語言、框架與工具
了解開發者每天使用的工具與服務有助於你決定：
- 應投資哪些 SDK
- 是否該為特定 IDE 建立插件
- 是否該為某個熱門開源框架做出貢獻
常見使用案例與任務
即使你的 API 非常通用，也必須了解開發者試圖完成的常見使用案例。這有助於：
- 建立對開發者的溝通訊息
- 找到擴展 API 或建構額外工具的靈感
- 如果你不知道開發者在做什麼——走出去問他們！
偏好的溝通方式
- 是否追蹤 Twitter 上的 API 動態？
- 偏好電子郵件通知？
- 在活動中聽聞新技術？
- 閱讀行業媒體？
你需要建立日常溝通管道，並規劃在緊急情況下能快速觸及開發者的途徑。
市場規模與地理分佈
- 目前有多少開發者？可觸及的市場有多大？
- 需要繪製全球重要的開發者中心分佈圖
- 這些資訊影響你是否需要在地化內容或舉辦全球活動
市場規模可能很難或很昂貴去取得。在早期，一個有根據的估算通常就足夠了，隨著時間推移再進行更深入的分析。
案例：Slack 的開發者分群分析
以下是 Slack 開發者受眾分群的範例：
| 屬性 | 描述 |
|---|---|
| 身份認同 | 企業開發者（又稱 IT 開發者、企業工程師、內部開發者） |
| 開發者熟練度 | 擅長實作商業流程，但不一定熟悉 Slack 平台。習慣使用 SDK 和框架而非原始 API |
| 偏好平台 | Windows 和 Linux 腳本、Web 開發者、SharePoint 或 Confluence |
| 偏好語言與框架 | Java、.NET。許多人使用 AWS（如 AWS Step Functions），部分用 Slack 做報表整合，有些正在探索 Node.js |
| 常見使用案例 | 內部用途——審批流程（請假、報帳、一般性）、報表，以及在 CRM 和工單系統中查找客戶。主要挑戰：企業開發者承受來自業務端的大量壓力，而現有方案（如 SharePoint）被認為既笨重又不友好 |
| 偏好溝通方式 | 偏好透過電子郵件收到重要 API 變更通知。追蹤 Slack 的 API 部落格但不追蹤 Twitter。參加的主要活動由 Amazon、IBM 等企業軟體供應商舉辦 |
| 市場規模與分佈 | 截至 2018 年 5 月，Slack 有超過 20 萬名每週活躍開發者在平台上建構（含內部整合）。主要地理分佈：舊金山、紐約、東京、柏林、倫敦、西雅圖、班加羅爾 |
Slack 實際上有兩類開發者：應用程式開發者（為其他團隊建構 Slack App）和企業開發者（為自己的 Slack 團隊建構內部整合）。每個受眾群體可能非常不同，需要不同的策略。
許多新創公司認為「所有人」是一個好的分群。並非如此！ 即便是最廣泛使用的 API 也會對使用者進行分群。將開發者受眾定義為「所有開發者」並不具生產力。
提煉價值主張#
你需要寫下 API 的核心價值主張（Value Proposition）：
- 開發者為何應使用你的 API？用途是什麼？
- 你的競爭優勢是什麼？開發者為何該在意？
不同平台會強調不同的優勢：
- Google — 強調 Android 的龐大分發量與用戶規模
- Apple — 強調 iOS 的強大變現能力與用戶付費意願
一些 API 提供更簡單或更具成本效益的做事方式：
- Cloudinary — 幫助開發者即時建立縮圖和調整圖片大小
- Google Vision API — 提供方便取用的複雜影像辨識功能
價值主張範例：
| API | 價值主張 |
|---|---|
| Stripe API | 提供更簡單、更標準的方式接收線上支付 |
| YouTube API | 允許你在網站中嵌入影片播放器或提供 YouTube 搜尋功能 |
| SoundCloud API | 讓你開發允許使用者上傳和分享歌曲的應用程式 |
價值主張不等於行銷定位（Marketing Positioning）。行銷定位關注消費者對品牌或產品的感知，而價值主張應該是具體的，且是開發者真正在意的。此階段用詞不重要，實際價值才重要。
常見錯誤：
- 建立太多低價值陳述（如「在某些情況下稍便宜一點」、「在 X 上稍微好用一些」）
- 應力求為開發者帶來大而有說服力的價值
你提供給基於你的 API 進行建構的人的價值應該是顯著的。這個價值不必直接可以貨幣化，但 API 必須在某些方面比第三方開發者或合作夥伴自行建構來得更好、更快或更便宜。
— Chris Messina，Uber 開發者體驗負責人
定義開發者漏斗#
開發者漏斗（Developer Funnel） 是一個簡單但有效的概念，描繪開發者從不知道你的 API 到成為熟練且成功用戶的旅程。
Figure 8.1: The developer funnel
在漏斗的每一步，開發者人數越來越少。你的工作是讓更多開發者進入漏斗，然後推動他們向下移動。各階段說明如下：
認知（Aware）
- 建立開發者認知是一個持續而重要的第一步
- 讓開發者知道你的 API 及其獨特、有說服力的價值主張
- 即使擁有成熟且成功 API 的組織仍持續確保對開發者社群的可見度
- 例如 Twilio 的創辦人仍在矽谷投放廣告
熟練（Proficient）
- 開發者需要知道如何使用 API
- 可參考如何建立簡單「Hello World」應用程式的指南，或參加完整的培訓與認證課程
- 目標：開發者能根據你的文件化最佳實踐輕鬆使用 API
建構中（Building）
- 開發者正在積極使用 API 建構應用程式
- 程式碼可能尚未進入生產環境，但 API Key 正被使用中
- 這個階段的重要性在於，它證明了你所闡明的價值主張是正確的
成功（Successful）
- 對每個開發者而言，「成功」的定義可能不同
- 可能意味著從 API 使用中獲利、達到某個使用閾值、在生產環境中處理交易，或與其他系統整合
- 你需要為你的 API 和開發者受眾定義什麼是成功
漏斗指標#
不同的開發者漏斗有不同的里程碑。你需要建立自己的漏斗並定義其步驟。以下是一些指標範例：
| 面向 | 指標範例 |
|---|---|
| 認知 | 進入 API 網站、訂閱電子報、參加聚會 |
| 熟練 | 完成實作練習、建立黑客松專案、建立開源範例、執行「Hello World」範例 |
| 使用 | 建立並使用 API Key、部署並修改範例應用程式、建立並運行預生產環境 |
| 成功 | 產生營收、將程式碼部署至生產環境、獲得用戶、建立商業模式、每天活躍使用 API 150 次 |
繪製現狀與未來狀態#
了解了漏斗與指標之後，你需要知道每個指標的實際數字。
範例：圖片濾鏡 API 的關鍵指標狀態報告
| 面向 | 每月持續狀態 | 累計 |
|---|---|---|
| 認知 | 每月 500 名不重複用戶造訪 api.imagefilters.com | 累計 10,000 名不重複開發者 |
| 熟練 | 200 名開發者完成入門階段 | 累計 5,000 名不重複開發者 |
| 使用 | 50 名開發者升級至 Pro 版本 | 累計 1,500 名付費開發者 |
| 成功 | 新開發者處理 50 萬張圖片 | 累計處理 2.5 億張圖片 |
有些衡量指標直接連結到開發者數量，有些則衍生自開發者使用量。有時你可以在不獲取新開發者的情況下提升數字——透過與現有開發者合作，讓他們更多地使用你的 API。
接下來需要加入兩個額外維度：
- 市場潛力（Market Potential） — 每個指標的長期目標是什麼？
- 短期目標（Short-term Targets） — 短期內要達成什麼？
範例：含短期目標與市場潛力的關鍵指標
| 面向 | 每月持續狀態 | Q2 目標 | 市場潛力 |
|---|---|---|---|
| 認知 | 每月 500 名不重複用戶造訪 | 成長至 700 | 50 萬開發者 |
| 熟練 | 200 名開發者完成入門階段 | 成長至 400 | 25 萬開發者 |
| 使用 | 50 名開發者升級至 Pro 版本 | 成長至 70 | 15 萬開發者 |
| 成功 | 新開發者處理 50 萬張圖片 | 成長至 70 萬 | 5 萬開發者 |
制定戰術#
知道了現狀與目標之後，是時候規劃將開發者推過漏斗各階段的戰術步驟了。
認知戰術範例：
- 建立 API 文件網站
- 執行 Facebook 廣告活動將開發者導向網站
- 製作開發者喜愛的周邊商品，印上 API / 平台 Logo
- 在大型開發者活動設攤位
- 為與 API 相關的熱門開源專案做貢獻
- 在行業媒體發表文章
- 執行 Product Hunt 推廣活動
- 在活動中演講
熟練戰術範例：
- 撰寫入門教學與 API 各面向的教程
- 建立動手做的程式碼實驗室（Code Labs）
- 建構程式碼範例、模板和 SDK
- 舉辦黑客松（Hackathon）
- 建立開發者認證計畫
- 撰寫白皮書
- 舉辦線上研討會（Webinar）
使用戰術範例：
- 建立開發者可管理 API 使用量的註冊系統
- 建立優惠券或免費層級系統以激勵生產環境使用
- 與合作夥伴進行設計衝刺（Design Sprint）以建構產品級 API 使用
- 為新 API 功能運行 Beta 計畫
- 執行回饋計畫以捕捉改善使用體驗的方法
成功戰術範例：
- 與精選開發者共同行銷
- 與成功開發者共同撰寫內容，分享使用 API 的技巧
- 在開發者網站新增最佳實踐專區
- 舉辦 API 最佳化工作坊
- 建立頂尖開發者計畫，表彰成功開發者及其成就
容易混淆戰術與其對應的漏斗階段。例如，有些人可能認為可以透過黑客松達成開發者成功，但黑客松實際上促進的是開發者熟練度。確保你做的是正確的行動以推動正確的指標。
季度計畫範例#
將目標對應到戰術的高層級季度計畫範例：
- 提升開發者認知至 5,000 名新開發者
- 戰術：執行開發者行銷活動
- 戰術：在主要媒體發表兩篇文章
- 提升開發者熟練度至 1,000 名新開發者
- 戰術：在開發者活動中舉辦兩場工作坊，每場 300 人
- 戰術：建構新的開發者網站首頁，改善入門的行動呼籲（CTA）
- 戰術：建立五個描述常見使用案例的教程
- 推動 40 名新開發者在生產環境使用 API Key
- 戰術：與業務團隊合作找出 20 個候選人，與他們進行設計衝刺
- 戰術：為新的 Thumbnail 功能運行 Beta 計畫，涵蓋 20 個合作夥伴
- 將圖片處理 API 呼叫量提升至 15 萬次
- 戰術：與前五名開發者合作增加其 API 使用量
- 戰術：與兩位成功使用 API 的開發者合寫文章
許多公司使用 OKR（Objective Key Results，目標關鍵成果） 來結構化這些計畫。Google 等組織強烈推薦這種格式並認為其非常有效。
當你首次建構 API 時，計畫應該非常直接：問自己「開發者在使用 API 之前必須擁有什麼？」——大概是文件、基本範例和開發者登陸頁。隨著時間推移，這些基本項目完成後，再問「開發者應該擁有什麼才能熟練且成功地使用 API？」
建立衡量指標#
將開發者活動連結到衡量指標是最困難的挑戰之一。關鍵在於：
- 在執行每個活動前，認真思考你想影響的指標是什麼
- 在每個活動結束後，衡量你是否達到了目標
範例：
- 舉辦活動時 → 衡量實際完成動手實驗的開發者數量，追蹤該群體是否成為活躍開發者
- 設計衝刺後 → 衡量合作夥伴是否實際實施了衝刺的建議，從而提升 API 使用
範例：開發者活動衡量報告
| 衡量項目 | KPI | 目前 | 目標 | 活動 | 預期影響 | 實際結果 |
|---|---|---|---|---|---|---|
| 開發者認知 | 網站進入量 | 10,000 | 100,000 | 在 SXSW 演講 | 5,000 名新開發者 | 7,000 |
| 熟練度 | Token 建立數 | 5,000 | 10,000 | 舉辦技術網路直播 | 5,000 個新 Token | 3,000 |
建立繁榮的生態系統就像園藝。你無法確定哪個活動在特定情況下會成功。透過衡量、迭代和改善，你可以學到什麼有影響力、什麼沒有。
結語#
建立開發者策略的核心在於知道要衡量什麼，以及哪些行動會影響你的衡量指標與目標。遵循本章所描述的流程將幫助你清楚定義開發者策略，其餘的就是建構與執行。
你需要了解你的使用者、他們的需求和使用案例，並據此調整 API。保持與使用者之間開放且透明的溝通管道至關重要——這對於獲取回饋和改善 API 不可或缺。你需要培育你的生態系統，投入大量努力使其成長和成功。
— Ido Green，Google 開發者倡導者