Два сайта и три модели продаж: как мы разобрались с персональными данными интернет-магазина бытовой техники

Иногда работа с персональными данными начинается с чекбокса, а заканчивается вопросом: кто вообще продаёт товар?

Клиент попросил проверить формы на двух сайтах интернет-магазина бытовой техники: регистрацию, заказ, обратный звонок, возврат и рекламную подписку. Но когда мы стали выяснять, кому после отправки формы попадают имя, телефон и адрес покупателя, обнаружились три разные модели продаж.

В одном случае товар продавал владелец сайтов, в другом — поставщик, а иногда заявка уходила контрагенту, который уже сам находил конечного продавца. Чтобы привести в порядок персональные данные, сначала пришлось разобраться во всей системе продаж.

Коротко о проекте

Клиент

Интернет-магазин бытовой техники. Название и сведения об участниках проекта не раскрываем.

Масштаб

Два сайта, собственная CRM, несколько поставщиков, платёжные и кредитные сервисы, доставка и дополнительные услуги.

Начальная задача

Проверить формы сайтов и подготовить документы по персональным данным.

Главная сложность

Определить продавца, получателя заявки и ответственного за данные покупателя в каждой из трёх моделей.

Результат

Согласованная модель продаж и обработки данных, новая оферта, политика, отдельные согласия, инструкция разработчику и черновик изменения уведомления Роскомнадзора.

Начали с форм, а пришли к устройству бизнеса

Мы прошли все места, где посетитель мог оставить данные. В результате аудита выделили десять проблемных зон, шесть из них — высокорисковые.

В одних формах согласие на обработку данных было объединено с политикой и офертой. В регистрации отдельного согласия не было. Рекламную подписку можно было оформить без самостоятельного согласия на рекламу. Политика не охватывала быстрые заказы, возвраты и часть внешних сервисов, а уведомление Роскомнадзора — всю работу интернет-магазина.

Исправить формулировки без понимания бизнеса было нельзя: сначала требовалось выяснить, кто получает заказ и на каком основании.

Мы направили клиенту опросник о сайтах, CRM, телефонии, поставщиках, банках и доставке. Он заметил, что на самостоятельное заполнение может уйти неделя. Поэтому известные сведения мы собрали сами, а оставшиеся вопросы разобрали во время коротких звонков. Клиент рассказывал, как проходит заказ, мы уточняли участников и сопоставляли ответы с договорами.

Так выяснилось, что перед нами не одна модель интернет-магазина.

Один заказ мог пройти по трём маршрутам

Для покупателя всё начиналось одинаково: он видел один бренд, выбирал технику и оставлял заявку. Дальше заказ мог пойти по одному из трёх маршрутов.

При собственной продаже договор заключается с владельцем сайта. В агентской модели продавцом становится поставщик: представленный договор предусматривал работу от его имени, поэтому права и обязанности по сделке возникают у принципала. Это следует из статьи 1005 Гражданского кодекса.

В третьем сценарии владелец сайта передавал заявку контрагенту, а тот мог сам стать продавцом или направить покупателя другой организации. В переписке её сначала называли «четвёртым лицом». Этот эпизод и показал главную проблему: список компаний нельзя бесконечно дописывать в документы, не определив роль каждой.

В новой оферте мы закрепили общий порядок заказа, но не назначили одного продавца для всех товаров. Покупатель должен узнать конкретного продавца, цену, получателя оплаты и условия доставки до принятия индивидуальных условий.

Один номер телефона — разные получатели

После разделения моделей продаж стал понятен путь данных покупателя.

Кроме продавцов в работе участвовали хостинг, CRM, почта, телефония, банки и сервисы рассрочки. Для каждого мы выясняли, какие сведения он получает, зачем, действует ли по поручению владельца сайтов или становится самостоятельным оператором.

Так в политике появилась отдельная цель — приём и передача заявки потенциального покупателя контрагенту. Компаниям, которые только обрабатывали обращение, ограничили состав данных. Поставщиков, заключавших договор с покупателем, отразили как самостоятельных получателей.

Каждой форме — своё решение

До проекта пользователь мог одной отметкой одновременно принять политику, согласие и оферту. Мы отказались от универсального чекбокса: разные действия требуют разных оснований.

Например, данные, необходимые для заключения или исполнения договора по инициативе покупателя, могут обрабатываться на договорном основании. Это предусмотрено пунктом 5 части 1 статьи 6 закона № 152-ФЗ.

Документы сами по себе не меняют старые формы, поэтому мы подготовили инструкцию разработчику: где разместить ссылки, какие чекбоксы обязательны, что проверять на сервере и когда запускать аналитику.

Для доказательства согласия недостаточно сохранить значение true. Нужны дата и время, страница, форма, текст чекбокса и редакция документа. Для cookie — ещё выбранные категории и факт принятия, отказа или изменения настроек.

Доставка оказалась установкой

После передачи основного комплекта выяснилось, что одна из организаций, указанная как участник доставки, фактически занималась установкой и утилизацией техники.

Для бизнеса это выглядело небольшим уточнением, но оно меняло цель передачи данных и договорную роль исполнителя. Мы исправили описание компании в политике и оферте, убрали её из блока о доставке и сохранили в разделе дополнительных услуг. Саму доставку связали с конкретным продавцом или привлечённой им организацией.

Иногда одно слово — «доставка» или «установка» — меняет сразу несколько документов. Поэтому мы описываем не названия подрядчиков, а их фактические действия.

Что изменилось после работы

В комплект вошли политика обработки персональных данных, согласия для форм и рекламы, новая публичная оферта, пояснения к ней и инструкция по внедрению. Позже мы проверили реестр и увидели, что изменения в уведомление Роскомнадзора были внесены.

Когда обновились правила дистанционной торговли, клиент вернулся с новым вопросом. Нам уже не пришлось заново разбирать весь бизнес: мы определили, какой маршрут изменился, и подготовили точечные формулировки для оферты.

Часть изменений внедряли разработчики клиента, поэтому результатом мы считаем не отправленные файлы, а понятную основу для работы: кто продаёт товар, кто получает данные, на каком основании и что должен увидеть покупатель.

Когда такой разбор нужен интернет-магазину

Похожая ситуация возникает, если сайт:

• продаёт собственные товары и одновременно работает как агент;
• принимает заявки для нескольких поставщиков;
• передаёт обращения другим продавцам;
• привлекает отдельные компании для доставки или установки;
• не показывает конкретного продавца до оплаты;
• использует одну политику и один чекбокс для всех форм.

Начать стоит не с копирования чужой политики. Возьмите один реальный заказ и пройдите его целиком: кто получает заявку, становится продавцом, принимает деньги, доставляет товар и хранит сведения о покупателе.

Именно такой разбор позволил нам связать два сайта, три модели продаж и всех участников обработки данных в одну понятную систему.