Получение поисковых запросов: Сбор данных из нескольких источников

Эта статья объясняет, как мы собираем поисковые запросы из пяти различных источников для создания комплексного набора данных для SEO-пайплайна.

Проблема: Неполные данные о запросах

Опора на единственный источник данных дает неполную картину:

  • Google Search Console: Показывает только запросы, приведшие к кликам (пропускает запросы с большим числом показов и низким CTR)

  • Google Ads: Показывает только платные поисковые термины (пропускает органический трафик)

  • Логи живого поиска: Показывают только поиски на сайте (пропускают внешнее обнаружение)

  • Algolia: Показывает только запросы автодополнения (пропускает полные поиски)

Нам необходимо агрегировать запросы из всех источников, чтобы понять полную картину поиска.

Обзор: Пять источников запросов

Пайплайн получает данные из пяти источников:

  • Google Search Console: Органические поисковые запросы с метриками вовлеченности

  • Google Ads: Платные поисковые термины с данными о конверсиях

  • Логи живого поиска: Поисковые запросы пользователей на сайте

  • Аналитика Algolia: Запросы автодополнения поиска

  • Планировщик ключевых слов: Предложения связанных ключевых слов

Каждый источник дает разные инсайты; вместе они создают комплексный набор данных о запросах.

Шаг 1: Получение запросов из каждого источника

1.1 Google Search Console (GSC)

Цель: Собрать органические поисковые запросы, которые привели к кликам.

Входные данные: URL веб-сайта, подтвержденный в Search Console.

Выходные данные: Список запросов с метриками вовлеченности (запросы, клики, показы, CTR, позиция).

Спецификации данных:

  • Текст запроса

  • Клики (количество пользователей, кликнувших на наш результат)

  • Показы (количество раз, когда наш результат появлялся)

  • CTR (рейтинг кликов в процентах)

  • Средняя позиция в результатах поиска

Период обратного просмотра: 90 дней (максимум для детальных данных о запросах)

Фильтрация: Минимум 1 клик (исключает запросы только с показами)

Доступ: Google Search Console API через сервисный аккаунт с правами только для чтения

1.2 Поисковые термины Google Ads

Цель: Собрать платные поисковые термины, которые запускали показ рекламы.

Входные данные: Аккаунт Google Ads с доступом менеджера аккаунтов.

Выходные данные: Список поисковых терминов с метриками производительности (термины, показы, клики, стоимость).

Спецификации данных:

  • Текст поискового термина

  • Показы (количество показов рекламы)

  • Клики (количество кликов по рекламе)

  • Стоимость в микроединицах (1 миллион единиц = 1 денежная единица)

Период обратного просмотра: 2 года (все доступные исторические данные)

Агрегация: Объединяет данные по всем авторизованным аккаунтам

Фильтрация: Минимум 1 показ

Доступ: Google Ads API через OAuth2

1.3 Запросы живого поиска

Цель: Собрать поисковые запросы пользователей на сайте.

Входные данные: Внутренние логи поиска от поискового сервиса.

Выходные данные: Список запросов с метриками частоты (запросы, количество, вовлеченность).

Спецификации данных:

  • Текст запроса

  • Частота (количество раз поиска)

  • Данные о вовлеченности (поиски, приведшие к взаимодействию с продуктом)

Период обратного просмотра: Разный (обычно 30-90 дней в зависимости от хранения логов)

Взвешивание: Запросы взвешиваются по вовлеченности (поиски с взаимодействием получают более высокий балл)

Фильтрация: Удаление дубликатов и подсчет вхождений

1.4 Топ-поиски Algolia

Цель: Собрать поисковые запросы автодополнения из аналитики Algolia.

Входные данные: Данные аналитики поиска Algolia.

Выходные данные: Список топ поисковых запросов с частотой (топ-запросы, количество).

Спецификации данных:

  • Текст запроса

  • Количество поисков (число раз, когда искали)

Период обратного просмотра: 90 дней

Фильтрация: Ограничение недавними поисками с высоким объемом

Доступ: Algolia Analytics API через учетные данные приложения

1.5 Идеи из Планировщика ключевых слов

Цель: Собрать предложения связанных ключевых слов.

Входные данные: Семенные ключевые слова (категории продуктов, семейства, распространенные поисковые термины).

Выходные данные: Список ключевых слов с метриками (ключевые слова, объем поиска, конкуренция, предложения по ставкам).

Спецификации данных:

  • Текст ключевого слова

  • Среднемесячное количество поисков

  • Уровень конкуренции (низкий, средний, высокий)

  • Предлагаемое значение ставки

Фильтрация: Только релевантные ключевые слова (исключаются несвязанные предложения)

Доступ: Google Ads Keyword Planner API через OAuth2

Шаг 2: Нормализация и агрегация запросов

2.1 Нормализация текста запроса

