Как Google оптимизирует сканирование социальных сетей, разделяя посты и комментарии

Термины и определения

Managed Account-type source (Источник типа управляемого аккаунта)

Внешний источник контента из социальной сети (упоминаются Google+, LinkedIn), данные из которого собирает система.

Posts (Посты)

Контент верхнего уровня.

Engagements (Вовлеченность)

Производный контент, связанный с постом верхнего уровня (комментарии, ответы).

Scheduler (Планировщик)

Компонент, управляющий временем и частотой сканирования внешних сущностей.

Scheduling Queue (Очередь планирования)

Хранилище (например, Redis Queue) для задач на сканирование. Используются отдельные очереди для Posts и Engagements.

Managed Account Worker (Рабочий процесс управляемого аккаунта)

Процесс, который берет задачи из очереди, запрашивает контент у API социальной сети, парсит ответ и сохраняет данные.

Throttling Manager (Менеджер регулирования нагрузки)

Централизованный компонент, управляющий квотами API и ограничениями скорости запросов (rate limits).

Check Rate (Частота проверки)

Интервал для периодического сканирования Engagements, если API социальной сети не поддерживает уведомления об обновлениях.

ADS LookUp Service (Служба поиска ADS)

Служба, управляющая информацией об аккаунтах, авторизацией (access tokens) и рассчитывающая ограничения скорости на уровне пользователя.

Actual User Limit (Фактический лимит пользователя)

Рассчитанная метрика для управления троттлингом, основанная на общей квоте приложения и количестве пользователей.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает метод планирования сканирования (crawl) контента из социальной сети.

1. Контент разделяется на категорию «пост» (основной контент) и категорию «вовлеченность» (ответный контент).
2. Запускаются два потока: первый получает объект для сканирования постов, второй — для сканирования вовлеченности.
3. Определяется тип социальной сети (Тип 1 или Тип 2).
4. Если Тип 1:
   • Запись для постов обновляется следующим временем выборки (next fetch time).
   • Таблица активной вовлеченности обновляется значением, которое заставляет процессор *воздержаться* от выборки контента вовлеченности до тех пор, пока не будет определено наличие нового контента.
5. Если Тип 2:
   • Сканирование контента перепланируется в соответствии с частотой проверки (check rate).
6. Расписание сканирования устанавливается в зависимости от типа социальной сети.

Ядро изобретения — это адаптивный механизм планирования, который оптимизирует ресурсы краулера в зависимости от возможностей API социальной сети. Тип 1 подразумевает, что API уведомляет систему о наличии новых комментариев (например, через счетчик комментариев). Система экономит ресурсы, не проверяя комментарии без необходимости. Тип 2 подразумевает, что API не предоставляет таких уведомлений, вынуждая систему регулярно опрашивать источник с использованием check rate.

Claim 16 (Зависимый от 1): Уточняет, что если социальная сеть (Типа 2) поддерживает ограничения скорости на основе пользователя (user-based rate limit), то расписание сканирования корректируется на основе этого ограничения.

Система динамически адаптирует частоту сканирования, чтобы избежать превышения квот API, выделенных социальной сетью для конкретного пользователя или аккаунта.

Где и как применяется

Патент полностью сосредоточен на этапе CRAWLING – Сканирование и Сбор данных (Crawling & Data Acquisition).

Он описывает инфраструктуру для планирования и выполнения запросов с целью получения контента через API социальных сетей, а не стандартное сканирование веб-страниц.

Взаимодействие компонентов:

• Scheduler: Определяет расписание и наполняет Scheduling Queue.
• Managed Account Worker: Извлекает задачи из очереди и выполняет запросы к API.
• Throttling Manager: Контролирует частоту запросов к API, предотвращая превышение квот.
• ADS LookUp Service: Предоставляет данные авторизации и рассчитывает rate limits.

Входные данные:

• Список управляемых аккаунтов (Managed Accounts).
• Временные метки (next fetch time) и частота проверок (Check Rate).
• Конфигурация API социальных сетей (поддержка уведомлений).
• Данные об ограничениях скорости (Rate Limits) и токены авторизации.

Выходные данные:

• Собранный контент из социальных сетей (посты и данные о вовлеченности), сохраненный в базе данных системы через Batch Insert process.

На что влияет

• Конкретные типы контента: Влияет исключительно на процесс сбора данных из социальных сетей (в патенте упоминаются Google+ и LinkedIn как примеры).
• Патент не описывает влияние на ранжирование веб-страниц, товаров или любого другого контента в основном поиске Google.

Когда применяется

• При каких условиях работает алгоритм: Алгоритм применяется постоянно для управления расписанием сканирования запланированных социальных аккаунтов.
• Триггеры активации: Истечение запланированного времени сканирования (next fetch time).
• Адаптация: Логика планирования адаптируется в зависимости от типа API (наличие уведомлений) и при приближении к пороговым значениям Rate Limits.

