Partner Data represents any signals that a partner is able to pass to ID5 to help recognize the user. Browsers are taking increasing steps to obfuscate signals to third parties, therefore to maximize the addressability of your audience, ID5 requires publishers and advertisers to send IP address and user agent into the pd string and recommends the provision of hashed emails, mobile ad ids and any other signals for consented users when available. If there are any signals you feel might help reconcile your users across your properties, please discuss this with your ID5 representative and we will advise you of how to pass them through. If you do not want to pass signals through a client side integration, please reach out and we can discuss server side options.
Signals passed in the ID5 ID request, are used to inform ID5 ID generation and linking users across domains. “Hard signals” such as hashed email addresses take priority for cross-domain linkage purposes. ID5 performs a real-time look-up for the value provided and returns the ID5 ID that was already associated with that value. If the value doesn’t exist in the ID5 database, a new ID5 ID is created and provided in the response.
Publisher provided signals such as IP address and user agent may be used in ID5’s probabilistic algorithm when ID5 deems that they may be more accurate than those that ID5 can source directly from the http request. ID5 requires sha256 hashing & URL-safe base64 encoding to ensure that personally-identifiable information isn’t transmitted in the ID5 ID call.
Key | Description | Type |
0 | other | Optional |
1 | sha256 hashed email (see below for how to cleanse the email prior to hashing) | Recommended |
2 | sha256 hashed phone number (remove all characters besides numbers before hashing) | Recommended |
3 | cross-partner user id value (i.e. a user id that could be used across ID5 Partner Numbers / Accounts) | Optional |
4 | cross-partner user id source (value will be provided by ID5) | Optional |
5 | partner-specific user id value (i.e. a user id that is specific to a single ID5 Partner Number / Account) | Optional |
6 | Apple ID for Advertising (IDFA) (lowercased) *Recommended for in-app requests* | Recommended (when available) |
7 | Google Advertising ID (GAID) (lowercased) *Recommended for in-app requests* | Recommended (when available) |
8 | Full URL (text). Example: https://id5.io/solutions/ | Recommended (Not necessary to include if you are sending key 9) |
9 | Domain (text). Example: www.id5.io | Recommended (Not necessary to include if you are sending the full URL key 8) |
10 | IPv4 address of the end-user’s device. Example: 77.99.190.227 | |
11 | The IPv6 address of the end-user’s device. Example: 2001:0db8:85a3:000:000:8a2e:0370:7334 | Recommended |
12 | The user agent string of the end-user’s device (text). Example: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 | |
13 | A flag for whether the hashed email provided is a burner email (boolean). As emails are provided to ID5 in hashed form, ID5 is unable to determine whether provided hashed emails are ‘burner’ emails. Publishers can use this flag to signal to ID5 whether the provided email should be treated as a ‘burner’ email. At the moment, we recommend you send ‘true’ for all icloud email addresses. Example: true | Optional |
14 | Apple ID for Vendor (idfv). An alphanumeric string that uniquely identifies a device to the app’s vendor. | Optional |
15 | CTV ID - the specific user id for the CTV ecosystem the user is observed in, as received by the CTV/OTT/Publisher provider | Optional |
16 | CTV ID Type - the type of the CTV id received (i.e. Roku, Samsung, etc) | Optional |
17 | An IAB TechLab Tokenization Framework token (e.g. uid2) | Optional |
10
(for the URL-encoded IPv4), key 11 (for the URL-encoded IPv6) and key 12 (for the URL-encoded IPv6) separated by &
’s (the order doesn’t matter)pd
field in any of our integrations.myuser@domain.com
10
(for the URL-encoded IPv4), key 11 (for the URL-encoded IPv6) and key 12 (for the URL-encoded IPv6) separated by &
’s (the order doesn’t matter)pd
field in any of our integrations.lee.ann.smith@gmail.com
Key 5= Partner-specific user ID value (this could be a proprietary publisher first party ID for example) = 123456
(note: we discourage the use of special characters in the IDs).lee.ann.smith@gmail.com
normalizes to leeannsmith@gmail.com
10
(for the URL-encoded IPv4), key 11 (for the URL-encoded IPv6) and key 12 (for the URL-encoded IPv6) separated by &
’s (the order doesn’t matter)@gmail.com
:.
(ASCII code 46) from the username of the email address. lee.ann.smith@gmail.com
normalizes to leeannsmith@gmail.com
.+
(ASCII code 43) and all subsequent characters from the username of the email address. leeannsmith+school@gmail.com
normalizes to leeannsmith@gmail.com
.