Средний чек за период: как усреднение дневных значений меняет результат

В дневном отчёте уже есть средний чек. Можно ли получить показатель за месяц, просто усреднив значения по дням?

Разберём на условном примере за два дня. Учитываем только оплаченные заказы в рублях, без возвратов. Каждому заказу соответствует одна итоговая сумма.

1 ноября:
Оплаченных заказов — 1.
Общая сумма заказов — 1 000 ₽.
Средний чек — 1 000 ₽.


2 ноября:
Оплаченных заказов — 9.
Общая сумма заказов — 900 ₽.
Средний чек — 100 ₽.

Если взять среднее арифметическое двух дневных значений, получим:
(1 000 + 100) / 2 = 550 ₽.

Но за весь период покупатели оплатили 10 заказов на общую сумму 1 900 ₽.

Правильный средний чек за период:
1 900 / 10 = 190 ₽.
Разница существенная: 550 ₽ против 190 ₽.

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

Оба результата математически корректны, но описывают разные показатели. 550 ₽ — среднее арифметическое дневных средних чеков. 190 ₽ — средний чек по всем оплаченным заказам за период.

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

В SQL эта ошибка возникает, когда сначала считают средний чек по дням, а затем применяют AVG к полученному столбцу. Функция усредняет дневные значения, не учитывая, сколько заказов стоит за каждым из них.

Куда пропали клиенты без покупок? Ловушка WHERE после LEFT JOIN

Нужно вывести всех клиентов и их оплаченные заказы. Даже если оплаченных заказов нет, клиент должен остаться в отчёте.

Допустим, у нас три клиента:

Конверсия 100% или 50%? Сначала уточните, что вы считаете

Один пользователь создал два заказа и оплатил один. Какая конверсия из создания заказа в оплату?

Посмотрим на условные события за один день: Посмотрим на три события за один день. Во всех случаях пользователь один — user_id = 7:

Представим: в отчёт добавили новые регистрации, и общий D30 retention снизился с 20% до 10%. При этом ни один из пользователей, для которых D30 уже наступил, не изменил своё поведение. Ошибка может оказаться в знаменателе: туда попали люди, чей тридцатый день ещё впереди.

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

Семь строк в SQL — ещё не семь дней. Как пропуски дат меняют скользящую сумму

Для показателя «за последние семь дней» легко написать:

Покупка в сентябре, возврат в октябре. Почему два отчёта показывают разные суммы

Пример: 15 сентября покупатель заплатил 1000, а 5 октября получил частичный возврат 400. Других операций нет. Какую сумму показать за сентябрь — 1000 или 600 р.? Ответ зависит от вопроса, на который отвечает отчёт.

Разберём два управленческих отчёта по платежам. Берём только успешно проведённые оплаты и возвраты, без комиссий. Срез — на начало 28 октября 2026 года. В учебной базе даты записаны в одном часовом поясе, суммы — целыми копейками.

Данные для SQLite: