Заказы Маркета в аналитике: исключите тесты по полю fake

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

Найдите признак в исходном ответе

В документации метода «Информация о заказах в кабинете» поле fake описано и как фильтр запроса, и как поле заказа в ответе: true означает тестовый заказ, false означает настоящий заказ покупателя. Метод доступен для всех моделей работы.

Для отбора настоящих заказов задают "fake": false в теле запроса POST /v1/businesses/{businessId}/orders. Это фрагмент условия отбора, а не полный готовый запрос: остальные параметры, авторизацию и структуру ответа сверяйте с текущей документацией метода.

Не определяйте тест по названию товара, нулевой сумме или знакомому номеру. Для этой задачи используйте документированный признак типа.

Сохраните тип до объединения данных

Возьмите уже полученный ответ API или его сохранённый образец. Найдите известный тестовый заказ по идентификатору. Проследите, куда при загрузке попадает его fake: отдельная колонка, поле хранилища или правило фильтрации.

Проверьте, что логическое false не теряется как «пустое значение». Если промежуточный файл превращает логические значения в текст, документируйте это преобразование. Строка "false", логическое false и отсутствующее поле требуют осознанной обработки, а не проверки «поле непустое».

Отсутствующий признак не объявляйте автоматически настоящим заказом. Сначала установите, был ли он в исходном ответе и не потерялся ли при преобразовании. До выяснения выделите такие записи в отдельную контрольную группу.

Сверьте состав отчёта

Для одного и того же магазина, периода и набора статусов сравните список уникальных идентификаторов до фильтра и после него. Рабочий набор должен содержать записи с подтверждённым fake = false; тестовые и записи с неразобранным типом храните отдельно.

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

Зафиксируйте границы проверки

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

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