D5/M10 · 23.10 · Директ → Метрика по ecommerce-покупкам

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

D5/M10 · Директ и Метрика: январь–сентябрь 2025/2026

Расчёт 23.10.2026 по локальным D2 (Direct Reports API, снимок 23.10), M6/M7 (Metrica Logs API, снимок 22.10) и B4 (Битрикс, снимок 22.10). Новых запросов к кабинетам и изменений внешних систем не было. Вопрос и критерий (question.md) · 54 месяца в читаемой таблице (monthly.md) · все поля TSV (monthly-comparison.tsv) · 6 итогов TSV (nine-month-summary.tsv) · проверки (validation.json) · код расчёта (build.py).

Что показывают числа

Бренд Год Расход Директа, ₽ с НДС Клики CPC, ₽ Целевые визиты ecommerce-покупки Директа PurchaseRevenue, ₽ Предв. ДРР, % Метрика: все уникальные purchaseID Из них в визитах Директа Битрикс: созданные без тестовых
Gerard Darel 2025 2 054 661,35 64 379 31,92 297 13 134 825 15,64 4 912 376 6 561
Gerard Darel 2026 2 412 077,59 199 140 12,11 243 10 525 250 22,92 4 377 248 6 162
IRO Paris 2025 661 815,34 14 891 44,44 44 1 688 610 39,19 1 094 58 1 288
IRO Paris 2026 741 362,27 41 308 17,95 64 3 771 720 19,66 770 69 1 001
Tara Jarmon 2025 1 265 702,15 37 267 33,96 179 7 272 000 17,41 2 218 220 2 416
Tara Jarmon 2026 1 169 762,85 47 064 24,85 130 5 294 083 22,10 1 363 136 1 634

Это не финансовая ДРР выкупленных заказов. Формула предварительного столбца: сумма Cost выбранного бренда и периода / сумма PurchaseRevenue по ecommerce-цели покупки и модели LC × 100. Для девяти месяцев используется отношение сумм, а не среднее месячных процентов. Для финансовой ДРР неизвестны фактическая выручка после отмен/возвратов, состав расходов PDF Марии и правила отнесения заказа к каналу. Полученные проценты не подтверждают и не опровергают заявленные около 10%: неизвестен знаменатель этой цифры.

Пример для разговора: январь 2026

Бренд Расход, ₽ Клики CPC, ₽ Целевые визиты покупки Директа PurchaseRevenue, ₽ Предв. ДРР, % Метрика: все уникальные ID Метрика: ID в визитах Директа Битрикс: заказы
Gerard Darel 278 174,61 41 870 6,64 16 484 120 57,46 736 17 1 009
IRO Paris 111 168,13 3 390 32,79 19 858 900 12,94 170 22 214
Tara Jarmon 122 030,26 4 043 30,18 22 928 583 13,14 335 22 382

Определения и границы сравнения

  • Директ: Cost с НДС, Clicks, CPC = расход / клики. Conversions_<ecommerce purchase goal>_LC — целевые визиты. Цели GD 3061921558, IRO 264959892, Tara 3088990231. PurchaseRevenue запрошен с фильтром именно этих целей. Кампании на строках с -- по конверсии не дают числового вклада: 51 из 207 строк, по 6 девятимесячным итогам соответственно 7/11/14/11/6/2. Число целевых визитов следует читать как сумму показанных чисел, а не доказанное полное число заказов.
  • Метрика: из массива ecommerce purchaseID взят каждый зарегистрированный элемент; в основном показателе повторный ID внутри одного счётчика и периода считается один раз. Визит отнесён к Яндекс Директу только при lastTrafficSource=ad и lastAdvEngine=ya_direct; «из них» означает ID с хотя бы одним таким визитом. Это модель последнего источника Logs, не строгая проверка того, что заказ создан исключительно этим каналом. 24 ID за два года наблюдались и в визите Директа, и в визите другого источника (по шести группам 9/4/2/2/4/3); внутри общего количества они не удваиваются. Счётчик не всегда гарантирует заказ именно своего сайта: M7 обнаружил отдельные попадания в чужой счётчик, для окончательного сопоставления требуется точный order_id.
  • Время: Месяц Директа — Month из Reports API; месяц Метрики — purchaseDateTime события; месяц Битрикса — created_at заказа. У 9 наблюдений месяц покупки отличается от месяца визита. Различие месячных итогов нельзя без построчного разбора считать потерянными заказами.
  • Битрикс: B5, все созданные заказы, кроме текущих тестовых A/FT; отменённые, неоплаченные и нулевые включены. Это независимый контроль масштаба, не подмножество одного и того же отчёта Метрики. Общая база 19 062 заказа против 14 734 уникальных ecommerce-ID в сохранённых визитах; разность агрегатов не является оценкой потерянных событий, так как отличаются дата, покрытие и правила включения. Построчная сверка M7 (../2026-10-22-historical-order-reconciliation/report.md) отдельно исследует совпадение ID.
  • Кампания: у 78 наблюдений покупки из визита Яндекс Директа 2025 поле lastDirectClickOrder содержит кампанию, отсутствующую в соответствующем исходном D2 TSV: GD 97968325 — 50, IRO 88311358 — 7, Tara 100062067 — 21. Все 2026 наблюдения совпадают с набором ID D2. Пока не установлено, объясняется ли это историческим составом кабинетов, правами, остановленными кампаниями или областью отчёта. Их покупки нельзя автоматически приписывать расходу D2.

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

Проверка и следующие вопросы

Скрипт воспроизводимо прочитал 54 строки D2, 15 165 наблюдений покупки в 14 464 визитах M7 и 19 062 нетестовых заказа B4; создал 54 помесячные строки и шесть итогов. Независимый SQL (validation.sql) с COUNT(DISTINCT purchase_id) по счётчику/году и признаку источника вернул те же шесть пар чисел Метрики. Входные TSV и SQLite не менялись. Официальная семантика Direct Reports и поля Metrica Logs использованы для подписи показателей.

  1. Что именно входит в заявленные ~10% ДРР: какие расходы, какая фактическая выручка и какие статусы заказов? Требуются первичные помесячные числитель/знаменатель и список ID. Уже открыт ASK-0011 (../../questions.md#ask-0011) о расходе PDF и ASK-0008 (../../questions.md#ask-0008) о выкупах.
  2. Почему три ID кампаний 2025 есть в атрибуции Метрики, но отсутствуют в D2; какие кабинеты и исторические кампании должны входить в базу? Подготовлен ASK-0013 (../../questions.md#ask-0013).
  3. Как на уровне ID, даты и модели атрибуции сверить PurchaseRevenue и целевые визиты Директа с ecommerce-покупками Метрики и заказами Битрикса? Нужен экспорт с order_id/purchaseID, временем события, кампанией и историей изменения заказа; существующий ASK-0002 (../../questions.md#ask-0002) закрывает ошибки отправки ecommerce.

До ответов это проверка исходных чисел и определений, а не оценка эффективности рекламы.


Источник: analysis/2026-10-23-direct-metrica-monthly/report.md.