資料與報表
在月結報表之前發現異動
轉換率在四號開始下滑。月結報表在下個月三號才顯示出來，那時已經沒有人記得中間改動過什麼。每日盯住並不困難。困難的是每日盯住而不變成背景雜音，而這件事完全取決於門檻定在哪裡。一個幾乎每朝都響的提示，兩星期內就會被靜音；而被靜音的提示比沒有提示更差，因為它令所有人繼續相信有東西在看著。
- 觸發
- 兩個
- 執行頻率
- 每日一次，每季檢討區間
- 工具
- 3 件
- 需要 durable execution
- 不需要
流程
上面那條累積用來定義「正常」的歷史。下面那條由這段歷史重新推算區間，把昨日的數字放進去比較，除非異動持續，否則保持沉默。
每朝一次
n8n 排程
取回昨日數字
n8n · Make
寫入歷史表
Sheets · Airtable
每季重設區間
Manual
計算正常區間
n8n · Make
連續兩日超出區間？
n8n IF
一句話：什麼動了、動了多少
Slack · WhatsApp
保持沉默
—
逐步拆解
- 01
每朝一次
n8n 排程一日一次，在平台過夜結算之後。每小時查一次並不會令你更早發現，只會增加對著一個仍在改寫的數字作出反應的機會。
- 02
取回昨日數字
n8n · Make轉換率和 CPM，每個帳戶各一個數值。同時盯住三十個指標，單憑機率就會幾乎每日產生一次提示，而那時根本未有任何事情出錯。
- 03
寫入歷史表
Sheets · Airtable一個指標一日一行，長期保留。這裡的歷史不是存檔，而是用來決定什麼算異常的輸入；只有三星期歷史的監察，幾乎沒有東西可以比較。
- 04
每季重設區間
Manual第二個觸發，也是令這件事長期可用的關鍵。一盤生意若然真的變了——新渠道、新定價——它就有了新的正常水平；用舊水平算出來的區間會一直響下去。重新擬合是一個判斷，所以留給人做。
- 05
計算正常區間
n8n · Make取過去若干週的同一個星期幾，再按這個數字本身的上落幅度定出區間——常見做法是取平均值上下各三個標準差。不要隨手挑一個整數百分比。一個逐週上落兩成的指標，會不停觸發一條一成的規則；而一個平穩的指標，則會把真正的百分之八變動藏在規則背後。
- 06
連續兩日超出區間？
n8n IF「第二日」正是分別所在。即使什麼都沒有改變，偶爾出現一點超出區間也屬預期之內；要求持續兩日，可以除去其中大部分，代價是遲一日，而相對於一個月，這是划算的交換。
- 07
一句話：什麼動了、動了多少
Slack · WhatsApp寫明指標、昨日數值、離開了哪一個區間、已經持續多久。不要寫原因——這套機制偵測的是變化，不是成因。附上一個猜出來的解釋，正是提示失去信任的方式，因為猜錯的次數足以連帶推翻那些偵測得對的結論。
數據說不出的事
第一項界定昨日那個數字有多實在。之後兩項解釋為什麼門檻是推算出來、而不是揀出來的，以及為什麼星期一和星期六的同一個數字並不是同一個數字。
Meta 的廣告成效數據「refresh every 15 minutes and do not change after 28 days of being reported」。所以昨日那個數字仍屬暫定；根據它發出的提示，是對著一個尚未定下來的數字發出——這也是「要連續兩日才通知人」的另一個理由。
Meta Marketing API — Insights best practices抽象地講並不存在一個正確的門檻；它由流程本身的離散程度推算出來。「It is an acceptable practice to base the control limits upon a multiple of the standard deviation. Usually this multiple is 3.」而按指定機率設定的界限，本身帶著一個明確的誤報率——在 0.001 界限之下，即使一切正常，「the probability of a point falling above the upper limit would be one out of a thousand」。把區間收窄，換來的是更早發現，付出的是更多誤報；這個取捨決定了這個提示能否活得下去。
NIST/SEMATECH e-Handbook — What are control charts?跨時間收集的資料「may have an internal structure (such as autocorrelation, trend or seasonal variation) that should be accounted for」。把所有日子混在一起擬合出來的區間，會把每個週末當成異常，同時錯過真正的平日變動；所以比較的對象是同一個星期幾，而不是平坦的過去三十日。
NIST/SEMATECH e-Handbook — Introduction to time series analysisSheets 每個專案每分鐘容許 300 次讀取和 300 次寫入，每個使用者每分鐘 60 次；配額每分鐘重新補滿，之上沒有每日上限。每次執行重讀一次完整歷史，遠在這個範圍之內；每個帳戶每個指標各讀一次，就是把它用超的做法。
Google Sheets API — Usage limits
什麼情況不值得做
以下三種情況，維護成本會高於遲些才發現的代價。
你的每日歷史還不足幾個月。區間是由這段歷史算出來的，歷史太短，監察就會變成什麼都響或什麼都不響，而兩種結果都在教人不要理會它。
每日成交量小到單憑隨機波動就可以令比率上落三分之一。在這個規模之下，幾乎每一日都算異常，任何門檻都分不出真正的變化和一個普通的星期二。
提示響起的當日沒有人可以處理。比月結報表早三星期發現一個變動，只有在有人當日就能去看的前提下才值得維護；否則你只是造了一條更快的路，去在同一個時間知道同一件事。