TikTokのUGC契約に使う再生回数の証跡記録の作り方

公開指標のデータ仕様と設定

TikTok Metrics scraperのビルド0.1.36は、`auto`、`knownUrls`、`profileUrls`の各モードに対応しています。指定できるパラメーターは、`startUrls`、任意の`maxItems`、`includeProfileMetrics`、`requestTimeoutSecs`、`maxConcurrency`、`failOnNoMetrics`です。この試行方法では、`knownUrls`を選び、対象の公開動画URLを1件指定して、`maxItems`を1に設定します。プロフィールから投稿を探索するプリセットを、全履歴の取得を保証するものとして扱わないでください。`includeProfileMetrics`をtrueに設定すると、可能な範囲で取得した現在の公開プロフィール情報が追加されます。フォロワーの識別情報や非公開の分析データは追加されません。

データセットの1行は、動画1件について取得を試みた結果、または取得できた結果を表します。指標を有用なデータとして数える前に、必ず行の状態と`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に含まれる場合は、参照元での取得失敗、または指標を取得できなかったことを示します。これらは欠損値または不明な値として保持し、再生回数ゼロとして数えてはいけません。

動画1件を対象とする対照テストで、投稿IDとプロフィールIDの一致、公開カウンター、プロフィールのフォロワー数、精度フラグを検証しました。いくつかの回数は`likely_rounded`で、保存数と再投稿数は`exact`でした。これにより、公開カウンターと識別情報への対応を確認できました。視聴維持、視聴完了、非公開のリーチ、クリック数、売上、広告不正、重複を除いた視聴者数を立証するものではありません。

Taskプリセットにある対象URLのサンプルをすべて、既知の公開動画1件のリンクに置き換えてください。

納品の証跡記録を作成する手順

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`。

6行のうち1行で、確認に使える有効な公開再生回数の記録が得られました。残りの5行では、手作業で解決する必要がある具体的な不足事項が示されました。