Как поддерживать план трекинга, когда события меняются

В старом сценарии приложение отправляет purchase_completed, когда сервер подтверждает оплату. В новом сценарии рассрочки разработчик использует то же событие после одобрения заявки. Деньги в этот момент ещё могут не поступить, а заказ позже может быть отменён.

Обе реализации передают order_id, amount иpayment_method с нужными типами. Проверка структуры пройдёт. Но отчёт, который считает по этому событию оплаченные заказы, начнёт складывать покупки и одобренные заявки.

Исправлять нужно описание действия и реализацию. Простое добавление нового значения в список способов оплаты эту проблему не решит.

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

{
  "event": "purchase_completed",
  "trigger": "Сервер подтвердил полную оплату заказа",
  "must_not_fire": [
    "Заявка на рассрочку одобрена, но заказ не оплачен",
    "Пользователь повторно открыл экран результата"
  ],
  "deduplication_key": "order_id",
  "parameters": {
    "order_id": "Обязательная строка; ID заказа на сервере",
    "amount": "Обязательное целое; полная сумма заказа в копейках",
    "payment_method": "Обязательная строка: card или installment"
  }
}

Рядом с записью нужны владелец решения, затронутые отчёты и версии приложения, для которых действует правило. Версию описания и версию приложения лучше хранить отдельно: один документ может применяться к нескольким сборкам.

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

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

Поэтому изменение принимают вместе с правилами перехода. В нашем примере возможны два разных решения.

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

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

1. Заказ оплачен картой. Событие приходит после подтверждения сервера; его order_id совпадает с заказом, а сумма соответствует согласованному определению.
2. Рассрочка одобрена, но оплаты ещё нет. Событие покупки не приходит. При последующей полной оплате оно появляется.
3. Экран результата открыт повторно. Приложение не создаёт новую покупку с тем же order_id.
4. Сеть пропала перед отправкой. После восстановления соединения проверяют доставку события и повторные записи. Ожидаемое поведение зависит от используемого SDK.

Проверка на устройстве подтверждает эти сценарии в конкретной сборке. После выпуска нужна проверка потока: какие версии отправляют событие, есть ли повторы по заказу и какая доля оплаченных заказов находится в аналитике. Перед сравнением нужно уравнять состав заказов и учесть задержку доставки событий.

Здесь также проявляется предел автоматической проверки схемы. Она может найти отсутствующий order_id или неверный тип суммы. Чтобы обнаружить отправку до оплаты, нужно сопоставление с состоянием заказа либо воспроизведение сценария. Одного каталога параметров для такого вывода недостаточно.

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

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

Выберите событие, которое команда сейчас меняет и по которому уже строится отчёт. Допишите условия отправки, исключения и правило устранения повторов. Затем попросите разработчика и аналитика независимо объяснить, в какой момент оно должно прийти.

Если ответы различаются, вы нашли проблему до выпуска. Если совпадают, проверьте сценарии на устройстве и сохраните результат рядом с версией описания. После релиза сравните ожидание с поступившими событиями. Для AppMetrica этот шаг разобран в отдельной инструкции.