LinkedInの公開コメント出力：ChronometricaとHarvestAPIを比較

まず収集範囲を比較する

Actorは、ホスト環境で動く収集プログラムです。両製品ともApify上のActorです。この比較で重要なのは、文書に記載された収集範囲が、調査で答えたい問いに合うかどうかです。確認済みの製品情報を表にまとめました。Chronometricaのドキュメント、HarvestAPIのドキュメント

出力された行数だけで選ばないでください。1行が表すのは、投稿に直接付いたコメント、返信、収集結果のいずれかかもしれません。それぞれの単位で答えられる問いは異なります。まず、1件の観測が何を意味するかを決めます。そのうえで、その観測を含む出力を比較します。

公開コメントの投稿者サンプルにChronometricaが適する理由

Chronometricaは、LinkedInの公開の投稿／フィードURLを1～100件受け付けます。対応している同一の投稿識別情報を指す入力は、重複を除去します。また、一意の公開コメントIDも保存します。これらの機能は、同じ収集元や保存済みコメントを2重に数えることを防ぐのに役立ちます。Chronometricaのドキュメント

これらの確認には、それぞれ異なる目的があります。投稿入力の重複除去は、収集元リストの重複を防ぎます。一意のコメントIDは、コメントの観測の重複を防ぎます。どちらも、コメント数を人数に変えるものではありません。1人の投稿者が複数のコメントを書くことがあるため、投稿者リストには別の確認が必要です。

任意設定の`includeAuthorDetails`は、保存した投稿者の重複を除いたうえで、その公開情報の取得を要求します。既定値は`false`です。投稿者情報に対する別の課金イベントが追加される場合があります。その情報が調査の問いに役立つ場合に有効にしてください。Chronometricaのドキュメント

最も適しているのは、収集範囲を説明できる公開トップレベルコメントのサンプルで進められる調査です。確認したコメントを保持し、投稿者リストを別に作成し、収集の限界を出力とともに保存できます。これにより、確認担当者は、そのサンプルから何を裏付けられるかを明確な根拠に基づいて判断できます。

これによって、議論の参加者全員を確認したことにはなりません。また、公開プロフィールがあるだけで、その人が営業上の条件を満たす見込み客になるわけでもありません。そのような結論には、追加の証拠が必要です。

返信の必要性によって選択が変わる場合

HarvestAPIは、投稿とコメントのURLを受け付けます。投稿を入力した場合は、各ルートコメントの結果内に、入れ子になった返信を最大5件含めると記載されています。コメントURLの場合は、`scrapeReplies`で返信を個別の結果として返すことができます。`postedLimit`や投稿者情報の取得モードも、選択に影響する場合があります。文書に記載された設定が、自分の要件に合うかを確認してください。HarvestAPIのドキュメント

行数の合計を比較する前に、ルートコメントと返信の数え方をそろえてください。ルートとは、トップレベルコメントのことです。ルートに付いた返信は、本文の観測数を増やします。ただし、異なる人の数が増えるとは限りません。

Chronometricaは、返信スレッド全体を収集しません。議論内のすべてのコメントと返信が必要なら、その要件を満たしません。数値による上限を取り除いても、収集範囲は変わりません。Chronometricaのドキュメント

確認する必要がある人々を定義する

この比較の背景には、購入検討者が自分のLinkedIn投稿にコメントや「いいね」をした人のプロフィールを見つけたいという要望があります。その根拠は、保存した公開検索結果の抜粋です。議論全体の記録ではありません。これは調査の必要性を示すもので、収集結果が検証済みであることを示すものではありません。公開の依頼

Actorを選ぶ前に、必要な母集団を1文で定義してください。母集団とは、調査で対象にする必要がある人々の集団です。たとえば、選んだ3件の投稿に表示されているトップレベルコメントの投稿者が必要かもしれません。別の調査では、返信の投稿者、「いいね」をした人、またはその3つの集団すべてが必要になるかもしれません。

これらの集団は分けて扱ってください。コメントの出力から、「いいね」をした人の完全なリストを確定することはできません。トップレベルコメントのサンプルから、返信投稿者の母集団を確定することもできません。問いに答えるために欠けている集団が必要なら、いったん止めて収集計画を変更してください。

何を主張するつもりなのかも定義してください。「これらの投稿者が収集したサンプルに含まれていた」という主張に必要な証拠は、「これが参加者全員である」という主張より少なくなります。主張の範囲が小さくても、得られた証拠に合っていれば有用です。

