クエリ取得: 複数ソースからの検索データ収集

この記事では、包括的なデータセットを構築するために、5つの異なるソースから検索クエリを収集する方法について説明します。このデータセットはSEOパイプラインで使用されます。

問題点: 不完全なクエリデータ

単一のデータソースに依存すると、不完全な全体像しか得られません:

  • Google Search Console: クリックにつながったクエリのみ表示（高インプレッション、低CTRのクエリを見逃す）

  • Google Ads: 有料検索キーワードのみ表示（オーガニックトラフィックを見逃す）

  • ライブ検索ログ: サイト内検索のみ表示（外部での発見を見逃す）

  • Algolia: オートコンプリートクエリのみ表示（完全な検索を見逃す）

完全な検索状況を理解するためには、すべてのソースからのクエリを集約する必要があります。

概要: 5つのクエリソース

パイプラインは5つのソースからデータを取得します:

  • Google Search Console: エンゲージメント指標付きのオーガニック検索クエリ

  • Google Ads: コンバージョンデータ付きの有料検索キーワード

  • ライブ検索ログ: サイト内ユーザークエリ

  • Algolia アナリティクス: オートコンプリート検索クエリ

  • キーワードプランナー: 関連キーワードの提案

各ソースは異なる洞察を提供し、組み合わせることで包括的なクエリデータセットが作成されます。

ステップ1: 各ソースからのクエリ取得

1.1 Google Search Console (GSC)

目的: クリックにつながったオーガニック検索クエリを収集する。

入力: Search Consoleで確認済みのウェブサイトURL。

出力: エンゲージメント指標付きのクエリリスト（クエリ、クリック数、インプレッション数、CTR、順位）。

データ仕様:

  • クエリテキスト

  • クリック数（ユーザーが結果をクリックした回数）

  • インプレッション数（結果が表示された回数）

  • CTR（クリック率、パーセンテージ）

  • 検索結果での平均順位

遡及期間: 90日間（詳細なクエリデータの最大期間）

フィルタリング: 最低1クリック（インプレッションのみのクエリを除外）

アクセス方法: 読み取り専用スコープを持つサービスアカウントによるGoogle Search Console API

1.2 Google Ads 検索キーワード

目的: 広告をトリガーした有料検索キーワードを収集する。

入力: マネージャーアカウントアクセス権を持つGoogle Adsアカウント。

出力: パフォーマンス指標付きの検索キーワードリスト（キーワード、インプレッション数、クリック数、コスト）。

データ仕様:

  • 検索キーワードテキスト

  • インプレッション数（広告が表示された回数）

  • クリック数（広告がクリックされた回数）

  • マイクロ単位のコスト（100万単位 = 1通貨単位）

遡及期間: 2年間（利用可能なすべての履歴データ）

集約: すべての認可されたアカウントのデータを結合

フィルタリング: 最低1インプレッション

アクセス方法: OAuth2によるGoogle Ads API

1.3 ライブ検索クエリ

目的: サイト内ユーザー検索クエリを収集する。

入力: 検索サービスからの内部検索ログ。

出力: 頻度指標付きのクエリリスト（クエリ、回数、エンゲージメント）。

データ仕様:

  • クエリテキスト

  • 頻度（検索された回数）

  • エンゲージメントデータ（製品インタラクションにつながった検索）

遡及期間: 可変（通常、ログ保持期間に基づき30～90日間）

重み付け: エンゲージメントによるクエリの重み付け（インタラクションのある検索は高スコア）

フィルタリング: 重複排除と出現回数のカウント

1.4 Algolia トップ検索

目的: Algoliaアナリティクスからオートコンプリート検索を収集する。

入力: Algolia検索アナリティクスデータ。

出力: 頻度付きのトップ検索クエリリスト（トップ検索、回数）。

データ仕様:

  • クエリテキスト

  • 検索回数（検索された回数）

遡及期間: 90日間

フィルタリング: 最近の高ボリューム検索に限定

アクセス方法: アプリケーション認証情報によるAlgolia Analytics API

1.5 キーワードプランナー アイデア

目的: 関連キーワードの提案を収集する。

入力: シードキーワード（製品カテゴリ、ファミリー、一般的な検索用語）。

出力: 指標付きのキーワードリスト（キーワード、検索ボリューム、競争率、入札提案額）。

データ仕様:

  • キーワードテキスト

  • 月間平均検索数

  • 競争レベル（低、中、高）

  • 提案入札額

フィルタリング: 関連するキーワードのみ（無関係な提案を除外）

アクセス方法: OAuth2によるGoogle Ads Keyword Planner API

ステップ2: クエリの正規化と集約

2.1 クエリテキストの正規化

集約前にクエリを標準化します:

  • 小文字に変換

  • 空白の正規化（複数のスペースを1つに圧縮）

  • 先頭/末尾の空白をトリミング

  • 特殊文字の削除（該当する場合）

2.2 マージと重複排除

すべてのソースからのクエリを結合します:

  1. すべてのソースクエリリストを読み込む
  2. 正規化されたクエリテキストで重複排除
  3. 指標をマージ（クリック数、インプレッション数、検索数を結合）
  4. 各クエリのソースを追跡
  5. 結合されたエンゲージメントスコアでソート

2.3 エンゲージメントシグナルによる重み付け

