L'API Data Manager permet d'importer plusieurs types de données utilisateur. Suivez les exigences de mise en forme, de hachage et d'encodage pour chaque élément de données afin que vos données soient reçues et traitées correctement.
UserData: données fournies par l'utilisateur, telles qu'une adresse e-mail ou un numéro de téléphone.IpData: données IP telles qu'une adresse IP et les codes temporels associés.PairData: ID Publisher Advertiser Identity Reconciliation (PAIR).MobileData: données identifiant un appareil mobile.
Configuration requise pour UserData
Un objet UserData est une collection d'objets UserIdentifier. Chaque UserIdentifier possède exactement l'un des attributs du tableau suivant.
| UserIdentifier | |||||||
|---|---|---|---|---|---|---|---|
email_address |
|
||||||
phone_number |
|
||||||
address |
AddressInfo
objectConsultez la spécification du format
AddressInfo. |
||||||
Format AddressInfo
Suivez les consignes de mise en forme ci-dessous pour créer l'attribut address d'un UserIdentifier.
| AddressInfo | |||||||
|---|---|---|---|---|---|---|---|
given_name |
|
||||||
family_name |
|
||||||
region_code |
|
||||||
postal_code |
|
||||||
address_line |
|
||||||
city |
|
||||||
administrative_area |
|
||||||
IpData exigences
Un objet IpData comporte les attributs suivants.
| IpData | |||||||
|---|---|---|---|---|---|---|---|
ip_address |
|
||||||
Configuration requise pour PairData
Renseignez le champ pair_ids d'un objet PairData avec une liste d'ID.
Mettez en forme chaque élément de la liste en procédant comme suit :
Hachez les données permettant d'identifier personnellement l'utilisateur fournies par la salle blanche à l'aide de l'algorithme SHA-256.
Chiffrez les octets de hachage avec un chiffrement commutatif EC à l'aide de la clé de l'éditeur pour la liste d'utilisateurs PAIR.
Encodez les données chiffrées à l'aide de l'encodage hexadécimal ou Base64.
MobileData exigences
Renseignez le champ mobile_ids d'un objet MobileData avec une liste d'ID mobiles. Ne hachez pas les ID d'appareils mobiles.
Format de code temporel
Si vous utilisez le format JSON pour les champs Timestamp, tels que timestamp et last_updated_timestamp de Event, utilisez le format RFC 3339. Voici quelques exemples de l'heure UTC du 8 août 2025 à 17:18:44.291 au format RFC 3339 et dans différents fuseaux horaires :
Fuseau horaire UTC :
2025-08-08T17:18:44.291ZFuseau horaire EDT, qui était à UTC-4 à ce moment-là :
2025-08-08T13:18:44.291-04:00Fuseau horaire PDT, qui était de sept heures avant l'heure UTC à ce moment-là :
2025-08-08T10:18:44.291-07:00Fuseau horaire de Tokyo, au Japon, qui est en avance de neuf heures par rapport à l'heure UTC et n'observe pas l'heure d'été :
2025-08-08T22:18:44.291+09:00
Si vous utilisez le format de tampon de protocole, définissez seconds et, éventuellement, nanos lors de la construction de Timestamp. Voici les valeurs seconds et nanos pour l'heure UTC du 8 août 2025 à 17:18:44.291 :
seconds:1754683124nanos:291000000
Encodage
Les exigences d'encodage diffèrent selon que vous chiffrez ou non les données utilisateur :
Données utilisateur non chiffrées : encodez les octets de hachage SHA-256 à l'aide de l'encodage hexadécimal (hex) ou de l'encodage Base64.
Données utilisateur chiffrées : si vous chiffrez les données utilisateur, vous devez encoder les octets de hachage bruts en base64 avant le chiffrement. L'encodage hexadécimal n'est pas compatible avec le hachage de pré-chiffrement. Vous pouvez ensuite encoder le texte chiffré obtenu à l'aide de l'encodage hexadécimal ou Base64.