设置用户数据的格式

Data Manager API 支持上传多种类型的用户数据。请遵循每个数据元素的格式设置、哈希处理和编码要求，以便系统成功接收和处理您的数据。

• UserData：用户提供的数据，例如邮箱或电话号码。

• IpData：IP 数据，例如 IP 地址和关联的时间戳。

• PairData：发布商与广告客户间用户身份匹配 (PAIR) ID。

• MobileData：用于标识移动设备的数据。

UserData 的相关要求

UserData 对象是 UserIdentifier 对象的集合。每个 UserIdentifier 仅具有下表中的一个属性。

UserIdentifier
email_address	格式 string 转换为小写。 如果电子邮件地址具有 gmail.com 或 googlemail.com 网域： 移除 @ 符号之前的所有英文句点 (.)。 从本地部分中移除加号 (+)，并移除其后的所有字符。 示例：[e-mail] → [e-mail] 如果邮箱的域名不是 gmail.com 或 googlemail.com，请勿移除英文句点或加号。 示例：[e-mail] → [e-mail] 空格符 去除开头、结尾和中间的空格。 哈希技术 使用 SHA-256 算法进行哈希处理，并对哈希字节进行编码。
phone_number	格式 string 使用 E.164 格式。 应包含加号 (+) 和国家/地区代码。加号后面的所有字符都必须是数字。 例如，美国电话号码 [phone] 应采用 [phone] 格式并进行标准化。 空格符 去除开头和结尾处的空格。 哈希技术 使用 SHA-256 算法进行哈希处理，并对哈希字节进行编码。
address	AddressInfo 对象 请参阅 AddressInfo 格式规范。

AddressInfo 格式

请按照以下格式设置准则来构建 UserIdentifier 的 address 属性。

AddressInfo
given_name	格式 string 转换为小写。 请勿添加 Mrs. 等前缀 空格符 去除开头和结尾处的空格。 哈希技术 使用 SHA-256 算法进行哈希处理，并对哈希字节进行编码。
family_name	格式 string 转换为小写。 请勿添加后缀，例如 Jr. 空格符 去除开头和结尾处的空格。 哈希技术 使用 SHA-256 算法进行哈希处理，并对哈希字节进行编码。
region_code	格式 string 一个双字符 ISO-3166-1 alpha-2 代码。 空格符 去除开头和结尾处的空格。 哈希技术 请勿对 region_code 进行哈希处理。
postal_code	格式 string 美国邮政编码和国际邮政编码均可使用。 对于美国地址，请使用 5 位数或 5 位数后跟 4 位数扩展。使用 4 位扩展邮编可能会提高您的匹配率。 对于所有其他国家/地区，请勿使用扩展邮政编码。 空格符 去除开头和结尾处的空格。 哈希技术 请勿对 postal_code 进行哈希处理。
address_line	格式 string 仅用于 Google Analytics。 用户地址中的街道名称和门牌号。 转换为小写。 移除符号字符。 空格符 去除开头和结尾处的空格。 哈希技术 使用 SHA-256 算法进行哈希处理，并对哈希字节进行编码。
city	格式 string 仅用于 Google Analytics。 用户地址中的城市。 转换为小写。 移除符号字符。 空格符 去除开头和结尾处的空格。 哈希技术 请勿对 city 进行哈希处理。
administrative_area	格式 string 仅用于 Google Analytics。 用户地址所在的行政区（州或省/自治区/直辖市）。 使用两个字母的缩写（例如 ca）或全称（例如 california）。 转换为小写。 移除符号字符。 空格符 去除开头和结尾处的空格。 哈希技术 请勿对 administrative_area 进行哈希处理。

IpData 的相关要求

IpData 对象具有以下属性。

IpData
ip_address	格式 string IPv4 或 IPv6 地址。 对于 IPv6 地址，大小写无关紧要（大写或小写均可）。 空格符 去除开头和结尾处的空格。 哈希技术 请勿对 ip_address 进行哈希处理。

PairData 的相关要求

使用 ID 列表填充 PairData 对象的 pair_ids 字段。请按照以下步骤设置列表中每个元素的格式：

1. 使用 SHA-256 算法对干净机提供的 PII 数据进行哈希处理。

2. 使用 PAIR 用户名单的发布商密钥，通过 EC 交换密码对哈希字节进行加密。

3. 使用十六进制或 Base64 编码对加密数据进行编码。

MobileData 的相关要求

使用移动 ID 列表填充 MobileData 对象的 mobile_ids 字段。请勿对移动 ID 进行哈希处理。

时间戳格式

如果对 Timestamp 字段（例如 Event 的 timestamp 和 last_updated_timestamp）使用 JSON 格式，请使用 RFC 3339 格式。以下是 2025 年 8 月 8 日下午 5:18:44.291 的世界协调时间 (UTC) 采用 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

如果使用协议缓冲区格式，请在构建 Timestamp 时设置 seconds，并视需要设置 nanos。以下是世界协调时间 (UTC) 2025 年 8 月 8 日下午 5:18:44.291 的 seconds 和 nanos 值：

• seconds：1754683124

• nanos：291000000

编码

编码要求因您是否加密用户数据而异：

• 未加密的用户数据：使用十六进制编码 (hex) 或 Base64 编码对 SHA-256 哈希字节进行编码。

• 加密的用户数据：如果您加密用户数据，则必须在加密前对原始哈希字节进行 Base64 编码。加密前哈希不支持十六进制编码。然后，您可以使用十六进制或 Base64 编码对生成的密文进行编码。

注意： 使用十六进制编码时，编码输出的大小写无关紧要。