Skip to main content

Исходы звонка: call_status и status_reason

call_status — финальная корзина завершённого звонка (пустая строка до финализации). Одна ось, один источник истины; качество (call_successful) и техническая надёжность (health) — отдельные оси и в статус не протекают: status_reason — уточнённая причина, всегда принадлежащая ровно одной корзине:
busy и user_declined — разные причины. busy означает «занято», user_declined — реальное отклонение вызова абонентом. Если вы строите отчёты по причинам недозвона, разводите их по этим двум значениям, а не по одному.Второе следствие для вашей логики повторов: постоянна ли причина, зависит от рынка. user_declined закрывает номер окончательно только на профиле США; на других профилях причина временная, и номер возвращается в набор, потратив попытку. Проверка запуска кампании отклоняет правило expert, которое повторяет постоянный исход (rule_permanent_retry).
health_reasons — коды, объясняющие вердикт warning/error. Вердикт звонка — худший из сработавших: любой код уровня «ошибка» делает звонок error, иначе warning. Словарь открытый, новые коды со временем добавляются — незнакомый код не считайте ошибкой разбора. Коды приходят из четырёх источников. Разделение важно: в health_reasons попадает результат правила, а не его вход — значения status_reason и внутренние коды событий здесь не встречаются никогда. 1. События звонка — что-то пошло не так внутри разговора: 2. Ось статуса звонка — сюда сворачиваются значения status_reason: Причины на стороне абонента (no_answer, busy, user_declined, invalid_destination, spam_blocked) и отмены по вашему решению до набора (cancelled_by_function, cancelled_by_operator) в вердикт не входят: это не дефекты платформы. 3. Пост-аналитикаanalysis_skipped, analysis_failed, analysis_interrupted, все уровня «предупреждение», по терминальному состоянию разбора. 4. Запись и таймингиrecording_head_lost (часть записи не существует) и slow_turns (90-й процентиль длительности тёрна выше настроенного порога), оба «предупреждение».