クエリはエンゲージメントに基づいてスコアリングされます:

  • GSCからのクリック: 最高重み（コンテンツへの直接的なエンゲージメント）

  • 広告からのクリック: 最高重み（ユーザーの有料意図がアクションに変換）

  • エンゲージメントのあるライブ検索: 中程度の重み（サイト内インタラクション）

  • エンゲージメントのないライブ検索: 低い重み（検索のみ）

  • Algoliaオートコンプリート: 低い重み（不完全な意図）

  • キーワードアイデア: 最低重み（提案された、観測されていない検索）

重み付け式は設定可能で、エンゲージメントが主要なランキングシグナルです。

2.4 低品質クエリのフィルタリング

無効なクエリは削除されます:

  • スパム: 数字のみ、特殊文字のみ、またはインジェクション試行を含むクエリ

  • ブランド名のみ: 自社ブランド名のみのクエリ

  • 低スコア: 最低エンゲージメント閾値を下回るクエリ

ステップ3: 技術的実装

3.1 クエリ取得プロセス

各ソースの認証とデータ取得:

  1. 認証情報（サービスアカウント、OAuth2、またはAPIキー）を取得
  2. それぞれのAPIに接続
  3. 指定された日付範囲のデータをリクエスト
  4. レスポンスを標準JSON形式に解析
  5. ローカルストレージに保存

3.2 Google Search Console クライアント

プロセス:

  1. サービスアカウント認証情報で認証
  2. 指定サイトのSearch Console APIをクエリ
  3. 結果をページネーション（各ページは最大25,000件を返す）
  4. クエリ、クリック数、インプレッション数、CTR、順位を抽出
  5. 集約してJSONとして保存

3.3 Google Ads クライアント

プロセス:

  1. OAuth2認証情報で認証
  2. すべての認可されたアカウントを列挙
  3. 各アカウントの検索キーワードをクエリ
  4. アカウント間で指標を集約
  5. インプレッション数でソートして保存

3.4 ライブクエリログ解析

プロセス:

  1. 内部検索ログファイルを読み込む
  2. 各ログエントリを解析（JSON形式、1行ごと）
  3. クエリテキストとエンゲージメントシグナルを抽出
  4. クエリの重複排除と出現回数のカウント
  5. エンゲージメントで重み付けして保存

3.5 Algoliaアナリティクス取得

プロセス:

  1. Algolia認証情報で認証
  2. 検索データのためにAnalytics APIを呼び出す
  3. 日付範囲フィルター付きでトップ検索をリクエスト
  4. 検索回数と結果指標を返す
  5. 標準JSON形式で保存

ステップ4: 増分更新

クエリ取得は、より高速な処理のために増分更新をサポートします:

初回実行:

  • すべての履歴データを取得（広告は2年間、GSCは90日間）

  • 埋め込みを計算（初期設定は遅い）

以降の実行:

  • 前回実行以降の新しいデータのみを取得

  • 可能な限りキャッシュされた埋め込みを再利用

  • 増分更新は迅速に完了

最適化ロジック:

  • 出力が存在し、最近であるかを確認

  • 新しいデータが利用できない場合はスキップ

  • 失敗時は最後のチェックポイントから再開

ステップ5: パイプラインとの統合

取得されたクエリは、後続のパイプラインステップに供給されます:

5.1 クエリクラスタリング:

  • 入力: エンゲージメント重み付きの結合クエリリスト

  • プロセス: 埋め込みを使用して類似クエリをグループ化

  • 出力: ページ生成のためのクエリクラスター

5.2 製品マッチング:

  • 入力: クエリ埋め込みとクラスター

  • プロセス: 各クラスターに関連製品をマッチング

  • 出力: クエリと製品のマッピング

5.3 クエリページ:

  • 入力: クラスタリングと製品マッチング

  • プロセス: 各クラスターのページコンテンツを生成

  • 出力: HTMLページとルーティングデータ

5.4 関連検索:

  • 入力: クエリ埋め込みとページデータ

  • プロセス: 各ページの類似クエリを検索

  • 出力: 関連検索の提案

参照: 完全なパイプラインアーキテクチャについてはSEOパイプライン概要

データ品質に関する考慮事項

重複の処理

クエリは、わずかなバリエーションで複数のソースに現れる場合があります。例:

  • "mini pc" (GSC)

  • "Mini PC" (広告)

  • "mini pc" (余分なスペースのあるライブ)

解決策: マージ前に正規化（小文字化、トリミング、空白圧縮）

スパムの処理

一部のソースには無効なクエリが含まれます:

  • ランダムな文字列

  • SQLインジェクション試行

  • 極端に長いクエリ

解決策: エンゲージメントシグナル、文字構成、長さルールによるフィルタリング

季節性の処理

クエリボリュームは季節によって変動します:

  • 祭事期間中はボリュームが高い

  • 休暇中はボリュームが低い

解決策: 季節変動を平滑化するために90日間の遡及期間を使用

パフォーマンス特性

  • 取得時間: ソースによって異なる; 並列取得により全体時間を削減

  • クエリボリューム: データソースに依存して数千から数百万

  • 集約時間: ユニーククエリの合計数に比例してスケール

  • 増分更新: 完全再取得よりも大幅に高速

  • リソース使用量: 集約に中程度のCPU、重複排除にメモリ

エラー処理

パイプラインは一般的な障害を処理します:

  • API利用不可: 指数バックオフで再試行

  • データ欠落: スキップしてログに記録; 他のソースで継続

  • 無効なエントリ: フィルタリングして処理を継続

  • 部分的な障害: 成功したデータを保存し、チェックポイント位置を記録

関連項目

参考文献

APIとサービス

関連記事

← ドキュメントインデックスに戻る