この違いについて詳しくは、LinkedInの公開コメント出力は議論全体を代表できるか？を参照してください。

少量の確認済み入力から始める

Taskは、Actorの入力設定を保存したプリセットです。公開の投稿者情報Taskを開き、実行前に実際の設定を確認してください。

保存した証拠では、Taskページに公開アクセスできたことを確認しています。そのページの確認だけでは、現在保存されている入力内容は確定できません。プリセットを出発点として、次の設定を自分で確認してください。

1. 保存されているURLを、収集対象の公開投稿URLに置き換えます。
2. 最初の確認では、`maxComments`を小さな上限値に設定します。
3. 公開の投稿者情報が必要なら、`includeAuthorDetails`を`true`に設定します。
4. 実行を開始する前に、残りの設定を確認します。

この例のフィールドと値は、保存した公開JSON Schemaに対するローカル確認に合格しています。JSON Schemaは、使用できる入力フィールドと値を定義するものです。この確認で確かめたのは入力形式です。実行時に収集元を利用できることを確認したものではありません。Chronometricaの入力ドキュメント

{
  "startUrls": [
    "https://www.linkedin.com/posts/timferriss_how-to-become-dramatically-more-productive-activity-7386884213343428608-wrF3"
  ],
  "maxComments": 10,
  "includeAuthorDetails": true
}

例のURLを、選んだ公開の収集元に置き換えてください。このURLは文書に記載された対象例であり、新たな収集結果の証拠ではありません。

確認済みのスキーマでは、`startUrls`に1～100件の項目、`maxComments`に1～1,000の整数を指定できます。後者は投稿ごとの上限です。10という設定は、範囲を限定したサンプルを要求します。コメントが10件保存されると保証するものではありません。Chronometricaの入力ドキュメント

最初のサンプルを使い、保存された本文と投稿者の識別子が、予定している分析に使えるかを確認してください。この確認前に量を増やすと、出力が大きくなっても、必要な問いに答えられないままになることがあります。

結果を説明する前に収集範囲を確認する

Chronometricaは、コメント行と、`OUTPUT`内の入力および収集範囲に関する結果を分けて扱います。コメントを要約する前に、各入力の結果を確認してください。収集範囲の記録と停止理由は、収集が終了した理由を説明するのに役立ちます。Chronometricaの出力ドキュメント

次の簡単な受け入れ確認を行ってください。

1. 各結果が、入力したどの投稿に属するかを確認します。
2. 公開の`commentId`値で、保存されたコメント行を識別します。
3. `authorUrl`または`authorId`が公開されている場合は、その値で投稿者を照合します。
4. 識別子が欠けている記録は、未解決のまま保持します。
5. 入力の収集範囲に関する結果と停止理由を確認します。
6. 確認したサンプルから裏付けられる主張を判断します。

入力の状態を示す記録を、コメントとして扱わないでください。同様に、画面に表示された議論の総数と、保存したトップレベルコメントの行数を直接比較しないでください。両者は異なる単位を指す場合があり、議論のうち表示されている範囲も異なる場合があります。

`collectAllAvailable`設定は、コメント数の上限を取り除きます。それでも、公開の収集元で取得できる範囲、料金の上限、時間の上限、または処理の失敗によって収集が止まる場合があります。この設定は、公開ページにすべてのコメントが表示されていたことを証明しません。Chronometricaの収集制限

当初の要件がすべてのコメントを求めているなら、取得できた公開サンプルを完全な出力と言い換えないでください。公開トップレベルコメントの収集元を超える内容が必要な場合、Chronometricaはすべてのコメントを集めるという要件を満たしません。

公開の投稿者フィールド、日付、リアクション数を取得できない場合があります。それらの不明な値は、そのまま保持してください。リアクション数の欠損は、リアクションが0件だった証拠ではありません。日付の欠損から、コメントがいつ掲載されたかを確定することもできません。Chronometricaの出力ドキュメント

計算を確認した架空の判断例

次の例は架空のものです。Actorのテスト、実際のデータセット、購入検討者の発言の引用、費用の測定結果のいずれでもありません。

ある調査担当者が、1件の公開投稿からプレビューを収集します。そのプレビューには、公開情報で区別できる7人の投稿者によるトップレベルコメントが10行含まれています。そのうち5人については、追加の投稿者情報を確認できました。残りの2人は未解決のままです。

