技術 Day 3｜PostHog 安裝

在這個系列中，我們主要會使用 PostHog，搭配一個 Next.js 專案進行實作。 PostHog 對我而言有點像是軟體開發的瑞士刀。不見得所有需求都能做到...

技術 Day 7｜把 Signal 寫進程式：Event Tracking

上一篇我們透過 Goals-Signals-Metrics（GSM），從「希望使用者成功」一路往下找到可以觀察的信號與指標。 以商品頁面的案例來說，我們希望使用...

技術 Day 8｜產品分析 Product Analytics

當我們開始收集事件後，下一步就是要觀察，否則這些事件就只是資料，本身並不會帶來任何意義。我們當然可以直接觀察事件本身，但通常能得到的資訊有限，因此需要一個工具來...

技術 Day 12｜當內建圖表回答不了問題：SQL / HogQL

前面我們了解到，如何在產品分析（Product Analytics）中建立不同類型的 Insight 來輔助觀察。然而，許多時候我們想觀察的事情，很難直接利用預...

技術 Day 4｜錯誤追蹤 Error Tracking

無論你對產品工程師有沒有興趣，只要你做的產品真的有人使用，大概都遇過使用者或其他同事跑來回報： 「這裡好像壞掉了。」 有些問題很單純，光看錯誤訊息就知道發生在哪...

技術 Day 10｜第一次成功：Funnel 與 Activation

前面幾篇文章，我們一路從「使用者想完成什麼」開始，用 GSM 找出 Signal，再把 Signal 寫成 Event，最後送進 PostHog 做分析。 到這...

技術 Day 11｜成功一次之後呢？Retention 與 Cohort

上一篇我們先把使用者生命週期畫成一張很簡單的地圖： 開始使用產品 ↓ 第一次取得價值 ↓ 持續取得價值 ↓ 停止使用，或者之後再次回來 我們用 Activat...

技術 Day 15｜Web Analytics：從流量到頁面體驗

前面介紹 Product Analytics 時，我們需要先決定想回答的問題，再建立對應的 Insight。 但對網站來說，有一部分資訊其實非常固定，例如有多少...

技術 Day 13｜產品資料不只在 Analytics：Data Sources 與 Model

很多時候，事件本身攜帶的資料仍不足以提供完整的分析資訊。 例如我們發送了訂單事件，但事件內不見得包含完整的商品清單。這時就可以利用資料來源（Data Sourc...

技術 Day 16｜Attribution：來源真的等於原因嗎？

上一篇文介紹 Web Analytics 時，我們可以利用 Sources 觀察使用者從哪裡進入網站，例如 Organic Search、Paid Search...

技術 Day 17｜Deploy 不等於 Release：Feature Flag

作為軟體工程師，開發功能通常是日常工作的一大重點，但一個功能不太可能在工程師一做好後，就直接丟給使用者，通常還會經過許多測試。 對大部分開發流程而言，應該至少會...