Get in touch
Back to archive
13.07Server-side и API-интеграции

PII и SHA-256: как передавать match data без лишнего риска

intermediate4 min readpii · sha-256 · hashing

TL;DR

  • PII - это данные, по которым человека можно прямо или косвенно идентифицировать: email, phone, ФИО, адрес, IIN, device identifiers.
  • Рекламные платформы часто используют хешированные first-party данные для matching и улучшения измерения.
  • SHA-256 - односторонний хеш: из нормализованного email можно получить строку, но обратно email из нее не восстановить обычным способом.
  • Хеширование не отменяет privacy, consent и юридические требования. Хешированный email все равно может быть персональными данными в рабочем смысле.
  • Главная ошибка - хешировать грязные данные: пробелы, разный регистр, разные форматы телефона и кириллица в неожиданных местах.

1. Что такое PII

PII, или personally identifiable information, - это информация, которая помогает идентифицировать человека.

В маркетинговых интеграциях чаще всего встречаются:

  • email;
  • phone;
  • first name и last name;
  • city, country, postal code;
  • IP address;
  • user agent;
  • external_id;
  • CRM id;
  • device identifiers;
  • IIN или другой государственный идентификатор.

Не все эти поля одинаково чувствительны, но все требуют аккуратной политики. Особенно в банках, страховании, медицине, EdTech для детей и любых продуктах с финансовыми данными.

2. Зачем рекламным системам match data

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

Если событие выглядит так:

{
"event_name": "Purchase",
"value": 45000,
"currency": "KZT"
}

оно полезно, но не идеально. Платформа знает, что покупка была, но хуже понимает, кто купил.

Если добавить корректные identifiers, match становится лучше:

{
"event_name": "Purchase",
"event_id": "order_123",
"user_data": {
"email_sha256": "...",
"phone_sha256": "...",
"client_ip_address": "...",
"client_user_agent": "..."
}
}

3. Как работает SHA-256

SHA-256 превращает входную строку в фиксированный хеш. Одинаковый вход дает одинаковый хеш. Разный вход дает другой хеш.

Это удобно для matching: платформа может сравнить ваш хеш со своим хешем того же email. При этом сырой email не передается.

Но есть нюанс: если email плохо нормализован, хеш будет другим.

ВходРезультат
User@Example.comодин хеш
user@example.comдругой хеш, если не привести к нижнему регистру
user@example.comдругой хеш, если не убрать пробелы

4. Нормализация перед хешированием

Перед SHA-256 обычно нужно:

  • trim пробелы;
  • привести email к lower case;
  • убрать пробелы, скобки и дефисы из телефона;
  • привести phone к международному формату;
  • проверить, что поле не пустое;
  • не хешировать мусор вроде test@test.com;
  • не смешивать разные типы идентификаторов.

Для телефона в Казахстане важно договориться о формате: +77001234567, 87001234567, 77001234567 должны стать одним стандартом до хеша.

5. Хеширование не равно разрешение

Это самый важный блок.

Хеширование снижает риск передачи сырого PII, но не делает данные "ничейными". Если ваша компания не имеет права использовать email для рекламного matching, SHA-256 не спасает ситуацию.

Практический minimum:

  • проверьте consent и privacy policy;
  • согласуйте список полей с юристами или DPO;
  • не отправляйте лишние поля;
  • храните mapping и access строго;
  • документируйте, куда уходят данные;
  • удаляйте тестовые и служебные аккаунты.

В корпоративной среде маркетолог не должен самостоятельно решать, можно ли отправлять phone hash в Meta или Google. Это вопрос совместный: marketing, legal, security, IT.

6. Локальный контекст СНГ/РК

В РК и СНГ есть привычка решать интеграции "по-быстрому": взять email из формы, отправить в рекламный кабинет, потом разобраться. Для S2S это плохой подход.

Особенно аккуратно нужно работать с:

  • банковскими заявками;
  • кредитными продуктами;
  • медицинскими услугами;
  • детским образованием;
  • государственными и quasi-government сервисами;
  • внутренними CRM ID, которые можно связать с человеком.

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

7. Ошибки

ОшибкаПоследствие
Хешируют без нормализацииMatch rate падает
Отправляют сырые emailPrivacy и security риск
Считают хеш "не персональными данными"Неверная risk assessment
Передают слишком много полейРастет поверхность риска
Хешируют на фронтенде без нуждыСырые данные все равно появляются в браузере
Нет документацииНикто не знает, что уходит в API

8. Чеклист

  • Список PII полей описан.
  • Есть согласование privacy/legal/security.
  • Email и phone нормализуются до SHA-256.
  • Хеширование происходит на сервере или в контролируемом слое.
  • Тестовые данные исключены.
  • Нет сырых PII в dataLayer без необходимости.
  • Есть логика consent.
  • Есть аудит того, куда отправляются identifiers.

9. Видео

Хеширование и SHA-256. Простыми словами и с примерами!

10. Главный совет

Относитесь к хешированным identifiers как к чувствительным маркетинговым данным. SHA-256 помогает передавать match data аккуратнее, но не заменяет здравый смысл, consent и юридическую проверку.

Sources / Notes