ChronometricaとApify Facebook Pages Scraper：ページのデータセットに合うのは？

必要なページのデータセットを明確にする

ある公開の議論で、LinkedInやFacebookなどのプラットフォームは、なぜAPIを通じて公開データを簡単に取得できるようにしないのか、という読者の質問がありました。APIとは、ソフトウェアがデータを要求するための仕組みです。この議論では、Facebookのビジネスページのデータや公開イベントも取り上げられています。特定のスクレイパーを求める話ではなく、データへのアクセスに関する広い問題を示しています。読者の議論

ページ用のActorが対応するのは、この問題の一部です。既知の公開ページのアドレスからレコードを収集します。選ぶには、必要な出力を明確にする必要があります。名前と件数の一覧は、連絡先リストや営業時間の表とは用途が異なります。

まず、データセットを使って何を判断するのかを書き出します。たとえば、件数を取り込む前に、各事業者に対応するページを確認する必要があるかもしれません。または、調査のために連絡先が必要かもしれません。必要なものが違えば、採用基準も変わります。

元のアクセスに関する質問だけでは、すべての購入者に精度の表示が重要だとはいえません。正確な件数と、精度が低い表示値を区別する必要がある作業では、精度の表示が重要です。ツールを選ぶ前に、その要件を明確にしてください。

出力仕様を比較する

この表を使って、最初に確認する点を選びます。業務に必要な項目は、選ぶ仕様の中に明確に記載されている必要があります。

製品に関する記載は、記載日に確認した公開ドキュメントに基づきます。文書化されていない機能の有無は不明です。ChronometricaのActor · Apify Facebook Pages Scraper

表は、必要な出力を起点にしてツールを選ぶために使います。必須項目の提供が明記されていなければ、追加の確認が必要です。そこから別のツールにもその項目がないと推測する必要はありません。

範囲の狭い仕様でも、必要な作業をすべて満たすなら適しています。追加項目が役立つのは、判断を変える場合や、後の収集作業を省ける場合です。データセットを広げる前に、各項目の用途を書き出してください。

採用できるページレコードの条件を定める

Actorを実行する前に、必要な項目を短いリストにします。ページの識別に必要な項目と、測定に必要な項目を分けてください。

識別項目は、そのレコードがどのページを表すかを判断するために使います。測定項目には、そのページで観測した値が入ります。観測時刻は、その値を収集した日時を示します。結果の状態は、収集結果を利用できるかどうかを示します。

レコードを確認してから採用する場合は、次の手順を使います。

1. 各レコードが、入力したどのページに対応する必要があるかを明記します。
2. ページを特定できる場合は、正規アドレスを必須にします。
3. 作業に必要な件数や、その他の測定値を指定します。
4. 用途に応じて許容できる精度を定めます。
5. 観測からの経過時間に許容上限を設けます。
6. 不完全な結果や失敗した結果を、どのように確認対象にするかを定めます。

正規アドレスとは、返されたレコード内でページを識別するために使う標準のアドレスです。異なるアドレスを入力して得たレコード同士を比較するのに役立ちます。

採用基準は、作業の目的に合わせて定めます。大まかな絞り込み用のリストなら、精度が低い件数でも使える場合があります。小さな差に左右される計算では、より精度の高い値が必要かもしれません。結果を見る前に基準を決めてください。そうすれば、たまたま得られた値に合わせて基準を変えることを防げます。

必須項目と任意項目も区別します。任意項目が欠けていても、レコードを有効に使える場合があります。必須項目が欠けている場合、そのレコードはまだ目的の判断に使えません。

入力した値とページの識別情報を分けて保持する

入力するアドレスと、採用するページの識別情報は、用途が異なります。確認中は、両方を参照できる状態にしてください。

Chronometricaは、入力した値と、正規アドレスである`channelUrl`を文書化しています。`startUrls`のスキーマでは、公開FacebookページまたはプロフィールのURLを1〜1,000件指定できます。重複する入力は1回だけ確認されます。重複を除いた入力ごとに1行の結果が作られ、使用量に加算されます。ChronometricaのActor

これらの規則は、入力の処理方法を示しています。異なるアドレスが、それぞれ別の事業者を表すことを証明するものではありません。異なる2つのアドレスでも、そのレコードを別々の対象として扱う前に、識別情報の確認が必要な場合があります。

次の3つの合計を区別してください。

1. 入力したアドレスの総数。
2. 処理した入力の数。重複は除きます。
3. 確認後に採用した、識別済みページの数。

1つ目の合計は、入力したリストを把握するために使います。2つ目は、収集結果との照合に使います。3つ目は、利用できるデータセットの規模を示すために使います。

返された各行について、入力したアドレスとの対応を確認します。次に、`channelUrl`を確認します。利用できる識別の根拠を使い、そのページが意図した対象と一致するかを確認してください。一致が不確かな場合は、その行を確認対象のままにします。

この比較は、データセットを作る前に収集仕様を選ぶためのものです。既存のディレクトリ内でページレコードを確認する詳しい手順は、地域事業者ディレクトリのFacebookページレコードを検証する方法をご覧ください。

件数は精度と時刻を併せて確認する

件数を計算に使う前に、その値の条件を把握する必要があります。Chronometricaは、出力仕様の一部として`countPrecision`と`observedAt`を文書化しています。利用する測定値と併せて、両方を確認してください。ChronometricaのActor

`countPrecision`は、返された件数の精度に関する情報を示します。返された値は、文書化された意味に従って扱ってください。数値として保存できるというだけで、正確な値だと判断してはいけません。

