Технический минимум маркетолога: что уметь руками до первого проекта

Вы ведёте рекламу в Meta для магазина бытовой техники в Алматы. Владелец присылает скриншот: «Вчера картой оплатили один заказ, T-312 на 62 000 ₸, а в Events Manager две покупки. Реклама считает дважды?» Ответ «это Meta так считает» его не устроит, а звать разработчика по каждому такому вопросу дорого. Магазин и цифры в уроке условные.

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

Один заказ, два пути отправки

T-312, 62 000 ₸

Браузер
Открыта страница «Спасибо»
Purchase
Сервер
Оплата подтверждена
Purchase

Две записи, одна продажа.

Заказ T-312 и две отправки Purchase: из браузера после открытия страницы «Спасибо» и с сервера после подтверждения оплаты.

Минимум в одной таблице

Что уметь	Что делать самому	Где учиться и тренироваться
Метки в ссылках	Собрать ссылку по схеме, прочитать чужую и найти ошибку в `utm_source` или `utm_medium`	UTM-метки, конструктор UTM
Google Tag Manager	Создать тег, триггер и переменную, поймать событие из dataLayer, пройти предварительный просмотр	GTM, упражнения 1 и 2 в тренажёре
GA4	Создать ресурс и поток, отметить ключевое событие, найти `generate_lead` в DebugView	GA4
Пиксель Meta	Отправить `Lead` и увидеть его в «Тестировании событий»	Пиксели и конверсии
Задача разработчику	Описать событие: когда срабатывает, с какими параметрами, где его проверить	Спецификация dataLayer
Чтение кода	Прочитать `dataLayer.push`, понять, какие поля и в каком виде уходят, и поправить готовый код	Упражнение 1 в тренажёре; 3-6 - для тех, кто хочет писать код сам, это следующая ступень
Таблица и метрики	Посчитать CPL, цену оплаты и ROAS по выгрузке, свести кабинет со списком заявок	Метрики и формулы, глоссарий
Путь до оплаты	Связать заявку из рекламы с оплатой в CRM	Сквозная аналитика
Браузер и сервер	Понимать, что отправляет браузер, что сервер и как Meta и GA4 убирают дубли	Серверный трекинг, Conversions API

Первые пять строк - это неделя 1 трека «Старт»: схема UTM, событие формы в тренажёре, свой GA4, пиксель Meta и ТЗ на три события. Метрики с формулами выписывают на неделе 0, заявки в CRM заводят на неделе 3, окупаемость считают в калькуляторе на неделе 4. Тренажёр работает прямо в браузере, аккаунт GTM для него не нужен. Конструктор UTM сам приводит метки к нижнему регистру, заменяет пробелы подчёркиваниями, переводит кириллицу в латиницу и не трогает макросы Meta вроде {{site_source_name}}. Пресеты Meta, Google и Telegram подставляют source и medium по схеме из урока про UTM, а кампанию впишите свою: spring_2026, brand_search и channel_post стоят в них для примера.

Чего в минимуме нет

Серверный код, серверный контейнер GTM, интеграции с CRM по API и SQL-запросы к выгрузке GA4 в BigQuery для первых проектов не нужны. Это работа разработчика или следующая ступень. Но такие схемы нужно уметь узнать и задать о них правильные вопросы. В магазине техники покупку с сервера отправляет код, который написал разработчик, а маркетолог должен понимать, что этот путь есть, и не принять его за ошибку.

Граница проходит по ответственности. Маркетолог описывает, что должно произойти, и проверяет, что произошло. Разработчик меняет код сайта и сервера. Задача без описания вроде «аналитика врёт» вернётся к вам с вопросами, а проверка без маркетолога заканчивается на «тег сработал».

Разбор: две покупки на заказ T-312

Разберём по шагам, что ответить владельцу.

Бизнес-событие. В базе магазина один заказ T-312, оплаченный картой на 62 000 ₸. С ним сверяют всё остальное: сколько бы записей ни было в кабинете, продажа одна.

