M8 · 22.10 · цели покупки и заказы

Главная · Все таблицы · Исследования

M8 — цели покупки и уникальные заказы Битрикса

Уточнение после M9: избыток достижений и отсутствие ecommerce в части визитов не оценивают качество ML-прогноза. Для этого отдельно проверены связь с покупкой и порядок событий: M9, Gerard Darel. Сильная связь двух SN-покупок есть, но примерно90% первых регистраций SN в визитах с обоими событиями находятся после ecommerce; время внутреннего расчёта модели неизвестно.

Срез получен 22.10.2026. Периоды: 01.01–30.09 включительно 2025 и 2026; весь трафик трёх сайтов, Москва.

Подтверждённый вывод: достижения ecommerce, автосбора и Sales Ninja считают разные события. Их нельзя складывать или использовать как взаимозаменяемое количество заказов. Ecommerce допускает точную сверку по номеру; у автосбора и Sales Ninja номер заказа в goalsOrder не заполнен ни в одном сохранённом достижении.

У Sales Ninja в 2026 число достижений основной цели в 3,98–6,79 раза больше созданных заказов Битрикса. Даже число целевых визитов больше числа заказов. Это не доказывает дубли заказов или ошибку модели: фактическое условие отправки требует проверки. Автосбор виден только с июня/июля 2026, поэтому его итог не отражает полное покрытие девяти месяцев.

1. Достижения целей по Reports API

Единица всех пяти столбцов целей — достижения, включая повторные. Битрикс — уникальные номера созданных заказов, включая неоплаченные и отменённые, без 19 текущих тестовых статусов A/FT. Нулевые значения 2025 относятся к этим конкретным ID; удалённые и прежние варианты целей здесь не восстановлены.

Отдельно Метрика рассчитывает ecommercePurchases, количество ecommerce-покупок. Это не метрика достижений цели goal<ID>reaches; ниже они сохранены раздельно.

2. Целевые визиты по Reports API

Визит учитывается один раз для каждой цели независимо от числа её достижений. Один визит может содержать несколько заказов и несколько целей; посетитель может возвращаться.

3. Прямое сопоставление с заказами Битрикса

Точное совпадение текста order_number = purchaseID или goalsOrder в своём счётчике, без ClientID как условия. Уникальный заказ считается один раз. Ищем в обоих сохранённых окнах M6; найденные заказы не переходят между годами визитов. Для выбранной ecommerce-цели множество прямых совпадений goalsOrder совпало с M7 по purchaseID.

Уникальные purchaseID логов включают тесты и номера, не принадлежащие выбранной когорте своего сайта. Поэтому этот столбец не равен найденным нетестовым заказам. Полный контроль Битрикса: 19 081 заказ; основной результат: 19 062. Итого 14 646 найдены, 4 416 не найдены в сохранённых логах своего счётчика. Отсутствие в этих окнах не доказывает потерю отправки.

Почему важна дедупликация: у GD в 2026 7 011 достижений ecommerce при 6 162 заказах Битрикса, однако по ID найдены только 4 359 заказов (70,7%). Избыток событий и отсутствие других заказов могут существовать одновременно.

4. Что можно связать с заказами для автосбора и Sales Ninja

У всех четырёх альтернативных целей goalsOrder пуст. Ниже — совместное присутствие в визите с purchaseID своего заказа Битрикса. Это не прямая привязка достижения к заказу и не доказательство оплаты. Несколько заказов в одном визите сохраняются как несколько уникальных заказов; цели не суммируются.

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

5. В каких визитах Sales Ninja отсутствует ecommerce-покупка

Источник этой таблицы — M6 Logs API, а не агрегаты Reports API. Знаменатель: уникальные визиты с выбранной целью; отсутствие = пустой purchaseID в том же визите. Это не утверждение, что человек никогда не покупал в другом визите, и не оценка прогноза модели.

