8.7 KiB

Raw Permalink Blame History

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).

8.7 KiB Raw Permalink Blame History Unescape Escape