Откуда записи. Пиксель Meta стоит на странице «Спасибо» и отправляет Purchase из браузера. Сервер магазина отправляет ту же покупку через Conversions API, когда платёжный сервис подтвердил оплату. Ради второго пути магазин и настроил S2S-трекинг: покупатель заказа T-310 закрыл вкладку раньше, чем открылась страница «Спасибо», и без сервера Meta не узнала бы о покупке. Покупатель T-312 страницу дождался, поэтому записей две. Это два пути одной покупки.

Что показывает счётчик. В общем числе полученных событий в Events Manager браузерные и серверные просто сложены, без дедупликации. Если работают оба пути, две покупки там на один заказ - ожидаемая картина.

Объединила ли их Meta. Браузерное и серверное событие Meta считает одним, если у них совпадают название и event_id (дедупликация пикселя и Conversions API) и второе пришло в течение 48 часов после первого. Как дедупликация работает в целом, видно на вкладке «Дедупликация событий»: какая доля событий из браузера и с сервера пришла с ключом дедупликации и насколько они пересекаются. Одну живую покупку в Events Manager не найти, поэтому проверяют на тестовом заказе в «Тестировании событий»: там видно, какое событие обработано, а какое отброшено как дубль. Серверное событие появится там, только если разработчик отправит его с кодом test_event_code из этой вкладки, а из боевых отправок код потом убирают (тестирование серверных событий). События с этим кодом Meta не выбрасывает: тестовая покупка попадёт в статистику и измерение рекламы, поэтому хватит одного заказа.

Ответ владельцу. «Две записи на один заказ - это нормально, если Meta оставила одну из них. Сегодня проверим это на тестовом заказе вместе с разработчиком. Если у браузера и сервера окажутся разные event_id, это ошибка настройки, и тогда Meta может посчитать покупку дважды».

В GA4 у той же задачи своё правило: покупки с одинаковым transaction_id GA4 засчитывает один раз, но только в веб-потоке. Покупку и её параметры там смотрят в DebugView, как советует руководство Google по проверке ecommerce.

Задача разработчику, которую можно повторить

Допустим, на тестовом заказе оба Purchase оказались обработанными. Сообщение «аналитика задваивает покупки» разработчик проверить не сможет. Такое сможет:

Где: сайт магазина, страница «Спасибо» и серверная отправка оплаты.

Что сделали: в 15:20 оформили тестовый заказ при открытом «Тестировании событий», разработчик отправил по нему серверное событие с test_event_code.

Что ожидали: один Purchase обработан, второй отброшен как дубль.

Что увидели: оба Purchase обработаны. В браузерном event_id случайная строка, в серверном номер заказа.

Что нужно: передавать в пиксель тот же event_id, что уходит с сервера.

Приложено: скриншот «Тестирования событий», телефон и имя покупателя закрашены.

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

Упражнение: свой минимум на тестовом сайте

Возьмите тестовый сайт с недели 1 трека «Старт» или любой сайт, где у вас есть доступ к GTM. По каждой строке таблицы сохраните одно доказательство, которое можно показать: ссылку, скриншот или файл.

Выполнено 0 из 9

Ссылка с метками по схеме и тот же переход в отчёте GA4 с источником и каналом.
Скриншот предварительного просмотра GTM, где тег заявки сработал по событию из dataLayer.
Скриншот generate_lead с параметрами в DebugView.
Скриншот Lead в «Тестировании событий».
ТЗ на три события сайта на одной странице.
Упражнения 1 и 2 в тренажёре, пройденные без открытия эталона (3-6 по желанию).
Таблица теста с CPL, где заявки взяты из вашего списка, а расход из кабинета.
Заявка с тестового сайта в таблице заявок с источником и статусом.
Абзац для владельца магазина техники: почему две покупки на один заказ - ещё не ошибка и как это выяснить.

Сначала пересмотрите второй скриншот. Если тег сработал по клику на кнопку, а не по событию из dataLayer, он считает нажатия, в том числе на форму, которая вернула ошибку. Отправьте форму с пустым email: generate_lead прийти не должен. Последний пункт проверяет, умеете ли вы объяснить то, что знаете. В абзаце для владельца нужны три мысли: записи пришли двумя путями, общий счётчик Events Manager дубли не убирает, а остался ли в итоге один Purchase, покажет тестовый заказ: если event_id совпадает, одно событие будет отброшено. Пункт, который не получился, подсказывает следующий урок: он стоит в той же строке таблицы.