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

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

Требования MobileData

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

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

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

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

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

• seconds : 1754683124
• nanos : 291000000

Кодирование

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

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