Вы строите выручку по каналу: соединяете sessions(user_id, channel) и orders(user_id, revenue) по user_id, затем считаете SUM(revenue) по channel. Получившаяся выручка сильно больше бухгалтерской. Что наиболее вероятно и что делать?

AЗаменить SUM(revenue) на AVG(revenue) — это скорректирует дублирование по сессиям
BДобавить SELECT DISTINCT на весь результирующий набор и пересчитать выручку
CИспользовать COUNT(*) вместо SUM(revenue), так проблема дублирования исчезнет
DЭто many-to-many и join explosion: у пользователя много сессий и заказов, поэтому revenue дублируется; нужно pre-aggregate или строить атрибуцию по более точному ключу, чтобы избежать duplication
Правильный ответ. Соединение двух one-to-many источников по user_id даёт many-to-many и ломает денежные метрики из-за duplication.

Разбор

Каждый заказ пользователя матчится на каждую его сессию, поэтому один и тот же revenue учитывается много раз в SUM(). distinct может случайно скрыть часть дублей и сломать данные по-другому, поэтому это плохой костыль. Правильный путь — определить целевой уровень данных, pre-aggregate до него и затем соединять.

Проверь себя · 1/3разбор после ответа
Вы считаете «уникальные покупатели по бренду». Данные: order_items(user_id, product_id) и products(product_id, brand). Пользователь может купить несколько товаров одного бренда. Какой расчёт на объединённых данных соответствует цели и устойчив к duplication?
Открыть Карьерник в Telegram

Ещё вопросы по теме «JOIN и кардинальность»