Когда стоит проверить сайт
Аудит полезен перед запуском рекламы, после добавления формы, смены CRM или подключения аналитики. Проверка нужна и тогда, когда документы уже размещены, но никто не сверял их с текущей работой сайта. Копия политики с другого проекта не объясняет, куда уходят именно ваши заявки.
Начинаем с опубликованных страниц и поведения сайта в браузере. Для бесплатной проверки достаточно адреса. Если часть функций доступна только после входа, заранее обозначим, какие выводы можно сделать без доступа и что потребуется посмотреть дополнительно.
Как определяем охват аудита
Перед проверкой уточняем, что относится к вашему проекту: основной домен, отдельные посадочные страницы, поддомены, магазин и личный кабинет. Если форма открывается во всплывающем окне или появляется после выбора услуги, учитываем способ ее вызова. Так в перечень проверки попадают действующие сценарии, которые нельзя увидеть по одному снимку главной страницы.
Большое количество адресов не всегда означает столько же разных способов обработки. Одинаковая форма может повторяться в карточках товаров, а на внешне похожих страницах могут использоваться разные приемники заявок. При согласовании охвата разделяем повторяющиеся шаблоны и самостоятельные сценарии. Отдельно перечисляем участки, для которых нужны авторизация, специальные права или участие сотрудника владельца.
Если требуется проверить только конкретное изменение, например новую форму записи, фиксируем эту границу. В выводах будет понятно, какие страницы и действия мы посмотрели, а какие остались за пределами задачи. Непроверенный личный кабинет не получает положительную оценку только потому, что открытая часть сайта работает правильно.
Что входит в проверку
- Формы заявки, подписки, обратного звонка и регистрации: поля, тексты, ссылки и порядок получения согласия.
- Политика обработки персональных данных: реквизиты, цели обработки, получатели и доступность документа на страницах сбора.
- Cookie, счетчики аналитики, чаты и виджеты: какие запросы отправляются при открытии страницы и после выбора посетителя.
- Маршрут заявки: сайт, почта, CRM и другие приемники, которые можно установить по коду и сведениям владельца.
- Вопросы к уведомлению в Роскомнадзор, если обработка требует его подачи.
Разделяем обнаруженный факт и предположение. Например, сетевой запрос подтверждает обращение к сервису, но не раскрывает все условия договора с ним. Адрес хранения данных уточняем по сведениям хостинга и подключенных систем.
Последовательность проверки формы
Сначала открываем страницу как новый посетитель и фиксируем доступные поля, обязательность заполнения и тексты рядом с кнопкой. Затем просматриваем документ по ссылке: совпадают ли оператор и назначение обработки с конкретным обращением. Проверяем, можно ли прочитать условия до отправки и вернуться к форме, сохранив возможность сделать осознанный выбор.
Далее проверяем поведение интерфейса. Если для сценария требуется согласие, пробуем отправить форму без него, затем с выбранным согласием. Учитываем повторное открытие окна, сообщения об ошибках и вариант с телефона. Для проверки не нужны настоящие сведения клиентов: состав тестовых данных и допустимые действия согласуем так, чтобы обращение не создало реальный заказ или платную операцию.
Отправку рассматриваем по этапам. Нажатие кнопки подтверждает действие в браузере. Ответ сервера показывает, как обработан запрос. Появление записи в согласованном приемнике позволяет проверить следующий участок пути. Эти наблюдения записываем раздельно, поскольку сообщение с благодарностью может появиться и тогда, когда запись дальше не сохранилась.
При проверке аналитики открываем сетевые запросы и хранилище браузера. Сопоставляем загрузку сервисов с выбором посетителя и сведениями в документах. Если требуется доступ к настройкам счетчика или CRM, указываем, какую часть вывода он позволит подтвердить. Недоступность системы отмечаем в отчете, не заменяя ее предположением об успешной передаче.
Как описываем найденное замечание
- Адрес страницы и действие, при котором обнаружено расхождение.
- Наблюдаемый факт: состояние поля, текст, запрос или ответ обработчика.
- Сведения владельца, которые нужны для уточнения вывода.
- Предлагаемое изменение и способ повторной проверки.
Как выглядит результат
Вы получите перечень замечаний с адресами страниц и объяснением, что нужно изменить. Отдельно укажем вопросы, для которых не хватает информации. Такой список помогает выбрать работы и проверить их выполнение.
Пример формата замечания: на странице заявки согласие отмечено заранее; нужно изменить поведение поля и повторить отправку формы. Это иллюстрация структуры отчета, а не история выполненного клиентского проекта.
Если захотите поручить исправления нам, согласуем документы и технические изменения до начала работ. Бесплатный аудит не обязывает заказывать доработку. После исправлений повторно проверим согласованные сценарии, включая отправку заявки и работу сайта на телефоне.
Как использовать отчет для исправлений
Замечания удобно разбирать по последовательности действий. Например, сначала нужно установить получателя заявки, затем уточнить документ и только после этого менять текст рядом с формой. Если сразу установить дополнительную галочку, исходное расхождение между настройками и документами может сохраниться. Поэтому объясняем зависимость предложенных шагов, когда она влияет на результат.
В согласованном перечне задач можно отделить изменение текста от настройки сайта и уточнения сведений у подрядчика. Владельцу будет понятно, какое действие выполняет разработчик, какое требует его ответа и почему отдельный пункт пока нельзя закрыть. Это особенно полезно, если документы готовил один исполнитель, а форму и CRM поддерживает другой.
Для приемки исправления используем исходный сценарий замечания. Повторно открываем ту же форму, проверяем доступность документа и воспроизводим действие, которое раньше приводило к проблеме. Если получатель или настройка изменились в ходе работ, обновляем описание проверенного пути. Положительный результат относится к этому сценарию и текущей конфигурации, а не к любым будущим изменениям сайта.
Предоставление доступов и объем технической доработки обсуждаются отдельно от бесплатного первичного просмотра. Описание подробной проверки не означает обследование всех внутренних систем бизнеса без согласования. Если требуется участие администратора CRM, заранее определяем, какой результат он должен показать и какие сведения при этом не нужно раскрывать.
Что потребуется от владельца
Для уточнения выводов понадобятся сведения об операторе, целях сбора, сервисах приема заявок и сроках хранения. Доступ к админке запрашиваем для согласованных изменений. Если сайт поддерживает другой разработчик, можем подготовить перечень задач для него.
Условия повторной проверки
Если замечание проявляется не всегда, в рабочем описании нужны условия воспроизведения: страница, последовательность действий, версия формы и используемое устройство. После изменения проверяем тот же путь. Отдельный успешный тест не закрывает другие согласованные сценарии, если они еще не проверены. Такая запись помогает владельцу отличить устраненную причину от случая, когда проблема просто не проявилась при одном открытии.
Условный пример: две похожие формы
Предположим, на главной странице есть заявка на консультацию, а в карточке услуги используется внешне такая же форма. Первая записывает обращение в базу сайта, вторая отправляет его во внешний сервис. При этом обе ведут на политику, в которой описана только отправка писем. Такой пример помогает понять, почему проверка каждой самостоятельной настройки важнее простого подсчета одинаковых галочек.
Вначале устанавливаем реальные получатели обеих форм. Затем уточняем у владельца назначение обращений, условия работы с сервисом и дальнейшее хранение. После этого можно предложить согласованные изменения документов и настроек. Если поставщик не сообщил необходимые сведения, вопрос остается открытым и явно обозначается в выводах.
Результатом исправления в этом условном случае будет согласованное описание двух путей заявки и повторная проверка каждого. Само добавление названия сервиса в политику еще не подтверждает, что все условия обработки соблюдены. Для выводов нужны сведения о процессе и фактические результаты проверки, доступные в пределах заказа.
Передать результаты можно владельцу либо разработчику, который будет устранять замечания. При обсуждении достаточно сослаться на номер пункта и адрес страницы: это уменьшает риск, что подрядчики исправят разные версии формы. Пример не описывает выполненный клиентский проект и не задает обязательный набор изменений для любого сайта.
Сроки и границы проверки
Бесплатный аудит занимает 24 часа. Срок исправлений определяем после проверки: он зависит от числа форм, платформы и интеграций. Для стандартного сайта ориентир составляет 2-3 дня после получения необходимых сведений и доступов.
Правовые основания обработки оцениваем по статье 6 закона о персональных данных. Проверка сайта не охватывает все процессы организации и не заменяет аттестацию информационных систем. Ее результат относится к доступным страницам, предоставленным сведениям и согласованному объему работ.
