Пример диагностики трекинга на вымышленных данных

Сначала: что это такое, а что нет

Всё в этой статье, что выглядит как кейс (магазин, количество заказов, цифры выручки, результат), вымышлено. Оно нужно, чтобы показать метод диагностики и вид документов, которые вы получите. Это не результат клиента, и статья его не заявляет.

Три образца отчётов, ссылки на которые даны ниже, я сделал именно для этого. На каждой странице каждого отчёта стоит пометка «Illustrative sample · Fictional business, data and outcomes» (иллюстративный образец, вымышленные бизнес, данные и результаты). Когда я привожу из них числа, это те самые вымышленные числа, и я ничего не добавлял.

Уточню: я основатель Fixel Pixel, продукта для трекинга в Shopify. Эта статья о методе консультации, а не о продукте. Ничто ниже от него не зависит, а обязательным итогом диагностики продукт никогда не бывает.

Задача

Рекламные платформы продавца на Shopify и его собственный реестр заказов расходятся в том, сколько продано и сколько событий покупки получено. Изнутри любой одной панели понять, какое число верно, если верно хоть одно, нельзя.

В этом вся задача, и она сложнее, чем кажется, потому что ошибка не всегда видна на дашборде. GA4 и Meta могут обе выглядеть нормально, при этом занижая или завышая то, что Shopify на самом деле продал. Расхождение становится видно только при сравнении каждой платформы с заказами.

Ограничения

Три ограничения определяют всё, что идёт дальше, и все три обязательны.

Пока диагностика не завершена, ничего не меняется. Если править пайплайн, не поняв его, вы диагностируете систему, которую только что изменили. Поэтому работа начинается с доступа только на чтение: роль viewer в GA4, Google Ads только на чтение, Meta Events Manager и учётная запись сотрудника Shopify с правами только на чтение. Ничего не правится, пока диагностика не закончена и продавец её не увидел.

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

«Сопоставлено» не может означать одно и то же на каждой платформе. GA4 передаёт ID заказа Shopify как transaction_id, поэтому событие purchase можно связать с заказом, который его породил. Meta даёт собственный event_id, который связывает событие purchase с одним заказом и показывает, что оно посчитано один раз, но выручку по заказам Meta не отдаёт. Google Ads отчитывается суммарно, построчного фида по заказам, который можно прочитать, нет. Для каждой строки в пакете нужно указать, что именно она подтверждает.

Почему очевидный путь не подошёл

Очевидный ход: переустановить пиксель, включить серверный трекинг и считать дело сделанным. Так лечат симптом (число в панели кажется низким или высоким), так и не выяснив, какое число вообще было верным.

Кроме того, так нельзя ответить на просьбу продавца «докажите». За словами «теперь должно быть исправлено» нет цепочки доказательств на уровне заказов, поэтому следующее расхождение между платформами возвращает вас в начало, с ещё одним набором отправителей, в котором нужно разбираться.

Что я делаю вместо этого

Метод состоит из фиксированной последовательности шагов, и порядок важен.

1. Сверка по каждому заказу только на чтение по всем активным платформам (Health Check) с письменным заключением: подтверждённая причина каждого существенного разрыва в границах объёма работ либо то, что остаётся неизвестным, почему и как это проверить. Дефекты, нормальные различия измерения и неподтверждённые гипотезы держатся отдельно. Срок заключения: два рабочих дня после старта работы и подтверждения, что доступа достаточно (Europe/Madrid, выходные не считаются). Если данных не хватает, отсчёт не начался, и я так и говорю, а не продлеваю срок молча. Отчёт остаётся у вас в любом случае, в том числе когда ответ «ничего не сломано».

2. Письменный объём работ и одна фиксированная цена, названные до любых изменений кода, для объёма, определённого достаточно чётко, чтобы его можно было оценить. Реализация идёт отдельной работой.

