
公開投稿のデータを収集する
LinkedIn Post Actor上のLinkedIn Post Text and Engagement Metrics Data Taskを開き、把握している公開投稿のURLを最大3件、`startUrls`に直接コピーしてください。既存のサンプルリスト全体を手作業で置き換えてください。このTaskには、コピーした投稿リンクを入力できます。キーワードによる投稿の発見、アカウント全体のアーカイブ、ブラウザー拡張機能、Google Docsとの連携には対応していません。
元のデータは変更せずに保存し、データセットの取得結果は分析表とは別に管理してください。取得できなかった投稿本文は、確認するまで保留にしてください。1回の実行が成功しても、すべてのメディアや動画の文字起こしを取得できることの証明にはなりません。Actorは投稿データを収集します。リンク先の研究の検証、画像内の根拠の確認、発言内容の検証、新しいコンテンツの執筆は行いません。
データセットの各行には、次の名前の出力フィールドが含まれます。`inputUrl`、`url`、`postUrn`、`activityId`、`ugcPostId`、`authorUrl`、`authorName`、`text`、`headline`、`publishedAt`、`observedAt`、`captionUrl`、`transcript`、`status`、`statusReason`です。欠損値は不明のまま扱います。`publishedAt`フィールドは、公開ソースのメタデータや`activityId`から導出される場合があります。投稿者が最初に公開した正確な時刻とは限りません。`publishedAt`は、正確な収集時刻を記録する`observedAt`と区別してください。
実践する8つの手順
- コンテンツで何を決めるかを明確にします。読者のどの課題を扱うかを選び、その課題に関係する、把握済みの公開投稿を参考資料として選定してください。アカウント全体を収集する必要はありません。
- 各投稿の正確なURLをTaskにコピーしてください。元のデータ行と取得結果を保存します。取得できなかった本文は、確認するまで比較に含めないでください。変更していない元のデータと、別の分析表を保存してください。
- 各投稿を読み、主な主張を自分の言葉で記述してください。主張に該当する原文の箇所を、自分用の非公開メモに保存します。対象読者、明示された条件、約束されている行動を特定してください。エンゲージメント数を、主張が正しいことの証拠として扱わないでください。
- 根拠を、手順を追って説明した具体例、リンクされた一次資料、個人の経験、実演、主張のみ、未確認の根拠に分類してください。個人の体験談は、ある可能性を示すことはできますが、それだけで普遍的な結果を証明することはできません。リンクは、出典の該当箇所を確認するまでは、確認済みの根拠にはなりません。
- 条件と反例を確認してください。その主張は、特定のツール、サンプル、組織、時期だけに当てはまるものですか。重要な条件は投稿内にありますか。それともリンク先の資料にしかありませんか。視覚的な根拠は、実際に確認するまで保留にしてください。
- 投稿キー、主な主張、根拠の種類、条件、不足している根拠、自分が答えられる独自の問いを並べ、投稿間の比較表を作ってください。言葉遣いやレイアウトだけでなく、論理の組み立て方を比較します。同じ主張が繰り返されていても、主張であることに変わりはありません。互いに独立した裏付けとして数えないでください。
- 自分で確認した例や資料で補える、実際に根拠が不足している点から、独自の切り口を選んでください。提示する主張、わかっている条件、手元にある根拠、検討すべき反例、読者が取る行動を含む、短い論旨の構成案を書きます。参考投稿の裏付けのない約束をコピーしたり、その投稿を焼き直した投稿を自動生成したりしないでください。
- 完成した比較表と、その構成案を選んだ理由を保存してください。コンテンツの執筆は、読者が別途行う作業です。参考用のサンプルは、LinkedInの全コンテンツを代表する調査でなくても、構成を学ぶために使えます。
主張と根拠を比較する具体例
ここに示す投稿の識別情報と本文は、すべて架空の例です。ある読者は、小規模なチームに、スプレッドシートへより安全にデータを取り込む方法を説明しようとしています。
主張と根拠の比較表
| 投稿キー | 主な主張 | 根拠の種類 | 条件 | 不足している根拠 | 自分が答えられる独自の問い |
|---|---|---|---|---|---|
| P1 | 同じに見える行を削除する | 一部を切り抜いた画像1枚 | 記載なし | 異なる注文をまとめてしまう可能性がある | 一般的なルールとして使わない |
| P2 | 注文IDと明細番号を組み合わせて、重複した取り込みを確認する | 4行のデータを使い、手順を追って説明した具体例 | 元データに、変わらない注文識別子と明細識別子がある | IDが欠損している場合は扱っていない | キーが欠損している場合に重複を確認する方法 |
| P3 | データを整理した後、私たちのチームは数時間を節約できた | 個人の経験 | 1つのチームの業務手順 | 比較の基準となるデータも時間の記録もない | 検証済みの効果ではなく、報告された主張として扱う |
独自の根拠として使う架空のデータ行
根拠として使う、次の4行の架空データを考えます。
- 1行目:O10、明細番号1、商品A
- 2行目:O10、明細番号1、商品Aの重複取り込み
- 3行目:O11、明細番号1、商品A
- 4行目:missing-order、明細番号1、商品A
4行のうち、1行目と2行目の1組は、キーが重複していることを確認できています。3行目は、商品が同じでも別のデータです。最後の行は、キーについて未解決の点が残っています。元データのキーと値を確認してから、重複取り込みと確認できた1行だけを削除してください。O10の元の行、O11の行、未解決の行を、残すべき3件の観測データとして保持します。未解決の行を、重複のない注文とも重複データとも呼ばないでください。ここでの要点は、確認した論旨が成り立つ条件です。重複排除の方法をもう一度詳しく説明することではありません。
5つの要素で組み立てる独自の論旨
- 提示する主張:確認済みのキーを使って重複を自動処理し、キーが欠損した行は手動確認用に残す。
- わかっている条件:キーは、対象の注文明細を識別できなければならない。
- 利用できる根拠:読者自身が作った、架空の具体例のデータ行。
- 検討すべき反例:同じに見える2つの商品が、別々の2件の注文に属している場合がある。
- 読者が取る行動:未解決のデータを別の台帳に記録して保持する。
根拠の種類によって、書き方の選択は変わります。P2には、有用な条件が明示されています。P1は、修正が必要な広すぎるルールを提示しています。P3では、数値で示す成果を約束することはできません。
出典と参考資料
著者 Chronometrica · 更新日
ページの先頭へ ↑
