Мы исследуем, как компании получают согласия и чем подтверждают их в спорах. Здесь — разбор доказательств и вопросы к своему процессу. Ссылка на наш проект будет в конце.
В деле Томского УФАС № 070/05/18-297/2026 компания представила копию электронного согласия и лог-файл. По её пояснениям, согласие фиксировали отметки advertisment: done и personal data: done.
Комиссия указала: «Данного лог-файла недостаточно для однозначной идентификации пользователя». В решении она также сослалась на обстоятельства, установленные при рассмотрении аналогичного дела: необходимый верификационный звонок не поступил, код подтверждения не был введён. Этот шаг был обязательным в процедуре самой компании. Доказательств технического сбоя, которым объясняли незавершённую проверку, компания не представила.
На вопрос «согласие у нас есть?» можно было предъявить сразу два артефакта. На вопрос «почему мы считаем, что его дал именно этот человек?» их оказалось недостаточно.
Согласие как документ описывает, на что человек соглашается. В споре понадобится восстановить ещё и обстоятельства получения согласия, а для конкретной рассылки — объяснить, почему оно распространялось на эту отправку и не было ли отозвано к тому моменту.
Разработчику, аналитику и DPO здесь приходится разбираться в одном процессе. У каждого есть своя часть ответа: текст, действие в форме, запись в системе, история рассылки.
Подпись на бумаге тоже можно оспорить
В деле Коми УФАС № 011/05/18-605/2019 в подтверждение согласия представили анкету с именем, телефоном и подписью заявителя. Он сообщил, что почерк и подпись ему не принадлежат. Заявитель также представил выписку, которую комиссия приняла как подтверждение его нахождения в Ухте в день заполнения анкеты, связанной с Ижевском.
В анкете также были исправления в дате и ошибка в отчестве. Комиссия оценила эти обстоятельства в совокупности и не признала анкету достаточным подтверждением волеизъявления заявителя. Почерковедческой экспертизы в решении нет; факт подделки документа не установлен.
У этих дел разные носители согласия. Поэтому из первого нельзя сделать вывод «надо собирать на бумаге», а из второго — «надо переходить на электронную подпись». В обоих случаях пришлось проверять связь между предъявленным артефактом и действием человека.
Дальше — наша модель проверки процесса, а не перечень требований ФАС из этих двух решений.
Что человек видел и на что согласился
Начать стоит с одного сценария: например, человек оформляет услугу и отдельно выбирает рекламную рассылку. Какие формулировки он видит рядом с кнопкой? Что написано у отметки? На какой документ она ведёт? Можно ли продолжить оформление без рекламного согласия?
Для проверки прошлого действия нужен текст, который действовал тогда. Ссылка на сегодняшний PDF этого не решает: документ могли обновить. Полезно сохранять редакцию согласия вместе с версией формы, где его предлагали. Иначе можно найти правильный документ, но так и не установить, показывался ли он этому пользователю.
Такая связь особенно нужна, когда на одном экране есть отдельная отметка про рекламу и общая фраза под кнопкой. Документ может описывать один выбор, а интерфейс — другой. Сначала это вопрос к владельцу формы: какое действие вы считаете согласием и что сохраняете о нём?
Для проверки согласия нужны сведения о каждом этапе — от предложенного выбора до исполнения отзыва.
Что произошло после нажатия
В томском деле отметки из лог-файла не подтвердили завершение предусмотренной процедуры. Это повод задать своей команде конкретный вопрос: что именно означает наша отметка об успехе?
Она может означать, что запрос принят, форма отправлена или все предусмотренные шаги завершены. Для пользователя это один короткий сценарий. Внутри системы события могут оказаться разнесены — и одна запись не обязательно подтверждает остальные.
Начните с незавершённого обязательного шага в собственной форме: не вводите код подтверждения и проверьте, какое состояние сохранилось. Может ли пользователь с таким состоянием попасть в аудиторию рассылки?
Отдельно нужно понять, с кем связано действие. Наличие номера в анкете ещё не объясняет, кто его указал. Успешное подтверждение номера даёт дополнительные сведения, но его тоже нужно связать с тем же действием и текстом. Код из другой сессии или общий факт авторизации не отвечают автоматически на вопрос о конкретном согласии.
Почему это согласие разрешало именно эту отправку
Даже бесспорное получение согласия не объясняет любую последующую рекламу. Нужно сопоставить его содержание с конкретной операцией: кто отправил сообщение, по какому каналу и на что распространялся выбор человека.
Представим рабочую ситуацию: пользователь разрешил рекламные SMS, затем пожаловался на письмо. Чтобы ответить, недостаточно показать общий статус «согласен на маркетинг». Нужно найти текст и выяснить, был ли email охвачен согласием. Это условный пример проверки, не обстоятельства приведённых дел.
При таком разборе полезнее идти от сообщения назад, чем от папки с согласиями вперёд. Найдите основание отправки, затем — редакцию текста и действие человека. При проверке может обнаружиться, например, что система хранит историю выбора, но рассыльщик использует только общую выгрузку без сведений о её актуальности.
Текущий статус в CRM может оставаться удобным для работы. Но для объяснения прошлой отправки нужна история: какое разрешение учитывали именно в тот момент. Перезапись отметки после отзыва не должна уничтожать возможность это установить.
Где заканчивается отзыв
Пользователь отозвал согласие, сотрудник изменил статус, обращение закрыли. Остался практический вопрос: что стало с сообщениями, которые уже запланированы?
Если аудиторию выгрузили вчера, сегодняшнее изменение в CRM может до неё не дойти. Поэтому при проверке отзыва смотрим не только на запись обращения, но и на то, кто получил новый статус и что сделал с очередью отправок.
Есть и более узкий случай: отзыв поступил, когда сообщение уже передали внешнему сервису. Возможность остановить его зависит от того, на каком этапе находится отправка и умеет ли сервис её отменять. Обещать, что одна проверка статуса исключит все такие ситуации, нельзя.
Для разбора понадобятся время поступления отзыва, сведения о передаче нового статуса и результат отмены. Если отправка всё же состоялась, эта последовательность позволит установить, где и когда возник разрыв. Одной отметки «отзыв обработан» для этого мало.
Что мы можем увидеть снаружи
На сайте видны форма, исходное состояние отметок, подписи и связанные документы. Какой выбор сохранился у конкретного человека, как его проверили перед рассылкой и дошёл ли отзыв до подрядчика — нужно выяснять у владельца процесса. Отсутствие этих сведений во внешнем отчёте не означает, что компания ими не располагает.
Одна проверка вместо общего вопроса «всё ли у нас нормально»
Возьмите одну реальную рекламную отправку и попросите собрать сведения о ней:
редакцию текста согласия и версию формы, предъявленные человеку при получении согласия
его действие и результат предусмотренной проверки
объяснение, почему согласие охватывало эту отправку
историю отзыва, если он поступал, и сведения о его исполнении
Проверьте, что собранные сведения относятся к одному человеку и нужной отправке: актуальный текст с сайта или журнал другой сессии не заменят недостающие материалы.
Полученный набор не гарантирует исход спора: содержание согласия и обстоятельства его получения тоже подлежат оценке. Зато он позволяет обсуждать конкретный пробел — утраченную редакцию, незавершённую проверку или неисполненный отзыв — вместо очередного переписывания документа на всякий случай.
Исходные кейсы и полный разбор модели собраны в исследовании Percival Lab.
Если завтра пользователь оспорит одну рассылку, что в вашей команде будет сложнее всего восстановить: его выбор, основание отправки или исполнение отзыва?
