# 如何在內容報告中區分 X 原始貼文、回覆與引用

查核每則已知貼文在公開頁面中的脈絡，以區分 X 的原始貼文、回覆與引用貼文。每則不同的帳號自撰貼文只儲存一筆紀錄。每則符合納入條件的貼文只分配一個主要類別。保留回覆對象與被引用貼文的連結，作為參考。無法確定的類型應標示為待釐清。不要把被引用的來源貼文或重複網址，算成研究帳號另外撰寫的一則貼文。

回覆是對另一則貼文作出回應。引用貼文則是在分享另一則貼文時加入內容。在本報告中，原始貼文是指經過查核，確認既非回覆、也非引用的帳號自撰貼文。回覆也可能包含引用。這種貼文只計為一則回覆，並另外記錄是否包含引用。

先進行人工查核，並建立已知貼文登記表。登記表是儲存貼文及其證據的清單。如果你已獲准使用帳號擁有者匯出的資料，可以使用這些資料。蒐集公開指標有助於這項工作，但不能取代確認作者與貼文類型所需的查核。

結果應回答買方問題「他們哪些推文的表現最好」中範圍較明確的版本：在各類別及既定觀測規則下，哪些已查核貼文獲得了所述的公開回應？提供的[公開提問紀錄](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)支持這項報告需求，但不能據此判定需求規模，或哪一種貼文類型表現最佳。

## 1. 定義帳號、樣本與計數單位

分類貼文前，先列出帳號清單。記錄你會接受的帳號識別碼。識別碼又稱 ID，是用來區分不同帳號或貼文的值。

明確列出打算查核的已知貼文，作為樣本。如果也設定發布日期條件，請記錄這些日期。提供的網址清單是經過挑選的樣本，不能證明它涵蓋帳號的完整歷史紀錄。

以每則不同的帳號自撰貼文作為計數單位。單位是指每個計數所代表的事物。請分開記錄下列單位：

- 請求網址：你提交以供蒐集資料的網址。
- 不重複貼文：透過這些請求找到，並已查核貼文 ID 的貼文。
- 帳號自撰貼文：作者符合帳號清單的不重複貼文。
- 已分類貼文：主要類型已經查核的帳號自撰貼文。
- 指標觀測紀錄：在指定時間儲存的計數器讀值。

同一則貼文可能對應多個請求網址，也可能有多筆指標觀測紀錄。這兩種情況都不會增加帳號自撰貼文的數量。

如果必須先找到貼文才能查核，請將尋找貼文視為另一項資料蒐集工作。[依關鍵字與日期搜尋 X 貼文](/zh-Hant/articles/%E6%8C%89%E9%97%9C%E9%8D%B5%E5%AD%97%E5%8F%8A%E6%97%A5%E6%9C%9F%E6%90%9C%E5%B0%8B-x-%E5%B8%96%E6%96%87/)指南說明了這個範圍界線。搜尋結果仍須經過身分與類型查核，才能納入本報告。

不要用收到的互動來判定帳號撰寫了哪些貼文。貼文的公開回覆計數器，記錄的是該貼文收到的回覆，不是作者撰寫了多少則回覆貼文。收到的引用與轉發計數，也應採用相同區分。

## 2. 查核已知網址，並保留傳回的身分資料

Actor 是託管的資料蒐集程式。[X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics) 的文件記載了適用於這項工作的功能：它接受已知的公開 X 或 Twitter 貼文網址，並傳回嘗試擷取指標快照的資料列。快照是某個觀測時間的一次讀值。

於 2026 年 10 月 25 日查核並凍結留存的公開規格，說明的是建置版本 1.0.4。它透過 `startUrls` 接受 1 至 1,000 個網址。它不會搜尋貼文，也不會傳回帳號封存資料。這些是文件記載的功能，並非為本指南執行後取得的結果。請參閱[已查核的公開建置規格](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)。

規劃首次查核時，可使用以下簡短的輸入格式：

```json
{
  "startUrls": [
    "https://x.com/OpenAI/status/2077446718728425686"
  ]
}
```

2. 查核已知網址，並保留傳回的身分資料

請將範例網址換成你所界定樣本中的一則已知公開貼文。提供的輸入格式有效，但本指南未使用它執行任何作業。加入更多已知網址前，先檢查第一筆傳回的資料列。

Task 是為 Actor 儲存的預設輸入設定。查核時，公開的 [X Campaign Post Metrics Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics) 頁面存在。但未透過已驗證的帳號讀取其儲存設定，也未執行該 Task。使用前請先檢查輸入。

請將請求網址 `inputUrl` 與傳回的貼文網址 `postUrl` 分開保留。同時保留傳回的貼文 ID `postId`，以及傳回的作者帳號 ID `profileId`。

