Omitting data from Tealium Collect

Silver Contributor
Silver Contributor

Is it possible to exclude certain data variables from what is collected in the Tealium collect tag? Would like to prevent certain pieces of data that could be considered PII/SPI from being swept up in the json object if possible.

3 REPLIES 3

Omitting data from Tealium Collect

Tealium Employee

Hi @greg_hollingswo.

The Tealium Collect tag is like any other tag in that its data can be manipulated indepently of other tags.

 

The way I have done what you are asking for is to have a JavaScript extension scoped to the collect tag, and do this

 

delete b['PII_data_1'];

delete b['PII_data_2'];

...

 

Since the extension is scoped to the Collect tag, b is a reference to the copy of the data layer that's just for that tag.

 

Mark

Omitting data from Tealium Collect

Bronze Contributor
Bronze Contributor
Hi @mark_reddin

Yes, this works just fine. However, some attributes are added by Tealium Collect itself (like loader.cfg: {...} and timing.*)
Is there a way to remove these too? Less from a PII perspective but still to reduce unnecessary payload.

Many thanks
Marco

Omitting data from Tealium Collect

Tealium Expert
Tealium Expert

Yeah, so, this is how I do it in a Collect Tag scoped extension:

(function (tagConfigObject) {

if (typeof tagConfigObject.validateProtocol_legacy !== "function") {

/**
* Store the original validateProtocol function somewhere safe, we'll invoke it later
*/
tagConfigObject.validateProtocol_legacy = tagConfigObject.validateProtocol;

/**
* Replace the existing validateProtocol function with one that allows us to inject
* runtime config overrides into the execution process
*/
tagConfigObject.validateProtocol = function (address, force_ssl) {

/**
* Override 1
* If u.data has the loader.cfg property, blank it out - it's used to send tag completion
* statuses to EventStream, but that's not part of our use-case.
*/
if (tagConfigObject.data && tagConfigObject.data["loader.cfg"]){
tagConfigObject.data["loader.cfg"] = {};
}

// Return the original result of this function expression
return tagConfigObject.validateProtocol_legacy(address, force_ssl);
}

}

})(u);

I forget the precise order of operations within the tag, and of course you could just modify the tag template to fix it if you wanted, but something along these lines effectively allows you to insert your own processor into the payload processing downstream of where a bunch of superfluous data is added to the tag.

I also have an extension which removes any variables that aren't part of an explicit mapping object, which means that by default none of the cp.* parameters are sent (can't tell you how much I don't want any tags hoovering up the entire cookie record for a customer) and only items on an allow-list are sent.

Public