Xプロフィールの監視に使うChronometricaとApidojo Twitter User Scraperの比較

Actorを選ぶ前に必要な出力を決める

Actorとは、ホスティング環境で動く収集プログラムです。選ぶ前に、保存する1件のレコードから何を知る必要があるかを決めてください。

フォロワー数の追跡で知りたいのは、「この観測時刻に、このプロフィールが表示していたフォロワー総数はいくつか」です。フォロワー一覧の内容について知りたいのは、「このプロフィールのフォロワー一覧に、どのアカウントが含まれているか」です。総数だけでは、後者の問いには答えられません。

Apidojoは、プロフィールの照会、プロフィールの各種件数、フォロワーとフォロー先の一覧、リポストしたユーザー、アカウントの詳細情報、検索モードを文書化しています。これらのレコードが必要な場合は、Apidojoを選びます。Chronometricaはスナップショットに特化した形式を持つため、指定したパネルに適しています。ただし、これを理由に、Apidojoには監視に役立つデータがないとは言えません。Apidojoのドキュメント

この表のChronometricaの制限は、確認済みの公開入力・出力ドキュメントに基づいています。Chronometricaのドキュメント

必要な出力を1文で書いてください。たとえば、「選んだ各プロフィールの現在のフォロワー数を保存し、次の観測と比較できるようにする」です。この要件には、スナップショットを使う手順が適しています。新しいフォロワーを個別に特定する必要がある場合は、選ぶツールが変わります。

指定したプロフィールパネルにChronometricaが適している理由

この比較の背景にある利用者のニーズは単純です。利用者が選んだ多数のXプロフィールについて、フォロワー数の増加を追跡することです。保存された要望では、提供者が選んだ固定の一覧ではなく、自分で選んだアカウントを対象にしています。また、追加のレポートを含まない、簡単な追跡手順を求めています。この要望は、ニーズがあることを示します。どちらかのActorが数千件のプロフィールを正常に収集した証拠ではありません。公開された利用者の質問

Chronometricaには、利用者が指定したプロフィールを入力できます。保存される公開プロフィールの各行には、`profileId`、`handle`、`profileUrl`、`observedAt`、`status`、`profileMetricStatus`が保持されます。公開例では、正確な`followersCount`と、取得できない指標フィールドを区別しています。このレコード形式は、観測結果を保存して比較するパネルに適しています。Chronometricaのドキュメント

各項目には役割があります。`profileId`は、保存した観測結果の間で同じプロフィールを照合するために使います。ハンドルには、その観測時に表示されていた名前を記録します。`observedAt`には、観測した時刻を記録します。状態フィールドは、その指標を使えるかどうかの判断に役立ちます。

正しく比較するには、フォロワー数だけでは不十分です。識別情報がなければ、別のアカウント同士を誤って比較するおそれがあります。時刻がなければ、観測結果を正しい期間に割り当てられません。数値の状態がなければ、取得できなかった値を実際の総数と誤認するおそれがあります。

これが、確認済みの情報に基づいてChronometricaを推奨する理由です。文書化されたレコード形式は、既知のプロフィール一覧と、現在の数値の繰り返し収集に適しています。変化を採用する前に確認するための情報を保持できます。

入力上限の1,000プロフィールが要件に合うか確認する

Chronometricaの公開された`profiles`入力には、最小1件、最大1,000件の配列を指定できます。配列とは、値の一覧です。これは入力の上限です。1回の実行で、有用なプロフィールの観測結果が1,000件返るという約束ではありません。Chronometricaの入力スキーマ

1回の入力で1,000件を超えるプロフィールを送信することが要件なら、Chronometricaはその要件を満たしません。件数の制限なくすべてのプロフィールを扱う要件に対応している、と説明してはいけません。

代わりに、各入力が上限内に収まるよう、あらかじめバッチを定義できます。バッチとは、分割して処理する単位です。この方法では収集手順が変わります。ただし、要求したすべてのプロフィールから使える数値を得られる保証にはなりません。採用可否の確認では、引き続き要求したすべてのプロフィールを確認する必要があります。

