docs(labs): упрощен язык учебных заданий

- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок.
- Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки.
- Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.

docs/labs/optional/identity-over-time.md

@@ -1,7 +1,8 @@
 # Как новые заказы меняют отчет о посетителях
 
-**Чему учит:** сохранять историю связей посетителей с покупателями
-и использовать ее для воспроизведения прежнего расчета.
+Вы сохраните историю связей посетителей сайта с покупателями магазина.
+На ее основе проверите, как новые связи меняют старые отчеты и что нужно,
+чтобы повторить прежний расчет.
 
 Факультатив доступен после ступени 1. Понадобятся Airflow и DBeaver с
 подключением `student` по [инструкции](../../../README.md#подключиться-из-dbeaver).
@@ -9,13 +10,14 @@
 ваши таблицы будут доступны только на узле этого подключения.
 Если предложенное имя таблицы занято, выберите свое.
 
-В событиях сайта посетитель обозначен кукой `client_id`, а в заказах
-покупатель — `user_id`. Сопоставив событие покупки с заказом, можно связать
-эти идентификаторы. Тогда и к прежним визитам этой куки можно добавить
+В событиях сайта посетитель обозначен `client_id` из cookie браузера,
+а в заказах покупатель обозначен `user_id`. Сопоставив событие покупки
+с заказом, можно связать эти идентификаторы. Тогда и к прежним визитам
+этого `client_id` можно добавить
 пользователя магазина. Вы проверите, как появление такой связи меняет число
 известных пользователей в отчете за прошедший день.
 
-## Сопоставьте посетителей с покупателями
+## Связи посетителей с покупателями
 
 Поставьте `world_live` на паузу, дождитесь завершения начатых прогонов
 генерации и обработки. Запустите `etl_pipeline` и дождитесь успеха.
@@ -32,7 +34,8 @@
 найдите самое раннее время события покупки, которое удалось сопоставить
 с заказом. Назовите эту колонку `first_purchase_at`.
 В событии `purchase` массив `purchase_id` содержит один номер заказа.
-Статус заказа не ограничивайте: отмена покупки не меняет владельца куки.
+Статус заказа не ограничивайте: отмена покупки не меняет найденную связь
+посетителя с покупателем.
 
 Источники распределены по разным ключам. Для соединения используйте
 `GLOBAL INNER JOIN`, заключив выборки событий и заказов в подзапросы.
@@ -43,7 +46,7 @@
 Для одной пары покажите номера заказов и события, по которым получили
 `first_purchase_at`.
 
-## Сохраните список связей после каждого модельного дня
+## История связей
 
 Создайте таблицу:
 
@@ -84,7 +87,7 @@ SELECT max(event_date) AS observation_day FROM dds.event_v;
 не устраняет повторы вставки. Сохраните и проверьте список перед тем,
 как запускать следующий модельный день.
 
-## Сравните дату покупки с датой появления связи
+## Дата покупки и дата появления связи
 
 Сравните списки за соседние даты: H0 с H1, затем H1 с H2. Найдите пары,
 которых не было в прежнем списке. Для нескольких таких пар покажите
@@ -101,7 +104,7 @@ SELECT max(event_date) AS observation_day FROM dds.event_v;
 у вас нет более ранних копий списка. Для новой пары можно установить
 интервал между двумя сохранениями, но не точное время внутри него.
 
-## Пересчитайте отчет за прежние дни
+## Пересчет прежних отчетов
 
 Возьмите один и тот же набор сессий из `dds.session_v` за даты до H0
 включительно. Постройте два дневных расчета:
@@ -128,7 +131,7 @@ SELECT max(event_date) AS observation_day FROM dds.event_v;
 На примере найденных различий объясните, какие данные нужно сохранять,
 чтобы повторить прежний расчет.
 
-## Что должно получиться
+## Результат работы
 
 У вас есть запрос сопоставления посетителей с покупателями, три сохраненных
 списка связей и сравнение двух расчетов на одном наборе сессий. На конкретных