鐵人檔案
本系列將從「產品型工程師」的角度出發，探討工程師如何從單純完成需求，進一步理解使用者問題、定義成功、利用數據驗證產品決策。內容將結合 PostHog 實作，涵蓋 Error Tracking、產品分析、事件追蹤、Dashboard、Feature Flag、Experiment 等工具，並搭配 Jobs to be Done、GSM 等產品思維框架。希望讓工程師不只會把功能做出來，也能知道該做什麼、為什麼做，以及做完之後如何判斷是否真的有效。
上一篇我們先把使用者生命週期畫成一張很簡單的地圖： 開始使用產品 ↓ 第一次取得價值 ↓ 持續取得價值 ↓ 停止使用，或者之後再次回來 我們用 Activat...
前面我們了解到，如何在產品分析（Product Analytics）中建立不同類型的 Insight 來輔助觀察。然而，許多時候我們想觀察的事情，很難直接利用預...
很多時候，事件本身攜帶的資料仍不足以提供完整的分析資訊。 例如我們發送了訂單事件，但事件內不見得包含完整的商品清單。這時就可以利用資料來源（Data Sourc...
前面幾篇已經開始累積不少 Metric。Activation、Retention、Conversion、Time to Value，加上 Data Source...
前面介紹 Product Analytics 時，我們需要先決定想回答的問題，再建立對應的 Insight。 但對網站來說，有一部分資訊其實非常固定，例如有多少...
上一篇文介紹 Web Analytics 時，我們可以利用 Sources 觀察使用者從哪裡進入網站，例如 Organic Search、Paid Search...
作為軟體工程師，開發功能通常是日常工作的一大重點，但一個功能不太可能在工程師一做好後，就直接丟給使用者，通常還會經過許多測試。 對大部分開發流程而言，應該至少會...
當我們把一個功能實作出來，也透過功能旗標和灰度發布來避免功能影響到太多人。然而當功能上線後，我們就可以把開發票關掉，然後趕往下一個任務嗎？ 系列一開始我們講到...
在開發功能時，即便是再資深的設計師，也會遇到無法斷言不同設計中哪個表現最好的問題。當我們認為某項改動能改善使用者的結果時，除了靠猜以外，讓真實使用者與統計說話是...
前一篇我們利用 Experiment 比較不同版本的結果。假設新版 Checkout 的 Conversion Rate 明顯比較差，我們至少已經知道這次改動可...