要求したプロフィール数、返された観測結果数、比較に採用した観測結果数の3つを分けて管理してください。返された行にも、確認が必要な場合があります。要求したプロフィールであっても、その期間に使える数値がない場合があります。

大規模なパネルでは、保存するレコードにバッチ名と収集時の情報も付けてください。複数のバッチを1つの報告期間として扱う前に、各バッチの観測時刻を確認してください。レポート上のラベルが同じでも、すべての数値を同時に観測したとは限りません。

保存済みTaskから始め、入力内容を確認する

Taskとは、Actor用に保存された入力設定です。Chronometricaは、開始用としてプロフィール比較の公開Taskを提供しています。保存された資料から、その公開ページにアクセスできたことは確認できます。ただし、Taskに現在保存されている入力内容は確認できません。実行前に入力内容を確認してください。プロフィール比較Task

確認済みの最小入力は次のとおりです。

{
  "profiles": [
    "https://x.com/elonmusk"
  ]
}

例のURLを、対象の公開プロフィールのURLに置き換えてください。この例は入力方法を示すものです。収集結果ではなく、そのアカウントの監視を推奨するものでもありません。

この入力は、キャッシュされた公開JSON Schemaを使ったローカル環境での確認に合格しました。JSON Schemaは、許可される入力フィールドと値を定義するものです。この確認で分かるのは、入力形式が保存済みスキーマに合っていることです。対象プロフィールにアクセスできることや、実際の収集が成功することは確認していません。Chronometricaの入力スキーマ

最初の採用可否の確認には、予定しているパネルから少数のプロフィールを選んでください。実際の作業で重要なプロフィールを含めてください。一覧を拡大する前に、保存された行を確認してください。目的は、各プロフィールを識別し、数値の状態を読み取り、使える観測結果を保存できるかを確かめることです。

リンク先のTaskは、作業の開始に役立ちます。手順がニーズを満たすかどうかは、確認した入力と保存した出力で判断します。

5段階の採用可否の確認手順を使う

1. パネルと各プロフィールの識別情報を定義する

追跡するプロフィールを保存してください。採用する各プロフィールについて、変わらない`profileId`と、観測時に確認したハンドルを保持してください。これにより、プロフィールのIDと表示されたハンドルを結び付ける対応表ができます。

観測結果の照合には、変わらないIDを使ってください。ハンドルの変更も確認できるように残してください。同じプロフィールかどうか確認できない場合は、解決するまでそのプロフィールを変化量の計算から除外してください。

入力上限を超える一覧では、収集前にバッチを定義してください。各バッチにどのプロフィールを含めるべきか記録してください。

2. スナップショットで問いに答えられるか確認する

必要なのが総数か、個々のフォロワーのレコードかを決めてください。履歴テーブルを作る前に、この判断をしてください。

スナップショットでは、観測された純増減を計算できます。これは、同じプロフィールで採用した2つの数値の差です。その差に関わる個々のアカウントは特定できません。次の作業でフォロワー一覧にどのアカウントが含まれるかを個別に特定する必要がある場合は、前の比較で示した切り替え条件に従ってください。

この確認により、計算ミスよりも大きな誤りを防げます。それは、判断に必要なものとは異なる種類のレコードを収集することです。

3. 数値を時刻と状態とともに保存する

各観測について、`profileId`、観測時のハンドル、`followersCount`、数値の状態、`observedAt`を保持してください。情報源と実行時の情報も保存してください。実行時の情報とは、保存した行を追跡するために必要な収集の詳細です。たとえば、バッチや報告期間が該当します。

数値を採用する前に、`status`と`profileMetricStatus`を確認してください。取得できない値と失敗の状態は、そのまま保持してください。欠損した数値を0に置き換えてはいけません。保存された観測結果が裏付ける場合に限り、実際の0を保持してください。Chronometricaは、この確認に使う識別情報、時刻、状態のフィールドを文書化しています。Chronometricaの出力ドキュメント

4. 比較可能な観測結果を比べる

