談 Threads 數據時，最容易混在一起的是三種來源：公開頁面看得到的數字、帳號本人在洞察裡看得到的數字，以及官方 API 實際回傳的欄位。它們不是同一件事，也不能用其中一種資料，直接替另一種資料補答案。
本文依 Meta 官方文件於 2026 年 7 月 22 日重新查核。Threads API 仍會更新；實際開發、除錯或查核時，請再回到文末的官方原始文件確認。
先看答案：資料來源決定你能回答什麼
| 資料來源 | 適合回答 | 不能直接回答 |
|---|---|---|
| Threads 公開頁面 | 一則公開內容目前呈現的文字、時間與部分互動 | 帳號本人才能看到的洞察、完整歸因 |
| Media Insights API | 自己貼文的瀏覽、喜歡、回覆、轉發、引用、分享 | 這篇貼文帶來多少追蹤 |
| User Insights API | 個人檔案瀏覽、帳號內容的彙總互動、目前追蹤總數 | 哪一篇造成追蹤增加 |
| 帳號本人的單篇洞察 | 介面當下提供的單篇成效欄位 | 介面未提供的歷史資料或因果證明 |
所以，分析前不要只問「有沒有這個數字」，而要先問：
- 它來自 API、帳號洞察，還是公開頁面？
- 它描述單篇內容、整個帳號，還是一段期間？
- 它是實際取得、尚未取得，還是自行推估？
單篇貼文可以取得哪些 Insights？
官方 /{threads-media-id}/insights 端點目前列出的 Media Insights 包含：
| 指標 | 官方定義要點 | 判讀提醒 |
|---|---|---|
views |
貼文被播放或顯示的次數 | 官方仍標示為開發中的指標 |
likes |
貼文的喜歡數 | 代表一種互動，不等於追蹤意願 |
replies |
貼文的回覆數 | 根貼文包含總回覆；回覆本身只計直接回覆 |
reposts |
貼文被轉發的次數 | 與引用貼文分開計算 |
quotes |
貼文被引用的次數 | 引用可能帶入新的敘事脈絡 |
shares |
Threads 貼文的分享次數 | 官方仍標示為開發中的指標 |
還有兩個容易忽略的限制：
- 回傳的單篇指標不會把巢狀回覆各自收到的互動全部加回根貼文。
REPOST_FACADE代表其他使用者建立的內容，查詢 Insights 時會回傳空陣列。
這表示「回覆很多」不一定等於每一層對話的互動都已被完整彙總。若要分析對話深度，必須另外讀取回覆關係，而不是只看根貼文的一個數字。
User Insights 是帳號層級，不是單篇歸因
User Insights 目前包含個人檔案瀏覽，以及帳號內容的喜歡、回覆、轉發與引用等彙總指標，也提供 followers_count 與追蹤者人口統計。
其中最容易被誤用的是 followers_count：
- 它代表查詢當下的 Threads 追蹤總數。
- 它不支援用
since、until取得某段期間的追蹤變化。 - 即使每天保存一次，也只能得到兩個時間點之間的帳號淨變化。
假設星期一總追蹤是 10,000，星期二是 10,080，我們只知道帳號淨增加 80。這 80 可能同時受到舊貼文、個人頁、搜尋、回覆、外部分享與取消追蹤影響，不能平均分給當天的貼文，也不能全部歸給其中瀏覽最高的一篇。
如果你接下來要比較內容，請先看如何確認分子、觀察窗口與追蹤轉換率，不要把帳號總追蹤差值當成單篇追蹤。
能不能取得「這篇帶來幾個追蹤」？
Media Insights 清單裡沒有單篇 follows 指標。
以本文更新時的脆稿 v1.1.0 為例，程式會由使用者在專用 Edge 親自登入後，讀取帳號本人原本就能看到的單篇 Threads 洞察。這項資料來自帳號本人的網頁介面，不是用 User Insights 的 followers_count 反推。
這裡有三條必要規則：
- 取得到的單篇追蹤才參與計算。
- 尚未取得時顯示「待擷取」，不寫成 0。
- 介面欄位若改變或讀取失敗，要保留失敗狀態，不用帳號差值補上。
0 代表已確認沒有追蹤；未知則代表還不能回答。把未知寫成 0，會讓平均值、排行榜與轉換率全部偏低。
官方 API 還能讀取哪些內容？
對已授權的帳號，官方 API 可以分頁取得自己建立的 Threads，以及 ID、文字、發布時間、永久連結與媒體類型等欄位。
Reply Management API 則能處理不同的回覆關係：
/{media-id}/replies取得指定內容下的頂層回覆。/{media-id}/conversation取得攤平後的頂層與巢狀回覆。/{threads-user-id}/replies取得某位使用者建立的回覆清單。root_post與replied_to可協助分辨根貼文及直接回覆對象。
這不等於可以任意下載任何人的完整帳號。實際能取得的欄位，仍取決於端點、內容公開狀態、帳號關係、Access Token 與應用程式權限。
權限與 Access Token 代表什麼？
依官方文件，讀取 Threads Insights 至少需要：
threads_basic：呼叫 Threads API 端點的基礎權限。threads_manage_insights：讀取 Insights 端點。
不同端點仍受各自的授權範圍限制。Access Token 是代表授權範圍的憑證，不是 Threads 密碼，也不表示應用程式能跨越官方權限取得所有資料。
因此，看到 API 回傳空值或錯誤時，應依序檢查：
- 查詢的是媒體節點還是使用者節點？
- Token 是否仍有效，且具備正確權限？
- 內容是否屬於可讀取的帳號或關係？
- 指標是否適用於這種媒體類型？
- 空陣列、0 與請求失敗是否被分開保存？
如果你關心 Token 與資料實際保存在哪裡，可以接著看脆稿為什麼採本機優先。
一張圖表至少要說清楚四件事
無論使用哪一套 Threads 分析工具，一張可信的圖表至少要能回答：
- 來源：官方 API、帳號洞察、公開頁面或人工輸入？
- 層級：單篇、帳號總計，還是期間彙總？
- 時間：查詢當下、發布後 24 小時，還是固定日期區間？
- 缺值：未知、讀取失敗與真實的 0 是否分開？
這四件事沒有說清楚，再漂亮的轉換率或排行也可能只是把不同層級的資料放在一起計算。
如果你已經遇到「瀏覽很高、追蹤卻沒動」的情況，先不要急著怪演算法；可以用高瀏覽低追蹤的診斷流程分辨是資料缺漏、題目偏移，還是個人頁沒有接住讀者。
常見問題
官方 API 可以直接取得單篇追蹤數嗎？
目前 Media Insights 沒有單篇 follows。followers_count 是帳號總追蹤數，不能替代單篇追蹤。
每天記錄 followers_count，就能推算昨天哪篇帶來追蹤嗎？
不能。你可以知道帳號淨變化，但無法從總數差值證明每一篇的貢獻。
API 回傳空陣列，是否代表互動為 0？
不一定。媒體類型、權限、內容關係或 REPOST_FACADE 都可能影響結果。空陣列、請求錯誤與數值 0 應分開保存。
可以用 API 分析任何競品帳號嗎？
不能把「公開可見」理解成「API 能完整讀取」。端點與欄位都受帳號關係、公開狀態與授權限制。
官方文件與本文邊界
本文整理的是「這些資料能回答什麼」，不是 API 開發教學。實際串接請以 Meta 官方文件為準：
最安全的原則仍然是：資料來源與未知值規則說得清楚，後面的比較才有意義。