ChronometricaとApify Facebook Postsの比較：視聴回数と再生回数を1行にまとめられるか

公開仕様で対応が明記されていること

Chronometricaは、`views`と`plays`を別々のフィールドとして明示しています。`contentMetricStatus`には、指標のステータス、精度、取得元が記録されます。そのため、同じコンテンツ行の中で、それぞれの回数を評価できます。片方の回数しか取得できなくても、その行が役立つ場合はあります。ただし、仕様があるからといって、片方しかない行に両方の値がそろうわけではありません。Chronometrica Facebook Metrics Scraper

Apify Facebook Posts Scraperは、`viewsCount`を公開仕様に記載しています。過去の課題では、保守担当者が、もう一方の回数を得るために別のReelsデータセットを使い、結果を結合する方法を説明していました。現在のReelsのREADMEには、Reelを直接入力した場合に正確な再生回数を取得できると記載されています。したがって、丸められた値しか出力されないという過去の懸念を、現在の仕様として伝えてはいけません。Postsの仕様、過去の課題、Reelsの仕様

この公開の課題はクローズされています。そこには、1回の実行で両方の数値を得たいという利用者の要望が記録されています。現在の不具合を示す証拠ではありません。この比較では、2026年10月20日に確認した公開仕様を使っています。新たな収集実行や、同じ対象の結果を照合する検証は行っていません。

根拠をもって比較できる違いは、明記された出力形式です。文書にない応答に含まれる可能性のある、すべてのフィールドについて述べているわけではありません。

レポートの要件から判断する

まず、データを使うレポートを確認します。フィールド名だけでは、その値がレポートの要件を満たすかどうかは分かりません。

たとえば、コンテンツ全体の概要には、丸められた視聴回数を使えるレポートもあります。同じレポートでも、別の計算には正確な再生回数が必要かもしれません。両方が同じ動画の値であっても、要件は別々です。

データを収集する前に、次の簡潔な判断表を使ってください。

1行にまとまった形式なら、回数のレコードを自分で結合する必要を減らせます。ただし、フィールドの確認は必要です。収集処理の成功と、レポートで採用できる行の取得は、別のことです。

同様に、レポートに必要なデータが得られるなら、結合は妥当な選択です。その価値は、最終的にどのようなレコードを作り、検証できるかで決まります。収集手順の数だけでは決まりません。

視聴回数と再生回数の要件を別々に定める

視聴回数と再生回数は異なる場合があります。収集、確認、レポート作成のすべての段階で、別々の指標として扱ってください。どちらの回数も、ユニーク視聴者数やリーチとして示してはいけません。また、比率を計算するときに、分母として互いに置き換えることもできません。

自社製品の仕様では、視聴回数を公開の動画視聴回数、再生回数をそれより広い範囲を数える公開カウンターと説明しています。根拠となる資料がない限り、1秒や3秒といった視聴時間の基準を当てはめてはいけません。各名称の意味は、Facebook動画の視聴回数、再生回数、リーチを参照してください。

レポートの各列について、要件を短く記述します。

1. その列に必要な回数の種類を明記します。
2. その列が必須か任意かを明記します。
3. レポートで認める精度を明記します。
4. 値を取得できない場合の扱いを明記します。
5. その値を使う計算があるかどうかを明記します。

これらのルールがあれば、一部の値だけを取得できた結果を扱いやすくなります。再生回数が任意なら、視聴回数しかない行でもレポートに採用できる場合があります。両方が必須なら、同じ行は両方の回数を必要とする条件を満たしません。

この2つの判断を区別してください。再生回数が欠けているからといって、有用な視聴回数まで捨てる必要はありません。ただし、一部の値しかない行を、両方の回数が必要な計算に使ってはいけません。

結果を見る前に、ルールを決めてください。そうしないと、使いやすい値に合わせて要件を変え、その変更をレポートの読者に明示しないままにしてしまう可能性があります。

既知の公開コンテンツURLから始める

最初の確認には、既知の公開コンテンツURLを使います。これにより、回数の取得と採用条件に判断を絞れます。投稿を広く検索すると、そもそも目的のコンテンツを見つけられたかという別の問題が加わります。

公開されているFacebook Engagement Metrics Tracker Taskを、開始時のプリセットとして使えます。Taskとは、Actor用に保存された入力設定です。資料を確認した時点でページは利用できましたが、保存されている入力内容は確認していません。プリセットにすでに設定されていると考えず、以下の設定を適用してください。

{
  "mode": "knownUrls",
  "startUrls": [
    "https://www.facebook.com/reel/3809524072644232/"
  ]
}

この最小限の入力は、現在の公開入力スキーマに照らして確認しています。実行はしていません。例のURLは、そこで今も両方の回数が公開されていることを証明するものではありません。レポートに必要な公開コンテンツのURLに置き換えてください。Chronometrica Actorと入力仕様

自分で確認する際は、実際の作業を代表するコンテンツを選びます。レポートの対象がReelsなら、公開Reelが適しています。製品ページにある使いやすい例だけでは、実際の対象コンテンツが要件を満たすかどうかは分かりません。

確認する結果と一緒に、対象URLを記録してください。その行が、収集しようとしたコンテンツを表していると確認するために、このリンクが必要です。

値とステータスを一緒に確認する

結果を取得したら、レポートに値を転記する前に、指標に関する情報をすべて確認します。Chronometricaが仕様に記載しているフィールドを使えば、コンテンツ行の中でこの確認ができます。公開出力仕様

次の順序で確認します。

1. その行が対象のコンテンツを指していることを確認します。
2. `views`と、それに対応する`contentMetricStatus`の情報を確認します。
3. `plays`と、それに対応する`contentMetricStatus`の情報を確認します。
4. 各値の精度を、レポートの要件と照合します。
5. 目的の用途に対して、その行を「採用可」「一部のみ採用可」「不適合」のいずれかに分類します。

