LinkedInのプロフィール・投稿・コメントを誤った対応付けなしで結合する方法

最初に行の粒度を決める

行の粒度とは、1行が何を表すかという意味です。行を収集する前に粒度を決めてください。

根拠データの粒度は、選択したコメントの観測記録1件です。コメントの観測記録1件とは、1回のスナップショットから保存したトップレベルコメント1件を指します。集計の粒度は、選択した投稿1件です。コメント件数と投稿件数は異なる指標です。両者を合算する前に、それぞれの意味をファイルに記載してください。

既知のソースURLを記載してください。レポートの対象期間も記載してください。レポートの締め切り時点は、対象に含める最後の観測時点です。締め切り後の行は元のデータセットに残します。その行は、このレポートには含めません。

この方法は、既知の公開投稿URL、その投稿の公開トップレベルコメント、確認済みの個人プロフィールにのみ使ってください。アカウント検索、1つのアカウントの全投稿、リアクション一覧、返信、メッセージ送信、職種ラベル、テキストスコアには使わないでください。

用語

URNは、型を含む文字列の識別子です。`urn:li:activity:1001`のURNの型は`activity`です。型もキーの一部です。`ugcPost`は別の投稿の型です。これらのActorでは、`member`は個人アカウントの型です。`organization`は個人アカウントの型ではありません。

LinkedInのURNガイドは、公式LinkedIn APIのURNの型を説明しています。このAPIは`person` URNを使います。Actorのプロフィールキーは`member`を使います。この2つのスキーマは同じではありません。一方のLinkedIn APIからもう一方へ識別子をコピーし、同一だと扱わないでください。

JSONは、テキスト形式のデータ形式です。長い識別子の桁が失われないように、JSONまたはテキスト列を使います。

ブール値のフィールドは、trueまたはfalseを取ります。デフォルトは、フィールドを変更しなかった場合に使われる値です。入力スキーマは、Actorが受け付けるフィールドを公開した一覧です。親キーは、コメント行に保存された投稿キーです。フォールバックとは、先のキーが欠けている場合に限り、次のキーを試すことです。正規URLとは、確認済みの1つのソースURLを指します。同じURLの別形式を指すものではありません。

互換性のあるキーは、URNの型と値が同じです。矛盾とは、1つのキーが2つの対象を指す場合、または2つのキーが別々の対象を指す場合です。同じ型同士のキーが1つの投稿を指していれば、URNの型が異なるだけでは矛盾になりません。

3つのActorが返すデータ

3つの公開Actorがソース行を提供します。結合処理は利用者が作成します。

LinkedIn Post Scraperのビルドは1.0.60です。LinkedIn Comments Scraperのビルドは1.0.47です。LinkedIn Profile Scraperのビルドは1.0.28です。実行前に各Actorのページを読んでください。後のビルドではフィールドが変わる可能性があります。

各Actorは公開ページを読み取ります。どのActorも、利用者のLinkedInログインを使いません。どのActorも、アカウントの全投稿を返しません。

コメントの入力には、`maxComments`、`includeAuthorDetails`、`collectAllAvailable`もあります。`maxComments`は1〜1000の整数です。デフォルトは100です。`maxComments`は、投稿または入力ごとに保存するコメント数の上限です。複数の入力を含む実行全体の上限ではありません。`includeAuthorDetails`はブール値です。デフォルトはfalseです。`collectAllAvailable`はブール値です。デフォルトはfalseです。`collectAllAvailable`が解除するのは、保存件数の数値上限だけです。公開範囲の制限は解除しません。返信は収集しません。

コメント件数と入力の状態は`OUTPUT`にあります。`OUTPUT`は実行の概要です。コメント行ではありません。その中の`inputResults`には、`status`、`statusReason`、`pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete`、`stopReason`が含まれます。

`pageCommentCount`は、ページで報告されている件数です。`publicRowsOnPage`は、そのページで確認できた公開行の数です。`savedRows`は、保存された数です。この3つの数は異なる場合があります。`isPublicPageComplete`は、Actorが公開ページを完全と判定したかどうかを示します。`isComplete`は、保存したコレクションが完全かどうかを示します。`stopReason`は、保存を停止した理由を示します。一部だけの結果になる原因には、保存上限、公開プレビュー、課金上限があります。不明な件数はnullのままにしてください。代わりに0を書き込まないでください。

