docs(labs): обращение «вы» во всех учебных заданиях
- Зачем:
- README и путеводитель обращаются к читателю на «вы», а ТЗ в docs/labs/
были на «ты»; после пересборки индекса смесь стала заметна.
- Что:
- во всех восьми файлах docs/labs/ местоимения, глаголы и повелительное
наклонение переведены во второе лицо множественного числа.
- названия ступеней в таблице README оставлены как в спеке.
- Проверка:
- grep по формам «ты/твой», 'ё' и 'менти' по docs/labs/ молчит;
git diff --check чистый; ревью диффа свежей сессией.
This commit is contained in:
1 parent
830efa7ef4
commit
cffe1aeb73
8 files changed
+80
-77
No files matched your search
@@ -3,7 +3,7 @@
|
||||
**Чему учит:** приставка `declared_` в имени колонки — предупреждение, а не
|
||||
украшение. Она говорит: это заявка клиента, а не деньги отчетности. Урок
|
||||
здесь дает конфликт: суммы не сойдутся, и раскапывать почему предстоит
|
||||
самому.
|
||||
самостоятельно.
|
||||
|
||||
Правило стенда: **поведение и атрибуцию считаем по трекеру, деньги — по
|
||||
бэкенду**. Эта витрина — единственное разрешенное исключение: атрибуции по
|
||||
@@ -88,21 +88,21 @@ UTM у бэкенда нет, метки живут только в кликст
|
||||
|
||||
## Ключ шардирования
|
||||
|
||||
Твое решение по [правилу донора](../architecture/storage.md), «Раскладка по
|
||||
Ваше решение по [правилу донора](../architecture/storage.md), «Раскладка по
|
||||
шардам». Зерно здесь составное, из трех колонок, и решение «взять хеш от
|
||||
одной из них» надо защищать отдельно: назови, какая доля строк придется на
|
||||
одной из них» надо защищать отдельно: назовите, какая доля строк придется на
|
||||
самое частое значение выбранной колонки.
|
||||
|
||||
## Конфликт, ради которого витрина и написана
|
||||
|
||||
Собери за один и тот же день две суммы: `sum(declared_revenue)` из своей
|
||||
Соберите за один и тот же день две суммы: `sum(declared_revenue)` из своей
|
||||
витрины и `sum(revenue)` из `dm.revenue_daily_v`. Они не сойдутся, и это
|
||||
верное поведение обеих витрин.
|
||||
|
||||
Базы у двух сумм при этом сравнимые: `revenue_daily` складывает цену позиций
|
||||
на количество и ни скидки, ни доставки в себя не берет — ровно то, что видит
|
||||
клиент. Значит все расхождение до копейки объясняется тем, что случилось с
|
||||
заказом, а не тем, как считали деньги. Ищи ответы среди таких причин:
|
||||
заказом, а не тем, как считали деньги. Ищите ответы среди таких причин:
|
||||
|
||||
- отмененный заказ из кликстрима никуда не девается: событие покупки
|
||||
случилось, а `revenue_daily` считает только оплаченные;
|
||||
@@ -113,7 +113,7 @@ UTM у бэкенда нет, метки живут только в кликст
|
||||
|
||||
Как эти же расхождения выглядят на зерне заказа, показывает стендовая
|
||||
витрина `dm.purchase_vs_orders_v` с ее классами расхождений: это готовый
|
||||
ответ на вопрос «а сколько именно и из-за чего». Запиши свой вывод —
|
||||
ответ на вопрос «а сколько именно и из-за чего». Запишите свой вывод —
|
||||
в двух-трех фразах, своими словами.
|
||||
|
||||
Проверять сходимость этих двух сумм не нужно и нельзя: они и не должны
|
||||
@@ -122,8 +122,8 @@ UTM у бэкенда нет, метки живут только в кликст
|
||||
## Как проверить себя
|
||||
|
||||
Деловой ключ — тройка `utm_source`, `utm_medium`, `utm_campaign` внутри
|
||||
дня. Собери прямой агрегат из `dds.event_v` за день, соедини с
|
||||
`dm.utm_effectiveness_v` полным внешним соединением и посчитай строки, где
|
||||
дня. Соберите прямой агрегат из `dds.event_v` за день, соедините с
|
||||
`dm.utm_effectiveness_v` полным внешним соединением и посчитайте строки, где
|
||||
ключа нет с одной из сторон или где расходится любая из пяти величин. Ноль —
|
||||
зеленый.
|
||||
|
||||
|
||||
Reference in new issue
Block a user