處理轉發網址時，這項區分很重要。目前的公開 README 說明，轉發輸入所對應的資料列描述的是畫面上可見的原始貼文。傳回的身分、作者、文字與指標，都屬於該原始貼文。請保留請求與貼文之間的對應關係。不要把這項請求算成轉發帳號另外撰寫的一則原始貼文。[公開建置與 README 證據](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)記載了這項行為。

## 3. 儲存對應關係、貼文登記表與指標觀測紀錄

不同單位應使用不同表格。紀錄表是用來儲存判定及其支持證據的表格。以下欄位名稱是建議讀者使用的紀錄表欄位；只有以反引號標示的 Actor 原始欄位名稱例外。

首先，為每筆嘗試處理的輸入儲存一筆請求對應紀錄。

| 儲存欄位 | 用途 |
| --- | --- |
| 請求參照編號 | 區分每個提交的網址 |
| `inputUrl` | 保留請求網址 |
| `postUrl` 與 `postId` | 記錄傳回的貼文身分資料 |
| `profileId` | 記錄傳回的作者身分資料 |
| `status` 與 `statusReason` | 保留傳回資料列的處理結果與原因 |
| `observedAt` | 記錄該資料列的觀測時間 |
| 對應關係判定 | 註明身分已查核或仍待釐清 |

接著，為每個已查核的不重複貼文 ID 建立一筆貼文登記紀錄。

| 儲存欄位 | 用途 |
| --- | --- |
| 已查核的貼文 ID | 確保一則貼文只算一個單位 |
| 作者與帳號清單的比對結果 | 顯示作者是否應納入報告 |
| `postType` | 原樣保留文件記載的類型線索，不加以改寫 |
| 主要類別 | 記錄經查核後判定為原始貼文、回覆、引用，或待釐清 |
| 是否包含引用 | 記錄已確認有、已確認無，或未知 |
| 回覆對象貼文連結 | 在需要時保留人工查核的回覆關係 |
| 被引用貼文連結 | 在需要時保留人工查核的引用關係 |
| 類型證據與原因 | 說明判定及任何不確定之處 |
| `publishedAt` | 保留傳回的發布時間 |
| 納入資格判定 | 註明此貼文是否納入分類報告 |

線索是有助於作出判定的證據。請將 Actor 原生提供的 `postType` 視為文件記載的線索。如果分類需要作出單靠該資料列無法確認的區分，請查核公開頁面的脈絡。

這份紀錄表中的回覆對象與被引用貼文連結，是讀者自行補充的證據。Actor 規格未提供回覆對象或被引用貼文 ID 的匯出。不要把人工新增的欄位當作 Actor 原生輸出。

最後，另外儲存指標觀測紀錄。保留貼文 ID、指標名稱、數值、`observedAt`、發布時間、指標狀態、精確程度與來源。精確程度用來描述數值有多精確。重複讀值應保留為同一則貼文的多筆觀測紀錄。

這些欄位都是文件記載的輸出欄位。但有文件記載，不代表每筆嘗試取得的資料列都會有可用值。這項區分應以[已查核的輸出規格](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)為準。

## 4. 套用單一主要類別規則

加總各類別前，先寫下規則。本報告採用以下順序：

1. 確認貼文 ID 與作者都已查核。
2. 確認作者符合已界定的帳號清單。
3. 如果貼文經查核確認為回覆，將主要類別設為回覆。
4. 否則，如果經查核確認為引用，則歸為引用。
5. 其餘貼文只有在公開頁面的脈絡支持此判定時，才歸為原始貼文。
6. 無法確定的類型應保留為待釐清。

這項規則讓各類別互斥，也就是每則符合納入條件的貼文只能歸入一個主要類別。

對於包含引用的回覆，將類別設為回覆，並將「是否包含引用」保留為「有」。如果分析需要，請儲存兩種參考連結。不要再把同一則貼文計入引用類別。

請將參考來源的記錄與帳號自撰貼文的計數分開。被引用的來源貼文有助於說明作者分享了什麼，但不會因此成為該帳號另外撰寫的一則貼文。如果來源貼文本身也獨立屬於你界定的樣本，請為它建立自己的查核紀錄，並套用相同的作者判定規則。

關係欄位缺失，不代表該關係不存在。尤其是原生輸出沒有回覆對象或被引用貼文 ID，這屬於輸出規格的限制，不能據此認定貼文沒有回覆對象或引用來源。

如果兩筆觀測紀錄對類型的判定不一致，請保留兩份證據。透過公開頁面的脈絡查核來解決衝突，或將類型保留為待釐清。不要為了得到偏好的結果而選擇類別。

