docs(labs): упрощен язык учебных заданий
- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок. - Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки. - Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.
This commit is contained in:
1 parent
3c3eb825e1
commit
4693bc5af9
24 files changed
+782
-684
No files matched your search
@@ -1,30 +1,38 @@
|
||||
# Задание 5: `dm.utm_effectiveness`
|
||||
# Задание 5: показатели рекламы, `dm.utm_effectiveness`
|
||||
|
||||
**Чему учит:** различать сумму покупки со слов клиента (`declared_`) и
|
||||
серверную выручку, находить причины их расхождения.
|
||||
Вы подготовите показатели рекламных каналов по событиям сайта. Суммы покупок
|
||||
в этой витрине будут отличаться от выручки по заказам магазина. В конце
|
||||
работы вы сравните их и объясните причины расхождения.
|
||||
|
||||
## Сначала прочитать
|
||||
## Подготовка
|
||||
|
||||
- [«Хранилище и его слои»](../handbook/storage-layers.md);
|
||||
- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
|
||||
|
||||
## Для чего нужна витрина
|
||||
## Покупки по рекламным каналам
|
||||
|
||||
Аналитик сравнивает рекламные каналы по дням: трафик, добавления в корзину,
|
||||
покупки и заявленные клиентом суммы.
|
||||
покупки и их суммы из событий сайта.
|
||||
|
||||
На стенде поведение и атрибуцию считают по трекеру, деньги — по бэкенду.
|
||||
Здесь сделано исключение: UTM-метки есть только в кликстриме, поэтому для
|
||||
оценки покупок по меткам используют клиентскую сумму.
|
||||
События сайта показывают действия посетителя и рекламные метки его переходов.
|
||||
Заказы магазина служат источником выручки. Но в заказах нет UTM-меток, поэтому
|
||||
в этой витрине вы возьмете суммы из событий покупки. Их передает браузер
|
||||
посетителя; дальше они называются клиентскими суммами. Приставка `declared_`
|
||||
в имени показателя напоминает об этом источнике.
|
||||
|
||||
## Что сделать
|
||||
## Создание витрины
|
||||
|
||||
Читайте `dds.event_v` напрямую, без соседних витрин DM. Зерно — **день
|
||||
события × `utm_source` × `utm_medium` × `utm_campaign`**. Зерно новое,
|
||||
поэтому витрина хранится готовым агрегатом — см. [«Как принято на ступени
|
||||
1»](README.md#как-принято-на-ступени-1). Создайте пять объектов:
|
||||
`dm.utm_effectiveness_rep` / `_dist`, донор `_stage_rep` / `_stage_dist` и
|
||||
публичное представление `dm.utm_effectiveness_v`. Ключ партиции — день.
|
||||
Читайте события из `dds.event_v`, без других витрин DM. В результате нужна
|
||||
одна строка на день и сочетание трех меток: `utm_source`, `utm_medium`,
|
||||
`utm_campaign`. События одного дня с одинаковыми метками попадают в одну группу.
|
||||
|
||||
Создайте пять объектов по [общим правилам ступени 1](README.md#создание-и-обновление-витрин):
|
||||
|
||||
- основные таблицы `dm.utm_effectiveness_rep` и `dm.utm_effectiveness_dist`;
|
||||
- промежуточные таблицы `dm.utm_effectiveness_stage_rep` и `dm.utm_effectiveness_stage_dist`;
|
||||
- представление для чтения `dm.utm_effectiveness_v`.
|
||||
|
||||
Разбейте данные на партиции по дням.
|
||||
|
||||
### Состав колонок
|
||||
|
||||
@@ -54,31 +62,32 @@
|
||||
Для `utm_campaign` выбран тип `String`: имен кампаний со временем становится
|
||||
много, и затраты на словарь `LowCardinality` перестают окупаться.
|
||||
|
||||
### Ритм пересборки
|
||||
### Дни для пересчета
|
||||
|
||||
События прожитого дня больше не меняются. Как в задании 2, соберите в донор
|
||||
дни от первого несобранного до последнего прожитого и замените дневные
|
||||
партиции. Добавьте задачу в `dm_transform`.
|
||||
События завершившегося модельного дня больше не меняются. Как в задании 2,
|
||||
найдите первый завершившийся день, которого еще нет в витрине. Рассчитайте
|
||||
все дни от него до последнего завершившегося, запишите их в промежуточную
|
||||
таблицу и замените дневные партиции основной. Добавьте задачу в `dm_transform`.
|
||||
|
||||
### Ключ шардирования
|
||||
|
||||
Выберите ключ самостоятельно. Если берете хеш одной из трех UTM-колонок,
|
||||
посчитайте долю строк с ее самым частым значением и обоснуйте выбор.
|
||||
|
||||
Ключ донора — тот же, что у цели (см. [«Как принято на ступени
|
||||
1»](README.md#как-принято-на-ступени-1) и раздел «Раскладка по шардам»
|
||||
[справочника хранилища](../architecture/storage.md)).
|
||||
У основной и промежуточной таблиц должен быть одинаковый ключ шардирования:
|
||||
см. [общие правила ступени 1](README.md#создание-и-обновление-витрин).
|
||||
|
||||
## Атрибуция по событию, а не по визиту
|
||||
## Рекламные метки событий
|
||||
|
||||
Группируйте события по их собственным меткам. Модели «первое касание» и
|
||||
«последнее касание» здесь не рассчитываются.
|
||||
|
||||
В `dds.session_v` записаны UTM первого события визита. Распределение по
|
||||
каналам может отличаться от этой витрины, и это не означает ошибку в
|
||||
расчете. В отчете различайте атрибуцию визитов и событий.
|
||||
расчете. Укажите в отчете, что распределяете по рекламным каналам отдельные
|
||||
события. Такое распределение называют атрибуцией.
|
||||
|
||||
## Прямой трафик остается в витрине
|
||||
## События без рекламных меток
|
||||
|
||||
Сохраните события без меток: прямой трафик обычно крупнейший канал, и без
|
||||
него доля рекламы будет завышена. Если отфильтровать такие строки, дневные
|
||||
@@ -108,13 +117,13 @@
|
||||
причины можно посмотреть в `dm.purchase_vs_orders_v`, где выделены классы
|
||||
расхождений.
|
||||
|
||||
## Как проверить себя
|
||||
## Проверка результата
|
||||
|
||||
Деловой ключ — `utm_source`, `utm_medium`, `utm_campaign` внутри дня.
|
||||
Получите прямой агрегат из `dds.event_v` за день и соедините его с
|
||||
`dm.utm_effectiveness_v` полным внешним соединением по ключу. Посчитайте
|
||||
строки, где ключ отсутствует с одной из сторон или различается любая из пяти
|
||||
величин. Расхождений должно быть ноль.
|
||||
Рассчитайте те же показатели по `dds.event_v` за выбранный день.
|
||||
Сопоставьте результат со строками `dm.utm_effectiveness_v` за этот день
|
||||
через `FULL OUTER JOIN` по `utm_source`, `utm_medium` и `utm_campaign`.
|
||||
Найдите сочетания меток, которые есть только с одной стороны, и строки,
|
||||
где различается хотя бы один из пяти показателей. Расхождений должно быть ноль.
|
||||
|
||||
Дополнительно сверьте дневные итоги:
|
||||
|
||||
@@ -126,10 +135,10 @@
|
||||
Сумма `visitors` по строкам повторно учитывает одного посетителя,
|
||||
приходящего по разным меткам. Для числа посетителей дня она не подходит.
|
||||
|
||||
## Что должно получиться
|
||||
## Результат работы
|
||||
|
||||
- [ ] у вас есть пять объектов витрины; донор объявлен через `AS` и
|
||||
использует ключ шардирования целевой таблицы;
|
||||
- [ ] у вас есть пять объектов витрины; промежуточная таблица объявлена через
|
||||
`AS` и использует ключ шардирования основной;
|
||||
- [ ] строки без UTM-меток сохранены, а `declared_revenue` хранится
|
||||
в `Decimal(18, 2)`;
|
||||
- [ ] вы записали, почему сумма отличается от `dm.revenue_daily_v`;
|
||||
|
||||
Reference in new issue
Block a user