3. Исправление, подготовленное параллельно с существующей настройкой. Старый трекинг продолжает работать, пока новый путь не доказан на настоящем тестовом заказе, в той последовательности, в которой должны срабатывать события: согласие, затем дедупликация, затем данные для конкретной платформы. Событие purchase, которое срабатывает правильно, но не в той последовательности, всё равно сломано.

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

Дальше я показываю эту последовательность на вымышленном магазине.

Часть 1: аудит (иллюстрация, вымышленные данные)

Первый документ: Sample 01: Measurement Audit (PDF; иллюстрация, вымышленные данные). Допустим, есть магазин с подпиской на продукты питания, торгующий в долларах США, с собственным фидом покупок, который отправляет продажи в набор данных для отчётности. За недельное окно проверки в нём создано 1000 подходящих оплаченных заказов. В принимающем наборе данных находится 1120 строк purchase.

Этот разрыв и есть обнаруженная проблема, но это ещё не диагноз. Аудит соединяет исходные заказы со строками получателя по стабильной ссылке на заказ и, прежде чем что-либо суммировать, проверяет всё, что не сопоставляется один к одному:

Шаг сверки	Строки purchase	Выручка от товаров
Принимающий набор данных, без поправок	1120	$134 400
Минус повторяющиеся строки по 120 заказам	−120	−$14 400
Уникальные подходящие заказы	1000	$120 000
Минус возвраты по тем же заказам до даты отсечения	число заказов не меняется	−$5000
Чистая выручка от товаров на дату отсечения	1000 оплаченных заказов	$115 000

Два разных явления прятались в одной жалобе «выручка слишком высокая». 120 повторяющихся строк оказались подтверждённым дефектом: получатель принял покупку, отправитель так и не получил ответ об успехе, а повторная отправка породила новый идентификатор продажи, и её приняли как ещё одну покупку. Сопоставление по ссылке на заказ выявляет повторы; сопоставление только по идентификатору доставки их скрывает. $5000, напротив, вообще не дефект. Это разница между выручкой от товаров и чистой выручкой от товаров после возвратов, два определения, которые никто не записал.

Третий пункт остаётся открытым намеренно: у 60 заказов нет истории клиента, нужной, чтобы отнести их к первым или повторным покупкам. Аудит говорит оставить их как «неизвестно», а не считать новыми клиентами.

Аудит также называет собственный охват: что проверялось, что тестировалось и что проблема относится к проверенному собственному фиду, а не ко всем рекламным платформам. Затем он передаёт список работ с ответственным и условием приёмки по каждому пункту, план релиза и отката и критерии закрытия: исходная группа заказов сходится к 1000 заказам и $120 000 выручки от товаров, и отдельное окно после релиза тоже сходится.

Часть 2: документация (иллюстрация, вымышленные данные)

Если через полгода никто не сможет найти описание исправления, его могут случайно отменить. Поэтому второй документ, Sample 02: Tracking Documentation (PDF; иллюстрация, вымышленные данные), устроен как реестр систем: каждый компонент, где он находится, кто им владеет, за что отвечает и, что не менее важно, чего не делает.

Описание события purchase не даёт дефекту вернуться. В примере оно задаёт: стабильный идентификатор продажи на заказ и получателя, сохраняющийся при повторных отправках, поэтому тайм-аут с последующей повторной отправкой даёт одну строку продажи; время события, которое не сдвигается при повторе; выручку после скидок и до возвратов, без налога и доставки; статус клиента «первый», «повторный» или «неизвестно»; корректировки возвратов как отдельные записи, привязанные к заказу, которые никогда не отправляют вторую покупку.

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

Часть 3: решение и проверка (иллюстрация, вымышленные данные)

Третий документ, Sample 03: Issue Resolution & Validation (PDF; иллюстрация, вымышленные данные), разбирает две проблемы отдельно, потому что у них разные причины.