次の予定収集では、`profileId`でレコードを照合してください。同じIDのプロフィールについて、両方の観測に使える数値があり、その数値同士を比較できる場合に限り、その組を採用してください。

その後、次の式で計算します。

`observed net change = later followersCount − earlier followersCount`

結果の横に、両方の観測時刻を残してください。観測間隔が異なれば、対象期間も異なります。プロフィール間で増加を比較する前に、その間隔を確認してください。

数値を取得できない場合は、変化量を不明のままにしてください。識別情報が一致しない場合は、別途確認してください。どちらの問題も、計算をするだけでは有効な結果になりません。

5. 変化量と対象範囲を一緒に報告する

要求したプロフィールのうち、採用した観測結果の組があるプロフィールの件数を示してください。数値の取得不可、観測の失敗、識別情報の未解決によって、確認できていないプロフィールの件数も示してください。

採用した組に基づく合計は、その組の範囲を表します。要求したパネル全体を自動的に表すものではありません。読者が結果を判断できるよう、含めたプロフィールを明確にしてください。

収集レコードがこれらの確認に合格したら、パネル全体の増加を比較する別の作業には、固定したXプロフィールパネルのガイドを使ってください。

架空の例：裏付けられる変化量は1件だけ

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

パネルには、既知のプロフィールが3件あります。2つの時点で観測結果を保存します。

• プロフィールAの正確なフォロワー数は1,000と1,200です。両方の観測で、変わらない識別情報により同じプロフィールだと確認できます。
• プロフィールBでは、最初の数値は採用できますが、2回目の数値は取得できていません。
• プロフィールCでは、異なる識別情報の下で数値が記録されており、同じプロフィールかどうか確認できていません。

プロフィールAでは、`1,200 − 1,000 = +200`と計算します。保存した2つの観測時刻の間で、フォロワー数の純増+200が観測されたと報告します。

プロフィールBには、採用できる変化量がありません。取得できなかった2回目の数値は、そのまま取得不可として残します。0で置き換えると、実際には確認していない減少を作り出してしまいます。

プロフィールCにも、採用できる変化量がありません。2つの数値が同じプロフィールのものだと確認するまでは、有効な組にはなりません。差を計算する前に、識別情報を確認してください。

したがって、このパネルでは採用できる比較が1件、確認できていない比較が2件あります。プロフィールAの結果とともに、この対象範囲を報告してください。+200を、3件すべてのプロフィールを対象にした完全な変化量として示してはいけません。

プロフィールAの有効な結果でも、誰がフォローしたか、誰がフォローを解除したかは特定できません。総数が変わった理由も分かりません。この結果が測るのは、採用した2つの総数の差です。個々のフォローやフォロー解除を測るものではありません。

この例は、ツールの選択に識別情報と数値の状態が重要である理由を示しています。使える監視レコードには、計算を行うための情報と、計算結果を不明のままにする判断のための情報の両方が必要です。

新しく作る履歴で何を確認できるかを知る

新しく収集する履歴は、最初に保存した観測結果から始まります。この手順では、Chronometricaはそれ以前のフォロワー数や、フォローとフォロー解除それぞれの総件数を提供しません。新しいパネルに、すでに過去の増加履歴が含まれているかのように説明してはいけません。Chronometricaのドキュメント

最初に採用したスナップショットで、開始時の数値が得られます。その後に比較可能なスナップショットを得ると、比較ができます。両方がそろうまでは、得られるのは現在の総数であり、選んだ期間の変化を測った値ではありません。

保存した観測時刻と、変化が起きた時刻を区別してください。2つのスナップショットが示すのは、観測結果の間の差です。その間に起きた各アカウントの操作の正確な時刻は分かりません。

収集に関する証拠と、事業への影響に関する証拠も区別してください。公開フォロワー総数が多いことだけでは、売上、フォロワー層の質、増加の原因は確認できません。これらの問いには、適切な追加の証拠で答えてください。

この比較は、目的に合う収集形式を選ぶための根拠を示します。提示された資料では、Chronometricaが比較対象のツールより低コストである、速く動く、収集結果の網羅性がより高い、より高い信頼性で動く、といった主張は裏付けられません。