В 2022–2023 годах американские регуляторы начали массово штрафовать медицинские организации за использование пикселя Meta без специального соглашения о защите данных. Расследование показало: обычный код отслеживания способен передавать на рекламную платформу названия диагнозов, содержание кнопок «Записаться к онкологу» и даже заполненные формы. Прецедент заставил пересмотреть архитектуру сбора аналитики во всём мире.
Для российских частных клиник вопрос стоит не менее остро. Федеральный закон №152-ФЗ «О персональных данных» требует согласия на обработку и передачу любой информации, позволяющей идентифицировать человека. Врачебная тайна (ст. 13 ФЗ-323) прямо запрещает разглашать сам факт обращения за медицинской помощью, диагноз и детали лечения. Передача этих сведений третьим лицам — будь то Яндекс.Метрика, VK Ads или другие рекламные системы — без надлежащих мер защиты грозит штрафами Роскомнадзора и репутационными потерями. Разберёмся, как построить маркетинговый стек, который сохранит эффективность аналитики и не нарушит закон.
Почему обычные счётчики на сайте клиники стали угрозой
Любой стандартный код веб-аналитики — JavaScript-пиксель Яндекс.Метрики, счётчик VK, пиксель myTarget — выполняется в браузере посетителя и имеет доступ ко всему содержимому страницы. Если на кнопке написано «Приём уролога», а в форме пользователь вводит имя и телефон, эти данные потенциально могут быть считаны и переданы на серверы рекламной платформы. Даже если маркетолог не настраивал целенаправленный сбор, сам факт возможности передачи конфиденциальной информации создаёт юридический риск.
Роскомнадзор последовательно усиливает контроль за оборотом персональных данных. Медицинские организации находятся в зоне особого внимания, поскольку оперируют специальной категорией сведений о здоровье. Утечка или неправомерная передача таких данных может привести к административной и даже уголовной ответственности. Зарубежные кейсы с Meta показали, что штрафы могут быть миллионными, а репутационный ущерб — катастрофическим. Российским клиникам стоит извлечь урок и пересмотреть используемые технологии.
Клиентский трекинг против серверного: где исчезают данные пациента
Чтобы понять разницу, представим два сценария.
Клиентский трекинг Пиксель загружается в браузере, видит всю структуру страницы (URL, заголовки, текст кнопок, поля ввода) и напрямую отправляет событие в Яндекс.Метрику, VK Ads или иной сервис. У клиники нет технической возможности гарантировать, что в отправку не попали запрещённые параметры.
Серверный трекинг Данные сначала поступают на собственный сервер клиники (например, на поддомен). Только после обработки и очистки они ретранслируются наружу. Это позволяет отсечь всё лишнее до того, как информация покинет контроль организации. Для российских реалий это принципиально: требования 152-ФЗ о локализации баз данных предписывают хранить первичную информацию на территории РФ. Серверный слой, развёрнутый на отечественной инфраструктуре, удовлетворяет этим условиям.
| Параметр | Клиентский трекинг | Серверный трекинг без очистки | Серверный трекинг с фильтрацией |
|---|---|---|---|
| Доступ к содержимому страницы | Полный | Отсутствует (данные приходят через контролируемое API) | Отсутствует |
| Риск передачи врачебной тайны | Высокий — любое поле может утечь | Сохраняется, если параметры передаются без изменений | Минимален — чувствительные поля удаляются или маскируются |
| Соответствие 152-ФЗ | Только при доказанном отсутствии сбора ПДн (что трудно гарантировать) | Формально выше, но нужна доработка | Достигается, если фильтр настроен корректно |
| Требования к серверу | Не применимо | Сервер должен быть на территории РФ | Сервер в РФ, журнал аудита событий |
Почему серверный Google Tag Manager не решит проблему сам по себе
Бытует мнение, что достаточно развернуть серверный контейнер Google Tag Manager (sGTM) на своём хостинге — и вопросы с законом закрыты. На практике это не так. Гайд американского агентства Cardinal Digital Marketing, изучившего десятки подобных кейсов в медицине, прямо указывает: sGTM — всего лишь среда исполнения, прокси, который пересылает события туда же, куда и клиентский контейнер. Если в клиентской части настроены теги, передающие текст кнопки или содержимое поля «Причина обращения», эти данные без изменений уйдут в рекламную систему.
В российском контексте это означает: установив sGTM на сервер в РФ, но не настроив фильтрацию, вы всё равно рискуете отправить ФИО, телефон и симптомы пациента напрямую в Яндекс.Метрику или VK Ads. Ни та, ни другая платформа не заключает с клиниками соглашений, разрешающих обработку врачебной тайны. Поэтому серверный GTM — необходимый, но недостаточный шаг. Требуется дополнительный уровень очистки.
Принцип «Privacy First»: фильтруем данные до отправки
Решение, которое закрывает юридические риски — программная прослойка, внедряемая между точками сбора данных и внешними сервисами. В США примером такой системы служит платформа Freshpaint, встроенные классификаторы которой автоматически распознают медицинские термины, номера телефонов, адреса и заменяют их безопасными токенами или полностью удаляют. Событие «очищается» ещё на стороне клиники, и во внешний мир уходит только обезличенная аналитика.
В России готовых аналогов такого уровня пока нет. Однако сам подход можно реализовать на базе серверного Google Tag Manager с кастомными шаблонами и регулярными выражениями. Логика такова:
- Создаётся словарь запрещённых полей: все параметры, которые могут содержать ФИО, диагноз, название конкретной медицинской услуги, контактные данные.
- Перед отправкой в Яндекс.Метрику или рекламный кабинет sGTM проверяет каждое поле. При совпадении с шаблоном значение либо удаляется, либо заменяется общим словом «медицинская услуга».
- Ведётся лог фильтрации для возможной проверки регулятором.
Такой «самодельный» сценарий не заменит промышленное решение, но для большинства частных клиник станет реальным шагом к соблюдению 152-ФЗ и врачебной тайны. Важно помнить, что после обезличивания данные перестают быть персональными — на них не распространяются строгие требования закона, и их можно использовать для маркетинга.
- Автоматическое распознавание чувствительных полей по заданным правилам.
- Фильтрация на стороне клиники, до передачи куда-либо.
- Возможность использовать серверный GTM как диспетчер очищенных событий.
- Отправка в рекламные системы только обобщённых названий (категория услуги, а не уточнённый диагноз).
- Аудит-лог, фиксирующий все факты обработки данных.
Мультиканальная атрибуция на собственных данных без раскрытия личности
После отключения прямых клиентских пикселей встаёт вопрос: как оценивать эффективность рекламных каналов? Ответ — переход на атрибуцию, основанную на собственных данных (first-party data), которые пользователь осознанно передаёт клинике: запись через форму, звонок по номеру с подменой, авторизация в личном кабинете.
Схема работы для российской клиники:
- Каждому визиту присваивается внутренний анонимный идентификатор (например, ID сессии). Он не содержит персональных данных и хранится только на серверах клиники.
- Все маркетинговые касания (переход из рекламы, органический поиск, email-рассылка) связываются с этим ID.
- Когда пользователь совершает целевое действие — записывается на приём или оставляет заявку — CRM или медицинская информационная система (МИС) фиксирует связку «ID сессии → ID пациента». Наружу уходит только агрегированный отчёт: «Кампания в Яндекс.Директе привела 15 записей к стоматологу, медианный срок от клика до визита — 2 дня».
- Ни один внешний сервис не получает ни фамилии, ни конкретного диагноза — только статистику, которую можно анализировать без риска.
Такой подход не только защищает информацию, но и даёт маркетологу полный контроль над моделью атрибуции. Можно настроить линейную, временну́ю или U-образную модель на своих серверах, обогатить данные офлайн-событиями (фактический приход в клинику, оплата) и не зависеть от алгоритмов рекламных платформ.
FAQ
Q: Какие риски несёт установка обычных счётчиков на сайт медицинской клиники? A: Счётчики Яндекса, VK и других систем могут собирать текст кнопок («Запись к онкологу»), содержимое форм с контактами, названия страниц с диагнозами. Это может быть расценено как нарушение 152-ФЗ и врачебной тайны, за что Роскомнадзор вправе наложить крупный штраф, а пациент — подать в суд.
Q: Чем серверный трекинг отличается от клиентского и помогает ли он соблюсти 152-ФЗ? A: При серверном трекинге события сначала поступают на собственный сервер клиники, где их можно проверить и очистить, прежде чем отправить в рекламную систему. Это позволяет выполнить требование о локализации данных и минимизирует риск утечки, но только при условии настроенной фильтрации.
Q: Можно ли полностью защититься, просто настроив серверный Google Tag Manager? A: Нет. Серверный GTM служит лишь прокси-сервером. Если в него без изменений приходят чувствительные параметры из клиентского контейнера, они уйдут наружу. Требуется дополнительная настройка правил, удаляющих или маскирующих запрещённые данные.
Q: Как очистить данные о пациентах перед отправкой в Яндекс.Метрику или VK Ads? A: Нужно создать фильтры на стороне серверного GTM (или кастомного прокси), которые по словарю терминов или регулярным выражениям определяют и вырезают из событий ФИО, телефоны, названия конкретных диагнозов. Оставшиеся обезличенные данные можно законно передавать.
Q: Как оценивать эффективность рекламы клиники, не передавая персональные данные? A: Используйте атрибуцию на собственных данных: внутреннему анонимному ID сессии присваиваются все касания, а при конверсии в CRM фиксируется связь с ID пациента. Внешним системам передаются только агрегированные отчёты без личной информации.