Skip to main content

Best Practices for All Client-Side Tags

Follow the best practices listed below to avoid common implementation issues for standard Client-Side Tags (CSTs) and Enhanced Client-Side Tags (eCSTs).

Identity Envelopes Must be Base64 Decoded Before Populating Them into an eCST Request

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.

Note

If you implement the eCST via the ATS for Web integration, you don’t have to base64 decode the envelopes.

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.

Note

  • The other data contained in the decoded envelope (the Unix Timestamp of the creation of the envelope and the version of ATS.js you’re using) should not be included in your eCST request.

Do Not Pass URLs as Custom Data

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.

Do Not Include Commas (",") or Equals Signs ("=") in Custom Data

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 "Enhanced Client-Side Tag for ATS for Web (Beta)".

Make Sure Custom Data are Formatted Correctly

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.

Do Not Pass PII Through Custom Data or “it”/”iv” Query Parameters

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.

Understand How Custom Data Macros Work When They Cannot Pull in a Value

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).