## 5. 計算前，先定義回應的比較方式

選定一項指標，並明確寫出觀測規則。指標是測量的數量，例如公開瀏覽次數或按讚數。沒有另行定義時，不要將不同計數器的數值相加。

請將帳號撰寫的貼文類型與收到的回應分開。引用類別的貼文也可能收到回覆、轉發與引用。這些收到的互動計數，描述的是對該則貼文的回應，不會改變其類別，也不會在登記表中增加貼文。

比較觀測紀錄時，請記錄貼文發布後經過的時間，也就是從發布到讀取指標之間的時間。發布後不久讀取的計數器與很久之後讀取的計數器，涵蓋的時間範圍不同。如果缺少發布時間，就無法得知這段時間。不要以 `observedAt` 代替 `publishedAt`。

Actor 文件記載，`postMetricStatus` 項目包含指標、狀態、精確程度與來源。狀態可以是 `present`、`unavailable` 或 `not_attempted`。精確程度可以是 `exact`、`unavailable` 或 `unknown`。每項使用的指標都應保留這些值。不要因為一項指標可用，就認定六項指標全都可用。

事先寫下品質規則。例如，報告可以要求數值存在、精確程度為精確，且有註明來源。這是建議讀者採用的規則，不代表已有執行結果符合這項規則。

缺失值應維持缺失。傳回的零則是測得的數值。不要為了補齊表格，把缺失的計數器值改成零。貼文可以已有查核確認的類別，但仍不符合指標資料列的納入條件。

每個類別都應列出已分類貼文數，以及符合條件的指標筆數。總值只應涵蓋符合條件的觀測紀錄。如果列出平均值，請以該指標符合條件的貼文數作為除數。平均值是總值除以納入的貼文數。當貼文數為零時，平均值無定義。

公開讀值與僅限帳號擁有者查看的報告數值，可能有不同的定義與時間範圍。如果你已持有獲准使用的匯出資料，請將它保留為獨立來源。在將兩種數值視為相等之前，請先參閱[公開計數器與帳號擁有者匯出資料比較指南](/zh-Hant/articles/%E6%A0%B8%E5%B0%8D-x-%E5%85%AC%E9%96%8B%E8%A8%88%E6%95%B8%E5%80%BC%E8%88%87%E8%87%AA%E6%9C%89%E5%88%86%E6%9E%90%E5%8C%AF%E5%87%BA%E8%B3%87%E6%96%99/)。

## 6. 逐步演算一個標示為原創虛構的範例

原創虛構範例。本例所有標籤與計數均為虛構，並非 Actor 結果、Task 結果或真實貼文 ID。

六個提交的網址對應到五則不重複貼文。其中兩個網址對應到 P1，其餘四個分別對應到 P2、P3、P4 與 U1。

| 虛構請求 | 對應的虛構貼文 |
| --- | --- |
| R1 | P1 |
| R2 | P1 |
| R3 | P2 |
| R4 | P3 |
| R5 | P4 |
| R6 | U1 |

範例中經查核的分類如下：

| 虛構貼文 | 主要類別 | 是否包含引用 | 虛構瀏覽次數 |
| --- | --- | --- | --- |
| P1 | 原始貼文 | 範例未註明 | 100 |
| P2 | 回覆 | 範例未註明 | 40 |
| P3 | 引用 | 有，依據已查核的引用類別確認 | 200 |
| P4 | 回覆 | 有 | 60 |
| U1 | 待釐清 | 未知 | 缺失 |

「未註明」不代表已確認沒有。實際紀錄表必須保留每項判定背後的證據。在本例中，U1 沒有可用的瀏覽次數，其缺失值不是零。

貼文數的計算如下：

- 6 個請求網址對應到 5 則不重複貼文。
- 5 則不重複貼文包括 4 則符合納入條件的已分類貼文，以及 1 則待釐清貼文。
- 4 則符合納入條件的已分類貼文，包括 1 則原始貼文、2 則回覆與 1 則引用貼文。

P1 雖然對應兩次請求，仍只計為一則貼文。P4 只計為一則回覆。它的引用標記仍會顯示，但不會增加第二筆分類紀錄。

這份虛構回應表依照範例的既定前提，使用相互匹配的瀏覽次數觀測紀錄。範例沒有提供實際的發布或觀測時間戳記。在實際報告中，請儲存這些時間，並確認觀測紀錄相互匹配。

