Nutzerdaten formatieren

Die Data Manager API unterstützt das Hochladen verschiedener Arten von Nutzerdaten. Beachten Sie die Formatierungs-, Hashing- und Codierungsanforderungen für jedes Datenelement, damit Ihre Daten erfolgreich empfangen und verarbeitet werden.

• UserData: Vom Nutzer bereitgestellte Daten wie eine E-Mail-Adresse oder Telefonnummer.
• IpData: IP-Daten wie eine IP-Adresse und zugehörige Zeitstempel.
• PairData: Publisher Advertiser Identity Reconciliation (PAIR)-IDs.
• MobileData: Daten zur Identifizierung eines Mobilgeräts.

Anforderungen an UserData

Ein UserData-Objekt ist eine Sammlung von UserIdentifier-Objekten. Jedes UserIdentifier hat genau eines der Attribute in der folgenden Tabelle.

UserIdentifier
email_address	Format string In Kleinbuchstaben umwandeln. Wenn die E-Mail-Adresse die gmail.com oder googlemail.com Domain hat, entfernen Sie alle Punkte (.) vor dem @-Symbol. Leerzeichen Leerzeichen am Anfang, Ende und in der Mitte entfernen. Hashing Mit dem SHA-256-Algorithmus hashen. Die Hash-Bytes mit Hexadezimal- oder Base64-Codierung codieren.
phone_number	Format string Das E.164-Format verwenden. Das Pluszeichen (+) und die Landesvorwahl angeben. Alle Zeichen nach dem Pluszeichen müssen Ziffern sein. Die US-Telefonnummer [phone] sollte beispielsweise so formatiert und normalisiert werden: [phone]. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing Mit dem SHA-256-Algorithmus hashen. Die Hash-Bytes mit Hexadezimal- oder Base64-Codierung codieren.
address	AddressInfo -Objekt Die Formatspezifikation für AddressInfo verwenden.

AddressInfo-Format

Verwenden Sie die folgenden Formatierungsrichtlinien, um das Attribut address eines UserIdentifier zu erstellen.

AddressInfo
given_name	Format string In Kleinbuchstaben umwandeln. Keine Anreden wie Mrs. verwenden. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing Mit dem SHA-256-Algorithmus hashen. Die Hash-Bytes mit Hexadezimal- oder Base64-Codierung codieren.
family_name	Format string In Kleinbuchstaben umwandeln. Keine Namenszusätze wie Jr. verwenden. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing Mit dem SHA-256-Algorithmus hashen. Die Hash-Bytes mit Hexadezimal- oder Base64-Codierung codieren.
region_code	Format string Ein aus zwei Buchstaben bestehender ISO-3166-1 Alpha-2 Code. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing region_code nicht hashen.
postal_code	Format string Sowohl US-amerikanische als auch internationale Postleitzahlen sind zulässig. Bei US-Adressen entweder 5 Ziffern oder 5 Ziffern gefolgt von einer 4-stelligen Erweiterung verwenden. Durch die Verwendung einer 4-stelligen Erweiterung kann sich die Abgleichsrate verbessern. Für alle anderen Länder keine Postleitzahl erweiterungen verwenden. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing postal_code nicht hashen.

Anforderungen an IpData

Ein IpData-Objekt hat die folgenden Attribute.

IpData
ip_address	Format string IPv4- oder IPv6-Adresse. Bei IPv6-Adressen spielt die Groß-/Kleinschreibung keine Rolle. Leerzeichen Leerzeichen am Anfang und Ende entfernen. Hashing ip_address nicht hashen.

Anforderungen an PairData

Füllen Sie das pair_ids Feld eines PairData Objekts mit einer Liste von IDs. Formatieren Sie jedes Element in der Liste so:

1. Personenbezogene Daten, die vom Cleanroom bereitgestellt wurden, mit dem SHA-256-Algorithmus hashen.
2. Die Hash-Bytes mit einer kommutativen EC-Verschlüsselung und dem Publisher-Schlüssel für die PAIR-Nutzerliste verschlüsseln.
3. Die verschlüsselten Daten mit Hexadezimal- oder Base64-Codierung codieren.

Anforderungen an MobileData

Füllen Sie das mobile_ids Feld eines MobileData Objekts mit einer Liste von Mobil-IDs. Mobil-IDs nicht hashen.

Zeitstempelformat

Wenn Sie das JSON-Format für Timestamp-Felder wie timestamp und last_updated_timestamp von Event verwenden, nutzen Sie das RFC 3339-Format. Hier einige Beispiele für die UTC-Zeit vom 8. August 2025 um 17:18:44.291 Uhr im RFC 3339-Format und in verschiedenen Zeitzonen:

• UTC-Zeitzone: 2025-08-08T17:18:44.291Z
• EDT-Zeitzone, die zu diesem Zeitpunkt 4 Stunden vor UTC lag: 2025-08-08T13:18:44.291-04:00
• PDT-Zeitzone, die zu diesem Zeitpunkt 7 Stunden vor UTC lag: 2025-08-08T10:18:44.291-07:00
• Zeitzone für Tokio, Japan, die 9 Stunden vor UTC lag und keine Sommerzeit hat: 2025-08-08T22:18:44.291+09:00

Wenn Sie das Protokollzwischenspeicher-Format verwenden, legen Sie beim Erstellen des Timestamp die seconds und optional die nanos fest. Hier sind die Werte für seconds und nanos für die UTC-Zeit vom 8. August 2025 um 17:18:44.291 Uhr:

• seconds: 1754683124
• nanos: 291000000

Codierung

Beachten Sie beim Codieren von Daten Folgendes:

• Bei der Groß-/Kleinschreibung der Codierungsausgabe spielt die Hexadezimalcodierung (Hex) keine Rolle.
• Bei der Base64-Codierung spielt die Groß-/Kleinschreibung der Codierungsausgabe eine Rolle.