ChronometricaとSocial FetchのInstagramプロフィール収集比較：どの結果が課金対象になるか

表示単価より先に、課金される結果の単位を比較する

結果の行、課金イベント、調査に採用したレコードは、それぞれ異なります。

結果の行は、入力に対する処理結果を記録します。課金イベントは、料金が発生する操作や結果です。採用したレコードは、自分の調査基準を満たすものです。検索失敗を記録した行があっても、業務に必要な公開データが得られたとは限りません。

Chronometricaでは、`ok`と`partial`のスナップショットにプロフィールイベントの料金が発生します。`missing`、`blocked`、`invalid`、`failed`の行には、このイベントの料金は発生しません。これらの行は、後から確認できるように残ります。現在のFree料金では、有用な結果1,000件あたり$2.50に、プラットフォーム使用料が加わります。検索に失敗しても、プラットフォーム使用料が増える場合があります。対象外になるのは、プロフィール結果イベントの料金だけです。Chronometricaのルールと料金

Social Fetchでは、`not_found`や非公開という結果も含め、完了した検索結果1,000件あたり$1.98と記載されています。計算処理やプロキシの料金は別途発生しません。公開料金APIには、開始イベントも記載されています。Social Fetchのルールと料金

これらの違いは、リンク先のChronometricaの提供条件とSocial Fetchの提供条件に基づいています。この比較でフィールドの詳細が不明だからといって、その機能がないとは判断できません。

表示単価の低さと、課金対象となる結果の範囲の狭さは、異なる判断材料です。どちらも、それだけでは請求総額を示しません。結果の単位、開始イベント、プラットフォーム使用料が異なるため、1,000件あたりの価格だけでは単純に比較できません。有効なハンドルが大半を占めるリストでは、失敗したプロフィールイベントを課金対象から除外する実用上の利点も小さくなる場合があります。

プロフィール一括処理で必要な成果を定める

この比較のきっかけとなった公開の質問は、プロフィール収集をほかのInstagramツールと比べるとどうか、というものです。その背景には、インフルエンサーの一括調査とシステム連携という、より広い業務があります。料金への苦情があったことを示すものではありません。投稿の商業的な背景は不明です。そのため、読者の疑問を示す根拠にはなりますが、独立した立場からの推奨や市場規模の主張を支えるものではありません。公開された読者の質問

自分のリストでツールを選ぶ前に、成功の条件を1文で書きます。たとえば、採用するレコードには、確認作業に必要な公開プロフィールのフィールドが含まれていること、と定めます。次に、そのフィールドを列挙します。「リクエストが完了した」といったルールでは、返されたデータが次の判断に使えるかどうかが明確になりません。

公開スナップショットを集める業務は、クリエイターの選定、プロフィール一覧の作成、指標の定期確認などに役立ちます。その業務の判断に関わるフィールドを選びます。有用なデータを含むレコードでも、自分の作業に必須のフィールドが欠けている場合があります。

存在確認の業務には、別のルールが必要です。公開スナップショットが得られないハンドルも含め、入力した各ハンドルを分類する必要があるかもしれません。その分類自体を、採用できる結果とするかどうかを決めます。

また、一部のデータが欠けたレコードを使えるかどうかも決めます。欠損値であることを明示して保持できるプロジェクトもあります。確認が済むまで保留にする必要があるプロジェクトもあります。これは、自分で決める採用可否の判断です。課金対象の結果区分だけでは、その判断はできません。

別の分析担当者も適用できるように、ルールを明確にします。同じ行を見た2人の判断が異なる場合は、リストを拡大して収集する前にルールを明確にします。これにより、2つの提供条件を一貫した基準で比較できます。

Chronometricaの行を2つの観点から確認する

処理結果の確認には`status`を使います。プロフィール結果イベントの課金が適用されるかどうかの確認には`isBillable`を使います。収集データとともに、両方のフィールドを保持します。Chronometricaは、これらのフィールドと、結果に基づく課金ルールを文書に記載しています。Chronometricaの出力と課金ルール

まず、結果の区分を確認します。`ok`または`partial`の行は、課金対象のプロフィール結果区分に入ります。記載された失敗区分では、このイベントは発生しません。次に、その行が自分の採用基準を満たすかどうかを確認します。この2つの確認は、目的が異なります。

