Конверсия

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

Один документированный этап изменения терминологии относится к Google Analytics. 21 марта 2024 года Google объявил, что события, называвшиеся конверсиями в поведенческой аналитике, станут ключевыми событиями — key events. Отдельное название ввели для анализа важных действий на сайте и в приложении, сохранив конверсии в рекламном контексте. Это изменение названий конкретного продукта, а не дата появления самого понятия конверсии. ^[6]

В актуальной справке Google Analytics ключевым называется событие, измеряющее особенно важное для бизнеса действие. На его основе можно создать конверсию Google Ads. Поэтому при чтении старого отчёта недостаточно заменить слово: нужно выяснить, из какого продукта и раздела взято число. ^[1]

Яндекс Метрика использует другое разделение: цель описывает интересующее действие, достижение — выполнение её условия, а показатель «Конверсия» представляет отношение целевых визитов ко всем визитам. ^[4] Один и тот же заказ может быть реальным результатом бизнеса, техническим событием сайта и частью процентного показателя. Эти названия помогают уточнить, о каком уровне идёт речь.

Для сопоставления данных разных лет полезно сохранять не только названия столбцов, но и определения. В учебном архиве строка «конверсии: 20» без названия системы и единицы не позволяет понять, было ли двадцать покупок, двадцать записей события или двадцать процентов успешных посещений.

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

Удобно разделить реальное действие, техническое событие и учтённый результат. Покупатель оформляет заказ, на сайте срабатывает программный сигнал о действии, затем аналитическая система применяет правила подсчёта и связи с источниками перехода. В учебном примере нажатие «Оплатить» ещё не означает принятого платежа. Если записывать только нажатия, отчёт будет считать попытки, даже когда банк отклонил оплату.

Значимость задаётся до оценки результата. Если задача — получить содержательное обращение, просмотр страницы контактов может служить промежуточным сигналом, но не становится автоматически таким обращением. Подмена конечного действия более лёгким событием способна улучшить цифры, не решив исходную задачу.

В Google Analytics любое собираемое событие можно отметить как ключевое. Однако само присвоение статуса не доказывает коммерческую ценность. Отметка меняет способ представления события в аналитике. Решение, какое действие действительно нужно бизнесу, остаётся за владельцем проекта. ^[1]

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

Атрибуция — распределение учтённого результата между источниками и взаимодействиями, предшествовавшими действию. Справка Google Ads описывает пути к конверсии, а справка Analytics — распределение вклада между точками такого пути. ^{[1, 3]}

Учебный пример: читатель увидел объявление издания, позднее вернулся из поиска и купил подписку. Если оба контакта наблюдаются, правило учёта может назначить всю одну покупку последнему источнику либо разделить её вклад между источниками. Условное деление 0,4 и 0,6 означает доли одной покупки в отчёте, а не две покупки. Это иллюстрация принципа, не описание настройки конкретной модели Google.

Такое распределение отвечает на вопрос «кому приписан результат по правилу». Вопрос «случилась бы покупка без рекламы» требует сравнения с ситуацией без её показа. Google отдельно различает обычные приписанные конверсии и дополнительный результат, измеряемый Conversion Lift — экспериментом с группами, получающими и не получающими рекламу. ^[7] Поэтому нахождение объявления в пути ещё не доказывает, что именно оно создало покупку.

Наконец, счётчик сайта видит лишь полученные им сигналы. В учебном примере подписку оплатили по телефону, а сведения об оплате не передали в аналитику сайта. Продажа есть в журнале заказов, но отсутствует среди событий сайта. Проверять нужно связь источников данных, а не объявлять отсутствие продажи по пустой строке отчёта.

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

Следующая классификация — рабочая схема проектирования измерения. Она не задаёт обязательные названия целей для всех сайтов.

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

В Яндекс Метрике целевой визит может содержать несколько достижений одной цели. Поэтому число достижений нельзя без проверки подставлять в числитель доли целевых визитов. Оба показателя полезны, но описывают разные свойства поведения. ^[4]

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

Учебная ситуация: региональное медиа приглашает читателей оформить платную подписку. Команда сначала выбирает конечный результат: подтверждённое оформление, а не простое открытие формы. Затем отдельно описывает промежуточные шаги, которые помогут найти место затруднения.

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

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

В российском интерфейсе Метрики важно отдельно смотреть достижения и целевые визиты. В Google Analytics и Google Ads нужно учитывать разделение ключевого события и рекламной конверсии. Ни один набор названий нельзя автоматически переносить в другой продукт без сопоставления определения. ^{[1, 4]}

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

Практический результат такого описания — возможность объяснить каждую спорную запись. Если сигнал пришёл дважды, можно проверить номер заказа и статус оплаты. Если заказ есть, а сигнала нет, исследуют передачу сведений. Совпадение одной записи ещё не говорит, что вся система работает без пропусков.

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

Первый контроль касается единиц. Визит, или сессия, — посещение сайта, внутри которого система объединяет действия посетителя. Один читатель может прийти утром, уйти и вернуться вечером: в учебном примере это два посещения одного человека. Точное разделение визитов задаёт система; технически распознанный посетитель также не означает безошибочно установленную личность. Метрика различает посетителей, визиты и достижения цели. ^[4]

Учебный набор содержит 100 визитов; в десяти произошло 15 достижений одной цели. Доля целевых визитов равна 10 / 100 × 100% = 10%, а число достижений равно 15. Значение 15% не является той же долей целевых визитов. ^[4]

Если в этих данных требуется показатель по людям, нужен отдельный подсчёт пользователей. Из числа визитов нельзя восстановить количество разных людей без дополнительных сведений. Повторные визиты и несколько достижений делают простое переименование некорректным.

