Capturing Custom Data (pdata) for Client-Side Tags (Standard Implementation)

If you implement the tag via GET, the pdata is included as a string in the URL after the "<TAG ID>" parameter in this format:

&pdata=<k1>%3D<v1>%2C<k2>%3D<v2>

If you implement the tag via POST, the pdata are included in a JSON object after the URL:

-H 'Content-Type: application/json' \

-d '{

"segments": {

"<k1>": "<v1>",

"<k2>": "<v2>"

}

}'

"<k1>" is the value for key 1 (the key of the first key-value pair of custom data)

"<v1>" is the value for value 1 (the value of the first key-value pair of custom data)

"<k2>" is the value for key 2 (the key of the second key-value pair of custom data)

"<v2>" is the value for value 2 (the value of the second key-value pair of custom data)

If you implement the tag using GET request methods, do not include commas (",") or equals signs ("=") in keys or values, as this results in incorrect parsing of the data. See “Replacing Commas and Equals Signs in pdata Keys and Values” below for more information.

If you implement the tag using GET request methods, make sure that the entire string after "pdata=" is URL-encoded so that non-alphanumeric characters such as "/" can be properly parsed. This includes both the equals sign ("=") separating the keys and values and the commas (",") separating the key-value pairs, as well as any non-alphanumeric characters in the keys and values themselves. For example, something like "pdata=visitor=new" will not work because it is not URL encoded.

Do not pass URL strings as values in pdata. This can be a privacy risk where, in the worst-case scenario, PII (personally identifiable information) is included in the string. LiveRamp provides a privacy-safe URL value for the page on which the pixel was fired, described in the “Data Automatically Captured” section of this document.

For online Onboarding use cases, a minimum of 25 devices must populate each segment (for example, if "Gender=Male" is the segment being populated, it must have at least 25 devices). This is a privacy guidelines. This does not apply to data collected for use cases (such as some measurement use cases) that use our File-Based Recognition workflow.

When using ad server macros to populate pdata "values", connect with your ad server partner to understand what values (if any) will be passed when a macro cannot access the data element associated with the macro. This is important, because if the macro leaves the "value" blank, then the Enhanced Client-Side Tag (eCST) will fail to fire properly and will error (status code: 400). An easy trick to circumnavigate this issue with ad servers is to place an underscore after the macro so that there will always be a value (_) for pdata key/value pairs, even in the event that the macro doesn't populate with the intended value.

Make sure that the pdata contains at least one key/value pair. That is, "https://di.rlcdn.com/api/segment?pid=1234&pdata=" in a GET implementation is not allowed.

Make sure that all keys have values. That is, something like "&pdata=<k1>%3D" in a GET implementation is not allowed because key 1 does not have a value.

Make sure that all values have keys. That is, something like "=value1" in a GET implementation is not allowed.

Do not include more than 400 unique keys per tag ID. Not every call must contain the same keys, but across all calls on a particular tag ID, the sum of unique keys should not exceed 400.

Do not include the same key multiple times within the pdata passed in a given call. That is, something like "key1=value1,key1=value2" in a GET implementation is not allowed.

For a given key to support enumerated fields (both within Connect or in LiveRamp's systems in general), do not pass more than 250 distinct values per key for Onboarding workflows.

visitor = yes

category = home