調査担当者は、3つの結果を分けて報告します。

• サンプルには、確認したトップレベルコメントが10件含まれています。
• それらのコメントは、確認した7人の異なる投稿者によるものです。
• 5人の投稿者について追加情報を取得でき、2人は未解決のままです。

計算は単純です。確認した投稿者7人から、追加情報がある投稿者5人を引くと、未解決の投稿者は2人です。コメントの10行は、10人を表しているわけではありません。また、詳細情報の結果が2人分未解決だからといって、その投稿者がコメントのサンプルに存在しなかったことにはなりません。

調査の問いに答えるために、それらのコメントに付いた8件の返信も必要だとします。トップレベルコメントのサンプルでは答えられません。そこで調査担当者は、HarvestAPIの返信モードを検討します。HarvestAPIのドキュメント

取得する可能性があるその8行の返信は、別の単位です。投稿者を確認せずに、新たな8人として数えることはできません。一部はトップレベルコメントのサンプルにすでに含まれる人によるものかもしれません。また、複数の返信が同じ人によるものかもしれません。

当初の問いが、確認したトップレベルコメントの投稿者7人だけを対象にしているなら、この範囲を限定したサンプルで足りるかもしれません。参加者全員を対象にしているなら、同じサンプルでは不十分です。判断の基準は、ファイルの大きさではなく、必要な母集団です。

4種類の記録を分けて出力する

4つのテーブル、または明確に分けた記録のグループを保持してください。それぞれ目的が異なります。この構造にすると、他の人が各行の意味を推測せずに、作業内容を確認できます。

1つ目のテーブルには、保存したコメントの観測記録を入れます。各コメントとともに、収集元の投稿と`commentId`を保持してください。公開の投稿者識別子がある場合は、それも保持します。欠損値をそのまま保存すると、後の分析で、不明な情報と実際に確認した0を区別できます。

2つ目のテーブルには、確認した投稿者を重複なく入れます。公開の識別子を使って、保存したコメントから作成してください。この投稿者テーブルでは、同じ識別済み投稿者による複数のコメントを1人として数えます。身元を識別できないものは未解決のまま保持してください。空欄の値がすべて同じ人を指すとも、それぞれ別の人を指すとも決めつけないでください。

3つ目のテーブルには、投稿者情報の取得結果を入れます。確認した投稿者と追加情報の対応関係を保持してください。追加情報がなくても、コメント投稿者として確認できている場合があります。詳細情報を取得できた人数を投稿者数として扱うと、証拠にすでに含まれている人を除外してしまいます。

4つ目のテーブルには、投稿ごとの公開情報の収集範囲を入れます。各入力の結果、停止理由、収集時の状況を保持してください。投稿の収集元と収集時刻も、出力とともに保持します。これらの記録は、サンプルの読み取り方を説明するものです。コメントの測定値ではありません。

この分離は、後で結果を解釈するときにも役立ちます。たとえば、確認済みコメント数を知らないうちに変えてしまうことなく、公開の投稿者情報を調べられます。次に投稿者の職務を調べる場合は、コメント投稿者の職務ガイドを使い、未解決の事例も保持してください。

サンプルの確認後に続行するかを決める

より大規模に実行する前に、最初の出力で、定めた問いに答えられるかを確認してください。保存した各コメントを元の投稿までたどれること、同じ投稿者による重複を区別できること、詳細情報の欠損を説明できることを確認します。各入力の収集範囲の記録を理解していることも確認してください。

次に、観測数を増やすことで調査が改善するかを判断します。トップレベルコメントのサンプルを増やせば、確認したトップレベルコメントの投稿者についての証拠を追加できます。ただし、その収集範囲と、返信の投稿者や「いいね」をした人についての問いとの不一致は解消できません。

受け入れ基準は具体的にしてください。たとえば、投稿者情報が未解決でも受け入れる一方で、各投稿について明確な収集元と収集範囲の記録を必須にする調査もあります。別の調査では、人数に含めるすべての観測について、投稿者の識別子を必須にするかもしれません。これらは調査上の選択です。結果を要約する前に明示してください。

収集の成功を、営業上の価値の証拠にしないでください。公開の投稿者リンクから分かるのは、公開プロフィールへのアクセス先です。見込み客が条件を満たすかを判断するには、別の基準と、それを裏付ける証拠が必要です。