コメント用Actorは、型を含むフィード更新URLを受け付けます。投稿用Actorには`/posts/` URLが必要です。フィードURLしか分からない場合は、コメントの親キーを残してください。一致を確認した`/posts/` URLを入手してから、投稿のスナップショットを収集してください。`/posts/`のスラッグを作り上げないでください。

次のTaskを使い、サンプル入力を変更してください。サンプルを変更しないままでは結合できません。投稿用Taskのサンプルは、コメント用Taskのサンプルとは別の投稿です。

2つのコメント用Taskを、別々のコメント集合として追加しないでください。その投稿に使うコメント用Taskは1つ選びます。詳細を取得するTaskでも、投稿者IDのないコメントが返る場合があります。有用な詳細情報のリクエストによって、別の課金イベントが発生する可能性があります。リクエストしても、IDが必ず得られるわけではありません。課金が必ず発生するわけでもありません。

デフォルトでは投稿者詳細はオフです。このデフォルト出力では、安定したコメント投稿者キーがnullであることがよくあります。公開識別子と公開URLは、後で変わる場合があります。プロフィールのスナップショットが示すのは、その観測時点のプロフィールです。それ以前のコメント時点での職業を証明するものではありません。この方法では職種を割り当てません。

実行のドキュメントでは、実行上限とタイムアウトを説明しています。大規模な実行の前に読んでください。シートにアクセストークンを入れないでください。

コメントを投稿に対応付ける方法

記載された順序で対応付けます。同じ型同士を照合する規則を守ってください。対応付けに使うキーは、1つの投稿を指す必要があります。最初に、利用可能な互換性のあるキーをすべて確認し、矛盾がないか調べます。優先順位の低いキーでも、矛盾するものを無視してはいけません。この確認を終えてから、記載された順序で、根拠のある最初の対応付け基準を選びます。その基準を記録してください。基準の列は利用者が作成するものです。Actorはこの列を返しません。

1. 型を含む`postUrn`の一致。
2. activity型の範囲内に限り、`activityId`の一致。
3. ugcPost型の範囲内に限り、`ugcPostId`の一致。
4. 確認済みの正規ソースURL。

コメントのフィールドは`postUrn`、`activityId`、`ugcPostId`、`postUrl`です。投稿のフィールドは`postUrn`、`activityId`、`ugcPostId`、`url`です。どのフィールドもnullになる場合があります。

型を含まないIDより先に、型付きURNを使ってください。1つの投稿にactivityの値とugcPostの値が両方存在し、それぞれ異なっていても問題ありません。これは正常です。activityの値とugcPostの値を比較しないでください。型をまたいで数字が一致しても、根拠にはなりません。

架空の例の投稿Aには、activityの`1001`とugcPostの`2001`があります。これらは1つの投稿に対する2つのキーであり、矛盾ではありません。矛盾が生じるのは、1つのキーが2つの投稿を指す場合、または利用可能なキーが別々の2つの投稿を指す場合です。フォールバックの順序があっても、根拠の弱いキーでこの矛盾を覆すことはできません。コメントは未解決のままにしてください。

URLは、型付きキーが欠けている場合にだけ使ってください。両方のURLが、確認済みの同じ正規ソースURLである必要があります。確認できなければ、その行は未解決のままにします。URLによる対応付けの根拠は、型付きキーより弱いものです。対応付けの基準と、両方の観測時点を記載してください。

この結合を行う前に、重複する投稿スナップショットから参照用の行を1行だけ選んでください。参照データに同じ投稿の取得成功行が2行残っていると、結合時にコメントが複製されます。参照データを修正してください。参照データを変えずに、複製されたコメント行だけを削除してはいけません。

投稿スナップショットがない場合は、対応するデータがないということです。空の投稿という意味ではありません。投稿の取得に成功し、保存されたコメントがない場合は、別の結果です。投稿の取得試行が失敗した場合も、別の結果です。実行しなかった入力も、別の結果です。

個人プロフィールを対応付ける方法

コメント投稿者が個人アカウントを意味すると確認してから、その投稿者にプロフィールを対応付けてください。コメントのフィールドは`authorType`です。値は`person`、`organization`、nullのいずれかです。投稿用Actorは、投稿者の型を`Person`と記録する場合があります。各ソースの値は、取得したとおりに保存してください。この意味の確認では、`person`と`Person`はどちらも個人アカウントを意味します。大文字と小文字の一致を条件にしないでください。文字を一致させるために、保存されたテキストを編集しないでください。

