如何為 TikTok 用戶原創內容協議建立觀看證據收據

公開指標約定與設定

TikTok Metrics scraper build 0.1.36 接受模式 `auto`、`knownUrls` 及 `profileUrls`。它接受參數 `startUrls`、可選的 `maxItems`、`includeProfileMetrics`、`requestTimeoutSecs`、`maxConcurrency` 及 `failOnNoMetrics`。就此試行方法，選擇 `knownUrls`，使用一條預定的公開影片 URL，並把 `maxItems` 設為 1。不要把個人檔案發現預設當作完整歷史的承諾。把 `includeProfileMetrics` 設為 true，會加入盡力取得的目前公開個人檔案事實，而不是粉絲身分或非公開的分析數據。

數據集中的一列代表一項已嘗試或已解析的影片結果。在把指標視為有用之前，必須先檢查列狀態及 `statusReason`。此處使用的原生數據集欄位為：`inputUrl`、`postUrl`、`postId`、`profileId`、`profileHandle`、`profileUrl`、`publishedAt`、`videoDurationSeconds`、`views`、`likes`、`comments`、`shares`、`saves`、`reposts`、`profileFollowersCount`、`postMetricStatus`、`profileMetricStatus` 及 `scrapedAt`。缺失的指標以 `null` 傳回，而不是零。指標精確度標記包括 `exact`、`display_rounded`、`likely_rounded` 及 `unavailable`。一個精確的公開整數仍然只是平台的公開計數，而不是已驗證、每人只計一次的人數。Actor 不會輸出衍生比率。

在評估數據集列之前，先檢查最終執行摘要中的 providedUrls、contentUrls、inputUrls、resolvedUrls、metricRows、noPublicMetricRows、blockedRows、failedRows 及 statusCounts，以確認處理結果。成功的執行摘要中，若 metricRows 顯示已解析的數據，即確認已提取計數。若目標出現在 noPublicMetricRows、blockedRows 或 failedRows，則表示來源失敗或指標不可用。這些值必須保留為缺失或未知，絕不可計為零次觀看。

單片對照測試已核對相符的帖文與個人檔案 ID、公開計數、個人檔案粉絲人數及精確度標記。多個計數為 `likely_rounded`，而收藏次數與轉發次數為 `exact`。這確認公開計數及身分資料可以得到支援。它不能證明留存、完播、非公開的觸及、點擊、銷售、廣告欺詐或不重複觀眾。

把 Task 預設中的所有範例目標 URL 換成你已知的單一公開影片連結。

逐步建立交付收據的方法

1. 檢查帖文之前，先記錄所有已協議的交付規則。寫下預期的創作者帳號代號、要求的影片內容、帖文身分、截止時間及時區。列出 UGC 合約所承諾的確切指標。不要估算酬金率，也不要預測未來收入。
2. 為你的影片 URL 執行數據收集程式。把模式設為 `knownUrls`，並把 `maxItems` 設為 1。如需個人檔案身分事實，把 `includeProfileMetrics` 設為 true。把範例 URL 換成你的目標 URL。檢查 `postId` 及 `profileHandle` 是否與你的紀錄相符。
3. 人手觀看已發佈的影片。確認影片顯示正確的產品、創作者、場景及訊息。用你的人手覆核時間戳，記錄簡短的通過或不合格備註。公開觀看計數不能核對影片場景、授權權利或適當的廣告披露。
4. 儲存原始觀看指標及狀態標記。一併檢查 `views` 次數、`postMetricStatus`、`profileMetricStatus` 及 `scrapedAt`。目前的平台約定把精確度報告為 `exact`、`display_rounded`、`likely_rounded` 或 `unavailable`。不要把已四捨五入的數字改成精確次數。不要把讚好、分享或收藏加進觀看次數。
5. 把實際觀察時間與已協議的截止時間比較。在截止時間之後取得的觀看快照，不能顯示截止當時的次數。把過遲的讀數分開保存。不要用編造的每日比率計算缺失的觀看次數。
6. 為證據列指定清晰的覆核狀態。只有在身分、人手檢查、截止時間及指標精確度全部符合合約條款時，才使用 `checked_public_count_for_review`。檢查失敗時，使用 `delivery_gap`、`timing_gap`、`precision_gap`、`source_unavailable` 或 `private_metric_required`。
7. 組合最終觀看收據。合併合約參照、目標 URL、人手檢查結果、觀察時間戳、公開觀看次數、精確度標記及覆核狀態。把較早及較後的觀看快照分開保存。
8. 把證據收據提交給品牌合作方或覆核流程。此收據記錄公開平台指標。它不會開立發票、處理付款或保證宣傳活動結果。

虛構收據例子

以下例子使用原創虛構數據，顯示不同帖文結果如何對應覆核狀態。目標規則要求：已協議的帖文在 10 月 10 日 12:00 UTC 有精確的公開觀看次數，而且人手場景檢查為通過。

• 候選 V1（虛構）：創作者帳號代號及產品相符。人手場景檢查通過。於 12:00 UTC 取得的快照顯示 40,000 次觀看，精確度為精確。狀態：`checked_public_count_for_review`。
• 候選 V2（虛構）：內容及截止時間相符。計數顯示 1.2M 次觀看，精確度標記為 `likely_rounded`。確切觀看次數仍然未知。任何 1,200,000 的數字都是由顯示值推算出的估計，而不是已核證的確切次數。狀態：`precision_gap`。
• 候選 V3（虛構）：場景檢查通過，精確度為精確，觀看次數為 50,000。快照於 12:07 UTC 取得，遲了 7 分鐘。狀態：`timing_gap`。
• 候選 V4（虛構）：快照於 12:00 UTC 取得，精確次數為 20,000 次觀看。人手檢查發現影片顯示錯誤產品。狀態：`delivery_gap`。
• 候選 V5（虛構）：因來源錯誤，抓取程式沒有傳回公開指標。觀看次數為缺失（null），而不是零。狀態：`source_unavailable`。
• 候選 V6（虛構）：合約要求已核對的美國觀看次數。公開計數不會按觀眾所在地劃分。狀態：`private_metric_required`。

六列之中，只有一列產生可供覆核的有效公開觀看紀錄。其餘五列標明需要人手解決的特定差距。