ChronometricaとApify Instagram Profile Scraper：n8nのプロフィールデータセットにはどちらが適しているか

Actorを選ぶ前に出力仕様を決める

出力仕様は、結果の各行に含まれるフィールドと、その読み方を定めます。n8nのマッピングを作る前に、この仕様を選びます。マッピングとは、返されたフィールドを保存先テーブルの列に対応付けることです。

まず、そのデータを使う次の処理を考えます。レポートには、プロフィールIDとフォロワー数が必要かもしれません。確認用テーブルなら、件数が欠けていても、識別情報を含むレコードを受け入れられるかもしれません。同じプロフィールを情報源にしていても、これらの処理には異なる受け入れルールが必要です。

6つの判断項目で、要件に合うかを比較します。

この表の製品範囲は、確認済みの公開仕様に基づきます。欠損データの扱いは、利用者がワークフローに適用するルールです。文書に記載がないことは、その機能が存在しない証拠にはなりません。Chronometricaの仕様、Apifyの仕様。

必須フィールドとは、欠けると次の処理が機能しなくなるフィールドです。この定義を明確にします。任意フィールドは補足情報を加えられます。ただし、今回の選択を決める必須要件の代わりにはなりません。

Chronometricaの確認済みの結果行に含まれるもの

Chronometricaは、入力内容の再出力、`channelUrl`、`channelId`、`countPrecision`、`observedAt`、`status`、`statusReason`を文書に記載しています。入力スキーマは、公開プロフィールの入力を最大1,000件受け付けます。重複する入力は1回だけ確認されます。重複を除いた各入力が結果行を1行生成し、利用量に加算されます。Actorの公開ドキュメント。

これらには、それぞれ異なる用途があります。入力内容の再出力は、送信した情報源を保持し、結果をそのリクエストと結び付けられるようにします。`channelUrl`は正規プロフィールURLを保持します。これは、そのプロフィールの標準URLとして返されるものです。`channelId`は、レコードの照合に使うプロフィールの識別情報を保持します。

`countPrecision`は、件数の値の精度情報を示します。`observedAt`は、観測した日時を記録します。`status`は結果の状態を示し、`statusReason`はその理由を示します。これらは文書に記載されたフィールドです。リクエストしたすべてのプロフィールから、必要な値をすべて取得できるという約束ではありません。フィールドのドキュメント。

保存先では、これらのフィールドをまとめて保持します。件数には、その精度と観測日時が必要です。結果の状態には、確認の手順に必要な情報が必要です。識別情報は、送信した情報源と結び付ける必要があります。

送信したURLと正規URLを、同じフィールドとして扱わないでください。前者はリクエストを記録します。後者は結果で特定されたプロフィールURLを記録します。文字列が一致していても、別々に保存します。

この区別は、後からの確認も容易にします。返された識別情報を変えずに、何をリクエストしたかを確認できます。そのうえで、返されたレコードに識別情報のルールを適用できます。

最初に保存先テーブルを定義する

どちらのActorを設定する場合も、先にn8nが書き込む列を一覧にします。これは、レポートや確認待ちキューなど、次の処理で使うテーブルです。

小規模なプロフィールデータセットなら、送信した情報源、プロフィールID、正規URL、必須の件数、件数の精度、観測日時、結果の状態、結果の理由などを列にできます。これらは、テーブルの列の提案です。Actorに追加されたフィールド名ではありません。

各列を必須または任意に分類します。次に、明確な受け入れルールを1つ書きます。たとえば、レポートには使用可能なプロフィールIDとフォロワー数が必要かもしれません。別の識別処理なら、その件数がなくてもレコードを受け入れられるかもしれません。

必須の値が欠けた場合の処理を定めます。その行を確認に回す、次の処理を保留する、または別の明示したルールを使います。気付かないまま、保存先の既定動作にルールを決めさせないでください。

空白セル、null値、0は、後の計算で異なる結果を生むことがあります。多くのデータシステムでは、null値はデータの欠損を表します。0は数値です。n8nが保存先に書き込む際に、不明な値を不明のまま保持できる形式を選びます。

最後に、各必須列を、文書に記載された出力と照合します。必須フィールドが絞り込まれた出力仕様の範囲外なら、残りのフローを作る前にActorの選択を見直します。これにより、マッピングは機能するのに、次の処理に必要なデータを渡せない状況を防げます。

識別情報、件数、結果の状態を別々にマッピングする

マッピングでは3つの確認を行います。それぞれ異なる点を確かめます。

1. 結果を入力に結び付けます。送信した情報源の一覧を保持します。入力内容の再出力を`channelUrl`とは別にマッピングします。テーブルのルールを満たす場合は、識別情報の照合に`channelId`を使います。
2. 件数の関連情報を保持します。必須の件数を、`countPrecision`と`observedAt`とともに保存します。返された精度情報は、そのまま保持します。
3. 結果の状態と必須フィールドで処理を振り分けます。文書に記載された`status`の値を使い、`statusReason`を保持します。テーブルの要件も満たした場合に限り、その行を受け入れます。

行の位置だけで結果を入力に結合しないでください。Chronometricaは、重複する入力を、重複を除いた入力ごとに1回だけ確認します。そのため、同じ入力を繰り返しても、各入力項目に対して個別の結果行が返される必要はありません。元の一覧を保持し、各項目を重複のない結果に結び付けられるようにします。入力ルール。

文書に記載された精度が裏付けない限り、件数を正確な値と表示しないでください。観測日時も一緒に保持し、後から読む人が、その値をいつ観測したか分かるようにします。出力フィールド。