Перед агрегацией запросы стандартизируются:

  • Приведение к нижнему регистру

  • Нормализация пробелов (сведение нескольких пробелов к одному)

  • Удаление начальных и конечных пробелов

  • Удаление специальных символов (где применимо)

2.2 Объединение и удаление дубликатов

Запросы из всех источников объединяются:

  1. Загрузка всех списков запросов из источников
  2. Удаление дубликатов по нормализованному тексту запроса
  3. Объединение метрик (комбинирование кликов, показов, поисков)
  4. Отслеживание, какие источники внесли вклад в каждый запрос
  5. Сортировка по комбинированному баллу вовлеченности

2.3 Взвешивание по сигналам вовлеченности

Запросы оцениваются на основе вовлеченности:

  • Клики из GSC: Наибольший вес (прямое взаимодействие с нашим контентом)

  • Клики из Ads: Наибольший вес (платное намерение пользователя, конвертированное в действие)

  • Живые поиски с вовлеченностью: Средний вес (взаимодействие на сайте)

  • Живые поиски без вовлеченности: Меньший вес (только поиск)

  • Автодополнение 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, по одной на строку)
  3. Извлечение текста запроса и сигналов вовлеченности
  4. Удаление дубликатов запросов и подсчет вхождений
  5. Взвешивание по вовлеченности и сохранение

3.5 Получение аналитики Algolia

Процесс:

  1. Аутентификация с учетными данными Algolia
  2. Вызов Analytics API для данных поиска
  3. Запрос топ-поисков с фильтром по диапазону дат
  4. Возврат количества поисков и метрик результатов
  5. Сохранение в стандартный формат JSON

Шаг 4: Инкрементальные обновления

Получение запросов поддерживает инкрементальные обновления для более быстрой обработки:

Первый запуск:

  • Получение всех исторических данных (2 года для Ads, 90 дней для GSC)

  • Вычисление эмбеддингов (медленная первоначальная настройка)

Последующие запуски:

  • Получение только новых данных с момента последнего запуска

  • Повторное использование кэшированных эмбеддингов, где возможно

  • Инкрементальные обновления завершаются быстро

Логика оптимизации:

  • Проверка существования и актуальности выходных данных

  • Пропуск, если нет новых данных

  • Возобновление с последней контрольной точки при сбое

Шаг 5: Интеграция с пайплайном

Полученные запросы передаются на последующие шаги пайплайна:

5.1 Кластеризация запросов:

  • Вход: Объединенный список запросов с весами вовлеченности

  • Процесс: Группировка похожих запросов вместе с использованием эмбеддингов

  • Выход: Кластеры запросов для генерации страниц

5.2 Сопоставление с продуктами:

  • Вход: Эмбеддинги запросов и кластеры

  • Процесс: Сопоставление каждого кластера с релевантными продуктами

  • Выход: Сопоставления "запрос-продукт"

5.3 Страницы запросов:

  • Вход: Кластеризация и сопоставления с продуктами

  • Процесс: Генерация контента страницы для каждого кластера

  • Выход: HTML-страницы и данные маршрутизации

5.4 Связанные поиски:

  • Вход: Эмбеддинги запросов и данные страниц

  • Процесс: Поиск похожих запросов для каждой страницы

  • Выход: Предложения связанных поисков

См.: Обзор SEO-пайплайна для полной архитектуры пайплайна

Соображения по качеству данных

Обработка дубликатов

Запросы могут появляться в нескольких источниках с небольшими вариациями. Пример:

  • "mini pc" (GSC)

  • "Mini PC" (Ads)

  • "mini pc" (Live с лишним пробелом)

Решение: Нормализация перед объединением (нижний регистр, обрезка, сжатие пробелов)

Обработка спама

Некоторые источники содержат недопустимые запросы:

  • Случайные строки символов

  • Попытки SQL-инъекций

  • Чрезвычайно длинные запросы

Решение: Фильтрация по сигналам вовлеченности, составу символов, правилам длины

Учет сезонности

Объем запросов варьируется в зависимости от сезона:

  • Больший объем во время праздников

  • Меньший объем во время каникул

Решение: Использование периода обратного просмотра в 90 дней для сглаживания сезонных вариаций

Характеристики производительности

  • Время получения: Зависит от источника; параллельное получение сокращает общее время

  • Объем запросов: От тысяч до миллионов в зависимости от источников данных

  • Время агрегации: Масштабируется с общим количеством уникальных запросов

  • Инкрементальные обновления: Значительно быстрее, чем полное повторное получение

  • Использование ресурсов: Умеренная загрузка ЦП для агрегации, память для дедупликации

Обработка ошибок

Пайплайн обрабатывает распространенные сбои:

  • API недоступен: Повторная попытка с экспоненциальной задержкой

  • Отсутствующие данные: Пропуск и логирование; продолжение с другими источниками

  • Недопустимые записи: Фильтрация и продолжение обработки

  • Частичные сбои: Сохранение успешных данных и позиции контрольной точки

Смотрите также

Ссылки

API и сервисы

Связанные статьи