ChronometricaとClockworksを比較：検証できるTikTokコメントデータセットの選び方

調査する投稿リストを決める

ある調査者は、「TikTokの全コメントのデータを取得するには？」と質問しました。その投稿によると、使用したツールは最上位コメントを収集できても、さらに返信を開くことができませんでした。つまり、返信の収集も実際の要件に含まれます。「全て」という言葉は望む結果を示しますが、収集ツールが返せる範囲を示すものではありません。公開された調査上の質問。

最上位コメントは、投稿に直接付くコメントです。返信は、コメントのスレッド内に付くコメントです。議論を調べる場合、最上位コメントだけを集めると、調査したいやり取りが抜けることがあります。

ただし、返信への対応だけでは、この比較の結論は出ません。まず、対象の投稿がすでに分かっているかを確認します。固定のリストがあれば、入力の範囲が明確になります。収集した各行を、指定した投稿と照合できます。

プロフィールから始める場合は、動画の選択も収集作業に含まれます。Clockworksは、プロフィールのユーザー名から動画を取得する機能を文書に記載しています。この入力の流れによって、コメントの検証を始める前に選択が変わることがあります。Clockworksの仕様。

出力項目を比較する前に、この開始点を書き留めます。「この投稿リストのコメント」と「このプロフィール群から見つけた動画のコメント」は、異なる収集依頼です。

文書に記載された機能と用途の適合性を比較する

Chronometricaは、指定した投稿との厳密なID照合と、実行全体でのコメントIDの重複除去を文書に記載しています。重複除去とは、同じコメントIDを繰り返し取得しても、別々のコメントとして採用しないことです。また、返信を独立した行として出力し、投稿ごとのサマリーで、上限に達した状態と取得元からこれ以上データを取得できない状態を区別すると記載しています。これらの機能は、固定の投稿リストを慎重に検証する用途に適しています。Chronometricaの仕様。

この表は、確認した仕様をまとめたものです。速度や実測の精度を順位付けするものではありません。Chronometricaの仕様、Clockworksの仕様、Clockworksの入力スキーマ。

Chronometricaは、公開された動画投稿と写真・カルーセル投稿のコメントにも対応すると記載しています。返信の項目には、`parentCommentId`、`replyToCommentId`、`isReply`、`replyDepth`、`replyCount`があります。これらの項目は、スレッドの構造を保つのに役立ちます。ただし、スレッドの全ての部分が取得可能な状態だった証明にはなりません。Chronometricaの仕様。

この比較は、文書に記載された機能と用途の適合性を扱います。表にない機能が、その製品に存在しないと示すものではありません。この記事のために提供された資料には、精度や信頼性の優位性を示す、条件を統一した実行結果はありません。価格も比較していません。保存されたClockworksのStoreページ上部とREADMEで、価格の記載が一致していないためです。ClockworksのStoreページとREADME。

コメントと返信の上限を別々に設定する

上限とは、定めた範囲内で収集処理に返すよう求める最大件数です。その行数が返るという保証ではありません。

Chronometricaでは、`maxCommentsPerVideo`で最上位コメントの上限を1〜1,000件に設定します。`includeReplies`の切り替えで返信を収集するかを指定します。返信を含める場合、`maxRepliesPerComment`でコメントごとの返信上限を別に設定します。範囲は1〜100件です。Chronometricaの入力スキーマ。

データセットの規模を計画するときは、この区別が重要です。最上位コメントを3件指定しても、返信も指定すれば、3行を超えることがあります。また、設定した上限より少ない行数になることもあります。

次の設定例は、文書に記載された項目と有効な範囲の値を使っています。公開URLは入力形式を示すためだけのものです。使用前に、調査に合う公開投稿のURLに置き換えてください。

{
  "startUrls": [
    "https://www.tiktok.com/@zachking/video/7631200623693729038"
  ],
  "maxCommentsPerVideo": 3,
  "includeReplies": true,
  "maxRepliesPerComment": 2
}

