Vendor specific information in UDO

[sriram_devadas]

Currently we have implemented only one tag (SiteCatalyst) on our site. As we roll-out Tealium, we intend to add several tags. The choice of tags will be driven by different business groups. What is a good layout for the UDO? I am assuming: 1. Some of the udo data will be common for all tags. 2. Some of the udo data will be vendor specific data and be of no use to other tags. 3. We will know the common/specific tags only as we implement new tags. Was thinking of 2 options: A. Use a naming convention in the UDO variable names: datapoint1 (common data point) datapoint2_vendor1 (vendor1 specific data) datapoint3_vendor2 (vendor2 specific data) B. Use a 2 level data structure, use the flatten extension and do the mappings based on flatten's output. Any thoughts on this would be helpful.

[Clint]

Sriram, because Tealium iQ works best with a flat object I would recommend option A. First, it's going to work most smoothly with Tealium iQ because it is the native method. Second, having the vendor name (for data sources specific to a vendor) as a suffix on the data source names will make it absolutely clear to anyone working with the UDO which variables are for what especially if the variable name itself is equally descriptive. I would be tempted to give my common variables a suffix as well in this situation. Maybe something like _shared or _common

[son_hoang]

This part: 3. We will know the common/specific tags only as we implement new tags. Makes me think you may not always know if a data point is going to be vendor specific so you may want to keep the names semantic/generic. If you do know a set of datapoints are specific, I would probably have the vendor name as a prefix, rather than a suffix. Since data sources are organized alphabetically, it helps group them together.

[jared_hislop · Accepted solution]

I agree with Son, but would remove all vendor specific naming conventions. Keep all the names generic because you never know when a new vendor will want to use a specific value. The beauty of Tealium is getting rid of vendor specific data so all vendors can share a common data layer. When you start to introduce vendor specific naming convention it begins to fall back into the "old ways" of using props and eVars and other confusing naming conventions. I would recommend option A but without the vendor specific part: A. Use a naming convention in the UDO variable names: datapoint1 (common data point) datapoint2 (vendor1 specific data) datapoint3 (vendor2 specific data) Then in the notes section of each data point you can specify the vendor this data point if for, but if a future vendor wants to use that variable you're not going to get confused because you have datapoint1_siteCatalyst mapped to a doubleclick floodlight tag. (just an example)

[sriram_devadas]

Thanks Jared. Another Q, we currently have one library profile and a number of extensions to support the tags. As we add tags, I was thinking the number of extensions attached to this profile might grow. Is there any recommendation you have on managing the number of extensions.

[jared_hislop]

Going back a step, the number of extensions really depends on the quality of your data layer. If you are just developing your data layer like it sounds, I would suggest you build it as robust as possible. Even if you don't think you'll need the value now I would suggest thinking about future needs. What data points are you going to want in the future? This will significantly cut down on the number of extensions. However, using extensions is inevitable, but that is the benefit of working with Tealium :) So I would recommend using the Labels feature in the UI. This will allow you to filter the extensions on the labels you have created. That way you don't have to sift through all the extensions.