`observedAt`は観測時刻を示します。作業に使えるほど新しいレコードかを判断するのに役立ちます。過去の値の履歴を示すものではありません。

次の3点を確認します。

1. 測定値が存在することを確認します。
2. その精度が基準を満たすことを確認します。
3. 観測時刻が、経過時間の許容上限を満たすことを確認します。

データをエクスポートまたはインポートするときは、元の値と、その精度に関する情報を一緒に保持します。件数だけを残して精度を捨てると、後の利用者が、レコードの根拠を超えて値を確かだと判断する可能性があります。観測時刻を捨てると、値がどれほど古いかを判断できません。

欠損値は不明のまま保持します。0は、合計、平均、順位、フィルターに影響する値です。返された測定値が0であることを示す場合だけ、0を使ってください。空欄や取得できない件数から、0だとは判断できません。

ページ同士を比較する場合は、観測時刻の違いを許容できるか決めます。一定の収集期間内なら認める基準にしてもかまいません。ただし、その期間を明記してください。Actorは採用判断の根拠を提供します。基準は、作業の目的に合わせて定めます。

取り込む前に結果の状態を確認する

返された行は、収集結果の記録です。行があるだけでは、必要なデータがすべてそろっているとはいえません。

Chronometricaは、結果の確認に使う`status`と`statusReason`を文書化しています。返された状態は、文書化された意味に従って読んでください。注意が必要な結果について理由が示されている場合は、その内容を確認します。ChronometricaのActor

内部の確認作業では、3つのグループに分けます。これらは作業用のラベルです。Actorが返すと約束された状態の値ではありません。

1. 採用：識別情報が適切で、必須の値がそろい、精度と時刻が基準を満たしている。
2. 要確認：利用前に、識別情報の確認、説明、または別の判断が必要である。
3. 取り込み保留：利用できる根拠だけでは、目的の用途に使えない。

要確認の行と取り込み保留の行は、作業用の記録に残してください。これらは、入力したリストと採用済みデータセットの差を説明します。早い段階で削除すると、不完全な収集が完了したように見える可能性があります。

重複を除いたすべての入力を、結果行と照合します。次に、すべての結果行を、内部の確認判断と照合します。採用した件数の最終合計を報告する前に、説明できない差を調べてください。

後で再び収集する場合は、以前の結果と後の観測を区別できる情報を十分に残します。これは、自分の記録を管理するための規則です。Actorの文書化された範囲に、過去データの収集機能を追加するものではありません。

架空の例：20件のページアドレス

これは架空の例です。実際のデータセット、製品テスト、購入者の発言、費用の実測結果ではありません。

ディレクトリを管理するチームが、20件の公開Facebookページのアドレスを入力します。取り込む前に、正規の識別情報、適切な精度の観測済み件数、観測時刻、結果の状態が必要です。より幅広い事業者プロフィールは必要ありません。

チームはChronometricaを選びます。確認に必要な項目を備えた行を返すという文書化された仕様が、要件に合うためです。入力する各アドレスの欄と、確認結果を記入する列を設けた採用確認シートを用意します。

まず、チームは入力リストの重複を確認します。返された行との照合には、重複を除いた入力の合計を使います。20件のアドレスを入力すれば、20件の対象を採用できるとは考えません。

次に、各`channelUrl`が意図した事業者に対応するかを確認します。必要な件数を確認し、`countPrecision`を読み、`observedAt`を経過時間の基準と照合します。その後、`status`と、該当する`statusReason`を確認します。

チームは不明な件数をそのまま保持し、対象を特定できていないレコードを確認のために保留します。これらの確認が終わってから、採用した対象の数を報告します。この例では、成功率や採用件数の最終合計を架空の数値で示していません。

同じチームが後で営業時間や評価を必要とする場合は、収集仕様を選ぶ前に、Apify Facebook Pages Scraperが扱う幅広いページ詳細情報を評価します。Apify Facebook Pages Scraper

Taskを起点に入力を確認する

Taskとは、Actorの入力設定を保存したものです。公開されているFacebook Page Data API Dataset Taskを、この手順の出発点にできます。

Taskのページは、アクセス可能であることを確認済みです。確認では、ページへのリクエスト成功を示すHTTP 200と、意図したTaskのタイトルを記録しました。この確認は、現在保存されている入力を確かめたものではありません。実行前に、使用する入力を設定し、現在のActorスキーマに照らして確認してください。

この最小限の入力は、キャッシュされた公開スキーマに対する静的チェックに合格しました。

{
  "startUrls": [
    "https://www.facebook.com/MrBeast/"
  ]
}

静的チェックは、入力の構造を調べるものです。該当する場合は、項目名、必須項目、許可された選択肢、リストの件数、文字列のパターン、数値の制限を確認します。例のページに現在アクセスできることや、収集によって採用基準を満たすデータが返ることを証明するものではありません。例のアドレスを、収集したい公開データの取得元に置き換えてください。ChronometricaのActor

次の簡単な手順で進めます。

1. 必須項目と採用基準を書き出します。
2. 既知の公開ページのアドレスを用意します。
3. 現在のスキーマに照らして入力を確認します。
4. 予定する取得元の特徴を代表する少数の入力で実行します。
5. 識別情報、精度、時刻、結果の状態を確認します。
6. 返されたレコードが基準を満たしたら、収集規模を広げます。

少数の入力での実行は、自分の作業手順を評価するために使います。何を入力し、何が返り、各行をなぜ採用または保留したかを記録してください。大規模な取り込みを決める前に、これらの点を確認できる試行が有用です。