この設定では、3件の最上位コメントから、それぞれ2件の返信を収集できる可能性があります。この単純なケースでは、最上位コメント3行と返信6行で、合計9行になり得ます。これは規模を計画するための計算であり、予想される結果ではありません。取得できるコメントや返信によっては、どちらの件数も上限を下回ります。

Taskは、保存された入力設定です。確認済みのTikTokコメントと返信のエクスポートTaskを、公開された初期設定として使えます。使用前に、その入力設定が調査に合うかを確認してください。

小規模な収集結果を全て確認できるように上限を決めます。出力とその制限を理解してから、上限を増やします。

各行を検証するために必要な情報を残す

検証できるデータセットを作るには、コメント本文だけでは不十分です。各行を出典に結び付け、必要な場合は親コメントにも結び付ける必要があります。

元の指定投稿リストを、エクスポートしたデータと一緒に保存します。入力した投稿の識別情報、返された投稿の識別情報、コメントID、取得できた返信の関連付けを残します。指定リストには、何を依頼したかが記録されます。各行の識別情報があれば、何を採用したかを検証できます。

データに変わらない投稿IDが含まれる場合は、それを使って指定リストに属するかを確認します。確認する問いは単純です。この行は、指定した投稿のいずれかに属するでしょうか。似たキャプションやクリエイター名では、この問いに答えられません。

コメントIDは、重複を確認するときにコメントを識別するためのものです。個々のエクスポートファイル内だけでなく、実行全体でIDを比較します。収集結果を複数のファイルに分けても、繰り返し取得した同じコメントを追加のコメントとして採用してはいけません。

文書に記載された返信の項目を、エクスポートにも残します。`isReply`で行の種類を区別し、取得できた親コメントへの関連付けで関係を保ちます。`replyDepth`と`replyCount`は、取得元の状況を示す情報として残します。返信件数を、その件数分の返信行を収集した証拠として扱ってはいけません。Chronometricaの出力仕様。

必要な識別情報や関係を示す値が欠けている場合は、欠損のまま残します。0で置き換えたり、近くの文章から親コメントを推測したりしてはいけません。欠損のために必要な確認ができない場合は、その行を要確認にします。

収集した行と実行サマリーの整合性を確認する

整合性の確認とは、件数と記録が一致するかを調べることです。データセットの最終的な集計値を計算する前に、実際の実行サマリーを読みます。

Chronometricaは、上限に達した状態と、取得元からこれ以上データを取得できない状態を区別するサマリーを文書に記載しています。返されたサマリー内のラベルと定義を使います。自分のレポートに合わせて、Actorが標準で返すかのようなサマリー項目を作ってはいけません。また、取得元からこれ以上データを取得できないことを示すラベルがあっても、投稿のコメント履歴を完全に保存できた証明にはなりません。Chronometricaの仕様。

次の簡単な手順で確認します。

1. 指定した投稿IDと収集設定を保存します。
2. 各投稿について、仕様に基づくサマリーと停止条件を読みます。
3. 各行を指定投稿リストと照合します。
4. 実行全体のコメントIDを調べ、同じコメントの繰り返し取得を確認します。
5. 採用した最上位コメント行と返信行を別々に数えます。
6. 採用した件数の合計を、エクスポートとサマリーに照らして確認します。
7. 解消できない差異を記録します。

これらの判断について、利用者側で検証記録を残します。これは自分で作る記録であり、Actorの出力項目ではありません。インポートした観測レコードの件数、除外した観測レコード、採用した重複のない行、未解決の確認事項を記録できます。

観測レコードとは、インポートしたファイルに含まれる、1回の取得で得た記録です。重複のないコメントとは、必要な検証を経て、別個のものと確認されたコメントです。この2つに同じ合計値を使ってはいけません。件数が異なる場合は、両方を残し、その理由を説明します。

結果は投稿単位でも残します。一括処理の合計だけでは、未確認の投稿が見えなくなることがあります。投稿ごとの合計を分ければ、どの投稿で上限が適用されたか、どの投稿に必要な確認が残っているかが分かります。