組織の投稿者は、個人プロフィールとの結合対象から除外したままにします。組織のURLを`/in/`プロフィール行に変えることはできません。`urn:li:member:11`と`urn:li:organization:11`は異なるキーです。無理に一致させるためにURNの型を取り除かないでください。

個人であることを確認した後、次の順序で対応付けます。

1. member IDの一致：プロフィールの`profileId`とコメントの`authorId`。
2. member URNの一致：プロフィールの`profileUrn`とコメントの`authorUrn`。
3. 根拠の弱い代替手段：`publicIdentifier`と`authorPublicIdentifier`、またはプロフィールの`url`とコメントの`authorUrl`にある正規の`/in/` URL。

null同士を対応付けないでください。空白セル同士も対応付けないでください。member IDがプロフィールXを指し、URLがプロフィールYを指す場合、その行には矛盾があります。根拠の弱いURLを使って、どちらかを採用してはいけません。

URLや公開識別子は、スナップショットの間に変わることがあります。この弱い根拠を使う場合は、両方の`observedAt`の値と対応付けの基準を記載してください。URLがnullなら未解決のままにします。名前、写真、ヘッドラインはキーではありません。欠けているリンクを埋めるために、名前で検索しないでください。

同じプロフィールフィールドを、投稿者のフィールドである`authorId`、`authorUrn`、`authorPublicIdentifier`、`authorUrl`、`authorType`と比較することもできます。この比較で確認するのは、投稿の投稿者としての関係だけです。実施は任意です。コメント投稿者を確認するものではありません。コメント投稿者を投稿の投稿者で置き換えないでください。あるアカウントの全投稿を、そのアカウントの全コメントに結合しないでください。

one post snapshot
    -> many comment observations

one person profile
    -> many comments by that person

optional post-author match
    -> the post row only
    -> not the comment author

1人が多くのコメントを書くことがあります。1つの投稿に多くのコメントが付くこともあります。この2つの矢印は別の関係です。

コメントの識別には、`commentId`、`commentUrl`、親キー、`observedAt`を使います。IDやリンクはnullの場合があります。その観測記録も残してください。安定したIDを作り上げないでください。同じテキストだからといって、同じコメントと扱わないでください。シートの行番号をIDとして扱わないでください。複数回の実行をまたいで観測記録を1件に絞るのは、親キーと`commentId`の両方が安定しており、一致する場合だけです。安定した`commentId`がない行は、別々の観測記録として残します。

プロフィールと投稿の状態には、`status`、`statusReason`、`observedAt`を使います。プロフィールの取得に失敗した行もソースファイルに残してください。その行を、プロフィールの対応付けに成功したものとして扱わないでください。

結合前にスナップショットを1件選ぶ

参照行とは、結合で使うことを認めた1件のスナップショットです。確認済みの投稿ごとに、取得成功の投稿行を最大1行選びます。確認済みの個人ごとに、取得成功のプロフィール行を最大1行選びます。結合の前にこれを行ってください。

元のデータセットを残してください。2つのスナップショットを混ぜて新しい行を作らないでください。選択ルールをファイルに記載してください。明確なルールの1つは、レポートの締め切り前で、取得に成功した最新のスナップショットを選ぶことです。

1人に取得成功のプロフィールスナップショットが2件あれば、1件を選びます。両方を参照データに残すと、その人の各コメントがスナップショットごとに複製されます。結合後に増えた行は、参照データの誤りです。参照データを修正してください。複製だけを削除して、正しいシートになったと判断しないでください。

次に、選択したコメントの観測記録を起点に左結合を作成します。最初に、各コメントを1件のソース投稿に結合します。その後、その個人のコメント投稿者を最大1件のプロフィールに結合します。投稿との対応がないコメントも残します。プロフィールとの対応がないコメントも残します。

結合後の根拠データ表の行数は、選択したコメントの観測記録の件数と同じでなければなりません。行数が多ければ、参照キーがまだ複数の行を指しています。

利用者が作成する次のフィールドを、根拠データ行に入れます。対応付けの基準、対応付けの結果、スナップショットの選択ルール、比較したソースの時点です。利用者が作成したフィールドであると明記してください。Actorのフィールドとして提示しないでください。

