如何隨時間追蹤 Facebook 貼文指標的變化

如何設定你的歷史表

良好的追蹤表需要簡單、清楚的欄。你不需要複雜軟件或艱深技術詞語來設定。每次從貼文收集公開資料時，都儲存一列新資料，並包含核心細節，例如 Content ID、Observation Time、Metric Name、Metric Value 和 Precision。

當你使用 Chronometrica Facebook Metrics Scraper 提取公開資料時，這個工具會把列傳回它的 Apify dataset，而執行摘要則儲存在 key-value storage（OUTPUT）。你的團隊之後把那些 dataset 列匯入永久歷史表。你也可以在內部表加入 run ID 欄，把同一次收集批次中檢查過的所有貼文歸為一組。這個 run ID 是在收集器完成之後，從你的下游工作流程元資料加入。這個抓取工具本身會收集公開頁面並傳回結構化資料，但不會直接寫入你的資料庫、發送自動警示，或代你儲存歷史。

閱讀公開資料時，要把各個計數名稱分開。觀看次數、播放次數、心情、讚好、留言和分享量度不同動作。在原始日誌表內，把兩個不同計數合成一條自製公式，會令歷史難以理解。如果你想檢視基本互動定義，請看我們關於 Facebook 貼文表現公開資料 的指南，當中有清楚的設定步驟。

按固定時間表收集資料

要看到清楚的模式，你需要按簡單、重複的時間表檢查目標貼文。人手複製和貼上會花太多時間，並導致漏掉日子和紀錄中斷。

你可以使用 Chronometrica Facebook Metrics Scraper 自動收集公開指標數字。這個工具接收一份公開 Facebook 連結清單，造訪那些公開頁面，並傳回目前可見的數字。

你可以使用排程工具，例如 Apify Schedules，按既定模式執行收集工具。不過請緊記，排程是目標指引，而不是保證準時的時鐘。排定的執行可能因網絡流量或系統隊列而延遲開始。因此，請永遠記錄抓取工具成功讀取貼文時的確實觀察時間（scrapedAt），而不要假設它在一個同步的整體完成時間執行。

例如，管理某項指定宣傳活動的團隊，可能選擇在第一天每四小時檢查新貼文，其後兩星期每天同一時間檢查一次，較舊的貼文則每星期檢查一次。這個時間序列只是一項宣傳活動的說明性工作流程例子，不是每個設定都必須採用的已證實規則。

如何處理資料缺口和跳過的檢查

公開收集工具讀取公開網頁。有時網頁載入失敗、網絡連線中斷，或 Facebook 暫時隱藏頁面。當一次檢查失敗，收集工具會把該貼文留在主要輸出之外，或把它記錄在另一份跳過列的清單（SKIPPED_DATASET_ROWS）。

你如何處理這些缺失的檢查，決定歷史是否保持準確。檢查失敗時，你必須遵守三條實用規則：

第一，缺失的檢查絕不是零。如果收集器在下午四時漏掉一則貼文，不要在觀看次數欄輸入 0。輸入零表示貼文失去全部觀看次數，這會破壞你的平均值，並在圖表上造成虛假下跌。讓該列保持缺失，或在狀態欄寫上 skipped。

第二，不要編造假數字來填補缺口。不要猜測在漏掉的時段中途，數字可能是多少。猜測會把錯誤帶進歷史表。

第三，計算跨越缺口的變化時，要調整時間計算。如果下午四時的檢查失敗，晚上八時下一次成功的檢查，必須與中午那次檢查比較。這兩次良好檢查之間的時間是八小時，不是四小時。

如何計算變化和速度

比較兩次讀數之前，請確認你對上完全相同的內容身分、相同的指標標籤、相同的來源定義，以及相同的精確度級別。從播放次數減去觀看次數，或比較兩則不同貼文，會得出無效數字。

表現的變化稱為 delta。計算 delta 的方法，是就完全相同貼文上完全相同的指標，用較新的數字減去較舊的數字。

