Shopify-магазин онлайн-курсов продаёт разными способами: разовые покупки, рассрочки, подписки с бесплатным пробным периодом, апселлы. Параллельно идёт лидогенерация: формы и попапы Klaviyo и Alia, запись на звонки через Calendly. Реклама в Meta и Google Ads, атрибуция в Triple Whale. Заказчик из Вьетнама.
Запрос клиента: старт пробного периода не доходил до Meta и Triple Whale, Purchase передавал неверную ценность, у лидов не было серверной отправки.
Что показал аудит:- Purchase уходил в Google Ads из трёх источников: нативное приложение, пользовательский пиксель и GTM.- Purchase в Meta отправляли и нативное приложение Facebook & Instagram, и GTM из песочницы Custom Web Pixel, каждый со своим event_id.- Покупки через Shop Pay проходили мимо трекинга чекаута.- Старт пробного периода создавал заказ на $0, и кампании на максимум ценности получали конверсии с нулевой ценностью.- Лиды отправлялись только из браузера, без Conversions API. event_id был только у половины событий.- Серверный GTM был создан, но хостинг не развёрнут. В веб-контейнере лежали 25+ устаревших скриптов.
Что сделано:- Развёрнут серверный GTM на Stape на собственном поддомене. У него 5 точек входа: браузер, Shopify Flow (все заказы, включая Shop Pay и продления подписок Appstle), вебхуки Klaviyo и Calendly, лендинг GoHighLevel (этот старый лендинг в ходе работ перенесли на основной домен, но возможность оставлена, если владелец решит вернуться к его рекламе).- На витрине собираются все необходимые идентификаторы рекламы, и через атрибуты корзины они переносятся в заказ.- Настроена нормализация на сервере - у события одно каноническое имя, а распределение по платформам задаётся таблицей. Новое событие добавляется строкой в таблице, а не новым тегом.- Ценность пробного периода: в Meta и Google Ads уходит стоимость плана с коэффициентом удержания, в GA4 полная стоимость. Пробный период определяется по плану подписки, а не по нулевой сумме.- В Meta уходят 8 хешированных параметров, в Google Ads полный адресный блок для Enhanced Conversions.- Настроена дедупликация покупок: event_id - это номер заказа, общий для браузерной и серверной половин.- Triple Whale был установлен корректно через нативное приложение, в его работу не вмешивалась. Для улучшенного сопоставления заявок с сайта дополнительно настроен вебхук в Triple Whale с сервера через Data-In API.- Внедрён Consent Mode v2 с отдельными настройками для ЕС и Великобритании.
Лидогенерация:- Формы и попапы Klaviyo и Alia и запись на звонки в Calendly переведены на серверную отправку: Lead в Meta, lead в Google Ads.- Рекламные идентификаторы хранятся в браузере 30 дней и сохраняются при переходах между страницами до отправки заявки.- event_id генерируется в браузере и проходит всю цепочку, поэтому он одинаковый в Meta и Google Ads.- В Calendly (внешний домен) ID рекламных кликов передаются через параметр ссылки, а вебхук возвращает их на сервер. По типу встречи определяется событие: запись на звонок или VIP-заявка.- Каждый тип заявки получает условную ценность. Соотношение ценностей не даёт алгоритму учиться на дешёвых массовых заявках.- В GA4 заявки идут из браузера, в рекламные платформы - только с сервера.
Проверка шла на реальных заказах и заявках, по логам серверного контейнера. Проверены покупки из Meta, Google, email-рассылки и прямых заходов; оплата через Shop Pay и Apple Pay, апселл; встроенные браузеры Instagram и Facebook; пробный период за $0 и за $1; заявки из форм и попапов. Все события приняты платформами, event_id совпадает, пустые поля не уходят. Это был очень сложный проект - я его недооценила. Но заказчик был терпелив и стоек. Проект завершили, остались незакрытые вопросы, но они зависят от разработчиков.