Отчёты и учебная конверсия

Оглавление серии

Отчёт отвечает на сформулированный вопрос: сколько продано, какой была скидка или какая доля сессий дошла до оплаченного заказа. Число Orders в таблице не является автоматически выручкой или конверсией. В «Полке» сопоставим учебные суммы с WooCommerce Analytics и отдельно рассчитаем синтетическую воронку, не выдавая её за статистику запущенного магазина.

После урока вы сможете объяснить gross/net sales, влияние coupon/refund и знаменатель conversion. Данные придуманы для обучения. Analytics UI не запускался, traffic не измерялся, real users отсутствуют. Таблица funnel намеренно помечена synthetic и не является экспортом WooCommerce.

Сумма каталога и сумма продаж

Regular price GRID-PDF равна 12.00. При pair покупке вместе с FORM-ZIP gross product amount составляет 20.00. LAB10 уменьшает eligible сумму на 2.00, поэтому net sale до refund составляет 18.00. Налог и доставка в модели отсутствуют. Если позже возвращена стоимость одного item, sale metrics должны учитывать refund, а не только первоначальный total.

Официальная Analytics and Sales Reports определяет gross sales, net sales, total sales и average order value. Например, net sales учитывает возвраты и coupons, total добавляет применимые taxes/shipping. Для нашего нулевого tax/shipping примера net и total могут совпасть, но это совпадение условий, а не общая идентичность показателей.

Average order value требует выбранного numerator и подходящего count Orders. Если один оплаченный заказ имеет net 18, средняя равна 18. Если добавить ещё один за 12, сумма 30 и средняя 15. Технический Draft order без завершения не следует включать как вторую продажу только потому, что record присутствует в базе.

В reports сначала выберите период, timezone и included statuses. Разные настройки могут менять результат даже при тех же исходных Orders. Не сравнивайте вчерашний export с сегодняшним dashboard без этих условий. Возврат может учитываться на дату refund, поэтому изменение периода влияет на видимую динамику.

Reports используют обработанные данные

В будущем локальном Woo Analytics откройте Orders и Products report. Найдите known SKUs и сравните доступные totals с actual Order lines. Если данные обновляются не сразу, проверьте статус обработки и предусмотренные инструменты Analytics. Нельзя исправлять задержку случайным изменением статуса завершённого заказа: это создаст новые events и исказит историю.

CSV export отчёта помогает сохранить выбранный срез, но должен сопровождаться названием показателя и условиями. Файл «продажи.csv» без period/status filters трудно использовать для сравнения. В course source fixtures стабильны, поэтому объяснение можно читать независимо от конкретного Order ID вашей лаборатории.

Downloads report отвечает на вопрос о выдаче файлов, а не о количестве разных людей. Один purchaser может скачать материал несколько раз, другой — не скачать его сразу после оплаты. Поэтому downloads нельзя прямо назвать customer count или conversion. Для каждого показателя важно понять, что считается событием и как оно связано с Order.

Не используйте webhook inbox rows как количество продаж. Updated callbacks могут отражать изменения contact, notes или refund и повторяться. Receiver предыдущей главы подтверждает приём, но не агрегирует бизнес-показатели. Авторитетный state и определения метрик остаются необходимы даже при безошибочной signature.

Воронка имеет свой знаменатель

Для synthetic-A зададим сто sessions, шестьдесят product views, двадцать sessions с add-to-cart, двенадцать с checkout и восемь paid orders. Synthetic-B имеет сто sessions, шестьдесят два views, двадцать один cart, пятнадцать checkout и девять paid orders. Полный fixtures/funnel.csv приведён ниже.

cohort,sessions,product_views,add_to_cart_sessions,checkout_sessions,paid_orders
synthetic-A,100,60,20,12,8
synthetic-B,100,62,21,15,9

Session-to-paid conversion для A равна 8/100 = 8%, для B — 9/100 = 9%. Если считать checkout-to-paid, получаем 8/12 ≈ 66.7% и 9/15 = 60%. Один показатель вырос, другой снизился. Это не противоречие: сравниваются разные основания. Формулировка «конверсия улучшилась» без знаменателя скрывает важное различие.

В таблице product_views названо событие, а cart/checkout — число sessions, где действие произошло. Если один участник посмотрел три товара, число views может быть больше числа sessions. Наша маленькая модель задаёт конкретные числа, но в реальном измерении definitions должны быть согласованы до сбора. Иначе вы смешаете events и уникальные visits в одной воронке.

Paid orders также не обязаны быть уникальными sessions: один участник может оформить два заказа, а другой вернуться через несколько устройств. В synthetic fixture предполагаем простую связь для арифметики. Настоящий attribution потребует отдельного правила и подходящей обработки приватности. Woo sales reports сами по себе не предоставляют универсального числа storefront sessions.

Причину нельзя доказать двумя маленькими строками

Разница 8% и 9% в двух вымышленных cohorts не доказывает эффект новой кнопки. Данные искусственные, sample маленький, случайность и отличия visitors не обсуждались как реальный эксперимент. Можно сформулировать гипотезу: B чаще доходит до checkout, но реже завершает этот этап. Затем проверить события и payment errors в фактическом проекте.

Для «Полки» это способ научиться задавать следующую задачу. Например, отказ Dummy failure имеет известную искусственную причину. Он не сообщает о недостатках настоящего provider. On-hold BACS order также не значит, что человек отказался навсегда: в real flow confirmation может задержаться. Статус и момент наблюдения должны соответствовать вопросу анализа.

Объедините отчёт с качественным описанием сценария. Если CART pair имеет правильный total, но customer не понимает формат TXT, проблема предложения не проявится одной цифрой. Если checkout требует ненужное поле, полезно изучить конкретный шаг UI. Метрики помогают выбрать место для анализа, а не заменяют объяснение поведения.

Для самостоятельной арифметики измените paid_orders A с восьми до шести, сохранив sessions и checkout. Session conversion станет 6%, checkout conversion — 50%. Затем измените sessions до ста двадцати, сохранив шесть orders: первая метрика снизится, вторая останется прежней. Так проявляется зависимость от знаменателя без запуска аналитической системы.

Результат урока — reports читаются через определения, synthetic data обозначены честно, а число технических callbacks не подменяет продажи. Последняя глава добавит приватность, backup и обновление: сопровождение магазина должно сохранить не только theme, но и согласованные товары, orders, permissions и настройки измерения.