`partial`の行には、特に注意が必要です。この行はイベントの課金ルールに含まれますが、必須フィールドがすべて存在することを保証するものではありません。レコードを採用する前に、実際のフィールドを確認します。データの完全性を測る指標として`isBillable`を使わないでください。

同様に、失敗した結果をすべて、アカウントが存在しないという結論に置き換えないでください。収集がブロックされた場合と、プロフィールが見つからない場合では、結果が異なります。後から確認する人が、その行から何が分かるかを判断できるように、報告された区分を保持します。

欠損値は、不明のまま保持する必要があります。指標がない場合は、0に置き換えないでください。0は、観測された数値です。不明とは、観測値がないことです。両者を同じものとして扱うと、絞り込み、順位付け、集計の結果が変わる場合があります。

非公開プロフィールのメタデータと、非公開コンテンツも異なります。非公開プロフィールについての結果が得られたことから、非公開の投稿や連絡先にアクセスできると推測しないでください。この比較では、その前提でどちらかのツールを選ぶべきではありません。業務に必要な公開データ、または検索結果を明確にします。

架空のリストで判断方法を確かめる

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

ある分析担当者が、現在の公開プロフィールと古いハンドルを含むリストを持っています。業務の目的は、有用な公開スナップショットから確認用リストを作ることです。担当者は少数のプロフィールフィールドを必須とし、後から確認できるように収集結果を保持します。

次の4つの架空の結果を考えます。

1. プロフィールAでは、必須フィールドを含む`ok`の行が返されます。担当者は、このレコードを採用します。
2. プロフィールBでは、`partial`の行が返されます。必須フィールドが欠けているため、担当者は確認のために保留します。
3. 古いハンドルCでは、`missing`の行が返されます。担当者は結果を保持しますが、スナップショットのリストからは除外します。
4. プロフィールDでは、`blocked`の行が返されます。担当者はこの区分を保持し、アカウントが存在しないとは記録しません。

Chronometricaの文書に記載されたルールでは、最初の2つの結果にプロフィール結果イベントが発生します。最後の2つには発生しません。プラットフォーム使用料は発生する場合があります。これは公開されたルールを説明する例であり、実行結果の報告ではありません。Chronometricaのイベントルール

プロフィールBは、課金対象の結果と採用するレコードが異なる理由を示しています。課金対象の区分には入りますが、この担当者が定めた、より厳しいフィールド要件は満たしていません。ツールを選ぶ前に、このような一部欠損レコードの扱いが業務に適しているかを判断する必要があります。

ここで、業務の目的を変えます。担当者が、各ハンドルの存在や非公開かどうかの確認を必要としているとします。この場合は、完了した確認自体が成果になります。入力リストが同じでも、目的が変わると、選ぶツールが変わる場合があります。

これらの架空の結果から、請求総額を計算しないでください。プラットフォーム使用料、開始イベント、実際のリストに含まれる有用な結果の割合について、実測情報はありません。この例で確認するのは判断ルールであり、収集費用ではありません。

簡単な採用確認手順を使う

この手順で、必要な結果と、返されたデータが示す根拠を照合します。出力の確認と課金の確認も分けて行えます。

1. 必要な結果を書きます。公開スナップショットが必要なのか、完了したハンドル確認が必要なのかを明記します。レコードを利用可能にするフィールドを列挙します。一部欠損レコードの扱いも決めます。
2. 現在のイベントルールを読みます。どの結果に料金が発生するかを確認します。見つからない場合や非公開の場合の結果、開始イベント、プラットフォーム使用料を確認します。確認した条件の日付を記録します。
3. 小規模な入力リストを用意します。実際の業務に関係する公開情報源を使います。業務に古いハンドルが含まれる場合は、それらも入れます。成功すると予想できる情報源だけでサンプルを作らないようにします。
4. 返された行を確認します。Chronometricaでは、`status`と`isBillable`を保持します。必須フィールドは別に確認します。不明な値と失敗した結果を、確認できる状態で残します。
5. 実際の料金を確認します。記録されたイベントとプラットフォーム使用料を、提供条件と照合します。採用したレコード数は、返された行数や課金対象のプロフィール結果数とは別に数えます。
6. 適した提供条件を選びます。結果の定義、フィールドの採用基準、実際に発生した料金を合わせて判断します。実行規模を拡大する前に、重要な不一致や不明点を解消します。

