Где сайт получает и передаёт данные
Карта данных начинается с конкретных полей: имя, телефон, email, адрес, комментарий к заказу, файл и идентификатор пользователя. Для каждого источника отмечаются получатель, место хранения, срок и внешние сервисы. Отдельно проверяются URL, параметры запросов, журналы ошибок и аналитические события, куда персональные данные часто попадают незаметно для владельца сайта.
Такая карта нужна для практических изменений. По ней можно убрать лишнюю передачу в Метрику, перенести обработку формы, ограничить содержание журналов и связать запрос пользователя на удаление с реальными записями в системах.
- формы, регистрация, заказы и личный кабинет
- аналитика, рекламные пиксели, чат и коллтрекинг
- URL, серверные логи и журналы ошибок
- CRM, почта, облачные хранилища и внешние API
- резервные и тестовые копии
Согласие, отзыв и доказательство действия
Техническая реализация согласия связывает текст документа, его версию, время, форму, пользователя и выбранные каналы связи. Для рекламных email и SMS полезно хранить отдельный статус каждого канала, тогда изменение одного выбора сохраняет остальные.
Отзыв согласия превращается в управляемый процесс: запрос регистрируется, связанные записи находятся в согласованных системах, действие фиксируется в журнале, а заявителю можно сообщить о результате. Страница услуги подробно описывает конкретную реализацию и способ приёмки.
Cookie, аналитика и сторонние скрипты
Cookie-баннер полезен, когда его выбор действительно управляет согласованными категориями тегов. Для этого составляется перечень скриптов, определяется момент их запуска и проверяется поведение при каждом варианте выбора. Отдельная проверка сторонних скриптов и Google Tag Manager показывает, какие домены получают данные со страницы.
В Метрике и других системах аналитики проверяются значения параметров, событий и URL. Телефон, email, номер заказа или токен доступа удаляется либо заменяется безопасным техническим идентификатором до отправки внешнему сервису.
Хранение, удаление и тестовые базы
Срок хранения превращается в понятное правило для конкретных таблиц, файлов и журналов. Автоматическое удаление выполняется по расписанию, оставляет запись о выполнении и очищает связанные вложения и дубли вместе с основной записью.
Для разработки используется обезличенная тестовая база: реальные ФИО, контакты, адреса и реквизиты заменяются согласованными значениями с сохранением структуры и связей. Документы и таблицы дополнительно проверяются на свойства файла, комментарии, историю правок и скрытые листы.
Что получает клиент
Результатом становится работающий технический механизм: журнал согласий, управляемая блокировка тегов, очищенные аналитические события, локализованный маршрут формы, процедура удаления, обезличенная тестовая база или защищённый обмен файлами. Приёмка строится на контрольных сценариях: отправка формы, изменение выбора, отзыв, истечение срока или попытка получить чужой документ.
- описание затронутых источников и систем
- настроенный механизм и журнал выполнения
- контрольные примеры для повторной проверки
- инструкция для владельца процесса
Как проверяется техническая реализация
Контрольный сценарий повторяет реальный путь пользователя. Тестовая заявка отправляется с понятными значениями, после чего проверяются база, CRM, письмо, журнал и сетевые запросы браузера. Для согласий отдельно фиксируются версия текста и выбранные каналы, для удаления — связанные записи и результат фонового задания.
Проверка затрагивает также ошибочные сценарии: закрытие формы, повторную отправку, отозванное согласие, истёкший срок хранения и попытку скачать документ другого пользователя. Такой подход показывает весь механизм, включая серверную обработку, журнал и связанные системы.
Для локализации и внешних сервисов сохраняется техническое подтверждение маршрута: адрес получателя, момент отправки, состав полей и результат после изменения. Это позволяет повторить проверку при обновлении формы, счётчика или менеджера тегов.