8件の観測レコードを含む架空のファイルで確認する

以下の演習は架空のものです。利用者側で行う検証の例です。現在のどちらのActorの出力でもなく、ベンチマークや顧客の結果でもありません。

インポートしたファイルに8件の観測レコードがあるとします。2件は、すでに取得したコメントIDの重複です。別の1件は、指定リスト外の投稿に属します。この3件を除外すると、採用する重複のない行は5行になります。

`8 − 2 − 1 = 5 accepted unique rows`

この5行のうち、3行は最上位コメントで、2行は返信です。採用した行に占める返信の割合は、次のとおりです。

`2 ÷ 5 × 100 = 40% of accepted rows`

分母が重要です。40%は、上記の検証後に採用したファイル内での割合です。元の投稿にある全コメントの割合でも、返信した人の割合でもありません。取得可能な全返信のうち、収集できた割合を示すものでもありません。

観測レコードの合計8件は、インポートした量を示します。合計5行は、検証を通過した重複のない行数を示します。3行と2行という内訳は、採用した行の種類を示します。それぞれの数値には異なる役割があります。

必要に応じて、除外した観測レコードと理由を検証記録に残します。そうすれば、別の確認者が、除外した行を採用データセットに含めずに計算を追えます。

この例は、識別情報の照合と重複確認が重要な理由を示しています。現在のどちらかのActorで、この架空の問題が生じたと示すものではありません。固定の投稿リストを扱うこの用途では、Chronometricaが文書に記載している検証機能が、その仕様を確認する理由になります。Chronometricaの仕様。

欠損を補わずに返信の文脈を保つ

取得できた関連付けを使い、採用した返信を親コメントごとにまとめます。こうすると、元の関係を確認できる状態で、スレッドの検討に使えるデータセットになります。

参照先の親コメントが、採用した行の中にあるかを確認します。あれば、その関連付けを残します。なければ、参照情報を残し、文脈は未解決と記録します。親コメントがないという事実だけでは、その理由は分かりません。

表計算シートで最も近い行に返信を結び付けてはいけません。行の順序は、親コメントへの関連付けの代わりにはなりません。返信から、欠けている親コメントの本文を推測してもいけません。

採用した返信でも、文脈が不完全なことはあります。その後の分析でも、この違いを明確にします。例えば、返信を1行として数えることはできても、やり取り全体を解釈するための文脈が足りない場合があります。

後で質的分析のコーディング用にデータを整える場合は、これらの検証結果をエクスポートと一緒に残します。次の段階は、TikTokコメントをNVivoで使うためのガイドで説明しています。ここでの判断対象は、投稿の選択、返信の構造、一括処理の集計値です。

収集を拡大する前にデータセットの範囲を報告する

有用なレポートは、採用したファイルの内容と、収集依頼で設定した範囲を示します。指定した投稿、収集設定、採用した重複のない行数、最上位コメント数、返信数、未解決の文脈を記載します。

実際に観測した合計と、設定した上限を分けます。上限は依頼の内容を示します。採用件数は、検証後のファイルの内容を示します。一方の値でもう一方を置き換えてはいけません。

架空の演習なら、次のように書くと明確です。「検証済みのファイルには、指定した投稿から採用した重複のない5行が含まれます。内訳は、最上位コメント3件と返信2件です。」関連する設定と、記録した停止条件も加えます。これを、投稿にコメントが5件しかないという主張に変えてはいけません。

必要な確認が完了していない場合も、そのことを記載します。不明な値は不明のまま残します。0は、測定した件数が0であることを意味します。件数の欠損を表す値として使ってはいけません。

小規模な収集で、使える識別情報、明確な行の種類、調査の問いに必要なスレッドの文脈が得られてから、作業を拡大します。必要な関係が未解決の場合は、その行を分析に使えるかを判断します。追加のデータを収集する前に、その判断を記録します。