Маркетинговая команда запускает лендинг, подключает аналитику, добавляет квиз и настраивает передачу обращений в CRM. Перед стартом проверяют объявления, бюджет, работу кнопок и получение заявок.
Вопросы персональных данных иногда сводятся к двум действиям: разместить политику и добавить галочку под формой. Но за интерфейсом сайта может находиться несколько сервисов, подрядчиков и мест хранения информации.
Для бизнеса это задача согласованной работы маркетинга, разработки и специалистов по персональным данным. Разберем, что стоит включить в подготовку рекламного проекта и как сформулировать запрос на проверку.
Рассмотрим условный проект: компания продвигает ремонт квартир.
Пользователь переходит из объявления, проходит квиз, указывает телефон и оставляет комментарий. Контакт поступает в CRM, копия — на почту, а уведомление — ответственному менеджеру. Позже компания решает предложить этому человеку другие услуги.
С точки зрения маркетинга это последовательность касаний. С точки зрения работы с данными — несколько операций, целей и участников, которые необходимо учитывать.
Поэтому полезно описать два маршрута одновременно:
Такое сопоставление помогает увидеть, какие сведения нужны для каждой задачи и где появляются дополнительные копии.
В рекламных проектах набор подключений меняется быстро. Сегодня работает форма обратного звонка, завтра появляется квиз, затем — чат и сервис рассылок.
Если каждый инструмент добавляет отдельный подрядчик, единого описания процесса может не быть.
Перед запуском стоит собрать таблицу:
ИнструментКакие данные получаетДля какой задачиКуда передаетФорма расчетаКонтакты и параметры запросаПодготовка ответаCRM и почтаЧатПереписку и сведения, оставленные посетителемКонсультацияСервис чата и подключенные системыФорма подпискиАдрес электронной почтыОтправка выбранных материаловПлатформа рассылок
Это пример структуры, а не универсальное описание любого сайта. В рабочей версии нужно указать реальные сервисы, получателей и настройки.
Отдельно учитываются инструменты аналитики. Для них важно установить состав собираемой информации и определить, относится ли она к персональным данным в конкретной схеме использования.
Контакт, оставленный для расчета стоимости, не следует автоматически считать разрешением на любое дальнейшее взаимодействие.
Ответ на запрос, исполнение договора и рекламная рассылка — разные цели. Для каждой необходимо определить подходящее правовое основание и проверить применимые требования.
Согласие является одним из оснований обработки, но не единственным. Поэтому подход «поставим одну галочку на все случаи» требует пересмотра.
Если обработка основана на согласии, важно проверить его содержание, способ получения и возможность подтвердить действие пользователя. Действующее требование статьи 9 закона № 152-ФЗ предусматривает отдельное оформление согласия от другой информации и документов, которые подтверждает или подписывает человек.
Для маркетинговой команды это означает: логику формы и документов нужно обсуждать до запуска, а не после того, как накопилась база контактов.
Политика обработки персональных данных должна соответствовать реальным процессам компании. Она не заменяет согласие там, где оно используется, и не исправляет технические настройки.
При проверке лендинга полезно пройти весь сценарий пользователя:
Статья 18.1 закона № 152-ФЗ предусматривает публикацию политики при сборе персональных данных через интернет и обеспечение доступа к ней.
При этом одного работающего документа на главном сайте может быть недостаточно для организационного контроля: отдельные рекламные страницы, поддомены и новые формы тоже нужно включать в проверку.
Успешное сообщение «Спасибо, ваша заявка принята» подтверждает только часть пользовательского сценария.
Внутри компании нужно выяснить:
Особое внимание стоит уделять доступам рекламных агентств, разработчиков и временных сотрудников. Передача проекта другой команде — повод проверить учетные записи и разрешения.
Вопросы локализации, возможной трансграничной передачи и условий работы внешних сервисов оцениваются отдельно, по фактической схеме.
Даже тщательно подготовленный проект может измениться после старта.
Маркетолог добавляет новую механику, отдел продаж просит дополнительные поля, разработчик подключает виджет. Каждое изменение способно повлиять на состав данных или их маршрут.
Поэтому полезно установить правило: при добавлении инструмента команда отвечает на несколько вопросов.
Какая новая информация появляется? Например, к телефону добавляются адрес объекта или загружаемые документы.
Зачем она нужна? Цель должна быть конкретной и понятной.
Кто ее получает? Нужно учитывать сервисы и людей.
Что меняется в документах и настройках? Ответ зависит от конкретного процесса.
Так проверка становится частью запуска, наряду с тестированием формы и рекламной аналитики.
Запрос «проверьте сайт на 152-ФЗ» слишком широкий. Без уточнений заказчик и исполнитель могут по-разному понимать объем работы.
При обращении в Proverka-152fz.ru стоит заранее подготовить перечень рекламных страниц, форм и известных интеграций. Затем согласовать, что именно будет изучено: публичная часть сайта, технические подключения, документы или внутренние процессы.
В результате проверки полезно получить по каждому замечанию:
Важно также определить границы заключения. Внешний просмотр сайта не позволяет достоверно оценить договоры с подрядчиками, права доступа в CRM и все места хранения данных.
Конкретный состав услуг Proverka-152fz.ru следует подтвердить перед началом работы.
Проверку трудно полностью передать одному сотруднику.
Маркетинг знает, какие механики используются и для чего собираются сведения.
Разработка понимает технический маршрут, настройки форм и интеграций.
Специалист по персональным данным оценивает основания обработки, документы и применимые обязанности.
Руководитель процесса назначает ответственных, согласует изменения и контролирует выполнение.
Отдельно рассматриваются вопросы уведомления Роскомнадзора и другие обязанности оператора. Они не решаются только добавлением текста на лендинг.
Наличие отчета — промежуточный этап. Работа завершается после исправлений и повторной проверки затронутых сценариев.
Если менялась форма, нужно убедиться, что она корректно работает и фиксирует предусмотренные действия. Если ограничивались доступы — проверить результат в системе. Если обновлялись документы — разместить актуальные версии и убедиться в их доступности.
Для маркетингового проекта полезно сохранить карту движения данных и назначить сотрудника, который будет поддерживать ее в актуальном состоянии.
Хорошая отправная точка — одна тестовая заявка. Проследите ее путь от рекламной страницы до сотрудника и хранения. Это покажет, где нужны технические исправления, где — обновление документов, а где — согласование процессов внутри компании.