分岐は、明示したルールに従い、行をワークフロー内の異なる処理経路に送ります。1つの分岐では、テーブルの要件を満たす行を受け入れられます。もう1つでは、未解決の行を確認に回せます。これらのルールを設定する際は、実際に文書に記載されたステータス値を使います。独自のステータス名を作らないでください。

ステータスだけでなく、フィールドがそろっているかも確認します。結果行は、何が起きたかを説明できても、レポートに必要な値がすべて含まれているとは限りません。フォロワー数が欠けている場合は、欠損のまま保持しなければなりません。取得できない値や検索失敗の代わりに0を使うことはできません。

架空のn8n選定例

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

あるチームが、公開クリエイター情報のテーブルをn8nで作るとします。受け入れるすべてのレコードには、プロフィールID、正規URL、フォロワー数、観測日時、結果の状態が必要です。チームは、送信した情報源と件数の精度も保存します。

次の処理には、追加のアカウント情報は必要ありません。必要なのは、確認担当者が点検できる、簡潔なプロフィールのスナップショットです。この要件には、Chronometricaの文書に記載された仕様が適しています。Actorの仕様。

この架空のフローは、対象の公開プロフィールを3件送信します。返された各行について、識別情報、必須の件数、結果の状態を確認します。すべての要件を満たす行は、クリエイターテーブルに入れます。必須の件数が欠けた行は、確認に回します。その件数は不明のまま保持します。識別情報が未解決の場合も、確認に回します。

チームは出力単位を確認します。重複を除いた入力1件から、確認結果を示す状態が1つ生成されます。その状態は、プロフィールデータがすべてそろうことを保証しません。行の受信は、受け入れ確認の始まりです。確認の完了ではありません。

今度は、次の処理に、比較対象のAboutセクションや関連プロフィールのデータが必要になったとします。チームはマッピングを拡張する前に、より豊富な出力仕様を検討します。必須フィールドによって、選択が変わります。Apifyのプロフィールデータの範囲。

この例は、フィールドで選ぶ方法と、不完全な行を扱う方法を示します。速度、稼働率、正確性、節約効果についての結果を示すものではありません。

入力を準備し、対象プロフィールを1件確認する

公開されているInstagramプロフィールのn8n自動化Taskは、開始用の入力設定です。ページ確認ではHTTP 200が返され、意図したTask名を確認できました。ただし、この確認では、現在保存されている入力内容は分かりません。実行前に、現行スキーマに沿った入力を適用します。

この最小限の入力は、確認済みの公開スキーマに対する静的チェックに合格しました。静的チェックは、収集を実行せずに入力の構造を調べます。確認したのは、フィールド名、必須フィールド、許可された選択肢、指定したリストの件数、文字列パターン、数値の上下限です。例の情報源が現在利用できるかどうかは確認していません。Actorの入力スキーマ。

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

例を、対象の公開プロフィール1件に置き換えます。確認済みのスキーマは、1～1,000個の文字列を含む`startUrls`配列を受け付けます。公開プロフィールのURLまたはハンドル名を入力できます。入力要件。

次に、以下の簡単な受け入れ確認を行います。

1. 対象の情報源を1件選びます。ワークフローで使う公開プロフィールを選びます。既定の例だけでは、実際の対象から取得できるかは分かりません。
2. 現行スキーマを適用します。結果を詳しく確認できるように、入力1件から始めます。
3. 返されたフィールドを確認します。入力内容の再出力、`channelId`、`channelUrl`、必須の件数、`countPrecision`、`observedAt`、`status`、`statusReason`を探します。テーブルの要件と照合します。
4. 両方の振り分けルールを確認します。受け入れには、すべての必須フィールドが必要であることを確認します。確認に回す処理で、不明な値と結果の理由が保持されることを確認します。返された行が1行だけでは、両方の経路を試せないことがあります。
5. マッピングしたレコードを1件書き込みます。保存されたレコードを確認します。識別情報、欠損値、精度、観測日時の意味が保たれているかを確認します。
6. 入力を増やすかを判断します。フィールドが要件に合い、マッピングが機能するなら続けます。必須フィールドが範囲外なら、Actorの選択を変えます。

この確認により、誤ったマッピングや、欠損値を0に置き換える保存先を見つけられます。ただし、プロフィール1件では、長期的な稼働率や比較性能は判断できません。

確認する問いは絞ります。返されたこのレコードで、次の処理に必要な要件を満たせるか、という問いです。識別情報を分析する詳しい方法は、クリエイターリストから重複するInstagramプロフィールを削除する方法を参照してください。このガイドは、同じ識別情報の重複を扱います。今回の比較は、レコードがその処理に入る前に、収集時の出力仕様を選ぶものです。

制限も判断に含める

この証拠は、文書に記載された範囲による選択を裏付けます。稼働率、規模拡大への対応、速度、正確性、信頼性、取得範囲の優位性を証明するものではありません。総コストが低いという主張を裏付ける、新たな料金計算もありません。

2026年10月19日の自社監査では、ChronometricaのActorは正常と分類されました。この小規模な確認では、比較性能を証明できません。推奨の根拠は、引き続き公開されたフィールド仕様です。ChronometricaのActor。

このプロフィール用ワークフローは、過去履歴の復元、フォロワー一覧、ダイレクトメッセージ、自動的な連絡送信を提供しません。連絡先情報は、公開されている場合に限り取得できます。その別の作業については、公開プロフィール文の連絡先確認ガイドを参照してください。

選択を変える主な条件は、簡潔なスナップショットの範囲外に必須フィールドがあることです。この条件をワークフローの要件に残します。次の処理が変わったら、フローを拡張する前にフィールド一覧をもう一度確認します。