これらは、自分で確認するための手順です。この記事のための実行は行っていません。今後、小規模な実行を行えば、選んだ情報源、入力、採用基準についての根拠が得られます。ただし、ツール間の一般的な性能順位を示すものにはなりません。

確認記録は簡潔に保ちます。採用基準、入力リスト、返されたデータ、課金記録をまとめて保存します。別の人が、行を採用した理由と、その行に適用された記録上のイベントをたどれるようにします。

課金された一部欠損レコードの多くがフィールド要件を満たさない場合は、収集規模を拡大する前に、ツールが業務に適しているかを見直します。存在しないと確認できた結果自体が有用なレコードになる場合は、それを採用基準に含めます。どちらの判断も、必要な業務から導きます。

費用全体の確認方法については、Instagram調査の収集予算を参照してください。この比較では、課金対象となる結果の単位と、失敗した行の扱いに焦点を当てています。

同一人物かどうかの確認と課金の確認を分ける

入力リストには、重複した項目、古いハンドル、チームが同じ人物を指すと考えている複数の参照情報が含まれる場合があります。これらは、同一人物かどうかに関する問題です。課金フラグでは解決できません。

Chronometricaの現在の`startUrls`スキーマは、公開InstagramプロフィールのURLまたはハンドルを1〜1,000件受け付けます。重複した入力は1回だけ確認すると記載されています。重複を除いた各入力から、結果の行が1行作られ、使用量が加算されます。Chronometricaの入力スキーマ

この入力重複のルールは、異なる2つのハンドルが同じクリエイターのものだと示すものではありません。また、返されたスナップショットも、古いスプレッドシートのラベルが現在のアカウント所有者を指している証拠にはなりません。そうした判断は、本人を特定するための関連証拠に基づいて行います。

確認した各結果を、確認対象としていた情報源に結び付けられるだけの情報を保持します。自分の処理でレコードを統合する場合は、一致すると判断した理由を残します。別の行と似ているという理由だけで、失敗した行を削除しないでください。

これは、採用したレコードを数えるときに重要です。2つの入力を1つの調査レコードに統合すると、その件数は変わります。しかし、それだけでは収集料金を説明できません。入力数、結果数、採用レコード数を分けて管理します。

同一人物かどうかを確認する詳しい方法は、クリエイターリストから重複するInstagramプロフィールを除く方法を参照してください。そのガイドで同一性を判断します。ここで紹介した確認方法は、何を課金対象のプロフィール結果とするかの判断に使います。

検証済みの最小入力から始める

公開されているInstagram Profile Metrics Snapshot Taskには、開始用のプリセットがあります。2026年10月20日のページ確認ではHTTP 200が返され、想定したTask名を確認できました。現在保存されている入力内容は確認できていません。実行を開始する前に、自分の入力を確認して適用してください。

この最小入力は、提供された現在の公開スキーマとの静的検証に合格しました。

{
  "startUrls": [
    "https://www.instagram.com/mrbeast/"
  ]
}

スキーマは、受け付ける入力の構造を定義します。静的検証では、収集を実行せずに、入力をそのルールと照合します。今回の検証では、フィールド名、必須フィールド、許可された値、リストの件数、文字列のパターン、該当する数値の上下限を確認しました。

この検証ではInstagramに接続しておらず、例に使った情報源が現在利用できることも確認していません。例のURLを、自分が対象とする公開情報源に置き換えてください。入力形式が受け付けられることと、情報源が利用できることは、別々に確認する必要があります。

初回の実行前に、入力リストを確認し、必須フィールドと一部欠損レコードの扱いを明記します。実行後は、リストを拡大する前に、実際の出力と課金記録を確認します。最初の収集は、すべての行をそのルールと照合できる規模に抑えます。

プリセットは、入力の準備に役立ちます。採用基準は、返されたデータが業務に使えるかどうかを決めます。イベント記録は、どの料金が適用されたかを示します。より大きな規模で利用を決める前に、この3つをすべて確認します。