最後に挙げた3つの分類名は、作業手順の中で確認結果を示すためのものです。ここでは、Actorの出力値として示しているわけではありません。

数値をエクスポートしたり変換したりするときは、精度の情報も一緒に残してください。特に、省略表示された回数を数値に展開した場合は、`compact_rounded`を保持します。展開によって変わるのは値の形式です。元の回数が正確になるわけではありません。

レポートを読みやすくするために、主な回数を1つの列に表示し、精度を隣の列や補足レコードに残すこともできます。大切なのは、後で使う人がその制約を確認できることです。精度の情報から切り離された数値は、根拠が示す以上に正確に見える場合があります。

欠損値は空欄のままにしてください。0は回数を示す値です。不明な値は、回数を示す証拠がない状態です。一方をもう一方に置き換えると、データの意味が変わります。

また、欠けている再生回数のフィールドを視聴回数で埋めてはいけません。それでは、2つ目の観測がないまま2つ目の数値を作ることになります。行は完全に見えても、収集した証拠を表さなくなります。

3つのURLで採用条件を確認する架空の例

次の例は架空のものです。製品テストでも、顧客の結果でも、実測した収集率でもありません。

ある分析担当者が、視聴回数と再生回数の列を分けたクライアント向けレポートを作成します。このレポートでは、各列で定めた精度の条件を満たす場合に限り、その回数を採用します。両方の回数を使う比較には、両方が採用条件を満たす必要があります。

担当者は、対象となる3つの公開コンテンツURLを確認します。2行には、必要な両方の回数が認められる精度で含まれています。3行目には採用できる視聴回数がありますが、再生回数は取得できません。

この架空の確認で、両方の回数を使えるURLの割合は次のとおりです。

2 / 3 × 100 = 対象URLの66.67%。

分母には、対象とした3つのURLをすべて含めます。たまたま両方の値がそろった行だけを含めるのではありません。レポートでは、対象コンテンツのうち、どれだけを比較に使えるか知る必要があるため、この選び方は重要です。

担当者は、視聴回数だけを使う用途のために3行目を残します。再生回数には取得不可と記し、その回数が引き続き必要なら、別のReelsの取得元を確認します。視聴回数を再生回数にコピーすることはしません。

ここで、同じ架空のレポートに、投稿の添付データ一式も必要になったとします。その要件があれば、より豊富なデータを得られるPostsを使い、結果を結合することが妥当になる場合があります。判断が変わるのは、必要な出力が変わったからです。架空の割合が、どちらかのツールの優位性を証明したからではありません。

この例は、採用条件の適用方法を示しています。66.67%という値は、どちらのActorの実際の収集性能についても何も示しません。

必要な出力が手間に見合う場合は結合する

方法を切り替える主な条件は、より豊富な投稿データが必要なことです。その必要性が、仕様に明記された単一の指標行の利点を上回る場合は、PostsとReelsを使い、結合の手順を計画します。Apify Facebook Posts Scraper

結合とは、同じコンテンツを表すレコードを組み合わせることです。組み合わせる前に、同じコンテンツであることを確認してください。本文が似ている、または回数が近いという理由だけで、2つのレコードを対応付けてはいけません。

利用できる出力に安定したコンテンツ識別子がある場合は、それを使います。URLを使う場合は、同じコンテンツを指していることを確認します。対応が不確かなレコードは、検証できるまで別々にしておいてください。

結合後も、各回数の取得元を残してください。値がどこから来たかを説明し、後で確認するために役立ちます。また、結合したレコードでも、どの取得元がどのフィールドを提供したか分かるようになります。

正しく結合できた証拠として、2つの回数の一致を求めてはいけません。2つは異なるものを測っています。まず同じコンテンツであることを確認し、次に各回数をそれぞれの採用条件で評価します。

結合したレコードにも、単独で収集した行と同じ確認が必要です。データセットを組み合わせても、必要なすべての値が存在すること、正確であること、計算に適していることが保証されるわけではありません。

選ぶ前に対象全体を確認する

最初のURLで、出力の確認方法を学びます。その後、対象のコンテンツURL全体に同じルールを適用します。採用できる行が1つあれば、その行については判断できます。残りの対象もすべて網羅できるとは限りません。

手順は簡潔にし、繰り返し使えるようにします。

1. 対象のコンテンツURLを一覧にし、意図しない重複を削除します。
2. 必要な回数と、認める精度を記録します。
3. 評価対象の方法で収集します。
4. コンテンツの同一性、値、ステータス、精度を確認します。
5. 明記した各要件を満たす行数を数えます。
6. 未解決のフィールドと、それぞれの次の対応を記録します。

採用条件を満たす件数を数える前に、集計単位を決めます。レポートが重複のない動画を対象とするなら、各対象動画を1回だけ数えます。採用できるURLを繰り返し複製して、要件を満たすコンテンツの割合が高く見えるようにしてはいけません。

用途が異なる場合は、結果も分けて報告します。ある行は、視聴回数だけを使うレポートには採用できても、両方の回数を使う比較には使えない場合があります。この違いを示す方が、全体に1つの合格または不合格のラベルを付けるよりも、利用可能なデータを有用な形で説明できます。

すべてのURLで両方の正確な回数が必要なら、回数が欠けている場合も、精度が足りない場合も、要件未達として扱います。確認したどちらの仕様も、すべてのURLでその厳しい条件を満たすとは保証していません。

この方法なら、架空のベンチマークを使わずに判断できます。公開仕様からは、各方法が何を明記しているかを確認できます。返された値が、対象コンテンツについてレポートのルールを満たすかどうかは、自分で確認します。