長いIDはテキストとして保持してください。スプレッドシートは長い数値を変えて、桁を失わせることがあります。JSONでエクスポートするか、インポート前にすべてのID列をテキストに設定してください。JSONの意味は前に説明しました。データセットのドキュメントには、エクスポートの操作手順が記載されています。データセットを選び、エクスポートを選び、形式を選び、ダウンロードを選びます。`OUTPUT`は別に保存してください。データセットのエクスポートには`OUTPUT`は含まれません。

手順

1. 粒度、既知のURL、レポートの締め切り時点、各件数の意味を記載します。根拠データファイルは、選択したコメントの観測記録1件につき1行にします。集計ファイルは、選択した投稿1件につき1行にします。この記載が終わるまでは、コメント総数と投稿に表示された件数を別々に扱います。
2. 安全なデータ結合のためのLinkedIn投稿ID・コメントIDを開きます。サンプルURLを、既知の公開投稿URL1件に置き換えます。`maxComments`を3にします。`collectAllAvailable`はfalseのままにします。投稿者詳細はオフのままにします。実行を開始します。結果が少ない、または空である理由を説明する前に、`OUTPUT`を開いてください。行が少ない理由には、保存上限、入力の失敗、公開範囲の制限、公開コメント自体が少ないことがあります。行数だけでは、どれが理由かは分かりません。
3. デフォルトのコメント行に含まれない投稿者キーが必要なら、最初のコメント用Taskの代わりに、公開プロフィール詳細付きのLinkedInコメント投稿者を使います。サンプル投稿を置き換えます。コメントは3件にします。無制限の設定はオフのままにします。`includeAuthorDetails`をtrueにします。両方の出力を貼り合わせないでください。それでも詳細が欠ける場合があります。追加の詳細リクエストは別に課金される可能性があり、IDが返らない場合もあります。
4. データ結合のためのLinkedIn投稿ID・投稿者キーを開きます。サンプルを同じ`/posts/` URLに置き換えます。投稿IDを渡さないでください。フィード更新URLを渡さないでください。フィード更新URLしかない場合は、コメントの親キーを残し、確認済みの`/posts/` URLを入手するまで投稿の収集を停止してください。スラッグを作り上げないでください。`ok`、`failed`、`invalid_url`の行は分けて扱います。`observedAt`を残します。投稿スナップショットがない場合は、対応するデータがない状態のままにします。
5. コメント投稿者のキーを読みます。コメント行に、このレポートで必要な投稿者情報がすべてそろっていれば、プロフィール用Actorは使いません。そろっていなければ、データ結合のためのLinkedInプロフィールID・URNで、重複のない公開`/in/` URLを収集します。重複するURLを除きます。組織のURLを除外します。名前、写真、ヘッドラインで検索しないでください。プロフィールの取得試行が失敗した場合も、ソースファイルに残します。失敗した試行を、対応付けできた個人として扱わないでください。
6. 参照データを選びます。確認済みの投稿ごとに、取得成功の投稿スナップショットを1件残します。確認済みの個人ごとに、取得成功のプロフィールスナップショットを1件残します。コメント収集を繰り返した場合は、安定した親キーと`commentId`の組み合わせごとに観測記録を1件残します。`commentId`がない行は、テキストが同じでも別々の観測記録として残します。元のデータセットはすべて残します。締め切りのルールを記載します。結合前に、参照データ内のキーの重複と矛盾を解消してください。
7. 選択した各コメントを1件の投稿に左結合します。型を含む`postUrn`の一致、activity IDの一致、ugcPost IDの一致、確認済みの正規URLの順に使います。URNの型をまたいで照合しないでください。その後、個人のコメント投稿者を最大1件のプロフィールに結合します。member ID、member URN、観測時点を記録した公開識別子または正規の`/in/` URLの順に使います。利用者が作成する基準、結果、両方のソースの時点を記載します。投稿の投稿者でコメント投稿者を補わないでください。あるアカウントの全投稿を、そのアカウントの全コメントに結合しないでください。
8. 根拠データの行数を数えます。選択したコメントの観測記録の件数と一致する必要があります。多ければ、参照データではまだ1つのキーに複数の行が対応しています。その参照データを修正し、結合をやり直してください。重複した根拠データ行の削除だけで修正を済ませないでください。親投稿との対応がないもの、個人キーが欠けているもの、プロフィール取得の失敗、組織の投稿者、矛盾を別々に数えます。
9. 解決済みの投稿キーごとに、コメントの観測記録をグループ化します。`commentsCount`は、選択した投稿行1行だけに入れます。その実行の`OUTPUT`が示す収集範囲を、投稿の横に記載します。保存されたコメントがない投稿も残します。取得に成功した空の結果、失敗した試行、実行しなかった入力は、別々の事実として残します。投稿者キーは、観測したアカウントとして数えます。重複を除いた人数とは呼ばないでください。コメント投稿者や閲覧者の全体とも呼ばないでください。
10. 根拠データ表、未解決データ表、投稿別集計表、ソース概要をエクスポートします。前述のデータセットのエクスポート手順を使います。`OUTPUT`も一緒に別途保存します。IDはテキストとして保持します。結果のすべての行に、ソースキー、利用者が作成した基準、不足している根拠を示します。欠けている情報を埋めるのは、その情報に正確に対応する根拠のあるソースURLがある場合だけです。それ以外は不明のままにします。

