ChronometricaとTweet Scraper V2の比較：既知のX投稿1件にはどちらが適しているか

料金についての質問から分かること

過去にクローズされたStoreの問い合わせには、既知の投稿URLを1件持つ利用者が、1,000件の結果に対して$0.40と説明された料金に疑問を示した記録があります。この金額は、その過去の問い合わせに出てきたものです。現在の料金を示すものでも、請求全体を説明するものでもありません。別の製品ならいくらかかったかを証明するものでもありません。この問い合わせは、現在のサービス障害の証拠ではありません。過去の利用者の質問

次の実行前に確認すべきなのは、選んだ製品が、依頼しようとしている作業そのものに対応しているかどうかです。

URLを1件指定するのは、既知の投稿を取得する作業です。必要な投稿は、すでに分かっています。確認したいのは、特定の時刻における本文と公開表示されるカウント値です。条件に合う投稿の集合を、収集ツールに探してもらう必要はありません。

投稿の探索は別の作業です。投稿を見つける必要があるため、トピック、プロフィール、リストを指定します。この作業では、入力、制限、課金単位が異なる場合があります。探索に適した製品が、既知のURLを1件取得する用途にも適しているとは限りません。

Actorは、Apify上で動く収集プログラムです。実行する前に、対応用途、入力項目、現在の課金条件の3つを個別に確認してください。入力項目が有効であることから分かるのは、そのうちの1つだけです。

この記事では、保存された質問だけから過去の請求額を計算することはできません。ただし、用途に対応した収集ツールを選び、その結果を利用前に確認するための手順は示せます。

まず対応する作業を比較する

この表で選択肢を絞ってください。その後、費用をかける前に、現在の製品ページを確認してください。

出典：Chronometrica、V2、Unlimited。

入力項目名の`startUrls`だけで選ばないでください。JSON入力スキーマは、使用できる項目名、型、値を定義します。製品の対応用途に関する規則の代わりにはなりません。URLを格納できる配列があるだけでは、あらゆる種類のURLに対応しているとは判断できません。

この表は、文書に基づいて用途への適合性を比較しています。速度、精度、信頼性、網羅性、実測費用の順位は示していません。この記事に提供された証拠では、そのような順位を付けることはできません。

この用途でChronometricaから得られるもの

Chronometricaは、公開XまたはTwitterの投稿URLを1件から1,000件含む`startUrls`リストを受け付けます。文書に記載された出力は、入力に対する取得試行のスナップショットを1件保持します。そこには、取得できた本文、公開表示されるカウント値（取得できた場合）、結果の状態、観測時刻が含まれます。欠損している件数は、欠損のまま保持されます。入出力仕様

入力に対する取得試行のスナップショットとは、指定した投稿の観測を試みた記録です。毎回、完全な本文と件数が返ることを保証するものと解釈してはいけません。

この区別があるため、既知の投稿の確認に出力を役立てられます。収集ツールが何を観測したかに加え、その観測結果を目的の用途に使えるかも知る必要があります。件数だけを見て、その取得可否の状態を確認しないと、実際より確かな値だと受け取るおそれがあります。

たとえば、報告書に投稿本文と公開表示されるカウント値1項目が必要だとします。本文を取得できても件数が欠損している場合、本文は目的に使える可能性があります。しかし、報告書の数値部分は未完成です。この2つを分けて判断すれば、一部しか得られていない結果を、完成した報告書のように扱うことを防げます。

明記されたリストの上限も重要です。1回の実行で1,000件を超えるURLを指定する必要があるなら、このActorはその要件を満たしません。文書に上限がある以上、無制限に収集できると説明してはいけません。規模が大きいプロジェクトには、別の計画が必要です。URLの重複や、観測時刻の一貫性も確認する必要があります。入力上限

この用途でChronometricaを選ぶ理由は明確です。既知のURLが対応する入力に合い、文書に記載された出力行には、取得試行を判断するために必要な状態が残るからです。

投稿1件で判断する架空の例

以下は架空の例です。顧客の利用結果、Actorのテスト、実際のデータセット、費用の実測ではありません。

分析担当者のMayaは、キャンペーン投稿のURLを1件持っています。今日作成する報告書のために、公開されている本文と取得可能な件数が必要です。ほかのキャンペーン投稿を探す必要はありません。

Mayaは収集ツールを選ぶ前に、要件をこう記します。「この公開投稿1件の取得を試みる。結果の状態、取得できた項目、参照元URL、観測時刻を保持する。」

Chronometricaの文書に記載されたスナップショット出力は、この要件に合っています。Mayaは、開発元が投稿1件の取得に対応する選択肢として案内するUnlimitedも候補に残します。Chronometrica、Unlimited

Mayaの受入確認は2つに分かれます。まず、実行結果に目的の投稿が記録されたかを確認します。次に、報告書に必要な項目が取得できているかを確認します。出力行が最初の確認に合格しても、次の確認には不合格となる場合があります。必要な件数を取得できない場合、Mayaは報告書でその値をnullのまま残し、その部分を未完成と記します。

翌週、依頼内容が変わります。今度はキーワードで200件の投稿を探す必要があります。新しい作業は探索なので、MayaはV2を再検討します。以前の投稿1件に対する選択だけでは、新しい判断は決まりません。V2の対応用途

