前一篇我們透過 Experiment，讓不同使用者接觸不同版本，再透過統計方法判斷改動是否真的帶來影響。

不過，即使我們已經知道結果發生了變化，也不代表我們知道為什麼。

假設我們把原本需要幾個步驟的購買流程改成一鍵下單。功能上線之後，完成購買的比例明顯增加。按照原本設定的指標來看，這似乎是一個成功的改動。

然而過了一段時間，我們發現退貨率也一起上升了。

我們可以再提出假設：是不是商品資訊不夠清楚？是不是新版流程讓使用者沒有注意到數量？是不是付款完成頁面的資訊不夠明顯？然後繼續修改產品、等待數據、再提出下一個假設。

直到某天客服收到一封信：

我剛剛不小心按到購買，可以幫我取消嗎？

這時我們才發現，一鍵下單帶來的「改善」裡面，可能有一部分只是使用者誤觸。

整個系統沒有壞掉，事件也都正確送出，甚至我們原本觀察的指標真的變好了。但這仍然不是我們想要的結果。

如果更早建立直接取得使用者回饋的管道，我們可能不需要繞這麼大一圈。

PostHog 的 Survey 就提供了這樣的功能。

建立 Survey 時，可以直接從空白問卷開始，也可以選擇 PostHog 提供的 Template。

裡面包含 Open feedback，以及幾個常見的問卷類型：

• NPS（Net Promoter Score）：詢問使用者推薦產品的意願。
• CSAT（Customer Satisfaction Score）：詢問使用者對某次體驗的滿意程度。
• CES（Customer Effort Score）：詢問使用者完成某件事情需要花費多少力氣。

這幾個分數測量的是不同事情，並不能直接互相替代。NPS 關注推薦意願，CSAT 關注滿意程度，CES 則關注完成任務所需要的努力。選擇哪一種，仍然要回到我們真正想確認的問題。

Survey 可以設定不同類型的題目，也可以加入開放式回答。

回到剛才的一鍵下單案例，如果我們已經懷疑可能存在誤觸，就可以在使用者完成購買後詢問：

剛才這筆購買是你原本就打算完成的嗎？

或者進一步讓使用者描述實際發生的情況。

這就是 Survey 很適合使用的場景：我們已經有一個想確認的問題，想直接從使用者取得答案。

Survey 也不一定要對所有使用者顯示。

透過 Targeting，可以限制 Survey 顯示給特定條件的使用者。例如只詢問使用新版 Checkout 的人，或者搭配前面介紹的 Experiment，針對特定 Variant 的使用者取得回饋。

也可以透過事件控制顯示時機。這讓我們可以在問題剛發生、使用者還記得當時情境時取得回饋，而不是隔了很久才要求他回想。

完成設定後，就可以在 PostHog 中查看回答與結果。

如果同時有 Session Replay，也可以從回覆進一步查看使用者當時的操作，將他說的事情與實際行為放在一起理解。

不過 Survey 更重要的價值仍然是：直接取得那些不會自然出現在事件資料中的資訊。

怎麼問？

有了 Survey 功能之後，另一個問題就是：我們到底要問什麼？

PostHog 提出了幾個 Survey 的設計原則。

第一個是不要詢問已經知道答案的問題。

例如：

你一週大概使用我們的產品幾次？

如果我們本來就有 Product Analytics，使用頻率直接從事件資料查詢通常更準確，也不需要浪費使用者的時間。

第二個是詢問具體的問題。

與其問：

你覺得我們產品怎麼樣？

如果真正想了解的是 Checkout，就直接詢問使用者剛才的 Checkout 經驗。問題越明確，取得的回答通常也越容易採取行動。

第三個是避免引導問題。

例如：

新版 Checkout 是不是比以前方便很多？

這個問題已經暗示了我們期待的答案。即使心中已經有假設，也應該盡量用中性的方式詢問。

第四個是尊重使用者。

使用者來到產品並不是為了幫我們填問卷。選擇適合的時機、把問卷保持簡短，並且只問真正需要的問題。

Survey 提供了一個很低成本的管道，讓工程師可以直接向真實使用者確認問題，而不是永遠只能從數據猜測。

不過它仍然有一個很明顯的限制：

我們得先知道要問什麼。

如果我們已經懷疑一鍵下單造成誤觸，就可以用 Survey 確認；但如果真正的問題完全不在我們的想像之中，我們可能連正確的問題都沒有寫進問卷。

這時候，繼續增加選項未必能幫助我們找到答案。有時候，我們需要和少數使用者進行更深入的對話，沿著他們的回答繼續探索。

下一篇，我們會暫時離開 PostHog，來看看另一種取得使用者資訊的方法：使用者訪談（User Interview）。

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見