Качество рекламных обращений

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

Вся модель «Линии» синтетическая. Для учебного набора A сохранены 40 принятых заявок: 16 пригодных, 12 о разработке, 8 с ожиданием гарантии продаж и 4 пока без решения. Это вымышленная полная сводка набора, а не реальная выгрузка. Небольшой sample-requests.csv показывает лишь примеры строк и не выдаётся за все сорок записей.

Определяем критерий пригодности

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

Запрос «дайте гарантию удвоения продаж» также не соответствует предложению. Аудит не обещает такой эффект. Причину запишем как expectation_mismatch, а не как недействительный трафик. Человек может быть настоящим и заинтересованным, но ожидать другого результата. Это вопрос сообщения и продукта, который нельзя автоматически объявить мошенничеством.

Четыре незавершённых обращения остаются pending. Их нельзя прибавить к пригодным или неподходящим до решения. Поэтому 16/40 описывает долю подтверждённо пригодных среди всех принятых в нашем заданном наборе, а не окончательную долю после закрытия всех случаев. Период и полнота статусов должны быть заметны.

Читаем причины по отдельности

Статус набора A	Количество	Значение
qualified	16	Предмет AUDIT-ONE подтверждён
not_fit_development	12	Нужна разработка
expectation_mismatch	8	Ожидается гарантия продаж
pending	4	Решение ещё отсутствует
Всего принятых	40	Полный синтетический набор

У каждой причины может быть другой следующий шаг. Разработка требует проверить, не обещает ли картинка готовый сайт. Гарантия продаж требует проверить формулировку пользы. Pending требует завершения определения статуса, а не немедленного изменения рекламы. Общая строка «плохие лиды» теряет эти различия.

Сохраняем связь без личных сведений

В sample-requests.csv используем R-A-001 и другие вымышленные идентификаторы. Нет имён, телефонов и адресов настоящих страниц. Поле reason описывает предмет задачи, а не характеристику личности. Это уменьшает риск превращения разбора кампании в оценку людей.

{
  "request_id": "R-A-001",
  "fictional": true,
  "offer": "AUDIT-ONE",
  "status": "qualified",
  "reason": "existing_page_and_report_expected",
  "payment_received": null
}

Google различает бизнес-действия и настройки conversion actions; при будущей передаче результата нужно отдельно согласовать механизм и назначение события. Полезное основание — официальная справка. Наш собственный qualified не становится автоматически основной конверсией кабинета и не означает передачу данных.

Сопоставляем качество и расход

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

У набора B расход 5000, пятьдесят принятых и пятнадцать пригодных. Стоимость принятой также 100, но пригодной — около 333,33. Сравнение только обычной заявки скрывает разницу. Однако эти числа не доказывают реальную эффективность A или B: они вымышлены и не являются результатом эксперимента.

В модели восемь пригодных обращений A и семь B отмечены как согласованные по объёму. Согласование не является оплатой или выполненной услугой. Поэтому revenue остаётся неизвестным. Нельзя умножить число согласований на учебные 5000 и представить произведение как фактическую выручку.

Разбираем пересмотр конкретного обращения

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

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

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

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

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

Проверяем изменения определения

Если позже студия добавит внедрение, часть запросов разработки может потребовать пересмотра. Но изменение предложения не должно задним числом исправлять прежний отчёт без пояснения. Старые результаты относятся к AUDIT-ONE той версии, которую видели люди. Новый паспорт получает отдельный ID или версию.

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

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

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