Best Practices for All Client-Side Tags

When used in conjunction with ATS, eCST can enable better addressability on your Activation and Measurement use cases. When using both products together, identity envelopes are first base64 encoded before being saved to a first-party cookie.

In a standard implementation, this cookie must be base64 decoded, and subsequently you must parse out the envelope’s value and then populate the envelope’s value into the eCST request. If you do not base64 decode your identity envelopes, LiveRamp’s match processes will not be able to resolve them back to RampIDs.

For example, in the base64-decoded envelope shown below, the envelope value is shown after the “envelope” parameter:

{"timestamp":1665580740566,"version":"1.1.3","envelope":"AiLWLs8jYkz1PyFp8tZnd9AJ7ZFfksZ7gc5-rr9EPzd8tGQkEjS5fobLiBf2ovWMBvRCYkRcI-EBMO_4L5nlejCbXVwwOi6XuJ8yyeBNHhF2L-Dh8fWGZpvVTPuwjA5ISCPu"}

In this example, you would populate the eCST request with the envelope value AiLWLs8jYkz1PyFp8tZnd9AJ7ZFfksZ7gc5-rr9EPzd8tGQkEjS5fobLiBf2ovWMBvRCYkRcI-EBMO_4L5nlejCbXVwwOi6XuJ8yyeBNHhF2L-Dh8fWGZpvVTPuwjA5ISCPu.

Do not pass URL strings as values in custom data (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.

When implementing the tag with custom data (pdata) via GET or the ATS integration, make sure not to include commas or equals signs within keys or values, as an equal sign will be interpreted as the end of the key, and a comma will be interpreted as the end of a value. This results in incorrect parsing of the key or value in your log file.

Replace any equals signs or commas within keys or values with a different character, such as an underscore (“_”) character. For example, say you had either of the following key-value segments: “shirt=red=true” or “shirt,red=true”. Since you cannot include “shirt=red” or “shirt,red” as a key in pdata, you might use an underscore instead and include “shirt_red” instead.

For more information, see "Replacing Commas and Equals Signs in pdata Keys and Values".

If you're including custom data (pdata) when using a standard implementation method, make sure that it is constructed in key/value pairs, and that all keys have values. For example, something like "&pdata=visitor%3" in a GET implementation will not work because the key "visitor" has no corresponding value.

Also, make sure that the entire string after "pdata=" is URL-encoded in a GET implementation 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.

The eCST does not support passing PII (plaintext or hashed) through the pixel. Any PII sent through custom data (pdata) or through “it”/”iv” query parameters will be removed from your log files. PII includes email addresses, phone number, name and postal, and IP addresses.

When using macros, it is important to understand what happens in a scenario where the macro is unable to pull any data into your CST or eCST request, such as when the macro fails to load or loads after the request. If it returns a blank value, that will cause the request to error, as the value associated with a key cannot be blank. To work around this issue, you can place an underscore (“_”) after the macro to ensure the request contains a value and does not fail. 

If the macro simply returns the macro itself, this will not cause problems unless the macro contains an equals sign or comma, as that will start a new key/value pair (however, generally this isn’t the case).