| 主要類別 | 符合納入條件的貼文數 | 瀏覽次數計算 | 瀏覽事件總數 | 每則符合納入條件貼文的平均瀏覽事件數 |
| --- | --- | --- | --- | --- |
| 原始貼文 | 1 | 100 | 100 | 100 / 1 = 100 |
| 回覆 | 2 | 40 + 60 | 100 | 100 / 2 = 50 |
| 引用 | 1 | 200 | 200 | 200 / 1 = 200 |

四則貼文符合納入條件的完整總值為 100 + 40 + 200 + 60 = 400 次虛構瀏覽事件。各類別總值相加同樣得到 100 + 100 + 200 = 400 次瀏覽事件。

這些是來源計數器記錄的事件，不是不重複人數。在這個虛構樣本中，引用類別的總值與平均值最高。但這不能證明引用導致更多回應，也不能建立普遍適用的類別排名。三個類別的貼文數分別只有一則、兩則與一則。

不要將 U1 納入任何類別的平均值，也不要將它的瀏覽次數設為零。請在表格旁列出它，標示為一則指標缺失的待釐清貼文。

## 7. 查核計數，並明確列出各種未成功狀態

分享報告前，請完成以下驗收查核：

1. 確認每個請求網址都能追溯至已儲存的處理結果。身分仍待釐清的請求也應保留並列出。
2. 以穩定不變的貼文 ID 查核不重複貼文。不要把重複觀測紀錄算成額外貼文。
3. 將作者與已界定的帳號清單比對。作者未知的貼文，不應納入精確的帳號自撰貼文數。
4. 確認每則符合納入條件的已分類貼文，都只歸入一個主要類別。
5. 確認包含引用的回覆，在主要類別總數中只計入一次。
6. 確認每個納入的指標值，都能追溯至其觀測時間、狀態、精確程度與來源。
7. 依據納入的貼文資料列，重新計算各類別總值。
8. 在結果旁註明待釐清與排除的數量。

不同問題應以不同狀態記錄。缺少貼文 ID 時，無法精確計算不重複貼文數。作者未知時，無法確認是否符合帳號清單。作者已知但不在帳號清單內，屬於排除項目，不是作者未知。類型待釐清可能使貼文無法納入類別，但貼文身分仍然可以是已知的。

指標缺失是另一種狀態。它不會抹除已查核的貼文，也不會使該貼文變成分類失敗。即使所有身分與類型都已確認，各貼文發布後經過的時間不同，仍會限制回應比較的有效範圍。

交付請求對應表、已查核的貼文登記表、指標觀測紀錄、書面分類規則，以及範圍界定清楚的成效表。註明每個計數包含哪些內容。說明樣本來自公開查核、獲准使用的帳號擁有者紀錄，或兩者兼有。

後續問題需要各自的方法。計算帳號每天撰寫的回覆數，需要發布日期與報告採用的時區。比較主題需要內容標籤。這兩項工作都無法直接從各類別總數得出。同樣地，[關鍵字共現分析](/zh-Hant/articles/%E6%89%80%E6%8F%90%E4%BE%9B%E7%9A%84-x-%E5%B8%96%E6%96%87%E6%A8%A3%E6%9C%AC-%E9%97%9C%E9%8D%B5%E8%A9%9E%E5%85%B1%E7%8F%BE%E5%88%86%E6%9E%90/)計算的是貼文中的詞語，不能用來確認回覆或引用關係。

## 下一步

根據帳號清單與公開頁面的脈絡，查核一則已知貼文。儲存提交的網址、傳回的身分資料、主要類別、參考連結，以及尚未釐清的欄位。接著查核一個重複網址，或一則包含引用的回覆。確認依照你的規則，同一則帳號撰寫的貼文仍只會產生一筆紀錄。

使用 [X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics)，針對已知網址蒐集文件所列的公開身分與指標欄位。準備執行前，請先替換範例輸入。確認每筆分類紀錄都能追溯至一則已查核的貼文，而且每個報告數值都能追溯至一筆符合納入條件的觀測紀錄後，再擴大蒐集範圍。

## 來源與延伸閱讀

- [X Post Metrics 公開建置版本 1.0.4 與 README——於 2026 年 10 月 25 日查核；僅確認文件記載的輸入、輸出與轉發處理行為；未執行](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)
- [X Campaign Post Metrics Task——於 2026 年 10 月 25 日查核；僅確認公開頁面存在；未透過已驗證帳號查核儲存設定，也未執行 Task](https://apify.com/chronometrica/x-post-metrics/examples/x-campaign-post-metrics)
- [創辦人如何分析其他 Twitter/X 帳號？——於 2026 年 8 月 11 日擷取；僅為一筆公開提問紀錄，並非需求或數量估計](https://www.reddit.com/r/SideProject/comments/1rpwva4/how_do_founders_analyze_other_twitterx_accounts/)