Форматировать пользовательские данные

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

• UserData : данные, предоставленные пользователем, такие как адрес электронной почты или номер телефона.
• PairData : идентификаторы согласования личности издателя и рекламодателя (PAIR).
• MobileData : данные, идентифицирующие мобильное устройство.

Требования UserData

Объект UserData представляет собой коллекцию объектов UserIdentifier . Каждый UserIdentifier имеет только один из атрибутов, перечисленных в следующей таблице.

Идентификатор пользователя
email_address	Формат string Преобразовать в строчные буквы. Если адрес электронной почты имеет домен gmail.com или googlemail.com , удалите все точки ( . ) перед символом @ . Пробелы Удалить начальные, конечные и промежуточные пробелы. Хеширование Хэширование с использованием алгоритма SHA-256 . Кодирование байтов хеша с помощью шестнадцатеричного кода или кода Base64.
phone_number	Формат string Используйте формат E.164 . Укажите знак плюс ( + ) и код страны. Все символы после знака плюс должны быть цифрами. Например, номер телефона в США [phone] следует отформатировать и нормализовать до [phone] . Пробелы Удалить начальные и конечные пробелы. Хеширование Хэширование с использованием алгоритма SHA-256 . Кодирование байтов хеша с помощью шестнадцатеричного кода или кода Base64.
address	Объект AddressInfo См. спецификацию формата AddressInfo .

Формат AddressInfo

Используйте следующие правила форматирования для построения атрибута address UserIdentifier .

АдресИнформация
given_name	Формат string Преобразовать в строчные буквы. Не используйте префиксы, такие как Mrs. Пробелы Удалить начальные и конечные пробелы. Хеширование Хэширование с использованием алгоритма SHA-256 . Кодирование байтов хеша с помощью шестнадцатеричного кода или кода Base64.
family_name	Формат string Преобразовать в строчные буквы. Не включайте суффиксы, такие как Jr. Пробелы Удалить начальные и конечные пробелы. Хеширование Хэширование с использованием алгоритма SHA-256 . Кодирование байтов хеша с помощью шестнадцатеричного кода или кода Base64.
region_code	Формат string Двухсимвольный код ISO-3166-1 alpha-2 . Пробелы Удалить начальные и конечные пробелы. Хеширование Не хешируйте region_code .
postal_code	Формат string Разрешены как американские, так и международные почтовые индексы. Для адресов в США используйте либо 5-значный код, либо 5-значный код с добавлением 4-значного расширения. Использование 4-значного расширения может повысить вероятность совпадения. Для всех остальных стран не используйте расширения почтовых индексов. Пробелы Удалить начальные и конечные пробелы. Хеширование Не хешируйте postal_code .

Требования PairData

Заполните поле pair_ids объекта PairData списком идентификаторов. Отформатируйте каждый элемент списка, выполнив следующие шаги:

1. Хешируйте предоставленные чистой комнатой данные PII с помощью алгоритма SHA-256 .
2. Зашифруйте байты хеша с помощью коммутативного шифра EC, используя ключ издателя для списка пользователей PAIR.
3. Закодируйте зашифрованные данные с помощью шестнадцатеричного кодирования или кодирования Base64.

Требования MobileData

Заполните поле mobile_ids объекта MobileData списком мобильных идентификаторов . Не хешируйте мобильные идентификаторы.

Формат временной метки

При использовании формата JSON для полей Timestamp , таких как timestamp и last_updated_timestamp для Event , используйте формат RFC 3339. Вот несколько примеров времени UTC 8 августа 2025 года в 17:18:44.291 в формате RFC 3339 и различных часовых поясов:

• Часовой пояс UTC: 2025-08-08T17:18:44.291Z
• Часовой пояс EDT, который на тот момент опережал UTC на 4 часа: 2025-08-08T13:18:44.291-04:00
• Часовой пояс PDT, который в то время опережал UTC на 7 часов: 2025-08-08T10:18:44.291-07:00
• Часовой пояс Токио, Япония, который опережает UTC на 9 часов и не переходит на летнее время: 2025-08-08T22:18:44.291+09:00

При использовании формата буфера протокола задайте seconds и, при необходимости, nanos при построении Timestamp . Ниже приведены значения seconds и nanos для времени UTC 8 августа 2025 года в 17:18:44.291:

• seconds : 1754683124
• nanos : 291000000

Кодирование

При кодировании данных следует учитывать следующее:

• При использовании шестнадцатеричного кодирования (hex) регистр выходных данных не имеет значения.
• При использовании кодировки Base64 регистр выходных данных имеет значение .

Следующие шаги

• Узнайте, как шифровать данные пользователя .