Вопрос про $5000 решается без изменения какой-либо конфигурации трекинга. В обоих отчётах одни и те же 1000 заказов; исправленное представление покупок даёт $120 000; финансы вычитают $5000 возвратов по тем же заказам до даты отсечения; и $120 000 − $5000 = $115 000 оставляет необъяснённую разницу, равную нулю. Решением становятся два сохранённых представления, «выручка от товаров» и «чистая выручка от товаров», с видимой датой отсечения возвратов.

Дефект повторной доставки обрабатывается в том порядке, в котором я работаю с любым дефектом:

1. Сопоставьте заказы со строками получателя. У 880 заказов по одной строке, у 120 по две, и каждая повторяющаяся строка совпадает со значением исходного заказа.
2. Проследите механизм. Первая доставка была принята, ответ на неё истёк по тайм-ауту, а повторная отправка использовала новый идентификатор продажи.
3. Воспроизведите до изменения кода. Тестовый набор из 1000 заказов со 120 случаями «принято, затем тайм-аут» даёт 1120 строк.
4. Исправьте и повторите тот же тест. 1000 строк, а разные заказы по-прежнему создают отдельные продажи.
5. Выпустите и скорректируйте отчётность. Исключите 120 доказанных повторяющихся строк из представления для отчётности; сохраните исходные строки и причины исключения.
6. Проверьте после запуска и закройте задачу. Отдельная группа с завершённой обработкой данных из 250 оплаченных заказов после релиза сходится с 250 строками получателя без необъяснённой разницы в стоимости товаров.

В таблице закрытия сравниваются «до» и «после», а в чек-листе отмечены пройденные проверки. Нерешённым остаётся один пункт: 60 классификаций клиента «неизвестно», которые не открывают заново решённый дефект.

Как я проверяю это в реальных внедрениях

Вымышленный пример аккуратный. Настоящие магазины таковыми не бывают, и метод построен с расчётом на это.

Соединение всегда идёт с реестром заказов Shopify, по одной строке на заказ с его выручкой. Сначала я смотрю на строки, которые не сопоставляются один к одному: пропущенные, повторяющиеся или с другим значением. Суммирую только после этого, потому что итог может оказаться верным случайно.

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

Старая реализация выводится из работы, только когда новая доказала себя на реальном трафике, и у каждого изменения есть путь отката. Если в течение месяца после приёмки поведение в пределах согласованного объёма начнёт меняться, я проверю причину.

Что метод может и чего не может доказать

Заявленное ограничение заложено в самом методе, а не набрано мелким шрифтом.

Google Ads отчитывается суммарно, поэтому сравнение там идёт между заказами, которые должны были дать конверсию, и конверсиями, сообщёнными за то же окно; данные по каждому заказу есть только там, где вы сами контролируете загрузку конверсий. Сопоставление по каждому событию в Meta показывает, какие события purchase пришли и посчитаны один раз, но выручку по заказам оно не видит. Пакет доказательств говорит, какое сравнение поддерживает каждая строка, а не подразумевает паритет между платформами, которого нет.

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

Окно Health Check в 30 дней служит базовым периодом, а не обещанием полной истории. Заключение называет подтверждённую причину, если она есть, а если нет, говорит, что остаётся неизвестным и как это проверить.

Ещё раз, чтобы не поняли неправильно

Магазин, числа и результат выше вымышлены и подобраны, чтобы показать метод. Эта статья демонстрирует, как я работаю. Она не доказывает результат ни для какого клиента, а три PDF остаются образцами формата и рассуждений, а не записями о работе.

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

Источники этой статьи

Метод тот, что описан на этом сайте, а разобранный пример опирается на трёхчастный набор образцов. Больше ничего не использовалось.

• Методология: диагностика, исправление, подтверждение: путь работы, стандарт сдачи и раздел «Как работает сопоставление».
• Sample 01: Measurement Audit (PDF): иллюстрация, вымышленные данные.
• Sample 02: Tracking Documentation (PDF): иллюстрация, вымышленные данные.
• Sample 03: Issue Resolution & Validation (PDF): иллюстрация, вымышленные данные.