Oracle Infinity Tag Business Decision Guide
This article is intended to serve as a business decision guide on implementing the Oracle Infinity UDO Tag Plugin and a gives a high-level understanding of the data layer and the rationale and applicability of implementing a data layer. If you have already implemented the Oracle Infinity Tag on your website and have made the decision to use the Oracle Infinity UDO Tag Plugin.
Introduction
The world of digital marketing is a complex space. Collection and the analysis of visitor behavioral and demographic data has become an integral part of web and mobile applications. Marketers are expected to consistently identify their customers and prospects and the online spaces they occupy. Moreover, marketers must then deliver content while measuring its engagement and effectiveness all the way through the conversion funnel and beyond. To accomplish this, marketers have historically needed to rely upon JavaScript “tags” to implement their strategies and programs on their websites. For the most part, “tagging” sites and other online experiences has been the domain of IT, subjecting marketing strategy to IT process and prolonged implementations based upon technical release schedules and resource availability.
In addition, as the technologies and tools used by marketers to implement digital strategies and deliver consumer experiences become more sophisticated, the technical requirements associated with installing and managing these tools continues to grow.
These factors are hampering marketers’ ability to quickly adapt to the fast-paced, dynamic digital marketplace and compromising the effectiveness of the very tools that are designed to make digital marketers successful.
The Infinity UDO tag plugin provides digital marketers tremendous flexibility and control to implement and optimize digital experiences while reducing IT dependence. This allows marketers to focus on marketing, rather than tags. Implementing the Infinity UDO tag plugin not only enables increased speed to market, reduction in development costs due to greater agility and flexibility in deployment as well as improved data integrity.
What is the Data Layer?
The Data Layer is a data structure that holds all data you want to process from your website or mobile application to another application. Conceptually speaking, a data layer is page-specific (but tool-agnostic) metadata that describes the page and the actions a user may take on it. A data layer typically consists of a JavaScript object that contains all of the values we’d want to report on for a given page or user.
The most common way to define the Data Layer is through the use of what is referred to as a Universal Data Object (UDO), which is written in JavaScript programming language. More specifically, the Data Layer is a JavaScript array that holds data in key-value pairs.
It is a “layer” because it is a logical element of the technology stack that delivers the interactive customer experience on your web site or mobile app.
- Experience Layer – The experience layer is where the user interacts and engages with your website or mobile app.
- Data Layer – The Data Layer sits in the middle to transfer visitor interaction data occurring at the experience layer to vendors at the application layer.
- Application Layer – The application layer is comprised of any number of digital vendors that support the functionality of your website, such as live chat, analytics, display advertising, personalization and more.
Why Implement a Data Layer?
Implementing a Data Layer is an upfront investment for a scalable, easily maintained implementation going forward. It does mean more work upfront- you have to first design the data layer to make sure it covers your reporting requirements, then you’ll need developers to add that to your site. But beyond those upfront tasks will help prevent broken reporting down the line.
One of the key arguments in favor of implementing a data layer is the way in which its values are populated, which allows you to 1) standardize data collection practices, and 2 avoid using DOM-scraping.
DOM-scraping is a method which marketing tags collect values from the Document Object Model (DOM) – the HTML structure – using javascript selectors (tag name, ids and classes). For example a marketing tag could use a Javascript or JQuery to pull the value from a form field and assign it to a variable.
Eliminate DOM-Scraping
DOM-scraping can be handy, because as along as a website’s HTML elements are well identified, values can be easily gathered from a page with some basic knowledge of Javascript.
But DOM-scraping is also problematic. If website structure changes due to redesign or new release, analytics script that relies on Javascript selectors for DOM-scraping may no longer be able to pull the correct values into your variables.
Enter the data layer. The data layer’s centralized data is built separately from the DOM, using a combination of three methods:
- Hard-coding variable values. Variables and values that don’t need to be dynamic can be hard-coded into the data layer.
- Back-end variable population. When using a template-based CMS, values can be pushed from the CMS database into the data layer as the page is being built.
- Front-end variable population. Using event listeners like onclick within HTML tags allows you to push values in to the data layer when an event occurs.
The data layer is built and populated independent of the DOM or the marketing applications, giving you more control over definitions of user events and offering pre-defined data about the content of the page.
Implementing a data layer is a serious investment, but if you pride yourself in trustworthy data and efficient operations, it is definitely worth considering. In the long run a data layer will increase IT efficiency, expand marketing autonomy and give you cleaner, more trustworthy data.
What to consider when implementing a data layer?
Ask Yourself (Below are some questions to ask yourself when considering using a data layer):
Have you previously used another tag management system? Often, a data layer set up for a different tool can be used by the Infinity UDO. Similarly, if the client ever moves away from using the Infinity UDO, their data layer can travel with them.
Have you previous implemented tag management system? Today, most tag management systems have their own standards. We recommend against using multiple UDO standards. If you have one and intend to convert from your current TMS solution to the Infinity UDO Tag plugin then we recommend seeking professional consultants that have expertise TMS conversions and enablement.
How often does the code on the site change? If the DOM/HTML of the site changes frequently, you don’t want to rely on CSS selectors. Most times reports will randomly break, and after much debugging we realized the problem was the developers changed the code without knowing it would affect analytics. It’s easier to tell a developer to put a data layer object on a page then leave it alone, than it is to tell them to not change their HTML/CSS.
How CSS-savvy is your Tag Management System (TMS) team? If you have someone on your team who is comfortable navigating a DOM using CSS, then you may be able to get away without a data layer a little more easily… but plan on that CSS-savvy resource spending a lot of time in your TMS.
How many pages/page types are on the site? A very complicated site is hard to manage through CSS- you have to familiarize yourself with the DOM of every page type.
How are CSS styles laid out? Are they clean, systematic, and fairly permanent? Clearly, the cleaner the DOM, the easier it is to scrape it.
How often are new pages or new site functionality released? Sites that role out new microsites or site functionality frequently would need a CSS-savvy person setting up their TMS for every change. Alternatively, relying on a data layer requires a data-layer-savvy developer on any new pages/site/functionality. It is often easier to write a solid Data Layer tech spec for developers to reference for projects going forward than to figure out CSS selectors for every new site/page/functionality.
How much link-tracking/post-page-load tracking do you have on your site? If you do need to track a lot of user actions beyond just page loads, involving IT to make sure you are tracking the right things (instead of trying to scrape things out of the HTML) can be extremely valuable.
What is the turn-around time for the developers? Many companies move to a TMS solution specifically because they can’t work easily within their dev team to set up analytics. A development-driven data layer may take many months to set up, stage, QA, and publish. Then if changes are needed, the process starts again. It may be worth going through the lengthy process initially, but if changes are frequently needed in this implementation, you may find yourself relying more on the DOM.
Infinity UDO and the Data Layer
The Data Layer is the foundation of the Infinity UDO platform and will serve as the master definition of your data across all of your digital assets and customer interactions. The Data Layer comprises all of the various data elements that will be collected across your site and the user interactions and events that will be tracked. The Infinity UDO relies on a root JavaScript Object (JSO) to collect customer experience data. The JSO is designed to be contained within a root object called dataLayer.
The point here is that dataLayer is generic and tool-agnostic. As long as it behaves like your typical JavaScript Array, it won’t be restricted to just one tool. The information in the dataLayer object above can be used by any application which has access to the global name space of this page.
The Data Layer can hold static or dynamic information. The Infinity UDO can push data into the Data Layer and then read it from there. For example, your website or mobile app can put static page information, such as the page category or transaction value, into the Data Layer. Alternatively, when a visitor adds a product to his/her cart, a dataLayer event (containing product’s information) could be fired. You can add this data to the Data Layer instantaneously using a push command.
Benefits of a well-defined and manage Data Layer
Below are some basic milestones that will need to be discussed among your developers, marketers and other shareholders.
- Decide on data layer structure and naming conventions (you should crate a data model before anything else) (link here) what use cases you are trying to solve? What data do you want to collect… gather use cases build a model and then decide????
- Develop and deploy code to populate the key-value pairs.
- Hard-code
- Back-end
- Front-end
- Remove the vendor-specific code from your website pages, templates or header.
- Update variable documentation, mapping your data layer elements to business/vendor requirements.
- Perform regular audits for data layer quality assurance.
Implementing a Data Layer using industry best practices and proven development methodologies provides you and your vendors with reliable and accurate data. You can be assured that the data you are relying on to make both immediate and long-term decisions for the business is solid.