根拠データの集計は手順8です。投稿の集計は手順9です。投稿の集計値をコメント件数として使わないでください。

公開データに対する1回の検証で確認できたこと

公開データに対する1回の検証では、既知の1件の投稿からコメントを3件保存しました。ソースにはコメント4件と表示され、4行が公開されていました。上限により保存したのは3件でした。保存した3件の親キーは、それぞれ同じソース投稿と一致しました。コメント投稿者1件は、別途取得した個人プロフィール行1件と一致しました。これらの確認対象の対応付けはすべて成功しました。

その実行のコメントの`OUTPUT`では、`isPublicPageComplete`がtrue、`isComplete`がfalse、`stopReason`が`max_comments_reached`でした。これらを合わせて読むと、Actorは公開ページを完全と判定していましたが、保存上限に達したため、保存はまだ不完全だったことが分かります。

この検証で確認できたのは、その行とその概要だけです。その後のすべての投稿について証明したわけではありません。ugcPostによる対応付け、組織の投稿者、nullのキー、矛盾について、新たに実データで行った検証ではありません。これらのケースには、前述のフィールドの規則と、以下の架空の集計例を使います。

架空の投稿・コメント・集計例

この節の値はすべて架空のものです。C1〜C6は学習用のラベルです。短いIDも学習用のIDです。LinkedInから収集した値ではありません。以下のURNを、実在するプロフィール、投稿、コメントとして扱わないでください。

レポートの締め切り時点は`time-2`より後です。member12について選択したスナップショットは、後の取得成功のものです。AとBでは、投稿の投稿者の型が`Person`として保存されています。C1〜C4では、コメント投稿者の型が`person`として保存されています。これらの意味は一致します。保存された文字の違いはそのまま残します。投稿Cの投稿者は組織として保存されています。

member11には、選択済みの取得成功プロフィール行が1件あります。member12には、取得成功のスナップショットが2件あります。結合前に1件を選んでください。member13には、失敗したプロフィール取得試行があります。AとBはmember11が書きました。Cを書いたのはmember11ではなく、organization11です。

C2は、型付きactivity URNでは一致しません。親URNがugcPost URNだからです。activity IDの`1001`は投稿Aと一致します。ugcPost IDの`2001`も投稿Aと一致します。同じ型同士で照合した両方のキーが同じ投稿を示しているため、これは確認の裏付けであり、矛盾ではありません。記載する対応付けの基準はactivity IDです。

C5は、両側でugcPostの`1001`を使っているため、投稿Cと一致します。投稿Aにも`1001`という数字がありますが、それはactivity IDです。数字が同じでも、C5をAに対応付けることはできません。

根拠データ表は6行を保持します。対応付け済みデータ表と未解決データ表は、元の表から必要な部分を示すビューです。一方が対応付けでき、もう一方ができない場合、同じコメントが両方に現れることがあります。これらのビューを合算して、コメント総数としないでください。

対応付け済みデータのビューは8行です。C1、C2、C3は、それぞれ両側の対応付けに成功しています。C4とC5は投稿側だけです。8はコメント総数ではありません。コメント総数は6です。

C6には未解決の部分が2つありますが、根拠データ行は1行です。コメントとしては1件だけ数えます。

