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