要知道貼文增長有多快，把該變化除以兩次檢查之間實際經過的小時數：

每小時增長率 = (新數字 - 舊數字) / 經過小時數

一個虛構的逐步演算例子

讓我們看一個明確標明為虛構的例子。例子只用單獨一則貼文，說明這些計算如何運作。在這個虛構情境中，我們在四次計劃中的檢查裡追蹤一則宣傳活動影片，記錄確實數字，處理一次錯過的執行，並計算真正的增長速度。

第一次檢查在上午 8:00，貼文顯示 1,200 次觀看。

第二次檢查在中午 12:00，貼文顯示 1,800 次觀看。

第三次檢查在下午 4:00，收集執行失敗，貼文被跳過。沒有新列儲存到主表。

第四次檢查在晚上 8:00，貼文顯示 1,750 次觀看。

現在讓我們逐步處理這些數字，看看這一天發生了甚麼。

由上午 8:00 到中午 12:00，剛好經過 4 小時。觀看次數由 1,200 增至 1,800。變化是 1,800 減 1,200，等於 600 次觀看。要得出每小時增長率，把 600 次觀看除以 4 小時。結果是每小時 150 次觀看。這顯示早晨穩定增長。

下午 4:00，檢查失敗。我們不寫零，也不編造假數字。我們只記下下午 4:00 沒有有效資料點。

晚上 8:00，檢查成功，顯示 1,750 次觀看。要計算變化，請回看上一次良好檢查，即中午 12:00 的 1,800 次觀看。中午 12:00 至晚上 8:00 經過的時間是 8 小時。變化是 1,750 減 1,800，等於 -50 次觀看。

要得出這 8 小時時段的每小時增長率，把 -50 次觀看除以 8 小時。結果是每小時 -6.25 次觀看。

理解下跌與平台數字

在我們的虛構例子中，觀看次數在中午至晚上八時之間由 1,800 跌至 1,750。當營銷人員看到這樣的下跌，公開收集器記錄的是公開網頁上顯示的數字，但無法告訴你變化背後的內部原因。公開計數下跌會因各種平台原因而發生，外部工具無法核實這些原因。當計數下降時，不要猜測或假定某個特定原因。只需把真實下跌作為一次真實觀察記錄在表中。

如果你需要分析公開留言串，或查看貼文上的文字回饋，請閱讀我們關於 Facebook 留言與客戶回饋分析 的指南，當中有實用步驟。如果你想進一步了解公開影片標籤如何不同，請閱讀我們關於 Facebook 影片觀看次數、播放次數和觸及 的指南，以理解每個計數的意思。

你也必須小心處理約整數字。Facebook 經常顯示簡短摘要數字，例如 1.2K，而不是完整數字，例如 1,243。當你用約整數字計算變化時，那些計算出的 delta 只是近似值，不是確實數字。

此外，一個沒有改變的約整顯示，並不能證明活動為零。如果貼文在星期一顯示 1.2K 次觀看，星期二仍然顯示 1.2K 次觀看，人們可能仍在觀看影片。總數只是尚未到達下一個公開跳點，例如 1.3K。絕不要只因為畫面上的約整摘要標籤保持不變，就假定貼文的新增觀看次數為零。

決定何時檢視一則貼文

與其設定僵硬的警示規則或依賴自動軟件警告，不如把貼文目前的增長速度與其過去模式比較，再作檢視。增長速度突然轉變，或出現負 delta，就是檢視該貼文的理由；單靠計數無法知道其原因。當貼文的增長速度明顯改變、較舊貼文出現突然變動，或你記錄到精確度為確實數字的負 delta 時，請仔細查看該貼文。

把每次檢查都儲存為新列，妥善處理錯過的執行，並按實際經過的小時做簡單計算，你就建立一份清楚的歷史，準確顯示你的 Facebook 貼文表現如何。