Пошаговый алгоритм

Процесс планирования и сбора данных

1. Инициализация Планировщика: Система запускает Scheduler для определенного типа источника (социальной сети).
2. Разделение Контента: Контент источника разделяется на Posts (верхний уровень) и Engagements (комментарии, ответы).
3. Запуск Потоков: Планировщик запускает два отдельных потока: один для постов, другой для вовлеченности.
4. Выборка Записей для Сканирования:
   • Поток постов ищет аккаунты, которые пора сканировать, основываясь на next fetch time.
   • Поток вовлеченности ищет объекты вовлеченности (active engagement objects), которые пора проверить на обновления.
5. Проверка Очереди: Планировщик проверяет, нет ли уже такой задачи в Scheduling Queue, чтобы избежать дублирования.
6. Добавление в Очередь: Задачи помещаются в соответствующую очередь (отдельные очереди для постов и вовлеченности).
7. Обработка Рабочим Процессом: Managed Account Worker подключается к очереди и извлекает задачу.
8. Согласование Квоты API: Рабочий процесс связывается с Throttling Manager для проверки доступной квоты API.
9. Выполнение Запроса и Сохранение: Рабочий процесс выполняет запрос к API, парсит ответ (например, с помощью Blog Parsing Adapter) и отправляет данные в Batch Insert process.
10. Адаптивное Перепланирование (Ключевой этап):
    • Для постов: Обновляется next fetch time.
    • Для вовлеченности:
      • Если API поддерживает уведомления (Тип 1): next fetch time устанавливается в null. Проверка приостанавливается до обнаружения нового контента.
      • Если API не поддерживает уведомления (Тип 2): Пост перепланируется с использованием стандартной частоты (check rate).
11. Корректировка по Rate Limits: Если предполагаемая нагрузка на API превышает квоту пользователя (для user-based rate limits), планировщик снижает частоту проверок (check rate), чтобы избежать блокировок.

Какие данные и как использует

Данные на входе

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

• Технические факторы:
  • Тип социальной сети (Managed Account Type).
  • Конечные точки API (Endpoints).
  • Значение курсора (Cursor Value) для пагинации ответов API.
  • Идентификатор частоты проверки (Check Rate ID).
  • Данные об ограничениях скорости (Rate Limits).
  • Данные авторизации (access tokens).
• Временные факторы:
  • Время следующей выборки (Next Fetch Time).
  • Интервалы выборки (Fetch Interval).

Какие метрики используются и как они считаются

• Check Rate (Частота проверки): Интервал, используемый для планирования сканирования вовлеченности для источников Типа 2.
• Оценка нагрузки API: Система рассчитывает предполагаемое общее количество вызовов API. Эта оценка сравнивается с доступными квотами.
• Actual User Limit (Фактический лимит пользователя): Метрика для адаптации расписания и регулирования запросов для API с пользовательскими лимитами. В патенте приводится формула расчета:

  $\text{Actual User Limit} = \text{Application Daily Quota} / \text{Number of Current Users}$

Патент описывает исключительно инфраструктурные процессы управления краулингом социальных сетей и не дает практических выводов для SEO-специалистов.

1. Инфраструктура Сбора Данных: Патент описывает систему, разработанную для эффективного сбора данных с учетом ограничений и особенностей API различных социальных платформ.
2. Разделение Контента: Ключевая особенность архитектуры — раздельная обработка основного контента (Posts) и производного (Engagements), так как они имеют разные характеристики обновления и требуют разных стратегий сканирования.
3. Адаптивное Планирование: Система адаптивно управляет частотой сканирования. Она снижает нагрузку, если API предоставляет уведомления о новом контенте (Тип 1), и использует регулярные проверки (Check Rate), если уведомлений нет (Тип 2).
4. Управление Нагрузкой (Throttling): Реализован сложный механизм защиты от превышения лимитов API через централизованное регулирование (Throttling Manager) и динамическую корректировку расписания.
5. Отсутствие связи с SEO: Патент не затрагивает аспекты ранжирования, индексирования или оценки качества контента в веб-поиске.

Патент является инфраструктурным и не дает практических выводов для SEO.

Best practices (это мы делаем)

Не применимо. Патент не содержит рекомендаций для SEO.

Worst practices (это делать не надо)

Не применимо. Патент не описывает борьбу с SEO-манипуляциями.

Стратегическое значение

Стратегическое значение для SEO минимально. Патент подтверждает, что у Google есть сложные технические решения для масштабного и эффективного сбора данных из социальных сетей. Это косвенно указывает на важность мониторинга социального контента. Однако патент не раскрывает, как именно эти собранные данные используются в алгоритмах ранжирования основного поиска.

Практические примеры

Практических примеров для SEO нет, так как патент описывает внутреннюю работу краулера социальных сетей.