如何用 AI 查詢 PostHog 並檢查結果
在聊天中透過 Leina 查詢 PostHog 事件資料,避開常見的指標陷阱,並將每日數值、時間邊界與期間總計對照來源資料進行檢查。
在團隊聊天中請 AI 代理「把我們這週新功能的使用情形畫成圖表」聽起來很簡單。但分析查詢很容易出現細微錯誤:把事件總點擊數與不重複活躍使用者搞混、以 UTC 而非團隊所在地時區來分日,或把今天尚未完整的一半資料當成突然的「使用量下滑」。
有了 Leina,你可以直接在 Slack 或團隊聊天中查詢 PostHog 分析資料。為了讓輸出值得信賴,請在視覺化圖表之外一併要求底層的每日資料,並在把結果放進簡報或週報之前,先將結果與你的 PostHog 儀表板比對。
先從團隊報告中已經在使用的事件開始,這樣你就有一個現成的來源可以比對。
查詢前先定義指標參數
像「這個功能用了多少?」這類模糊的要求會產生模稜兩可的圖表。在提示之前,先定義這些必要的查詢參數:
| 參數 | 要指定的內容 | 為什麼重要 |
|---|---|---|
| 專案 | 已連接的 PostHog 專案名稱 | 識別資料來源;正式環境與測試環境可能也需要分別篩選。 |
| 事件名稱 | 確切的事件識別碼(例如 billing_upgrade_clicked) | 避免查詢已棄用或拼錯的自訂事件。 |
| 衡量方式 | 總發生次數 與 不重複使用者 | 發生次數衡量事件量;不重複使用者計算觸發事件的人數。這是否代表採用情形,取決於該事件。 |
| 日期範圍與時區 | 明確的開始/結束時間戳記,以及報告時區(例如 America/Los_Angeles) | 避免接近午夜的事件被移到相鄰日期。 |
| 篩選條件 | 環境、測試帳號或特定使用者屬性 | 定義要納入哪些紀錄;使用符合你實際事件屬性的篩選條件。 |
| 不完整日期 | 排除今天,或將其標示為不完整 | 避免不完整的一天看起來像令人警覺的下滑。 |
在視覺化圖表之外一併要求表格式數值
在聊天中查詢時,一律要求每日摘要表與圖表兩者。視覺化圖表容易分享,但資料表才能讓你驗證計算。
在你已連接的聊天中複製並調整這段提示:
在我們已連接的 PostHog 專案
[project]中,計算[event_name]從[start timestamp]到[end timestamp]的 [總發生次數 / 不重複使用者]。
- 時區: 使用
[timezone]作為每日邊界。- 篩選條件: 套用
[例如 environment = production、排除內部員工]。- 格式: 同時回傳每日資料表與視覺化長條圖。
- 中繼資料: 說明專案、衡量方式、報告期間、確切篩選條件與擷取時間戳記。若可取得查詢或來源連結,請一併附上;否則提供我可以重現的條件。
- 不完整日期: 在報告時區中標示尚未完整的日期。
- 擷取缺口: 將缺少或不完整的資料與已確認的零計數分開報告。
僅執行讀取操作。
透過 Connections 連接一個可讀取目標 PostHog 專案的帳號。如果你使用 Slack,Slack 指南 (English) 涵蓋了聊天設定。PostHog 的 insight 指南 說明了哪些分析類型適合不同的問題。
先檢查一個日期,再檢查整個期間
在把圖表貼進高階主管更新之前,用以下兩項檢查將數字與 PostHog 比對:
1. 在 PostHog 中抽查一個已完成的日期
在瀏覽器中開啟 PostHog Insights,針對單一已完成日期(例如上週三)設定相同的事件與篩選條件,並將計數與代理的表格比對。相符是一項有用的初步檢查。它無法驗證整個查詢:不同的篩選條件也可能在某一天產生相同的計數。接著比對整個報告期間,包括接近開始與結束邊界的紀錄,並確認兩個查詢使用相同的專案、衡量方式、時區與篩選條件。
2. 驗證總計與不重複使用者的計算
- 總發生次數可加總: 如果你查詢的是總事件量,涵蓋整個期間且不重疊的每日資料列,在兩個查詢使用相同範圍與底層資料時,應加總為期間總計。
- 不重複使用者不可加總: 一位在週一與週二都活躍的使用者,會在週一的每日分組中計一次、在週二的每日分組中計一次,但在多日總計中只計 一次。
以下數值僅為示意:
| 日期 | 事件發生次數(可加總) | 不重複使用者(不可加總) |
|---|---|---|
| 週一 | 4 個事件 | 2 位使用者(Alice、Bob) |
| 週二 | 3 個事件 | 2 位使用者(Alice、Charlie) |
| 兩日總計 | 7 個事件(4 + 3) | 3 位使用者(Alice、Bob、Charlie) |
如果代理只是把每日不重複使用者數加總來報告多日不重複使用者總計,該計算就是有問題的。
數字不符時的快速疑難排解
當聊天中的數字與你在 PostHog UI 看到的內容不符時,使用以下檢查來縮小差異:
| 症狀 | 要檢查的根本原因 |
|---|---|
| 所有每日計數一致偏低 | 檢查 PostHog 中是否啟用了內部團隊篩選或機器人排除,但查詢中省略了(或反之)。 |
| 尖峰與低谷位移了一天 | 比對每個查詢使用的時區與日期邊界。 |
| 最後一天急遽下滑 | 檢查查詢執行時該日是否已完成。若已完成,應調查該變化,而不是假設資料不完整。 |
| 範圍中間缺少日期 | 檢查來源是確認零事件,還是查詢回傳了不完整的資料。 |
| 歷史數字與上週相比出現位移 | 檢查是否有延遲送達的事件、回填,或篩選條件與來源紀錄的變更。 |
你可以使用 PostHog 圖表審查工作表 記錄你的查詢參數與處理註記。
將觀察到的指標與假設分開
例如,使用虛構數字,一份報告可以將這些陳述分開:
- 觀察到的變化: 「結帳按鈕點擊數從週一到週四增加了 34%。」
- 假設: 「週二的 v2.4 行動應用程式發布可能有關。將受影響的使用者與其他分群比較,並檢查追蹤是否有變更;僅憑該比較無法確立因果關係。」
查詢檢查完成後,你可以請 Leina 依排程執行。指定時區與交付位置,然後檢閱第一次排程結果。當 instrumentation 或篩選條件變更時,請重新檢查查詢;週期性執行不能取代驗證。
PostHog 也提供自家的 AI 分析功能。選擇適合你團隊工作方式的流程,並在分享任何圖表時附上來源條件。