67 lines
8.7 KiB
Markdown
67 lines
8.7 KiB
Markdown
# SuperSam — аналитика коммуникаций: проверка и исправления
|
||
|
||
Проверка и правки: 02.10.2026, МСК. Данные — последние 30 дней, живая БД (.8) и живой RPC, сверка с кодом, триггерами и боевой сборкой фронта.
|
||
|
||
## Итог
|
||
|
||
Все четыре предложения сделаны. Цифры согласований больше не врут: «Согласовано» считается по факту подтверждения, а заказ, закрытый без согласования, получил честный статус «Без согласования» — и в аналитике, и в реестре, и в карточке.
|
||
|
||
## Что было не так (и что стало)
|
||
|
||
### 1. «Согласовано» на 137 заказах из 186 — это не подтверждения клиента → исправлено
|
||
Триггер `clear_manual_required_on_action` ставил `notification_status='confirmed'` на любой уход заказа с ручной работы, даже когда даты нет и клиент ничего не подтверждал (в истории: `manual_confirmation_required → delivered` + `manual_required → confirmed`, источник «system» — приходит обменом).
|
||
|
||
Стало:
|
||
- триггер пишет «Согласовано» только когда у заказа есть дата (её поставил логист или выбрал клиент), иначе — новый статус `closed_without_confirmation` («Без согласования»);
|
||
- 128 уже испорченных строк переведены в новый статус (бэкап: `/root/order_groups_confirmed_backfill_20261002.csv` на .8);
|
||
- новый статус подписан в реестре, карточке, истории действий и в списке «не поднимают трубку»;
|
||
- автодозвон такие заказы не трогает (планировщик исключает новый статус из выборки).
|
||
|
||
Проверка поведения (транзакция с откатом на боевой БД): закрытие без даты → `closed_without_confirmation`, закрытие с датой → `confirmed`.
|
||
|
||
### 2. Два блока аналитики показывали разные цифры → исправлено
|
||
Канал согласования теперь считается одним классификатором в RPC (`confirm_channels`) для обоих блоков: «Чем подтвердили» и «Как согласовали дату» дают одинаковый расклад — **логист 112 · робот 26 · ссылка 18**. Раньше было «менеджер 25» в одном блоке и «логист 116» в другом, потому что цифра зависела от текущего `notification_status` и «сгорала», когда заказ уходил в `completed`. Теперь считается по событию — задним числом не меняется.
|
||
|
||
### 3. «Открыли ссылку» = 1 из 438 → стало 73 (16.4%)
|
||
Метрика считалась по `opened_at`, который пишет только edge-функция, а страница клиента ходит RPC. Считаем по фактическому входу: `access_count > 0`, `last_accessed_at`, подтверждение приглашения.
|
||
|
||
### 4. Тестовые звонки попадали в статистику → исправлено
|
||
37 тестовых строк за 30 дней (6 с привязкой к группе) убраны из воронки, таблицы попыток и «не поднимают трубку». Во вкладке «Коммуникации → Аналитика» они тоже исключены, а их число показано отдельным показателем.
|
||
|
||
### 5. Вкладка «Коммуникации → Аналитика» → приведена в порядок
|
||
- «Всё время» теперь действительно всё время (раньше молча бралось 90 дней);
|
||
- «Дозвонились» и «Согласовали» считаются по тем же исходам, что в воронке;
|
||
- вместо «времени на линии» и «среднего звонка» (АТС пишет длительность нулём — цифры были фиктивные) честный блок «Тестовые звонки — не в статистике»;
|
||
- дни на графике — по МСК.
|
||
|
||
### 6. Каналы больше не выводятся ключами БД → исправлено
|
||
Каналы из ссылки (`sms`, `client`, `push`, `messenger`) и робот (`call`) подписаны человеческими словами; там, где дата есть, а источник не записан, стоит «Источник не записан» вместо «В обход (без даты)».
|
||
|
||
## Цифры до и после (30 дней, когорта 444 группы)
|
||
|
||
- Открыли ссылку: 1 (0.2%) → **73 (16.4%)**
|
||
- Робот позвонил: 80 → 79 · Взяли трубку: 54 → 55 (тестовые исключены)
|
||
- Согласовано: 186 (42.5%) → **156 (35.1%)**: логист 112 · робот 26 · ссылка 18
|
||
- «Чем подтвердили» = «Как согласовали дату»: 112 / 26 / 18 (раньше 25/137/24 против 116/24/18)
|
||
- Закрыто без согласования: **128** — вынесено отдельной цифрой в «Путь заказа»
|
||
- Не достали: было одной цифрой 236 → **25 ещё в работе + 293 заказа уже закрыты** (раньше закрытые прятались, потому что считались «согласованными»)
|
||
|
||
## Критическое, что нашлось попутно и выложено раньше
|
||
|
||
Согласование по ссылке не работало с 29.09: `confirmDeliveryChoice` читал переменную `src`, которой нет среди параметров (`p_src: src || null`) → `ReferenceError: src is not defined`. Клиент на странице выбора слота получал ошибку, выбор не сохранялся, канал согласования в заказ не записывался.
|
||
|
||
Доказательства: живая сборка содержала `p_src:src`; тест `deliveryInvitationApi.test.js` падал с тем же `ReferenceError`; последнее подтверждение по ссылке в БД — 28.09 (миграция каналов — 29.09). Исправлено коммитом `f2a9249`, канал (`sms`/`push`/`messenger`/`client`) снова записывается.
|
||
|
||
## Выложено
|
||
|
||
- Фронт: прод dost.supersamsev.ru и dev dev.mkn8n.ru, SW v135 (коммиты `f2a9249`, `6dba84f`, `bf2b355`, `c8e9e69`).
|
||
- БД: миграция `supabase/migrations/20261002_confirmation_honesty.sql` (статус + триггер + backfill 128 строк), обновлённый RPC `supabase/admin_comms_funnel.sql`.
|
||
- Планировщик автодозвона на .8: новый статус исключён из выборки (md5 сверен с локальным).
|
||
- Тесты: 19/19 в блоках аналитики, 51/51 по затронутым файлам; полный прогон — 11 падений, и все в файлах, которых правки не касались (проверено возвратом `orderGroupViews.js` — список падений не изменился).
|
||
|
||
## Чего не проверял
|
||
|
||
Клик-прогон админки под логином (вход по OTP, доступа у меня нет). Вместо этого оба блока отрисованы на **живом ответе RPC**: цифры согласованы (сумма каналов = стадия) и сырые ключи/«Неизвестно» на экране отсутствуют. Визуальный вид реестра с новым статусом стоит глянуть глазами при следующем входе.
|
||
|
||
Проверки, по которым получены цифры: `/tmp/ss_analytics_check*.sql`, `/tmp/ss_fix_recon.sql` (выполнены на .8 в контейнере `supabase-db`).
|