数から分かることは限られています。既知のURL1件は、取得依頼1件を意味します。200件の投稿を探すことは、別の作業を意味します。どちらの数からも、料金、返される行数、速度、成功の可否は予測できません。

大規模な実行の前に、小規模な受入確認を行う

受入確認では、出力を目的の報告書に使えるかを確かめます。大きなテスト用データセットは必要ありません。目的の公開URLと、必要な項目を記した短いリストから始めてください。

1. 要件を分かりやすい言葉で書く

正確な投稿URLを記録してください。必要な公開項目を1つずつ記してください。必須の項目と、あると役立つ項目を分けてください。

たとえば、本文と観測時刻を必須とし、公開表示されるカウント値の一部は任意とする報告書もあります。別の報告書では、特定の件数が必須かもしれません。同じURLを使っていても、それぞれの報告書では受入条件が異なります。

現在の観測結果が必要なのか、過去の値が必要なのかも明記してください。現在の取得では、その投稿の先月時点の件数は復元できません。過去の値が必要な依頼なら、収集ツールを選ぶ前にその要件を明示してください。

2. 対応用途と現在の課金単位を確認する

現在の製品の規則を読んでください。次に、予定する実行に適用される現在の料金を確認してください。何によって料金が発生し、記載された単位が入力にどう適用されるかを確かめてください。

過去の問い合わせに出てきた金額は、その計算に使わないでください。URL1件が常に課金対象の結果1件になるとは考えないでください。見慣れた項目名が課金単位を定義するとも考えないでください。現在の条件を読んでも疑問が解決しない場合は、実行前に解決してください。

料金と適合性は別々に確認します。料金が明確な製品でも、入力要件を満たさない場合があります。用途に対応している製品でも、費用が予算内に収まるかの確認は必要です。

3. Taskに保存された入力を確認する

Taskは、Apifyに保存された入力設定です。Chronometricaは、公開のX投稿分析スナップショットTaskを提供しています。

Taskを開き、実際の入力を確認してください。公開Taskページは、作業を始めるためのものです。ページが存在するだけでは、保存されたURLが目的の対象だとは確認できません。

次の最小限の入力は、確認済みの公開スキーマに適合しています。

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

例のURLを、目的の公開投稿のURLに置き換えてください。この例が示すのは入力の形式です。収集結果ではなく、例の投稿が現在も閲覧できることの証明でもありません。スキーマでは、要素が1件以上、1,000件以下の`startUrls`配列が許可されています。公開入力スキーマ

提示した入力は、保存された公開スキーマに対する確認に合格しました。この確認で分かるのは、許可された項目とリスト形式に合っていることです。実際の収集試行が成功することを確認したものではありません。

4. 値を使う前に取得試行を確認する

目的に沿った小規模な実行の後で、`status`、`statusReason`、`postMetricStatus`を確認してください。返された本文と件数も併せて読んでください。特定された投稿が、収集しようとした投稿と一致するかを確認してください。文書に記載された出力

行が存在するだけで、必要な項目がすべて収集されたとは判断しないでください。手順1で書いた受入条件に照らして、必須項目を1つずつ確認してください。

取得できない値は、報告書でもnullのままにしてください。0に変えないでください。0は値です。nullは、使える値がないことを意味します。nullを0に変えると、合計、比較、結論が変わるおそれがあります。

5. 参照元と観測時刻を保持する

取得を試みた入力について、記録を1件保存してください。参照元URL、特定された投稿の識別情報、取得試行の状態、各指標の取得可否、観測時刻を一緒に保持してください。

Actorが返す項目名が文書に記載されている場合は、その名前を使ってください。報告システムで別の列名が必要なら、対応関係を明確に残してください。API項目名を独自に作り、Actorの仕様の一部として示してはいけません。

その後の変化を測るには、別のスナップショットを取得して確認してください。同じ投稿の同じ項目を比較できるのは、両方の観測結果に使える値がある場合だけです。

スナップショットは履歴ではなく、観測結果として読む

現在公開表示されるカウント値が答えるのは、特定の時点に関する質問です。つまり、今回の試行で投稿を観測したときに、どの値を取得できたかということです。その件数がどのように変化してきたかは説明しません。

確認済みのスナップショットが2件あれば、変化を計算できる場合があります。両方に必要な件数があるなら、後の値から前の値を引いてください。結果には、両方の観測時刻を添えてください。その差が示すのは、両観測の間の変化です。

どちらかの値が欠損している場合、変化は不明です。欠損を0で埋めないでください。明記した規則なしに、以前の値をそのまま使わないでください。その差を、実測した増加と説明しないでください。観測結果が欠けていると、導ける結論も変わります。

投稿本文も、欠損している場合や一部しか取得できない場合があります。引用、分類、キャンペーンで使われた表現の特定に使う前に確認してください。収集ツールの出力は、報告書の入力データです。そのため、報告書に使うには受入確認が必要です。

この比較は、アーカイブ、過去の指標の復元、過去のキーワード出現頻度を保証するものではありません。これらの要件には別の証拠が必要です。公開データと非公開データの報告上の差に関するガイドでは、関連する報告上の背景を説明しています。指定した投稿本文の集合を分析する場合は、別のキーワード共起ガイドを使ってください。その手法で分かるのは、どの用語が一緒に現れるかです。既知のURLに使う収集ツールを選ぶための手法ではありません。