各合計を確認します。

• 選択したコメントの観測記録：6件。
• 左結合後の根拠データ行：6行。
• 親投稿に対応付けできたもの：5件。C1、C2、C3、C4、C5です。
• 親投稿に対応付けできなかったもの：1件。C6です。
• 取得成功の個人プロフィールに対応付けできたコメント行：3行。C1、C2、C3です。
• 使用した取得成功の個人プロフィール：2件。member11とmember12です。
• 個人の対応付け結果が未解決のもの：2件。C4のプロフィール取得の失敗と、C6の投稿者キーの欠損です。
• 個人プロフィールの対象範囲外となる組織の投稿者：1件。C5です。
• 識別できたmemberキー：3件。member11、member12、member13です。
• この3件のmemberキーは、2件のプロフィールと同じものではありません。また、3人の存在が証明されたわけでもありません。
• 親投稿別の収集行数：Aは2行、Bは2行、Cは1行、対応する親投稿がないものは1行です。
• 2＋2＋1＋1＝6です。

`commentsCount`は投稿行に残します。収集したすべてのコメント行にコピーしてから合算すると、Aの10を2回、Bの20を2回計上することになります。つまり20＋40＝60です。既知の表示件数を正しく合計するには、選択した投稿を1回ずつ使います。10＋20＝30です。投稿Cはnullです。nullを0に変えないでください。30を完全な合計と呼ばないでください。収集した観測記録の指標は別です。親投稿に対応付けできた5件と、対応する親投稿がない1件で、合計6件です。

この架空のシートには`OUTPUT`がありません。実際の収集範囲を判断するには、その実行の`pageCommentCount`、`publicRowsOnPage`、`savedRows`、`isPublicPageComplete`、`isComplete`、`stopReason`、`status`、`statusReason`がなお必要です。表示件数が10で収集行数が2というだけでは、収集率を示したことにはなりません。

member12の両方のスナップショットを参照データに残すと、C2とC3がそれぞれ複製されます。根拠データ表は6行から8行に増えます。最初に`time-2`のスナップショットを選んでください。根拠データ表は6行に戻ります。両方のスナップショットを参照データに残したまま、増えた根拠データ行2行を削除しても、次の結合の問題は修正できません。

member11は、選択した投稿のうちAとBの2件と、選択したコメントのうちC1の1件を書きました。この2件の投稿を、member11が書いたコメントに直接結合すると、C1が2回現れます。両方について述べる前に、それぞれの関係を別々に集計してください。投稿の投稿者としての関係では投稿が2件です。コメント投稿者としての関係ではコメントが1件です。親投稿による対応付けでは、C1は投稿Aだけに残ります。C1がmember11と一致するのは、コメント投稿者キーがmember11だからです。member11が投稿Aを書いたからではありません。

member12は、認められる対応の方向を示しています。選択した1件のプロフィールが、2件のコメントと一致します。C2はAに残ります。C3はBに残ります。同じプロフィールを共有していても、どちらのコメントも他方の投稿へ移ることはありません。

取得成功の投稿スナップショットだけでは、コメントの収集結果が空だったことを証明できません。コメント入力の処理が成功したことを確認し、保存行数が0だった場合に限り、空の結果を観測したといえます。その結果にも、上限による制約は残ります。ソース側の制限による制約も残ります。失敗した入力は不明のままです。試行しなかった入力も不明のままです。空の結果を観測したことと、表示された`commentsCount`がnullであることは別です。6行の例の合計は変わりません。C6は、対応する親投稿がないキーです。投稿の取得試行が失敗したものではありません。

この6行の外に、架空のケースに関する規則がさらに3つあります。上の合計には加えないでください。

memberキーがnullの個人でも、現在の`/in/` URLが完全に同じであれば、確認済みのプロフィール1件に対応付けできます。根拠の弱いURLを基準にしたことと、両方の観測時点を記載してください。URLがnullなら未解決のままにします。member IDがXを指し、URLがYを指す場合は、矛盾として残し、URLを使わないでください。`commentId`がnullのコメントは、独立した観測記録のままにします。テキストが同じでも、欠けているIDを補うことはできません。シートの行番号でも補えません。

完成したファイルは、何が一致したか、なぜ一致したか、何がまだ不明かを示します。人に順位を付けるものではありません。投稿の成功を評価するものでもありません。