TikTokのキーワード調査で検索語群を比較できる条件を保つ

収集計画を立てる

公開Taskに保存されている入力設定では、サンプルの検索語を3つ使い、`expandQueries`をfalse、共通の`maxResults`上限を重複のない動画150件、`resultsPerQuery`を50、`maxPagesPerQuery`を1、`searchDistribution`を"balanced"に設定しています。調査対象全体を実行する前に、このサンプルの検索語を目的の検索語に置き換えてください。

公開版Searchのビルド1.1.5で設定を検証するには、まず範囲を限定した試験実行を行います。サンプルの検索語リストを、実際に使う検索語1つに置き換えてください。`expandQueries`をfalse、`maxExpandedQueries`を0、`maxResults`を2、`resultsPerQuery`を2、`maxPagesPerQuery`を1、`searchDistribution`を"balanced"に設定します。

"python tutorial"を使った基本動作の確認では、投稿ID、投稿URL、投稿者ID、ハンドル名、五月と八月の公開日を含むメタデータが二行返され、OUTPUTの停止理由は`max_results_reached`でした。この試験実行では、検索の基本フィールドと出典情報を確認しています。ただし、複数の検索語を使ったトレンドのベンチマークでも、広告キャンペーンのテストでもありません。

標準データセットのフィールドと実行の記録

標準データセットのレコードには、`postId`、`postUrl`、`authorId`、`profileHandle`、`publishedAt`、`observedAt`が含まれます。検索の由来を示すフィールドには、クエリの背景情報が記録されます。`rootQuery`は元の検索語群、`query`は実際に実行した検索語、`querySource`はその検索語の由来を示します。`pageIndex`と`pageRank`には、収集したソースページ上の位置が記録されます。`status`と`statusReason`は、項目ごとの処理結果を示します。任意フィールドの値が収集元にない場合は、nullのままになります。

`OUTPUT`オブジェクトは、クエリの対応関係を自動で示すものではなく、実行の記録を提供します。主なフィールドは次のとおりです。

• `queriesSearched`：実際に実行した検索語の配列。
• `queryPlans`：クエリ、元の検索語群、由来の定義を含む計画リスト。
• `effectiveResultsPerQuery`：均等配分の計算によって引き下げられた、検索語ごとの動画保存件数の上限。
• `rowsSaved`：データセットに書き込まれた、重複のない動画の総数。
• `duplicatesSkipped`：全体の重複排除によって除外された候補動画数。
• `stopReason`：`max_results_reached`など、実行全体の停止状態。
• `sourceStatusCounts`：`{ok: 1}`など、収集元の状態を集計した値。
• `status`と`statusReason`：`status: "ok"`と`statusReason: null`など、最上位の実行結果。

検索語1つの対照実行では、`OUTPUT`に`stopReason: "max_results_reached"`、`rowsSaved: 2`、`sourceStatusCounts: {ok: 1}`、`status: "ok"`、`statusReason: null`が記録されました。

有用な動画の割合は、実行した検索語について、IDが判明しており、確認の結果関連性があると判断した動画数を、比較条件がそろい、確認可能な候補サンプルの動画数で割った値と定義します。失敗した検索語や未実行の検索語については、有効な割合を算出できません。

収集計画を立てる