Второй контроль — повторения. В учебном примере после одного рекламного клика произошло три достижения одного действия. При настройке Every, то есть учёте каждого достижения соответствующего действия, получится 3; при One, то есть одной конверсии этого действия после одного клика, — 1. Это учебный пример для одного действия и одного рекламного клика. Если отслеживаются разные действия, правило применяется к каждому отдельно. Настройки Google Ads позволяют такой выбор. ^[2]

Третий контроль — временная связь. Окно конверсии задаёт, сколько времени после рекламного взаимодействия учитывают последующее действие. Окно ретроспективного рассмотрения, или lookback window, задаёт, насколько далеко назад от уже выбранной конверсии ищут взаимодействия для распределения вклада. У них разные точки отсчёта. ^[3]

Учебный календарь: рекламный клик произошёл 10 июля, покупка — 30 июля. При условном окне конверсии 30 дней смотрят вперёд от клика: до 9 августа; покупка через 20 дней укладывается в этот срок. При окне ретроспективного рассмотрения 30 дней для покупки 30 июля смотрят назад: с 30 июня по 30 июля. Клик 10 июля попадает и в этот интервал. Первое правило отвечает, учитывается ли действие после клика, второе — какие прошлые контакты рассматриваются при распределении его вклада. Число дней в примере одинаковое, смысл настройки различается.

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

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

Для внешнего отчёта полезно сохранять дату выгрузки и возможную задержку получения данных. Если итоговая запись формируется позже действия, ранний отчёт может быть неполным. Конкретная задержка устанавливается по используемой системе, а не назначается универсальным числом.

Учебная оценка сверки: проверяющий взял 40 событий «подписка оплачена» и сравнил их с журналом подтверждённых заказов за тот же период. Для 36 событий совпали номер заказа и статус оплаты. Для четырёх пока не найдено подтверждение: это могут быть повторы, тесты или задержка передачи данных, но причина ещё неизвестна.

Доля событий с найденным подтверждением равна 36 / 40 × 100% = 90%. Это результат проверки выбранных сорока событий. Он не означает, что аналитика точна на 90% вообще: отдельно нужно искать реальные оплаченные заказы, события о которых совсем не поступили. Проверка только уже записанных событий таких пропусков не обнаружит.

При проверке полезно заранее описать отрицательный сценарий. Если посетитель открыл форму и ушёл, событие завершённой отправки возникать не должно. Если отправка не прошла проверку, нужно выяснить, какой сигнал реально передан. Такие сценарии помогают различить намерение, попытку и подтверждённый результат. Они не требуют публиковать реальные контактные данные пользователей: для организационного контроля можно планировать отдельные тестовые случаи и согласованный порядок их исключения.

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

Первая ошибка — называть конверсией любой удобный сигнал. Если действие выбрано только потому, что его легко посчитать, оно может не соответствовать задаче. Значение показателя определяется смыслом и правилом, а не названием в интерфейсе.

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

Третья — принимать атрибуцию за причинность. В учебном сравнении двух одинаковых по размеру и сопоставимых экспериментальных групп зарегистрированы 120 покупок при показе рекламы и 100 без неё. Разность равна 20, а не 120: часть покупок происходит и без рекламы. Это иллюстрация дополнительного результата. Надёжность такого вывода зависит от проведения эксперимента и случайных колебаний; одна разность ещё не доказывает эффект. Различие между приписанными и дополнительными конверсиями прямо выделено в документации Conversion Lift. ^[7]

Четвёртая — складывать рекламные конверсии из разных систем как независимые продажи. Один реальный результат может присутствовать в нескольких отчётах. До суммирования необходимо выяснить пересечения, правила и область наблюдения.

Пятая — оценивать качество данных только совпадением итоговых сумм. Две ошибки могут взаимно компенсироваться. Для содержательной сверки полезны отдельные объяснимые записи и проверка правил, а не только общий результат внизу таблицы.

Наконец, рост количества не доказывает улучшения качества. Если в отчёт попали нецелевые или тестовые действия, число может увеличиться без достижения задачи. Критерий качества результата нужно определить отдельно и не менять ради удобной динамики.

Правовой аспект

Если измерение включает обработку персональных данных, к нему относится статья 5 закона №152-ФЗ. Части 2, 4–5 связывают обработку с заранее определёнными законными целями и требуют соответствия данных этим целям и неизбыточности их объёма. Это содержание сверено по тексту на сайте Минтруда и справочной публикации нормы с меткой редакции от 26.07.2026. Действие всех изменений этой редакции на дату подготовки не подтверждено полностью; перед публикацией требуется проверка юристом. ^[5]

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

Зарубежные счётчики и персональные данные. С 1 июля 2025 года часть 5 статьи 18 закона № 152-ФЗ «О персональных данных» (в редакции Федерального закона от 28.02.2025 № 23-ФЗ) не допускает при сборе персональных данных граждан России, в том числе в интернете, их запись, хранение и другие операции с использованием баз данных за пределами России. Счётчики вроде Google Analytics передают на зарубежные серверы IP-адреса и идентификаторы cookie, которые могут относиться к персональным данным; о трансграничной передаче, кроме того, заранее уведомляют Роскомнадзор (статья 12 того же закона). Нарушения влекут ответственность по статье 13.11 КоАП РФ. Использование такого счётчика на российском сайте требует юридической оценки; для сбора данных о посетителях из России применяют системы веб-аналитики с хранением данных в России, например Яндекс Метрику.

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

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

• Цель в аналитике
• CR (коэффициент конверсии)
• Атрибуция
• Визит (сессия)
• Воронка продаж
• CPA (цена действия)