Такое различие поддерживает гипотезу, что цели отражают дополнительный/модельный сигнал. Название и результаты не устанавливают фактическое правило отправки. До проверки ASK-0004 (../../questions.md#ask-0004) цели не подтверждены как счётчики реальных уникальных покупок. Их фактический выбор и вес в стратегиях Директа в M8 не проверялись.

6. Наблюдаемое начало автосбора

Это первые наблюдения в выбранных логах, а не доказанные даты создания целей или установки интеграции. Для оформления у 79 элементов goalsDateTime=1970-01-01 03:00:00 (GD66, IRO9, Tara4); как фактическое время их использовать нельзя. Месяц во всех помесячных таблицах определяется датой визита, без подстановки выдуманного времени цели. В 2025 выбранные автосбор/SN ID имеют 0 и в отчётах, и в логах; Sales Ninja уже наблюдается с 01.01.2026.

Общее полное окно после появления обоих автосборов — август–сентябрь 2026. Здесь все достижения рассчитаны по M6 Logs API; Битрикс — уникальные созданные заказы того же окна без A/FT. Сходство общих количеств не доказывает совпадение состава заказов; goalsOrder автосбора пуст и в этом окне.

7. Связь с ClientID

Отсутствие ClientID в свойстве Битрикса не мешает точному совпадению номера заказа. Из 14 646 найденных M7 у 11 293 поле Битрикса пусто; 1 158 заказов с заполненным свойством не найдены. Это два отдельных участка учёта. Свойство и статусы — текущий снимок 22.10.2026; момент записи/перезаписи не установлен. Для целей без номера нельзя восстановить точное количество заказов только по счётчику достижений. ASK-0001 (../../questions.md#ask-0001) остаётся открытым.

8. Проверка источников и границы точности

• Шесть GET Reports API: без семплирования (sampled=false, sample_share=1), по 12 метрик, один агрегат; период и +03:00 переданы явно. Журнал запросов общий с M4–M6. Сырые данные повторно не выгружались.
• Повторно проверены SHA-256 всех 24 частей M6; прочитаны 1 992 628 строк. У всех выбранных достижений пять массивов согласованы по длине и позиции. Повторы сохранены; 84 628 элементов выбранных целей.
• Независимый полный проход массивов ID через JSON (без AST и фильтра основного расчёта), Python-множества для связей заказов и исходная B4 только для чтения: 210 проверок по целям и 12 контрольных чисел Битрикса без расхождений. SQLite integrity_check=ok; исходная M7 не изменилась.
• Reports API и Logs API не принудительно уравниваются: небольшие расхождения 2026 перечислены ниже. Причина не установлена; все 2025 значения выбранных целей совпали. Кроме того, ecommercePurchases API GD2026=4 545 против 4 543 элементов purchaseID M6, Tara2026=1 394 против 1 393. Исторические окна/даты обновления и алгоритмы источников могут различаться; это ограничения, а не доказанная причина.
• M6 содержит только визиты января–сентября двух лет; предыдущий декабрь, октябрь и поздние события отсутствуют. Текущие настройки 15 выбранных целей — снимок M4 от 22.10. Исторические условия и удалённые цели не восстановлены. Не выполнена фильтрация по URL конкретного события: принадлежность основного сравнения по site_id/counterID. Контекст чужих доменов в M7 остаётся ограничением.

9. Приоритеты следующей проверки

1. Семантика Sales Ninja: запросить правило vc_ecommerce_pokupka_one_session и _fix, частоту повторов, связь с purchaseID и обоснование ценности. Критерий — воспроизводимый путь события и таблица привязок к заказам, если такая привязка предусмотрена. Пока применять результаты как отдельный сигнал, а не как число продаж.
2. Разрыв ecommerce: разбирать конкретные отсутствующие номера M7 и сценарии создания, особенно оплаченные GD; проверить отправку и пограничные/поздние события. ASK-0002. Дополнительные события SN не закрывают этот пробел.
3. Неполный период автосбора: сравнить цели в общем окне после их первого появления; отдельно установить даты включения. Нулевые первые месяцы не интерпретировать как отсутствие продаж.
4. Связь ClientID: проверить источник и сохранение свойства заказа по ASK-0001; заполненность сама по себе не подтверждает успешную передачу ecommerce/офлайн-конверсий.

Все выводы — проверка данных и ограничения. Изменений целей, кампаний, заказов или интеграций нет; вопросы участникам не отправлены.

Артефакты и повторение расчёта

• Числа и помесячные массивы JSON (summary.json), помесячная таблица (monthly.md), ID и условия целей (goal-mapping.md).
• Вопрос и допуск API (question.md), проверка источников/хеши (verification.json), независимая проверка (independent-verification.json).
• Reports API: сырые агрегированные ответы/сводка (../../sources/metrica/2026-10-22/purchase-goals/summary.json); M6: manifest (../../sources/metrica/2026-10-22/logs-export/manifest.json).
• Частная SQLite (../../private/metrica/2026-10-22-goal-comparison/goals.sqlite): goal_events с исходными позициями, копия минимальных таблиц M7, views direct_matches/cooccurring_orders. ФИО/адреса/контакты не копировались. Не публиковать вне защищённого проекта: есть ClientID и номера заказов.
• Скрипты: collect_purchase_goal_reports.py → compare_purchase_goals.py → verify_purchase_goals.py → report_purchase_goals.py в tools/. Основной расчёт отказывается перезаписывать существующую производную БД; повторный сетевой сбор использует сохранённые ответы.

Определения: достижения и целевые визиты; поля Logs API. Условия API и бюджет — в question.md.

Источник: analysis/2026-10-22-purchase-goals/report.md.