1. 検索前に、調査で明らかにする問いと検索語群を定義します。同じ概念を表す検索語だけをまとめ、検索語リストを明示的に残してください。
2. 共通の`maxResults`、`resultsPerQuery`、`maxPagesPerQuery`、検索語拡張の有無、`searchDistribution`を設定します。固定したリストをそのまま比較する場合は、検索語拡張を無効にしてください。共通の`maxResults`は全クエリを通じた動画保存総数の上限となり、`resultsPerQuery`は個々の検索語の上限となります。
3. 検索語ごとに収集枠を計画的に割り当てる必要がある場合は、均等配分を選びます。先の検索語から順に収集枠を埋めることが目的の場合に限り、順次配分を選んでください。均等配分では、総件数の上限を分け合うために`effectiveResultsPerQuery`が引き下げられることがあります。ただし、各収集枠が埋まることも、未使用の収集枠が再配分されることも保証されません。
4. 計画上の収集枠と、実際に得られた有用なデータを分けて扱います。実行の有無、保存行数、判明した動画ID、重複、識別情報の欠損、収集元の障害状態を記録してください。収集元の障害後に有用な行が0件だった場合、データを取得できるかどうかは不明です。そのトピックへの関心がゼロだという意味ではありません。
5. 出典情報を保持し、全体の重複排除を慎重に扱います。ここでいう出典情報の保持とは、保存した正確な収集元と、`observedAt`に記録された収集時刻を残すことです。組み込みの全体重複排除では、動画は最初に確認されたクエリにだけ紐づけて1回保存されます。各クエリでの動画の出現をすべて記録するには、クエリごとに別の実行台帳を残してください。
6. すべてのグループに同じ手動の関連性判定ルールを適用します。`postId`と`postUrl`の正確な値を確認し、候補動画と有用な項目を区別してください。有用な動画の割合は、実行済みで利用可能なデータだけを使って計算します。失敗した検索語や未実行の検索語は、不明として扱います。
7. グループを比較する前に、データの不足を報告します。未実行の検索語はゼロではなく`not_attempted`と記録し、収集元の件数上限を明示してください。収集上限や障害の状況が異なる場合、単純な総件数だけで検索語群を順位付けしてはいけません。
8. 検索計画と実際のサンプル台帳を保存します。`queriesSearched`、`queryPlans`、`rowsSaved`、`duplicatesSkipped`、`stopReason`などの`OUTPUT`フィールドを確認し、停止に関する正確な記録を残してから、トレンド分析や広告クリエイティブ分析を行ってください。

説明用に作成した架空の収集台帳

以下の値はすべて、収集枠、停止状態、全体重複排除の限界を説明するために独自に作成した架空の値です。実際の製品のベンチマークや試験実行の結果を表すものではありません。

検索語A、B、Cの3つを使い、`maxPagesPerQuery`を1、検索語拡張を無効、`maxResults`を6、要求する`resultsPerQuery`を6に設定した場合を考えます。

• 均等配分の実行：報告された`effectiveResultsPerQuery`は2で、検索語ごとに動画を2件保存する計画上の上限が設定されます。各検索語から、重複のない関連動画が2件ずつ返された場合、台帳はA=2、B=2、C=2となり、合計6件の動画を保存します。有用な動画の割合は、各検索語で2/2です。
• 順次配分の実行：検索語A、B、Cのそれぞれに、検索語ごとの上限6件を設定します。検索語Aで6件の動画が保存され、共通の`maxResults`上限6件に達します。検索語BとCは一度も実行されません。台帳には、各検索語の計画上の最大件数を6と記録し、保存件数をA=6、B=0（`not_attempted`）、C=0（`not_attempted`）と記録します。BとCの保存行数を0と記録するのは台帳上の処理です。サンプルを取得できるかどうかは、依然として不明です。
• 均等配分の実行で収集元に障害が発生した場合：検索語Aでは有用な動画を2件保存し（割合は2/2）、検索語Cでも有用な動画を2件保存します（割合は2/2）。検索語Bでは収集元のエラーが発生します。検索語Bには、保存行数0、有用な行数0、関連性のある動画の割合は不明と記録します。`source_failed`というラベルは、読者が使う台帳上の表記です。標準データセットで定義された列挙値ではありません。

検索語ごとの動画の出現を記録した架空の台帳

別の架空のクエリ実行では、全体の重複排除で重なりを除外せずに、各検索語での動画の出現を調べます。

この出現表には、延べ6件の出現が、異なる5件の動画IDにわたって記録されています。全体の重複排除を適用した単一のエクスポートでは、V2は検索語Aにだけ紐づけて保持されます。V2の由来として検索語Aが保持されていても、検索語BにV2が出現しなかった証拠にはなりません。すべてのクエリでの出現を追跡するには、クエリごとに範囲を限定した実行台帳を別々に保存する必要があります。