Getting Started with DTM: Data Elements
When speaking to our clients all over the globe about the features of Adobe Dynamic Tag Manager and what sets it apart from the legacy TMS systems in the market, the conversation quickly turns to Data Elements. Data Elements within DTM allow you to build a customized and reusable data dictionary that will enable you to map the metadata of your Web applications to any analytics and marketing solution that you are implementing. As covered in an earlier post by my colleague here, you do not have to have a data layer to use DTM or Data Elements. If you do have a preexisting data layer or you are planning on creating one, you will never regret any work that facilitates the organization and structuring of your website’s metadata.
What is it that makes Data Elements so important and fundamental to DTM? It is not just one item, but the full collection of their capabilities beyond that of simply passing data into a data collection variable that gives them this vital role:
- Data Mapping: Provides a logical and robust data mapping to your website’s metadata, customized for your company in a vendor agnostic methodology.
- Data Persistence: Ability to set persistence of any Data Element.
- Conditional Logic: Use of Data Elements as preconditions or triggers for determining if additional tags or scripts should execute.
- Complete solution integration: Ability to reference Data Elements in any rule/tag/third-party script anywhere in DTM.
Because Adobe Dynamic Tag Management is built to run any marketing tag or script, it is essential that every component of DTM support that. Having the ability to create a solid data mapping that’s independent of the tool that is ultimately receiving the data is the first step in the process. In implementations without a TMS or using some other legacy TMS, you would struggle to take the value held in one variable in one tool and send that to another tool. For example, an Adobe Analytics eVar30 might hold a customer ID, and you also need to pass that into a Target mbox or a retargeting pixel. Within DTM, the Data Elements and the building of the rules sits at a higher level in the hierarchy of the implementation, where we would create a Data Element to capture and hold the customer ID. Once that is created, any system user can then send that data point to any technology of data collection tool that needs it. This methodology is faster and more efficient than other approaches used by other TMS tools.
Consume Any Data Source
You do not have to have a data layer before you can begin using and benefiting from DTM. Any work that you do in organizing and structuring the metadata of your websites will never be wasted, so if you are planning on or working to implement a data layer keep doing that. Dynamic Tag Manager was designed to be able to consume and leverage any data source.
- CSS Selector: We may not want to do it, but sometimes the only way to get a specific data point is the scrape the page or to pull it from a specific CSS element.
- Cookie: DTM can read any of your cookie values
- URL Parameter: Just like it sounds, DTM can grab any query string variable.
- Custom Script: If you need to perform some extra data manipulation to a data point or you want to use this custom area to access any system with a Web services or API, you are able to perform that function here.
The wonderful thing about this approach is that DTM allows your implementation and use of data objects to grow and mature with you. That means if you have to create Data Elements that use the CSS selector to begin with and then six months from now you implement a data layer you simply have to update the mapping. Every rule, tag, and pixel that is refereeing the Data Element will automatically have the new information, and you do not even have to remember all the items that are dependent on the Data Element as long as you update the mapping. This will save you hundreds of hours, if not more.
How long would you like for DTM to hold on to and make actionable the value of the data object inside of a Data Element? Pageview, session, or visitor?
Would you like the ability to perform real-time targeting and segmentation of your Web visitors based on which external display campaign brought them to your site? Persistence of Data Elements is the path to making this happen.
Using the image below as an example, we would create a Data Element that would capture the campaign ID from the query string.
The key here is to set the persistence to “Session.” This will enable you to not only pass the value of the Data Element into Adobe Analytics or any other tool that you are deploying through DTM.
Once you have created the Data Element and set the desired persistence, you can then use the Data Element as a precondition or a trigger for determining if rules containing your marketing tags should fire. In the scenario detailed in the image below, we are taking the Data Element “Display Campaign Id” and combining it with two other criteria to build a rule that will only execute when the user is on the order confirmation page, on a specific domain, and has a specific Data Element value.
DTM gives you the power to deploy A/B testing at any point in the journey based on the original campaign ID in real time, without any custom coding.
Complete Solution Integration
In the image below, we are working with a typical marketing script, but instead of having to have extra redundant code that scrapes the DOM, we can leverage the power of the Data Elements here as well. In the last line displayed, we simply reference one of the native DTM functions:
_satellite.getVar(‘Data Element Name Here’);
- Data Elements Documentation (http://microsite.omniture.com/t2/help/en_US/dtm/data_elements.html)
- Data Elements Video (https://outv.omniture.com?v=VmeXU2bDqrTZ6nZTPZ5XmfPlJ7O1DjZT)