跳至主要內容

內容與發現

哪篇貼文出現在訂單之前

你想知道哪一篇貼文帶來了訂單。時間軸比對能夠告訴你的,比這個窄,而且正因為窄才有用:哪些貼文出現在一段異常訂單之前。那是一份值得追查的名單,不是因果。平台數據裡面沒有一條由觀看者通往買家的路徑,所以比對得再多也造不出一條——而一個容許別人把輸出當成歸因的流程,比沒有流程更差,因為它令一個猜測看起來像是查核過的結論。

觸發
兩個
執行頻率
每晚一次
工具
5 件
需要 durable execution
不需要

流程

上面那條記錄發出了什麼、什麼時候發。下面那條把當日訂單與基準比較。兩邊在時間上交匯,而時間是這兩組數據唯一共用的鍵。

平台

貼文發出

Instagram Graph API

編排

為貼文分類

OpenAI · Anthropic

資料

一篇貼文一行

Sheets · Airtable

編排

每晚一次

n8n 排程

編排

取出當日訂單

n8n

編排

區間內是否高於基準?

n8n IF

通知

標記為值得追查

Slack · WhatsApp

編排

不作標記

逐步拆解

  1. 01

    貼文發出

    Instagram Graph API

    記錄它實際發佈的一刻,數字由平台讀取,不是由日曆讀取。預定時間與實際發佈時間並不是同一個時間戳,而整件事都建立在時間戳之上。

  2. 02

    為貼文分類

    OpenAI · Anthropic

    由模型讀取文案,按一份固定清單指派主題——產品、創辦人、客戶故事、優惠。它只做分類,不做別的。現在設定的標籤,就是日後唯一可以分組的維度,而自由填寫的標籤不算維度。

  3. 03

    一篇貼文一行

    Sheets · Airtable

    貼文 ID、發佈時間、平台、主題、格式。這裡完全不放訂單資料——兩邊維持分開,直到比對那一步,讓任何人都看得出接縫在哪裡。

  4. 04

    每晚一次

    n8n 排程

    在當日結束之後才跑,讓整日對整日。把一個未完的日子拉進比較,是製造出一個結論最容易的方法。

  5. 05

    取出當日訂單

    n8n

    訂單時間與金額,加上該星期幾的基準。星期二應該跟其他星期二比;拿它跟上星期六比,得出的是一個關於星期六的發現。

  6. 06

    區間內是否高於基準?

    n8n IF

    選一個你解釋得到的區間——例如發佈後 48 小時——以及一個已經計入星期幾、也計入當日其他活動的基準。問題是訂單有沒有異常,不是貼文有沒有奏效。

  7. 07

    標記為值得追查

    Slack · WhatsApp

    訊息寫明發出了什麼、什麼時候,以及該區間內的訂單與基準相差多少。它不會說貼文造成了訂單,因為數據支持不到,而這句訊息一定會被引用。這段文字要在上線之前吵完,不要等到有人把它放進董事會文件之後。

平台不容許的事

相關與因果之間那個距離,不是靠工程繞得過的分析缺陷,而是寫在這些介面返回什麼之內。

  • 「Data used to calculate metrics can be delayed up to 48 hours.」每晚比對讀到的是仍在變動的數字,所以第一輪只是暫定,而表格要標明哪些行已經穩定下來。

    Instagram Platform — Instagram Media Insights
  • 媒體洞察返回的是彙總數字——views、reach、shares、saved、total_interactions——不包含觀看者身分。限時動態的指標在少於五位觀看者時會返回錯誤碼 10:「Not enough viewers for the media to show insights」。這些數據裡沒有一條由觀看者通往買家的路徑,這正是為何比對只能以時間為鍵。

    Instagram Platform — Instagram Media Insights
  • 「You will not engage in Automated Data Collection without first obtaining Meta's express written permission.」缺失的身分連結不可以靠自己去收集補回,所以相關性是上限,不是第一版。

    Meta — Automated Data Collection Terms
  • YouTube 專案的預設配額是「100 search.list calls, 100 videos.insert calls, and 10,000 units per day combined for all other endpoints」。如果比對也涵蓋影片,每晚的抓取速度由此決定,而回補歷史數據必須分成多日進行。

    YouTube Data API — Getting started (quota)

什麼情況不值得做

以下三種情況,維護成本會高於少了一份報表的代價。

  • 只有一個渠道,一星期一篇。時間軸短到可以直接讀完,比對只是為一件已經看得見的事加上算術。

  • 你的訂單由人手在事發幾小時後補入。把一個粗略的時間戳跟一個準確的時間戳相接,會得出一張外表可信、底下卻建在較粗略那一邊的表;而這張表的壽命,會比任何人記得這項但書的時間更長。

  • 無論那一欄怎樣命名,上頭都會把標記讀成歸因。如果輸出注定被引用成「這篇貼文帶來 X 單」,誠實的選擇是不要做——一份被當成證據的候選名單,破壞力大於它所取代的那個空白。

延伸閱讀

聯絡我們

這些流程,你真正應該做哪一條?

我們每星期都在為香港的營運團隊跑這些流程。告訴我們哪個環節正在耗你的時間,我們會告訴你自動化划不划得來。

開始對談