Владелец интернет-магазина кофе в Алматы сравнивает пять дней до новой настройки аналитики и пять дней после. В отчёте 90 заказов вместо 60, и он пишет вам в WhatsApp: «Продажи выросли наполовину, можно добавить бюджет». Вы открываете CRM: там в обоих периодах по 100 оплаченных заказов, обычные для магазина 20 в день, около 140 в неделю. Продавать больше магазин не стал, он просто начал видеть то, что продавал и раньше. Добавите бюджет по такому отчёту - потратите больше денег, а повода для этого как не было, так и нет.
Магазин тот же, что в уроке об удержании: заказ 15 000 ₸, после товара и доставки остаётся 6 000 ₸. Сверку мы придумали для этого урока, все цифры в примере условные. Но ваша работа начинается не с отчёта, а с вопроса, ради которого вы открыли статью про настройку аналитики.
Пять дней до и пять дней после настройки
| Заказы | До | После |
|---|---|---|
| Оплачено в CRM | 100 | 100 |
| Учтено в аналитике | 60 | 90 |
Изменилась полнота учёта уже существующих продаж.
Откройте статью под задачу
В Academia легко провести вечер: прочитать про CRM, перейти по ссылке к событиям, оттуда к рекламе. Утром у вас три идеи и ни одного решения. Лучше приходить с записью из работы, например: «В CRM есть оплаченные заказы, которых я не нахожу в отчёте по каналам». Тогда статья нужна для дела: найти, почему заказы теряются, и понять, как это исправить.
У задачи должен быть человек, который ждёт результат, и решение, которое он по этому результату примет. В магазине бюджет на рекламу выбирает владелец, заказы сводите вы, отправку событий меняет разработчик. Сверку вы можете довести до конца сами, а рост продаж - другая работа, и делаете её не только вы. Скажите это владельцу заранее. Так вы договоритесь, за что он вам платит, и через месяц с вас не спросят выручку, на которую сверка не влияет.
Если своего проекта нет, возьмите тестовый сайт из трека «Старт». На нём можно отправить заявку, вызвать ошибку формы и сохранить скриншоты. В заметке напишите, что сайт тестовый. Для кейса о настройке таких данных хватит, а выдумывать выручку чужого бизнеса незачем: первый же заказчик спросит, откуда цифры.
Запишите проверку четырьмя строками
HADI расшифровывается как Hypothesis, Action, Data, Insights: гипотеза, действие, данные и вывод. Это порядок, в котором вы идёте от вопроса к ответу. Карточка ниже описывает техническую проверку: результат в ней подтверждают сценарии, которые можно повторить, и сверка заказов. Если же вы хотите понять, как изменилось поведение покупателей, нужен план эксперимента.
| Шаг | Что записать для магазина |
|---|---|
| H, гипотеза | Часть оплаченных заказов теряется по дороге в аналитику; сначала найдём, что общего у пропавших |
| A, действие | Сопоставим заказы по ID, воспроизведём найденную ошибку и исправим отправку там, где она возникает |
| D, данные | Заказы со статусом оплаты в CRM, события с теми же ID, пропуски, дубли и несовпадения сумм |
| I, вывод | Какие сценарии исправлены, что осталось несверенным и можно ли решать про бюджет по этому отчёту |
«Поставим новый инструмент» в первую строку не годится: в этой фразе нет причины ошибки. Допустим, два заказа уходят с одним ID. Перенесёте отправку на сервер, и они склеятся точно так же. Сначала найдите один заказ, на котором можно показать, где ID поменялся или пропал.
Карточка может измениться после чтения. Вы подозревали сбой отправки, а нашли другое: у CRM и отчёта разные часовые пояса, и поздние оплаты уехали в соседний день. Тогда исправлять надо период сравнения, а технология из заголовка статьи может и не понадобиться.
Сверка начинается с одинаковых заказов
В CRM магазина есть созданные, оплаченные, отменённые и возвращённые заказы. Для сверки берите только оплаченные, без отмен и возвратов, за один период, в одном часовом поясе и одной валюте. Потом ищите каждую оплату в аналитике по ID заказа. Итоги совпадут и тогда, когда пропуски и дубли уравновесили друг друга, поэтому сверяют список ID, а не итог.
В рабочей таблице одна строка на заказ: ID, время оплаты, сумма в CRM, сумма в аналитике и причина расхождения. Телефоны и имена покупателей сюда не выгружайте: для сверки они не нужны, а таблицу потом будут пересылать разработчику. Несовпадения сумм отметьте отдельно. Событие могло прийти, но с ценой одного товара вместо всего заказа.
Из 100 заказов сначала нашлись 60, после исправления 90. Если все найденные ID уникальны, доля учёта выросла с 60% до 90%, то есть на 30 процентных пунктов. Относительный рост: (90 - 60) / 60 = 50%. Вот откуда у владельца «выросли наполовину». Эту цифру можно ставить рядом с полнотой учёта, но продаж по CRM как было 100, так и осталось.
Для простоты пусть каждый заказ в сверке стоит 15 000 ₸. Тогда в CRM в обоих периодах 1 500 000 ₸ выручки. Аналитика сначала показывает 900 000 ₸, потом 1 350 000 ₸. Разница в 450 000 ₸ появилась в отчёте, а на счёт магазина таких денег не пришло. Вклад 100 заказов тоже не изменился: 600 000 ₸ до остальных расходов.
Определите, когда работа закончена
Срок у исправления сбора событий задают сценарии и проверка на рабочих данных. До начала работы перечислите все способы оплаты и случай, когда одно событие приходит дважды. Назначьте, кто отвечает за сверку, и договоритесь, что делать с расхождениями, которые останутся. После исправления пройдите этот список ещё раз вместе с разработчиком.
После наших 90 совпадений осталось десять пропусков. Разнесите их по причинам: заказ ещё в обработке, передача сорвалась, ID отличается или событие для этого сценария вообще не настроено. Работа закончена, когда выполнен критерий приёмки, о котором договорились заранее. То, что 90% выглядят лучше 60%, задачу не закрывает. Если часть заказов так и останется вне аналитики, опишите эту границу рядом с отчётом, чтобы владелец не принял 90 за все продажи.
У повторной покупки свой срок. Магазин считает её за 60 дней от первой оплаты. Напоминание уходит через 21 день после доставки, а итог ждут, пока закроются окна всех участников. За неделю вы узнаете, правильно ли отправляются сообщения, но ответа про повторные заказы за 60 дней к этому моменту не будет. Поэтому срок теста удержания считают до запуска.
Оставьте запись, к которой можно вернуться
Хорошая запись после сверки помещается в абзац: «По 100 оплаченных заказов в каждом периоде. В аналитике найдены 60 и 90, дублей среди них нет. Исправлена ошибка отправки в описанном сценарии. Десять оставшихся пропусков разбираем по ID. Выручка по CRM не изменилась». К ней приложите таблицу и шаги, по которым ошибку можно повторить.
С такой запиской владелец знает, что делать с отчётом. Вы продолжаете разбирать пропуски, разработчик получает случаи, которые можно воспроизвести, а бюджет обсуждают по расходу, оплатам и вкладу из CRM. Следующую статью вы откроете под следующий незакрытый вопрос и добавите ссылку на неё в ту же карточку.
Задание: карточка по своей статье
Выберите одну статью Academia, которая нужна вам для текущей задачи. Запишите проблему словами заказчика, решение, которое он примет, и четыре строки HADI. Укажите источник данных, что именно считаете (заказ, заявку, оплату), срок и критерий окончания. Если проект тестовый, отметьте это в первой строке.
Потом ответьте владельцу из начала урока на его «Продажи выросли наполовину, можно добавить бюджет». В ответе должны быть обе суммы выручки по аналитике, сумма по CRM и следующий шаг.
Аналитика показывала 900 000 ₸, теперь показывает 1 350 000 ₸, а в CRM в каждом периоде по 1 500 000 ₸. Продажи не выросли, вырос учёт. Решать про бюджет по этим данным рано: в условии нет ни расхода, ни связи заказов с каналами. Следующий шаг в карточке - разобрать десять пропусков и свести подтверждённые оплаты с расходом. Владельцу можно написать примерно так: «Заказов столько же, просто теперь аналитика видит 90 из 100. Про бюджет поговорим, когда я сведу оплаты с рекламой по каналам». Такой следующий шаг другой человек сможет проверить и принять.