Ошибки формы и качество конверсии

Упорядоченная воронка показала, где часть учебных сессий перестаёт проходить этапы. Теперь рассмотрим отправку формы подробнее. Один посетитель может ошибиться, исправить значение и отправить снова. Если считать каждую попытку человеком, отчёт потеряет смысл.

Результат урока — несколько связанных показателей качества формы. Используем отдельный вымышленный снимок form-v1. Его session_id обозначают собственные строки примера и не объединяются автоматически со снимком предыдущего урока.

Попытка и завершение

Попытка имеет request_id. Сервер может отвергнуть её по правилам данных, принять в обработку или завершить подтверждение. Отправка, принятие и результат относятся к разным моментам процесса.

В учебном CSV восемь уникальных попыток. Шесть соответствуют правилам данных, четыре приняты, две связаны с подтверждением. Пять сессий сделали хотя бы одну попытку. Одна доставка записи повторена, поэтому в исходном файле девять строк.

Значения адресов и содержимое формы не включены в CSV. Для объяснения достаточно категории ошибки и связи попытки. Это уменьшает лишние данные и сохраняет различие между наблюдением поведения и хранением личного содержания.

Структура снимка

Каждая строка содержит request_id, session_id, document_id, valid, accepted, confirmed и error_code. Булевы значения записаны как 0 и 1. Accepted не может быть истинным при valid=0; confirmed требует accepted=1.

Категория	Значение	Следующая диагностика
invalid_format	Данные не соответствуют форме	Подпись поля и обратная связь
missing_confirmation	Не выполнено обязательное условие формы	Понятность назначения условия
rate_limit	Сервер ограничил попытку	Причина и возможность повтора
capacity	Запрос не принят из-за ресурса	Состояние обслуживания
пустая категория	Нет зафиксированного отказа	Статус подтверждения

Название категории является нашим учебным договором. Оно не копируется из произвольного сообщения библиотеки и не показывает полный введённый текст. Для настоящей формы перечень должен соответствовать обработчику.

Расчёт без повторной доставки

Ниже полный form_report.py. Он проверяет согласованность строк, сводит повтор request_id и считает разные знаменатели.

import csv
from pathlib import Path

def report(rows):
    unique = {}
    for row in rows:
        item = dict(row)
        for key in ("valid", "accepted", "confirmed"):
            if item[key] not in {"0", "1"}:
                raise ValueError("Неверный признак")
            item[key] = int(item[key])
        if item["confirmed"] > item["accepted"] or item["accepted"] > item["valid"]:
            raise ValueError("Несогласованные этапы")
        key = item["request_id"]
        if key in unique and unique[key] != item:
            raise ValueError("Конфликт request_id")
        unique[key] = item
    items = list(unique.values())
    sessions = {row["session_id"] for row in items}
    completed = {row["session_id"] for row in items if row["confirmed"]}
    return {
        "attempts": len(items),
        "valid": sum(row["valid"] for row in items),
        "accepted": sum(row["accepted"] for row in items),
        "confirmed": sum(row["confirmed"] for row in items),
        "sessions": len(sessions),
        "completed_sessions": len(completed),
    }

if __name__ == "__main__":
    with Path(__file__).with_name("form.csv").open(newline="") as source:
        print(report(csv.DictReader(source)))

Ожидаемый отчёт содержит 8, 6, 4, 2, 5 и 2 соответственно. Повтор доставки не создаёт девятую попытку. Если одинаковый request_id имеет противоречивые поля, алгоритм сообщает об ошибке вместо выбора удобного значения.

В настоящем потоке статус может развиваться во времени. Тогда строки одного request_id с accepted и confirmed могут быть разными событиями законной последовательности. Наш CSV уже содержит итоговый снимок, поэтому конфликт имеет другой смысл. Договор источника определяет алгоритм.

Несколько долей

Подтверждений на попытку получается 2/8, или 25%. Подтверждённых сессий среди отправлявших — 2/5, или 40%. Доля принятых среди корректных попыток — 4/6. Это три разные характеристики, и ни одну не следует подписывать просто «конверсия».

Повторное исправление формы может ухудшить показатель на попытку и улучшить итог по сессии. Например, посетитель сначала получил понятную ошибку, затем успешно закончил. Само увеличение числа попыток не определяет ухудшение удобства.

Доля результата среди всех показов предложения требует данных первого этапа. Наш form-v1 содержит только отправлявшие сессии. Нельзя взять его два подтверждения и поделить на случайное число открытий другой недели.

Обратная связь формы

Для ошибки формата полезно показать конкретное поле и сохранить остальные допустимые значения. Для временного отказа сервера нужно объяснить возможность повтора. Одна фраза «что-то пошло не так» не помогает различить действия.

При этом повышение результата не должно означать отключение необходимой проверки. Если форма перестала отклонять некорректные адреса, число accepted выросло, но подтверждений может не стать больше. Основная метрика остаётся полезным результатом.

Не отправляйте в аналитику полный email или текст ошибки, содержащий пользовательские данные. Устойчивый короткий error_code позволяет исследовать категорию. Ограничения сервисов и политика конкретного проекта проверяются перед настоящим подключением.

Повтор и серверный результат

Двойное нажатие кнопки может создать две сетевые попытки. Блокировка кнопки помогает интерфейсу, но не гарантирует единственную серверную операцию. Для чувствительного действия нужен механизм идемпотентности и известная область request_id.

Наш расчёт удаляет повтор доставленной строки отчёта. Это не выполнение идемпотентности самой формы. Если сервер создал две записи с разными ID, аналитическая дедупликация не отменит вторую операцию.

Подтверждённый результат должен приходить из источника, который его действительно знает. Страница после нажатия кнопки не доказывает подтверждение адреса. Для учебного снимка этот факт задан явно; настоящая интеграция должна иметь проверяемую связь.

Выбор исследования

На восьми попытках нельзя доказать универсальную причину отказов. Сначала воспроизведите известный сценарий поля и состояние обслуживания. Затем соберите больший согласованный снимок и рассмотрите новые группы.

Проверьте также мобильный ввод, клавиатуру и понятность сообщений. Такая диагностика исследует механизм формы, а не только число в таблице. Изменение подписей нужно фиксировать отдельно от изменения договора событий.

Незавершённое окно

Некоторые попытки приняты, но ещё не имеют подтверждения. Если снимок сделан сразу после отправки, такой статус может быть нормальным ожиданием. В form-v1 отсутствует время каждой стадии, поэтому из него нельзя оценить скорость подтверждения.

Для настоящего сравнения нужно определить одинаковую зрелость результата. Например, обе группы должны иметь полное выбранное окно, а новые незавершённые попытки показываются отдельно. Иначе вчерашняя группа получит больше времени на завершение, чем сегодняшняя.

Категория ошибки также не равна окончательному исходу сессии. После invalid_format человек может успешно исправить ввод. Сохраняйте связь попыток, чтобы увидеть восстановление, а не объявлять каждую ошибку потерянным посетителем.

Если нужны данные до отправки, используйте известный договор form_start. Снимок одних запросов ничего не говорит о тех, кто открыл форму и ушёл без POST. Этот предел важен при выборе следующего исследования интерфейса.

Теперь отчёт различает попытку, принятие и завершение, сохраняя правильные знаменатели. Следующий урок задаст контролируемое сравнение двух вариантов, чтобы рост после правки не превращался автоматически в причинный вывод.