Сквозная атрибуция для двух Shopify-магазинов: от клика до заказа

Метку клика пришлось снимать в самой теме

Штатный путь — Web Pixel — не сработал: в песочнице Shopify он не пишет cart attributes, то есть метка клика просто не доезжает до заказа. Пришлось ловить её в самой теме магазина и дублировать собственным идентификатором визита (vid), чтобы связь клик↔заказ держалась даже там, где штатный механизм её теряет.

Middleware: HMAC по каждому магазину, дедупликация на входе

Собственный промежуточный сервис на http.server принимает уведомления Shopify и делает четыре вещи:

• проверяет HMAC-подпись — отдельным секретом для каждого из двух магазинов
• дедуплицирует события: Shopify повторяет доставку, отчёт от этого не должен расти
• передаёт данные с сервера в трекер: lead — обращение на каждый уникальный клик, sale — продажа с суммой на заказ
• пишет каждое событие воронки в собственный JSONL — гранулярный путь сохраняется там, где трекер уже только агрегирует

Conversions API: события схлопываются, а не задваиваются

Одновременно с передачей в трекер сервис отправляет с сервера Purchase в Facebook Conversions API — с тем же event_id, что и браузерный пиксель. Это ключевая деталь: без общего идентификатора вы получаете не восстановленную атрибуцию, а удвоенные конверсии в кабинете и оптимизацию по выдуманным цифрам.

Identity-граф вместо last-click

Отдельная база SQLite склеивает клик, покупателя и заказ по ksubid, хешу e-mail и checkout_token, с обратной привязкой к первому клику. Поверх этого графа — слой отчётов, который отвечает на вопросы, на которые нельзя ответить, если учитывать только последний клик:

• мультитач-путь покупателя и распределение заслуги между каналами
• роль канала: открывает / догоняет / закрывает
• LTV по каналу — а не разовая выручка первого заказа
• «победы атрибуции»: витрина сказала Direct, трекер поймал платный источник
• сшивка с post-purchase опросом «откуда узнали» — независимая проверка модели

Расход выгружается ежедневно — иначе окупаемость считается без затрат

Половина проектов по атрибуции ломается на банальном: выручка по каналу есть, а расход остался в кабинете. Расходы по кампаниям тянутся по расписанию из Google Ads API и Meta Marketing API прямо в трекер, поэтому цена продажи по каналу — не ручная сверка раз в месяц, а поле в отчёте.

Только стандартная библиотека

Весь контур написан на urllib, http.server и sqlite3 — без единой внешней зависимости. Причина прозаическая: код обязан работать на боевом сервере, где нет pip. Побочный эффект — нечему устаревать и нечего обновлять по сообщениям об уязвимостях.

Два дефекта расчёта, которые ломали доверие к отчёту

Первое, что дал контур, — возможность сверить отчёт с реальностью, и сверка сразу нашла две ошибки. Отменённые заказы попадали в выручку: на одном дне это давало завышение на 25,7% и, что хуже, выставляло отменённый заказ «победой атрибуции». Промокоды не вычитались — ещё 5,74% сверху. Оба дефекта закрыты; дневной отчёт перестал расходиться с реальной выручкой.

Цена продажи по каналу изменила решение по бюджету

Когда расход по кампаниям и отслеженные продажи сошлись в одном отчёте, картина оказалась неприятно чёткой: при ~186 тыс. кликов с Facebook — ни одной отслеженной продажи, тогда как все отслеженные продажи месяца пришли с YouTube при ~12 тыс. кликов. Владелец бизнеса на этих данных выключил FB-плечо и перераспределил бюджет. Это ровно та ситуация, ради которой строится атрибуция: не «красивая панель с графиками», а одно управленческое решение, которое без цифр не принимается.

Треть выручки без источника оказалась не багом трекинга

Около трети веб-выручки одного из магазинов приходила без источника — и правильный ответ здесь был не «чинить пиксель». Причина оказалась внешней: баннер согласия на куки блокировал сессию Shopify до нажатия кнопки согласия, то есть источник терялся ещё до того, как до него доходила очередь у аналитики. Диагноз подтверждён A/B-сравнением двух витрин и историческим прецедентом второго магазина — а не догадкой.