我們來了解跟 Data Lake 非常像的名詞- Data warehouses (資料倉儲)。這兩者都是新聞、企業書籍中常見的數據名詞，但到底有什麼差別呢？我們將從數據結構和使用情境上作比較。

延續 上一篇文章，我們來了解跟 Data Lake 非常像的名詞 - Data warehouses ( 資料倉儲 )。

這兩者都是新聞、企業書籍中常見的數據名詞，但到底有什麼差別呢？

兩者主要差異是

• Data Warehouses： 適合存放結構化數據、經常性要使用的數據
• Data Lake：適合存放非結構化數據、為特殊目的使用

更進一步來看，可以從下方 2 個點切入比較

• 寫入的數據結構 vs 讀取的數據結構 ( Schema on write vs. Schema on read）
• 經常性報告 vs 特殊專案 ( Regular reporting vs. Special projects）

寫入的數據結構 vs 讀取的數據結構

我們來看看「數據結構」上的差異。

Data Warehouses

• 必須先定義數據結構 (Data schema)
• 例如要追蹤使用者資訊，就必須先定義「哪些使用者的資料要寫到 Data Warehouses 的欄位中」。
• 知名產品例如有 Snowflake, BigQuery

Data Lake

• 不需先定義數據結構，可以將任意結構的數據丟進 Data Lake
• 當需要讀取時，再定義「讀取」的數據結構
• 多數的 Data Lake 都會使用 Object ( 物件） 格式進行儲存，把資料當成 1 個 Object 儲存

經常性報告 vs 特殊專案

接著從「使用情境」上作比較。

例如

• 考量速度：想像在整理日報時，今天寫的 query 和昨天寫的 query 會有 90 % 相似，因此使用結構化數據會比較好。
• 考量成本：如果是要為了特定專案(例如產品推薦系統），事前定義詳細結構反而會太花時間，因此可使用非結構化數據。

小結

你可能會好奇說：難道一定要 2 選 1 嗎？

答案是：不用，多數公司會選擇兩者併用。

重點是「如何有效率地同時使用這兩個工具」。

在 Saas 產業中，許多新創公司會先從 Data Warehouses 開始，接著再投資 Data Lake 來收集非結構化的資料。

以上就是企業中常見的 Data Lake 和 Data Warehouses 的解釋。

這篇文章 企業中常見名詞，Data Lake 和 Data Warehouses 的差別是什麼？｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在軟體公司工作，如果你的公司有數據團隊，或多或少都會聽過 Data Lake (資料湖) 這個名詞。但 Data Lake 是什麼呢？這篇文章打算用深入淺出的方式說明。

在軟體公司工作，如果你的公司有數據團隊，或多或少都會聽過 Data Lake（資料湖）這個名詞。

但 Data Lake 是什麼呢？這篇文章打算用深入淺出的方式說明。

Data Lake 的定義

Data Lake 是無結構化存放數據的地方 ( unstructured place to put data )。

主要是為了

• 長期儲存數據 ( long term storage)
• 不定時的查詢數據 ( infrequent querying)

為什麼需要 Data Lake?

為什麼企業需要建置 Data Lake 呢？主要有 3 個原因

• 企業正在收集比以前還要多的數據，但不會都立刻使用到
• 用來長期存放數據，但不需特別定義 Schema（數據結構）
• 閱讀數據的人更容易理解（這是跟 Data Warehouses (資料倉儲）相比，因 Data Warehouses 需要事先定義）

企業內的數據種類

先來了解公司會儲存什麼樣的數據。主要有 2 種

• structured operational data（結構化的營運數據）：類似一張 Excel 資料表
• Unstructured data（非結構化數據）：想像一個 Key-Value paired（鍵值配對）的資料，例如「姓名：朱騏，職業：Technical Writer」

前者的範例有

• Users（例如登入的使用者）& Organizations（註冊的公司）
• 產品銷售數據、訂單數量
• Saas app 數據（例如 DAU, MAU)
• 產品的發票或付款數據（例如金額、支付方式）特色是有定義好的 Schema 儲存資料。

後者的範例有

• 文字數據（例如 Twitter 使用者的 Tweet）
• Server 或 Application 的效能數據（例如 System Log）
• 網站點擊數、瀏覽數
• 產品使用的瑣碎資料（例如電商網站上的產品備註）特色是不需符合關聯式資料庫的結構 (ex. SQL)，因為數量太龐大、產生速度太快。

有了基礎概念後，你可能好奇說：「那這些數據可以如何使用呢?」

下方舉兩個企業內部的 Data Lake 使用案例。

Data Lake 使用案例

Case 1：營運場景

數據種類屬於「結構化的營運數據」。這個場景會用 Data Lake 來產出日報、月報。

例如

• 我們有多少的使用者
• 這個月我們賺多少錢
• 我們的顧客流失率是多少

Case 2：專案場景

數據種類屬於「非結構化數據」。

這個場景會用 Data Lake 來實作特別的專案 (例如 Machine Learning 專案)，即時觀察使用者的貼文動態。像是 Twitter 上的 What's happening 動態牆，可即時顯示近幾個小時的熱門 Tweet。

小結

以上就是 Data Lake 的簡單說明。下一篇文章，我們來了解跟 Data Lake 非常像的名詞- Data warehouses (資料倉儲)

這篇文章 Data Lake 是什麼？企業需要建置 Data Lake 的3個原因有這些｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

這篇文章一起來看看「當使用者使用 SSO 登入後，背後系統發生的事情」。如果你在軟體業工作，下次可以留意自家公司是使用哪一種方式來實作，能對產品的背後運作更加了解

上篇文章 講完了 SSO 是什麼、SSO 的兩種設計協定後，這篇文章一起來看看「當使用者使用 SSO 登入後，背後系統發生的事情」。

以 SAML 為例，看 SSO 的運作方式

當使用者登入 Gmail 時，背後實際上發生了

1. 輸入組織的的 Gmail，例如 chichu@pmstoolbox.com
2. Gmail Server 發現使用者使用「企業 Google 帳號」登入，對使用者的瀏覽器發出 SAR (SAML Authentication Request，SAML 授權請求)
3. 使用者的瀏覽器被轉址 (redirect) 到「身分提供商 (Identity Provider)」網站 ，例如 Okta, Auth0, onelogin…等
4. 身分提供商在使用者的瀏覽器介面上顯示登入頁面 (帳號/密碼)，使用者輸入帳號/密碼
5. 使用者的瀏覽器將加密後的帳號/密碼送回至身分提供商
6. 身分提供商產生「簽署核可的 SAML 聲明 (Signed SAML assertion)」，並送回至使用者瀏覽器
7. 瀏覽器將「簽署核可的 SAML 聲明」送至 Gmail
8. Gmail 驗證「簽署核可的 SAML 聲明」來自企業使用的身分提供商
9. Gmail 返回受保護的內容 (例如使用者的郵件內容)

PS. SAML 聲明 (SAML assertion)是一個經過加密簽署的 XML 文件，內容包含 (1) 使用者資訊 (2) 使用者能夠取用的服務。

來看使用者登入 SSO 之後，瀏覽其他應用程式的流程

當使用者登入 workday (Service Provider)時，背後實際上發生了

1. 使用者在 workday 的登入頁面上，輸入 chichu@pmstoolbox.com
2. workday 頁面對使用者的瀏覽器發出 SAR (SAML Authentication Request)
3. 使用者的瀏覽器被導流至 (redirect) 身分提供商 (Identity Provider) ，例如 Okta, Auth0, onelogin…等
4. 因為使用者已經登入 SSO，因此跳過登入步驟。身分提供商產生「簽署核可的 SAML 聲明 (Signed SAML assertion)」
5. 身分提供商將「「簽署核可的 SAML 聲明」送回至使用者瀏覽器
6. 瀏覽器將「簽署核可的 SAML 聲明」送至 workday (Service Provider)
7. workday 驗證「簽署核可的 SAML 聲明」來自企業使用的身分提供商 (Identity Provider)
8. workday 允許使用者使用服務

SAML 和 OpenID 的差異，工程團隊如何選？

這兩者的實作細節有差異，但大觀念是類似的。

兩者

• 都有經過加密
• 多數 Identity Provider 兩者都有支援

因此工程團隊在選擇時，主要是考量到協定與串接上所需的工來決定的。

如果你在軟體業工作，下次可以留意自家公司是使用哪一種方式來實作，能對產品的背後運作更加了解。

這篇文章 為什麼多數網站都可以一鍵登入？解釋背後技術 SSO 的流程 ｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

當我們使用大型網路公司的服務時，大家是否發現：我們竟然可以使用同一組帳號，在多個應用服務切換。最明顯的例子就是 Google 服務，只要登入一次，就可以在以下服務切換：Gmai、YouTube、Google Meet、Google Chat、Google Analytics。但為什麼可以這樣呢？這背後使用到的技術，稱為 SSO (Single sign-on)。

當我們使用大型網路公司的服務時，大家是否發現：我們竟然可以使用同一組帳號，在多個應用服務切換。

最明顯的例子就是 Google 服務，只要登入一次，就可以在以下服務切換

• Gmail
• YouTube
• Google Meet
• Google Chat
• Google Analytics
• …

但為什麼可以這樣呢？這背後使用到的技術，稱為 SSO (Single sign-on)。

這篇文章會解釋

• SSO 是什麼
• SSO 的兩種設計協定

SSO 是什麼

SSO 是一個授權架構 (Authentication Scheme)，它提供使用者可以用單一帳號使用同一組織下的多個應用服務 (Applications)。

使用 SSO 的組織例子有

• Gmail
• workday (美國知名的財務管理 & 人力資源管理 SaaS)
• Slack
• …

SSO 省去了使用者記憶多組的麻煩，能快速在同組織的不同服務下一鍵切換。

SSO 的兩種設計協定

SSO 是以「聯合身分(federated identity)」的概念設計而成。聯合身分能夠跨多個信任的獨立系統，彼此分享使用者的身分資訊。

基於此概念，有兩種設計協定:

• OpenID Connect
• SAML (Security assertion markup language, 安全聲明標記語言)

OpenID Connect

常見的 Google Sign in 頁面就使用了 OpenID Connect。

在 Google 使用 SSO 登入後，可以用一個 Google 帳號使用以下服務

• Gmail
• YouTube
• Google Analytics

OpenID Connect 使用 JWT (JSON Web Token) 來分享身分資訊，JWT 是經過簽署的 JSON 檔案。下方是 JWT 檔案的範例:

什麼是SAML?

另外一種 SSO 設計協定。

以 XML 來分享身分資訊，在大型企業的工作環境也很常看到。例如

• Microsoft 的 AD RMS
• Dropbox
• Slack
• Salesforce
• Sentry
• Zoom
• …

用於使用者後續登入 SaaS 服務。

下一篇我們實際來說說「當使用者使用 SSO 登入 Gmail 後，背後系統間發生的事情。」

此篇文章主要參考 ByteByteGo YouTube - What Is Single Sign-on (SSO)? How It Works

這篇文章 同一組帳密可以切換多個應用服務！軟體公司常見的 SSO (Single Sign-on) 是什麼？｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

Arihant Kumar Jain 是一位印度資深後端工程師，這篇文章摘要他對技術 PM的能力精進建議。

前言

Arihant Kumar Jain 是一位印度資深後端工程師，這篇文章摘要他在《An Ideal Technical Product Manager, Extract from an Engineer’s Diary》對於技術 PM (Technical Product Manager，簡稱 TPM) 的建議。

我們往往不會珍惜好的人或產出，直到體會到賽的。

這句話是我出社會後幾年的心得。

遇到神隊友不但可以把事情做得又快又好、甚至還可以偷學幾招 ; 遇到雷隊友不但把事情做的又慢又鳥，甚至還可能被拖下水。

神隊友不見得跟我們是同職位的人，也不見得是同年資的人。但只要這個人夠厲害，我們就應該試著觀察與分析、甚至聽聽他們的建議（如果他還願意給建議的話），我有過太多次「聽君一席話，勝讀十年書」的工作場景，因此只要遇到就會特別珍惜。

這篇文章討論的雖然是技術 PM，但內容值得其他 PM 職位的人學習。包含：

• 了解基本的電腦科學
• 注重細節
• 了解組織產品的軟體架構

一、了解基本的電腦科學 (Computer Science)

Product Manager 依據專精的項目不同，可以再分成：

• Business product manager
• Marketing product manager
• Technical product manager (TPM)

從字面上就可以看出， 3 個職位在專業上分別著重於商業、行銷、技術。

以 TPM 來說，至少對於技術討論、解決方案的構想、資訊架構都要有基本了解，例如設計 API 時要知道 REST, CRUD, HTTP status code… 的觀念。

這就像對於 UI 設計，PM 要了解公司目前的 UI Library 大概有哪些 Componet，才不會鬧出像是「PM 想這樣設計，但因公司的 UI Library 不支援，而要花更多時間成本客製化」的窘境。

要了解軟體技術，最基礎的學科就是電腦科學 (Computer Science)。

除了在職場上邊做邊學，也要定期補充學科知識，才能了解軟體技術的基本原理。

二、注重細節

對於一個已經工作 2-3 年的 PM 來說，寫 Spec 應該算是駕輕就熟的事情。但決定「好」跟「專業」的 Spec， 差別就在於文件的細節。

例如寫 UI 的 User Story 時，除了 User Story、Functional Map、UI Flow 之外，記得要規劃錯誤訊息 (Error Message) 這種反面案例。如果 PM 不規劃，就會麻煩到 QA 、Developer 甚至 Designer 幫忙規劃，反而讓其他人有「 PM 是不是都沒先想這塊」的念頭。

如果是 API 的 User Story ，則要先跟 Senior 工程師或是主管確認是否有 API 文件 (例如 Swagger )，仔細考慮每個資料節點的收集與傳送。

「好」跟「專業」的一線之隔，在於細節。

三、了解組織產品的軟體架構

軟體開發除了注重 Coding 的技術細節，設計完善的軟體架構也非常重要。

許多公司開發求快的結果，就是在產品上線後要不斷地花時間進行重構 (refactor)。這就像是蓋一棟危樓，草草成案就動土開工，後續必須花大量時間進行修補工程才能支撐不倒。

TPM 在整個過程中，可以協助當紀錄與畫圖的角色。

透過和工程師一起討論架構、整理結論、用繪圖工具畫成流程圖、系統架構圖，都能夠幫助自己對於組織的產品軟體結構更加了解，在設計產品時能夠更有 Sense。

共同參與技術討論，協助紀錄與整理資訊讓自己更理解產品。

下篇文章繼續講剩下的 3 點訣竅。

這篇文章 如何當一個技術 PM？從工程師角度來看 PM 需要具備的能力｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

要展現公司的獨特性，除了在產品設計、形象宣傳、美術風格都有類似的調性外，更重要的是要有一套指導原則，告訴整間公司的人應該如何做好他們的工作。Ethan Eismann 說：組織需要「產品原則 (Product Principle)」。

一、什麼是產品原則 ( Product Principle )？

Making work life simpler, more pleasant and more productive. （讓工作與生活更簡單、更開心、更有生產力）

這是知名的通訊軟體新創 — Slack 的公司使命 ( Mission )，這家公司的產品團隊、設計團隊都是秉持這樣的精神在設計產品。

每個人都有自己的個性，就連公司也不意外。

例如 Apple 充滿高雅、高科技感 ; Instagram 讓美好的回憶透過照片分享給其他人。那麼通訊軟體 Slack 呢？它們努力讓工作與生活更簡單、更開心、更有生產力。

要展現公司的獨特性，除了在產品設計、形象宣傳、美術風格都有類似的調性外，更重要的是要有一套指導原則，告訴整間公司的人應該如何做好他們的工作。

例如 Slack 的使命是讓工作與生活更簡單、更開心、更有生產力。但是要如何做到這件事情呢？

Ethan Eismann 說：

組織需要「產品原則 (Product Principle)」。

二、Slack 的產品原則

Ethan Eismann 是誰呢？

他是 Slack 的產品設計副總，負責領導設計與功能團隊開發產品。

根據他在《Why your organization needs product principles》的說明，Slack 將公司使命落地為 5 個「產品原則 (Product Principles)」：

• Don’t make me think. （別讓我思考）
• Be a great host. （當一個好主人）
• Prototype the path. （用原型來展示思考路徑）
• Don’t reinvent the wheel. （別重複造輪子）
• Make bigger, bolder bets. （下大膽的賭注）

這 5 個原則就像是檢查清單 ( checklist )，當 Slack 的員工需要做出某項決定時，可用來確認是否有遵循原則。

舉例來說，「Don’t make me think.（別讓我思考）」可以用來確保使用者在使用 Slack 時能「直覺地」操作。如果使用者必須來回確認功能的使用方式，代表功能必須重新設計。

使用者若能直覺地操作 Slack，代表他不需要對這項工具付出額外的注意力，而是專注在「溝通」並且盡快解決問題。最終將讓使用者的工作與生活更簡單、更開心、更有生產力。

我們可以看到「產品原則 ( Product Principles )」其實是一種手段 ( how we do )，目的是傳遞公司的使命價值 ( why we do )。而使用者看到的軟體功能 ( what we do )，則是透過產品原則達成的結果。

所以一家公司為什麼需要產品原則呢？ Ethan Eismann 說：

Product principles help teams evaluate work across functions to ensure we’re meeting our customers where they’re at.

（產品原則能幫助不同職能的團隊衡量工作成果，確保顧客需要的時候我們就在那裡。）

三、「產品原則」跟「黃金圈理論」不謀而合

黃金圈理論是什麼？

Simon Sinek 在 2009 年 TED演講 – 《偉大的領袖如何鼓勵行動》提出有名的「黃金圈 ( Golden Circle )」理論，他認為：

偉大的領導者／企業是由「Why」→「How」→「What」的順序與人其他人溝通 。

而一般平庸的領導者／企業則是反過來，由「What」→「How」→「Why」向其他人溝通。

有發現嗎？Ethan Eismann 的產品原則跟黃金圈理論不謀而合。

將「產品原則」呼應到「黃金圈理論」中

Ethan Eismann 在說明 Slack 的「公司價值、產品原則以及產品功能」時，其實分別對應到了黃金圈理論的「Why 、How、What 」三個層次。

• 公司價值：Why we do

Making work life simpler, more pleasant and more productive. (讓工作與生活更簡單、更開心、更有生產力)

• 產品原則：How we do

5 個產品原則
Don't make me think.（別讓我思考）
Be a great host. （當一個好主人）
Prototype the path.（用原型來展示思考路徑）
Don't reinvent the wheel.（別重複造輪子）
Make bigger, bolder bets.（下大膽的賭注）

• 產品功能：What we do

可參考《Designing teamwork: How our customers helped shape the future of Slack》，說明 Slack 新增與改進的功能。

Simon Sinek 在《找到你的為什麼》中提到：

你的獨特之處不單只在於為什麼 ( Why )，而在於你的為什麼加上怎麼做 ( Why + How)。

是這兩者結合使你與眾不同。

透過 Slack 的案例讓我們了解到，一個產品能夠備受客戶喜愛，甚至到後來成功地被大型企業併購 ( Salesforce 在 2020.12 宣布併購 Slack)，是因為產品的存在確實提供了客戶價值。

四、總結

Ethan Eismann 並沒有特別提到如何找到產品原則，但提出了 6 個思考產品策略是否有效的建議：

• 產品原則能呼應到公司使命與個性嗎？
• 產品原則夠精簡嗎？（它們應該可以用少於一句話表示）
• 我們有適當數量的產品原則嗎？（建議不超過 7 個）
• 產品原則具有可行性與廣泛適用性嗎？
• 你是否能夠想像，產品原則能夠有意義地應用在工作中？
• 產品原則能夠幫忙阻擋會造成產品走歪的隕石嗎？

最後我提供另一個想法：

制定「產品策略」的過程，其實就是自家公司找到「怎麼做 ( How)」的過程，這部分在 Simon Sinek 的《找到你的為什麼》有詳細說明，我推薦大家再去閱讀。

這篇文章 為什麼一家公司需要產品原則？跟 Slack 設計副總 Ethan Eismann 學習｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

承接 《工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？》中說到的:Stripe 背景介紹、Stripe API 產品的發展路徑、當支付產品變得愈來愈複雜時、產品團隊必須改變。這篇文章繼續來談 Stripe 是如何迭代他們的 API 產品。

承接 《工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？》中說到的：

• Stripe 背景介紹
• Stripe API 產品的發展路徑
• 當支付產品變得愈來愈複雜時
• 產品團隊必須改變

這篇文章繼續來談 Stripe 是如何迭代他們的 API 產品。

從一個 5 人小團隊開始

有趣的事情是，這場改革討論沒有想像中這麼盛大。他們從多年的客戶反饋下手，結合關鍵合作夥伴的串接經驗，以 5 人小組出發 (4 工程師 + 1 產品經理)，從「第一性原則」思考目前與未來的 Payment 方式，進而重構 API 設計。

「我已經不記得當時的日子是怎麼過的…但確實有一些默契讓這個小組得以不斷往前推進。」Stripe 的一位工程師說。後來他將這些看不見的默契重新歸納成 7 個原則，簡單摘要如下。

專注，Stripe 推動會議進行的 7 個訣竅

• Close laptops （關掉電腦，專心傾聽）：能幫助全體成員專心、全情投入在當下開會與共同思考。
• Pace your questions （將疑問排序討論）：將討論分成多段，每一段都先訂幾個想要討論的問題。當討論的過程中產出新問題時，先紀錄在一邊當成下一段的討論問題，把手頭上的問題討論完畢後再繼續新問題討論。
• Use colors and shapes（使用顏色與形狀來表示概念）：在討論許多抽象化的事情時，有相同的顏色或群組替概念分類，不要在當下糾結抽象化的概念應該如何命名。
• Focus on enabling real user integrations（專注在提升使用者串接的效率）：在設計 API 時團隊時常會卡在要用完美的變數名、完美的理論框架、看起來很聰明的解法，但這些對於實際串接者如果沒幫助，就要捨棄不用。
• Question every assumption underpinning existing APIs （質疑每一個已存在的 API 設計假設）：我們在規劃的時候，都會基於一個已存在的前提假設接著規劃，設計產品更是這樣。但如果要把結構打掉重做，那就要從起點開始去思考，去質疑會不會在起點就已經不是好的設計方法了。
• Invite domain experts as guests（邀請專家）：寫程式是一門專業，每一種支付方式也都是一門專業。記得邀請特定領域的專家加入會議，並且請他們給予該領域的看法與建議。
• Make decisions quickly knowing you might change your mind（意識到自己會優柔寡斷，趕快下決策）：我們在規劃時，若牽涉的主題愈複雜、愈容易優柔寡斷不敢對許多設計點下決定。比較好的做法就是讓全 Team 都有「迭代」的概念，先下一個決定做一個成果，繼續討論後發現有問題再修正下心的決定。

Photo by Jason Goodman on Unsplash

Stripe 引導客戶使用新產品的「藝術」

在經過一輪討論後，Stripe 重新設計了支付 API，新版的 API 跟原始 API 差異甚大，但在結構上可以應付未來不斷新加入的支付方式。Stripe 畫了一張圖來表示新版和舊版 API 在串接上的「功 (effort)」與「效果(Power)」，讓合作夥伴了解串接上的差異。（參考圖片，Charges 是舊版 API、PaymentIntents 是新版 API）

那 Stripe 是如何兼容說明新版與舊版的 API 呢？他們採取的策略如下：

1. 讓兩種 API 並行，通常在在美國的公司只需要信用卡的支付方式（舊版）
2. 美國公司如果想要往海外發展，潛規則地必須接受串接新版 API，但因為舊版 API 在後期開發新的支付方式時會變得極度痛苦 ( API 複雜度問題）
3. 建立一個 API 串接包 ( convenient packaging )，並在串接包中說明目前 API 有分成兩種，將新版 API 包裝成「global payments integration」。如果使用非 “global payments integration” 的串接方式，未來想要增加新的付款方式，串接難度會提高很多。

這真的是一個聰明的策略，淺意識地引導合作夥伴都要選擇新版的 API 串接。

我的啟發

這段故事根本是在告訴我們：「你要先放下執著，才能繼續成長(?)」。

為什麼呢？因為 2017 年曾經有篇 Bloomberg新聞報導宣傳：「US-based online payments startup Stripe’s system requires client companies to add just seven lines of code to their site to handle payments.」只要 7 行程式碼就可以串接完成付款服務，這在公司間的技術串接是非常不可思議的事情，也是對 Stripe 技術產品最好的讚譽。

當 Stripe API 重新翻新後，已經無法只靠「7 lines of code」完成技術串接了。想想看，要撕掉自己早期獲得的美名，這實在是一件困難的事情。

但經過這件事情後，Stripe 也學習到：

The more we grow, the more we realize that we must continue to build and rebuild deliberately and thoughtfully.

These are still early days.

(我們愈是成長，就愈是意識到必須謹慎而周到地進行建構與重建。現在仍然是早期階段)

持續迭代，持續完善。

這篇文章 推動會議進行的 7 個訣竅！支付科技新創 Stripe，是如何開發與改革舊版的 API 產品？｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

這篇文章是知名線上付款服務提供商 — Stripe 的 API 故事，由於時間長達 10 年已經可以當成是一段小歷史來看了。在 Stripe 身上我們可以看到一家以 API 服務為重的公司，是如何：(1) 根據市場上的需求調整 API產品 (2) 如何應付改動產品過程中累積的「產品債」(3) 如何召集團隊重新思考自家 API 產品的本質，並進行重構 (refactor)。

Stripe 這篇《Stripe’s payments APIs: the first ten years》文章寫得真好，把技術、招募、產品的內容都寫進一個故事了，看的實在過癮。

這篇故事從不同的視角可以看出不同韻味：

1. 對工程師來說，看完這篇故事你對 Stripe API 的設計也懂個大概了
2. 對產品經理來說，這篇故事寫出了一個成長中的產品團隊如何面對市場、破除對產品的假設來迭代產品
3. 對一般人來說，我們看到的是你要先放下執著，才能繼續成長（？）

這篇文章先來介紹 Stripe 的產品背景與困境。

Stripe 背景介紹

這篇文章是知名線上付款服務提供商 — Stripe 的 API 故事，由於時間長達 10 年已經可以當成是一段小歷史來看了。

在 Stripe 身上我們可以看到一家以 API 服務為重的公司，是如何：

1. 根據市場上的需求調整 API 產品
2. 如何應付改動產品過程中累積的「產品債」
3. 如何召集團隊重新思考自家 API 產品的本質，並進行重構 (refactor)。

這篇文章精彩的地方，就在於作者可以邊以 Stripe API 當作範例、邊解釋當時為什麼會這樣設計這些 API。

Stripe API 產品的發展路徑

許多的 API 產品往往在初期都是非常直覺化的設計，例如使用者取得 Token 之後，就可以取用一連串公司提供的 API 服務。

問題是當市場出現變化的時候，公司要如何去改動這些 API，讓串接 API 的開發者可以盡快理解 API 的邏輯、同時因應市場上出現的新需求。

舉例來說，Stripe 一開始服務的對象主要是美國境內的企業，在美國「信用卡」還是付款的大宗，因此Stripe 的 API 只要先滿足這些企業需求就好。

但是當 Stripe 逐漸長大開始要走向海外市場時，要面對的是更多元的支付方式，例如 ACH Debit（ACH 自動轉帳）、Bitcoin（虛擬貨幣支付）、各種當地支付（IDEAL-荷蘭、Alipay-中國、Giropay-德國…等）。Stripe 必須開始在原先以「信用卡」付款方式的 API 加上參數，好因應市場上百花齊放的新付款方式。

早期 Stripe 的 API 是非常單純的（2011–2015年）， 只需要 Token 和 Charges 兩個參數就可以就能應付「信用卡」的支付串接。但在 2015 年加入支援「比特幣支付」後，則新增了 BitcoinReceiver 參數。

當支付產品變得愈來愈複雜時

你可能好奇說：「為什麼要新增參數呢？」原因就在於「確認支付 ( payments are finalized ) 的時間點差異」。

「信用卡」確認支付的時機點幾乎是即時的。消費者刷卡時，Stripe 就會跟發卡銀行以及國際信用卡組織做刷卡資料確認。

「ACH Debit」則是銀行帳戶間的資金移轉，通常需要數天才能完成支付確認。

「比特幣支付」指店家雖然知道消費者發起比特幣交易，但必須經過礦工的運算（等待 6 個區塊產生，每個區塊產生的時間約為 10 分鐘）才算是完成支付。

從上面的例子可以看到，由於每一種付款方式有完全不同的特性，也導致設計 API 的困難度。API 是一個高度抽象化的產品，仰賴設計者定義參數之間運作的邏輯，來模擬真實世界中事物運行的狀況。

產品團隊必須改變

時間快轉到 2017 年年底，Stripe 內部團隊發現：「糟糕！再這樣下去 Stripe API 會變得愈來愈複雜，而且都會是 Stripe 這家公司特有的程式邏輯，非常不利於合作夥伴的串接…」團隊決定大刀闊斧，對龐大的 API 做一次大型的重構 (refactor)。

我看到這邊就知道，故事精彩的地方來了！

因為這個狀況不限於技術團隊，實際上當一家公司發展到一定規模時，總會有些產品、流程、制度已經不符合現在的使用狀況，但礙於大家都覺得：「哎呀，現在不是還好好的可以用嗎，幹嘛要改變呢？」因此拒絕改變。

這就像在一棟危樓上繼續加蓋，只要大樓還可以住人、沒立即性的危險，那幹嘛要打掉重建呢？

但 Stripe 思考到：「如果公司產品還要擴展到到其他國家，再痛也得改！」於是改革開始了。

下一篇文章繼續談 Stripe 是如何改善。

這篇文章 工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？當支付產品愈趨複雜時 Stripe 團隊決定這樣做！｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

這篇文章要來說「從事 Dropshipping 的老闆，如何找到銷售的產品與市場」，文章不會講到太深入的觀念，可以當作入門文章來讀。一共會提到 3 件重要的觀念：一、使用行銷數據二、如何判斷自家網路商店的競爭力？三、Shopify 的商業洞察

前言

這篇文章要來說「從事 Dropshipping 的老闆，如何找到銷售的產品與市場」，文章不會講到太深入的觀念，可以當作入門文章來讀。一共會提到 3 件重要的觀念：

• 一、使用行銷數據工具輔助分析
• 二、如何判斷自家網路商店的競爭力？
• 三、Shopify 的商業洞察

一、使用行銷數據工具輔助分析

網路市場是個需求變動極為快速的地方，有些賣家對市場很敏感，可以從新聞、社群媒體 “嗅出” 趨勢話題與商品。但多數老闆在開始一門生意之前是毫無頭緒的，因此需要「數據工具」來幫助判斷自己可以賣些什麼、該鎖定哪些利基/小眾市場、我的消費者都長得什麼樣子。

下面收集整理 3 款數據工具幫助我們分析。

1. Facebook Audience Insights (廣告受眾洞察報告)

Facebook 是現在世界上最大的社群平台，全球每個月有超過 22 億的活躍使用者、光是美國成人就花費平均每天 38 分鐘在 Facebook 上，而 Facebook Audience Insight 能夠從地區、喜歡的內容、所在位置、活動紀錄…角度切入，提供非常多有趣的消費者數據。

這篇文章使用「美國18–55歲，對休閒旅遊、健身與健康、國家地理歷險頻道同時都有興趣的族群」為例，直接教學如何使用 Facebook Audience Insight ，推薦一讀！

2. Google Ads — Keyword Planner

如果一項商品被愈多人搜尋，代表其「潛在需求」很高，是個很好的銷售切入點。那要如何知道一個商品的搜尋趨勢呢？我們可以使用 Google Ads 中的 Keyword Planner。

此功能簡單來說：

可直接搜尋一組/多組關鍵字，透過關鍵字的搜尋量來判斷潛在需求。

Keyword Planner 的使用是免費的，但如果想取得更詳細的搜尋量資訊就必須花錢，如下方所示。

如果付錢使用的話，就可以看到確切的數字：

3. Google Trends

Google Trends 應該是比較多人聽過也使用過的分析工具，如同它的名稱「Trends (趨勢)」，非常適合來找現在的趨勢話題、產品有什麼。

舉例來說，近幾年「Meditation (冥想)」非常流行，我們可以透過 Google Trends 了解整體趨勢如下：

Google Trends 的 y 座標顯示的是相對數值，並非絕對次數的搜尋量。對於找尋利基/小眾市場的老闆來說，其實只要知道趨勢是逐漸向上成長即可。

有趣的是，我們甚至可以透過 Google Trends 發現需求的季節性變化，提早因應需求。下方是 Canoe (獨木舟) 的搜尋量變化，可以看到高峰都是在「夏天 7–9月」

二、如何判斷自家網路商店的競爭力？

買廣告不是一個長久之計

找到了銷售方向、透過開店平台建立了網路商店後，下一步就是要觀察自家商店在網路上的競爭力。

在《當工具型平台愈來愈多時，對於電商產業的商家來說是一件好事情嗎？》我提到說：

在開店平台上，所有的人都可以使用相同的模組化工具，你建立的網路商店和我的一樣漂亮，甚至貨源可能都是同樣的，此時只剩下一個地方可以競爭：用更多的行銷來獲取客戶。

我們開始競爭同一組關鍵字 → 對關鍵字的需求導致費用上漲 →費用上漲代表我們平均獲得一位消費者的費用上升…

在 Dropshipping 的商業模式中，更有效的行銷手法產生創造更強的競爭力。我們的直覺是：那我就花錢買廣告，買愈多的廣告就有愈強的競爭力了吧！

但如同上面說的，在所有人都在競爭同樣幾組的關鍵字時，買廣告將會愈來愈貴，利潤也會隨之減少。因此單純的「買廣告」並不是長久之計，真正有效的是「做好網站的 SEO」，讓消費者透過搜尋找到你的店並且自己走進來。

SEO的基礎概念

SEO 涵蓋的知識點太多太廣，這邊只提兩個重要的「硬指標 (Hard Metrics)」：Number of linking domains (連結網域數量) 和 Authority of competing sites (競爭網站的權重)。

▶︎ Number of linking domains (連結網域數量)

Google 的網頁排名有很大的成分是看「網頁之間的連結」，當一個網站被愈多其他網站連結時，其排名會比較前面。

但這樣一想很奇怪，那我能不能建立許多沒內容的頁面、但都連結到同一個網站來提升排名呢？答案是：不行。

單純看「連結數量」很容易有作弊的狀況發生，因此更公平的做法是看「連結網域數量 (英文也稱 Linking root domains/ Unique linking domains)」，也就是有幾個網域互相連結。

打個比方，如果 A 朋友在禮拜一早上告訴你 X 餐廳很好吃，你可能會對這件事情有印象，如果他每天都提醒你一次 X 餐廳很好吃 (一週 7 次疲勞轟炸)，你有機會去吃那家餐廳 (但還是不一定，因為有可能是他個人偏好呀)。

但如果有 7 個朋友都跟你推薦 X 餐廳很好吃，那你去吃的機會就幾乎接近 “一定會去” 了 (大家都有不同偏好，但有這麼多人都跟我推薦，那應該真的很好吃)。

結論：Number of linking domains 愈多，網頁排名通常會愈前面。查看自己網站的 Linking domains 數量，推薦工具：Link Explorer

▶︎ Authority of competing sites (競爭網站的權重)

當然，Number of linking domains 只是排名的其中一項因素，還必須考慮連結來源的「權重 (Authority)」。

什麼意思呢？例如我有一個 A 網站，從我的 Blog (瀏覽次數可能只有 100 次)連結到 A 網站的效力、跟 New York Times (瀏覽次數超過 4億次)連結到 A 網站是完全不同的。

在 Google 排名中，網頁排名機制是使用 PageRank 演算法排名 (也是 Google 創辦人 — Larry Page 的名字)，更多資料可以閱讀 Wiki。

隨著排名演算法不斷更新， Google 已在 2016 年將 PageRank 演算法下架，目前的 Google 演算法整理可參考 這篇文章。

三、Shopify 的商業洞察

講完了比較硬核的知識後，我們一起來看看 Shopify 商業分析中的有趣洞察。

• 洞察 1：尋找配件需求高的市場

在 Dropshipping 的商業模式中，利益 (Markup) 較高的其實不是高單價產品 (例如電腦、電視)，而是其相關的配件。

消費者對於配件的「思考時間與謹慎度」相對比高單價產品低，購買量相對較高，最後計算毛利時反而以配件更為賺錢。

• 洞察 2：找到有熱情的消費者

如果你有特別的興趣，例如攝影、咖啡、魔術、自行車…等，應該不難想像會花非常多的錢在購買相關產品上。以手沖咖啡來說，光是手沖壺、磨豆機、濾杯、下壺、…等，零零總總加起來也是一筆可觀的消費。

• 洞察 3：尋找當地區域比較少見的話題產品

有些商品在當地不一定好購買。以「魔術道具」來說，在台灣就只有不到 10 家的魔術道具商可以購買，若想購買大部分都要跟美國、中國下訂。

像這種商品，消費者不見得會知道要去哪個國外網站上訂購，這就是一個很好的切入點。

• 洞察 4：降低銷售商品的週轉率 (Turnover rate)

盡量不要太頻繁更新商店的產品線 (例如這個月賣牙刷、下個月賣衣服、再次月賣充電線)，因為這樣網路商店就無法累積品牌辨識度，同時會浪費大量時間在更新產品頁面資訊。

• 洞察 5：考慮銷售可丟棄式、需重複購買的商品

根據 Invest 在《Customer Acquisition Vs.Retention Costs — Statistics And Trends》提到，獲得新客戶的成本是留住舊客戶的 5 倍，因此讓客戶不斷回頭購買會是可持續盈利的策略。

那要如何讓客戶持續回頭呢？銷售可拋棄式、須定期補充的商品 (例如口罩、美容保養用品)都會是不錯的選擇。

總結

以上是針對「如何找到銷售的產品與市場」的說明。我們了解到要做成一門網路生意，除了靠數據挖掘潛在市場需求外、增進 SEO 外，還可以參考 Shopify 提供的銷售 Tips 。

這篇文章是 Shopify 分析 2022 的趨勢商品，大家有興趣不妨快速瀏覽，可以刺激夠多網路商店銷售的點子。

這篇文章 想找到真正賺錢的電商市場？你可以善用這些行銷數據工具！這 3 件重要的觀念請筆記起來｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

我在《經營 Dropshipping 網路商店真有那麼好賺？說完優點，現在來看看有哪些缺點！》介紹了 Dropshipping 的商業模式。簡單說，Dropshipping (直購) 是「商家」透過供應商直接出貨給消費者，中途不接觸出貨相關事宜，主要將心力擺在經營網路商店與行銷廣告上。這篇文章分享 Dropshipping 的供應鏈內容，主要會說明供應鏈中的三個重要角色 — 製造商、批發商、零售商。

我在《經營 Dropshipping 網路商店真有那麼好賺？說完優點，現在來看看有哪些缺點！》介紹了 Dropshipping 的商業模式，包含：

• 商業模式流程圖
• 優點
• 缺點
• 開一家店要多少錢

簡單說，Dropshipping（直購）是「商家」透過供應商直接出貨給消費者，中途不接觸出貨相關事宜，主要將心力擺在經營網路商店與行銷廣告上。

這篇文章分享 Dropshipping 的供應鏈內容，主要會說明供應鏈中的三個重要角色 — 製造商、批發商、零售商。

一、供應鏈中的三個重要角色 — 製造商、批發商、零售商

身為消費者，我們可能對網路商店的「供應商」這個概念很模糊。實際上「供應商」可以細分成「製造商」與「批發商」，網路商店則被稱為「零售商」。

製造商（Manufacturer）

從嚴格的供應鏈定義來說，「製造商」是指從原物料採集（例如橡膠與石油…）到製作成看得到的產品，但在這裡我們不必鑽研的這麼深入，只要知道「製造商」就是實際製造產品的廠商即可。

舉例來說，縫製衣服的成衣廠、製作玩具的玩具工廠、生產家具的傢俱工廠…都可以算是製造商。製造商通常不會將產品賣給消費者，而是用批量的模式賣給批發商與零售商，通常會要求一定數量的購買量。

跟「製造商」直接買產品是最便宜的，但購買後必須自行處理後續的庫存、出貨的事務。

批發商（WholeSaler）

「批發商」會跟「製造商」一次買入大批量的產品，並且透過加價販售給「零售商」來賺取利潤。由於「批發商」一次購買的數量通常非常多，平均算下來產品的購買成本就會非常便宜。

多數的「批發商」只會販售產品給「零售商」，也不會直接販售給消費者。

零售商（Retailer）

「零售商」就是我們常接觸的實體通路或是網路商店，他們跟「批發商」進貨並加上一定的金額後，再販賣給消費者（我們）來賺取利潤。

以服飾業來舉例，女生在網路上常逛的蝦皮、Yahoo! 商城、露天商城 ; 實體通路的街頭服飾店都屬於「零售商」。

有趣的是，網路上的「零售商」有多數都屬於個人經營（例如我有同事就自己在 momo 上銷售香水），不見得都是公司行號成立的商店。以 Dropshipping 的商業模式來說，許多網路商店的老闆其實都是個人經營。

二、Dropshipping 的供應鏈流程

以《什麼是 Dropshipping ?》中的 Dropshipping 商業流程圖延伸，如果我們將上方提到的三個角色放到圖中，整個流程如下：

1. 「消費者」下單：消費者透過廣告、自行瀏覽網頁來到網店下單並付款，此時款項還不會入帳到網路商店的銀行帳戶。
2. 「網路商店」叫貨：在 Dropshipping 的商業模式中，網路商店本身不囤積庫存，而是在消費者下單付款後，才向批發商叫貨。
3. 「批發商」扣款與發送確認訂單：批發商收到網路商店的訂單，會先跟網路商店結帳扣款。若扣款成功，批發商的系統發出確認訂單信。
4. 「批發商」包貨：商家直接提供消費者的收貨地址給供應商，由供應商負責揀貨、包裝。根據 Shopify 的文章說明，這些批發商的包貨速度其實比想像中快，甚至可以做到當天下單、當天出貨的速度。
5. 「批發商」出貨：批發商將商品出貨給消費者。值得注意的是，在商品外包裝的出貨封條寫的是網路商店的資訊，連出貨發票（Invoice）上的公司 Logo 也是標示網路商店的。
6. 「批發商」提供發票與出貨追蹤單號：批發商將開立訂購發票給網路商店，並提供物流的追蹤單號。
7. 「開店平台」發送出貨通知：網路商店使用的平台，此時會發送 Email 給消費者，告知商品已寄出並提供物流追蹤單號。
8. 「開店平台」將消費者款項匯入網路商店帳戶：此時訂單已完成（Fulfillment），開店平台會將消費者的款項，匯入到網路商店當初設定的銀行帳戶中。
9. 「開店平台」處理爭議：通常流程到上一步就會結束。如果不幸地消費者收到的商品有問題，就會聯繫商家進行換貨。消費者通常不知道批發商的存在，有問題會直接找商家。

三、總結

在整個流程當中，我們不會看到有個角色叫做 Dropshipper（中文不知道怎麼翻譯…）。因為只要該角色願意協助出貨，製造商、批發商、零售商這 3 個角色都可以成為 Dropshipper。

因此我們可以把 Dropshipper 理解成「協助出貨事宜」的角色。

事實上，零售商也可以協助其他零售商出貨，只是在價格上不會比批發商來得便宜有競爭力，畢竟協助出貨的零售商自己也是跟批發商叫貨，會將批發價 + 自己想賺取的利潤。

對於消費者來說，Dropshipper 在整個商業流程中幾乎是「隱形的」，我們只會知道在哪個網路商店下單，但不會知道這商品到底是從哪裡來的。

所以下一次我們在網路上購物時，當賣家說「商品直接從倉庫出貨唷！」，我們就要意識到：

這個產品有可能賣家也不一定知道品質好壞，要有品質參差不齊的心理打算……

這篇文章 看不見的 Dropshipping：網購時當賣家說出這句話就要注意！一張圖了解 Dropshipping 整體出貨流程｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。