Накрутка поведенческих факторов

Происхождение и история термина

Практика документирована как минимум в сообщении команды поиска Яндекса от 23 мая 2011 года. Компания описывала попытки влиять на поиск с помощью эмуляции, то есть воспроизведения действий пользователей программой. В сообщении упоминались автоматические запросы и последующие переходы на сайты; Яндекс относил такие действия к поисковому спаму и предупреждал о последствиях для позиций. ^[6]

Это свидетельство существования метода в тот период, а не дата его изобретения. Современная справка формулирует предмет шире программной автоматизации: в неё входят и задания обычным пользователям, и предоставление услуг искусственного увеличения поисковых посещений. ^[1] Так история понятия связана с попыткой подменить интерес человека его внешними признаками; сводить её только к развитию ботов неточно.

Суть и механизм

Условная схема имитации состоит из трёх звеньев: действие совершается ради продвижения, попадает в статистику, затем предъявляется как свидетельство интереса. Это объяснительная схема статьи, а не описание закрытого алгоритма поисковой системы. Яндекс прямо указывает, что имитация искажает поведенческую статистику. ^[1]

Рассмотрим учебную ситуацию. Один читатель открывает материал, чтобы узнать расписание автобуса. Другой получает задание создать посещение определённой страницы независимо от её полезности. Оба могут быть людьми, но цели различаются. Поэтому проверка только на наличие программы не решает вопрос о подлинности интереса.

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

Рекламные клики образуют другую категорию. Google Ads называет недействительными клики по объявлениям, за которыми нет подлинного интереса к бизнесу. Среди примеров есть случайные нажатия, автоматический трафик и ручные клики ради изменения расходов или доходов. ^[4] Следовательно, даже недействительный рекламный клик не обязательно означает умышленную поисковую манипуляцию.

Виды и классификации

Для разбора инцидента удобно различать три уровня вывода. Эта рабочая классификация предложена редакцией, а не поисковиком.

Платформенные категории также следует различать.

Правило Google об автоматическом доступе не следует пересказывать как точный аналог категории Яндекса. Оно относится к взаимодействию с самим поиском, а не даёт универсального определения любого подозрительного посещения сайта. ^[2]

Как применяется на практике

Яндекс рекомендует проверять модули сайта и методы привлечённых специалистов. ^[1] Для владельца это повод запросить описание выполненных работ. Полезный ответ содержит конкретные действия, даты и страницы, а не только график роста. Такой запрос — предложенный здесь порядок проверки, а не обвинение подрядчика.

В учебном сценарии редакция заметила резкий рост посещений статьи. Аналитик сначала выбирает точный период и сохраняет исходные отчёты. Разработчик проверяет, что и как записывали системы. Ответственный за продвижение сопоставляет даты с кампанией и выполненными работами. Затем команда формулирует подтверждённый результат: например, «обнаружено расхождение записей, происхождение пока не установлено».

Google Analytics автоматически исключает трафик известных ботов и поисковых пауков — программ, обходящих страницы. Справка ограничивает обещание известными источниками: отключить эту очистку и посмотреть число исключённых ею посещений нельзя. ^[3] Поэтому аналитик не сможет получить точное число отброшенных ботов, просто вычитая показатель Analytics из другого счётчика.

Как измерить или проверить

Сначала договоритесь о единице подсчёта. В Analytics сессия — период взаимодействия пользователя с сайтом или приложением; внутри неё могут регистрироваться события. ^[7] Сопоставлять число сессий с числом отдельных событий как две оценки одного показателя нельзя. Для сверки нужны одинаковые определения, страницы, временные границы и правила удаления повторов. Это условия учебной модели ниже.

Предположим, две системы записывали один и тот же тип событий за одни сутки. В системе A осталось 1000 уникальных записей, в B — 850. Для примера у каждого события есть общий идентификатор, по которому можно проверить совпадение. При сверке обнаружились 800 событий, присутствующих в обеих системах.

Разность итогов составляет 150 событий. Относительно A она равна:

D = (A − B) / A × 100%

Здесь A и B — количества событий, D — относительная разность в процентах; знаменатель задаёт базу сравнения. Получаем (1000 − 850) / 1000 × 100% = 15%. Но несовпавших записей 250: это 200 только в A плюс 50 только в B. Уже поэтому разность итогов не равна количеству всех расхождений. Ни одно из этих чисел не названо числом ботов: происхождение событий в условии неизвестно.

Если A равно нулю, относительная разность по этой формуле не определена. Если B больше A, результат отрицательный: это направление расхождения, а не «отрицательная накрутка». Для дальнейшего разбора нужны сами записи и объяснение способа их получения, а не только процент.

Ошибки, ограничения и спорные вопросы

Отсутствие заметных ботов не доказывает естественность всех посещений: фильтрация Analytics относится к известному бот-трафику. ^[3] Отсутствие ручной меры Google также нельзя считать объяснением любой динамики: этот отчёт описывает решения, принятые после проверки человеком. ^[5]

Другое ограничение касается эффективности. Схожие даты роста посещений и изменения позиций ещё не связывают их причиной и следствием. В учебном разборе следует отдельно записывать наблюдение, предполагаемое объяснение и сведения, которых не хватает для проверки. Обещание подрядчика и подозрение владельца требуют одинакового внимания к основаниям.

Частые вопросы

Связанные термины

• povedencheskie-faktory
• perespam
• pessimizatsiya
• veb-analitika
• organicheskiy-trafik
• ad-fraud