План измерения рекламного результата

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

Продолжим вымышленную «Линию». Первое действие — заявка на согласование AUDIT-ONE, результат бизнеса — пригодное обращение. У нас нет реальных пользователей, счётчиков, cookies и отправок. Все идентификаторы обезличены и вымышлены. Действительные правовые основания и настройки сбора данных не определены; пример не является разрешением включить отслеживание.

Разделяем действия интерфейса и сервера

Событие form_open означает открытие раздела. Событие form_submit_attempt означает попытку отправки. Событие request_accepted означает, что обращение принято системой. Эти события могут происходить в разном количестве. Если сеть прерывается, попытка не подтверждает принятую заявку. Если человек повторяет отправку, нужны правила повторного события.

Поэтому бизнес-результат не назначается на обычный клик кнопки без основания. Для AUDIT-ONE пригодность определяется после чтения предмета обращения: существующая страница, задача аудита, ожидание отчёта. Это отдельный статус qualified_request. Он не возникает автоматически из заполненного поля URL.

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

Определяем единицы счёта

В событиях сохраним event_id и request_id. Первый различает записи журнала, второй связывает этапы одного обращения. Эти идентификаторы не являются настоящими клиентскими данными. В учебном примере их задача — показать, почему десять событий не обязательно означают десять новых заявок.

Событие	Основание	Единица
form_open	Открыт раздел согласования	Взаимодействие
submit_attempt	Нажата отправка	Попытка
request_accepted	Система приняла обращение	Заявка
qualified_request	Предмет соответствует AUDIT-ONE	Пригодная заявка
scope_agreed	Подтверждён объём	Согласованная работа

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

Сохраняем минимальный журнал

Создадим sample-events.csv с вымышленными R-001 и R-002. Первая заявка проходит принятие и пригодность. Вторая принята, но относится к разработке магазина. Данных настоящих посетителей нет. Текст обращения не передаётся рекламной системе в составе примера.

event_id,request_id,event,fictional
EV-001,R-001,request_accepted,true
EV-002,R-001,qualified_request,true
EV-003,R-002,request_accepted,true
EV-004,R-002,not_fit_new_store,true

Google Analytics запрещает отправлять данные, которые Google может использовать для идентификации человека; область описана в рекомендациях по исключению PII. Поэтому даже в будущей реализации нельзя считать рекламные параметры безопасным местом для имени, телефона или текста обращения. Конкретная схема данных требует отдельной проверки и допустимого основания сбора.

Сопоставляем бизнес-событие с платформой

Google Ads различает основные и дополнительные действия и особые случаи пользовательских целей; назначение влияет на отчётность и оптимизацию. Это описано в справке conversion actions. Мы не объявляем наше событие основным в аккаунте: выбранной системы и реализации нет.

У Метрики есть собственные цели. Согласованный бизнес-словарь помогает определить предмет, но не заменяет настройки счётчика. Не следует считать, что одинаковое название qualified_request создаёт одинаковую модель во всех системах. В lesson state platform_mapping остаётся неизвестным.

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

Планируем проверку без выдуманного выполнения

В EXPECTED.md запишем ожидаемое: R-001 считается одной принятой и одной пригодной заявкой; R-002 — одной принятой, но неподходящей. Это результат ручного чтения синтетического журнала, а не наблюдение системы аналитики. Программ обработки, браузера и сервера в уроке не запускали.

Если в реальном проекте события дублируются, сначала исследуют причину: повторное нажатие, повторная отправка, повторное подтверждение или сбой интеграции. Удалять все повторения без определения единицы нельзя. Иначе можно потерять действительные разные обращения или скрыть техническую проблему.

Разбираем повтор и незавершённость

Пусть R-001 имеет две записи request_accepted из-за повторной обработки одного запроса. Считать две новые заявки было бы неверно в нашей единице. Но удаление второй строки тоже может скрыть техническую проблему. Поэтому журнал событий и итог заявок выполняют разные роли: первый хранит историю, второй использует согласованное правило уникальности. На практике конкретный способ требует реализации и проверки, которых в уроке нет.

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

Есть и незавершённый случай: заявку приняли, но пригодность ещё не оценили. Он не относится автоматически к неподходящим. В отчёте сохраняется pending, а время решения остаётся неизвестным. Для сравнения периодов нужно учитывать, что ранний снимок содержит больше открытых случаев. Иначе более свежую кампанию можно ошибочно назвать хуже из-за задержки статуса.

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

Сохраняем границы цифры

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

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

Оглавление курса · Исходники серии