Data collection
This introduction is a brief summary of the Oracle Infinity Tag and an introduction to some of the Oracle Infinity data collection technologies. Oracle Infinity provides customers the ability to track user interactions on any device with a computer chip, or any application with a web connection. There are several technologies Oracle Infinity uses to collect data:
- Javascript based tag for web properties
- iOS and Android native SDK’s for mobile applications
- AMP integration for mobile sites
- Customizable Tracking Pixel for e-mail
- Data Collection API for custom post based tracking needs
After collection, data is augmented with device and geographical lookup data before being sessionized and persisted for reporting needs, or passed on to a data export endpoint.
Infinity Tag Capabilities
The Oracle Infinity Tag is probably the most common data collection technology in use. Users generate a tag using the Tag Management API or the Data Collection Administration UI. The various files that make up the tag are pushed to a CDN cache and the tag is ready to collect data.
You will need to deploy the tag to your web pages or web apps in order to gather data. This deployment consists of placing a single line of JavaScript on your site. Once it is in place, you can update the tag data collection behavior (add plugins, change configurations, deploy new code versions, etc.) without having to re-deploy it to your site. This is because the link on your page(s) references a CDN hosted loader that loads other CDN hosted assets specific to your tag. Changes made to the tag will update these assets on the CDN.
The tag has other features to help you determine how you want to manage and collect data:
- Cookies – The tag uses only first party cookies, and has configuration points to set the name, expiration date, and cookie type (session/persistent). There are additional plugins that can be configured to persist or read other cookies on the site if you choose to enable them.
- IP Obfuscation – The tag allows you to set a parameter to obfuscate the last octet of any collected IP addresses (dcsipa=1).
- Opt-out – The tag will look for an Infinity opt out cookie, but can also be configured to look for other opt out cookies set by consent management platforms.
- Page load events – The tag can be configured to automatically track page load events, or it can be put in a “manual mode” in which the tag files will load, but no default events will be sent. This is useful for single page apps and other sites/apps where developers want full control over how and when data is sent.
- Extensible design – The tag is designed to be extended by user configurable plugins and product modules. In this way you can store several different configurations for a tag, and then dynamically load them on your site to change how it behaves. This also means that your tags are only loading exactly what code they need for your site, and not “inactive code” that is only needed for one page or one portion of the site as a whole. The tag also supports loading client hosted plugins if you want to write custom code of your own.
- Built-in Debugging – The tag has a built in set debug functionality that can be enabled to either output debug messages to the browsers developer console, or to pop-up a box containing a list of all collected parameters.
- Click tracking API – The tag provides a set of functions that can be used to manually trigger data collection events. This is especially useful for single page apps, or other situations where users want to track custom events that are not otherwise triggered automatically. This document provides more information on Event Tracking Functions manual event collection.
- Mutations - Mutations are simple functions that provide a way to dynamically modify the existing event data sent to collection. They provide access to the entire message, can alter the data payload as it passes through the event tracking pipeline, and can specify different communication protocols and destinations. If you need to add a parameter to outgoing events, or modify the values of a parameter before it is sent to Infinity, a mutation is the tool to use.
- Mutations can be added to a page to load after the tag does, or embedded into the tag loader (ODC.js) by an Infinity Consultant.
- More data on mutations can be viewed here: Mutations
Infinity collects data as key/value pairs, and leverages schema-less data collection to store and index collected data. This means that clients don’t need to pre-configure parameters ahead of time, anything sent will simply be collected and stored until needed for reporting or export. Additionally, there is no limit in Infinity for how many parameters can be sent or collected on an individual event. Naturally, one can run into browser limitations on maximum GET or POST lengths, or cookie size limitations, but Infinity doesn’t limit collection by number of sent parameters as some competitors do.
Once data is collected, in order to be used for reporting, it must be given a friendly name and configured as a Dimension or Measure. The product documentation here describes the process of setting up reports.
Tag Structure
The Oracle Infinity Tag is actually several individual files that combine to provide the full functionality.
The main file that all tags will use is ODC.js, which is colloquially known as the “tag loader”. It contains all of the flags, variables, and settings that will tell the tag which features to turn on/off and how to behave. It is mostly unobfuscated and unminimized to make reading these settings easier for web developers. The loader also contains links to the main libraries and configured tag modules that it will download and execute.
The first file downloaded is common.js. It is a library of common functions and sets up the tag’s data collection pipeline, and manage dependencies for other files. All versions of the tag need common.js whether it’s a stand-alone Infinity tag for behavioral data collection.
The remaining files downloaded files are the product modules (like analytics.js), or custom plugins specified by clients hosted on their own site. Each integrated product will have its own module file that contains all of the business logic and data collection logic necessary to execute the various functions of that product.
The exact number of individual files depends on your tag configuration, but by doing it this way, we can reduce the overall size of the tag, and only download/execute code relevant to your site.
Consent Management
The Oracle Infinity Tag integrates well with 3rd party consent management platforms. While it does offer a plugin that will surface a configurable consent management pop-up banner, the typical recommendation from Infinity consulting is to wrap the Infinity tag include in the 3rd party consent management layer. Consult the documentation for your consent management layer to determine how to use it to include the Infinity tag on the page after consent to track has been granted by your site’s users.
Personally Identifiable Information (PII)
Infinity makes an effort to avoid collecting any PII by default with the Oracle Infinity Tag or Oracle Infinity SDK. The only default data point that we collect that might be considered PII in some situations is user IP address, and even then we offer integrated solutions to obfuscate the collected obfuscate it. Infinity recommends not sending any PII unless it’s hashed or otherwise obfuscated. This data can be translated into human readable values via a lookup table post collection.
Updates
Updates and new features are continually being deployed for the Oracle Infinity Tag and SDK. These updates are deployed as frequently as every two weeks (deploy window), however they are not automatically applied to your deployed tags or SDK’s. For the SDK you must download the most recent version of the SDK, compile it into your app, and re-distribute that app. For the tag, you must either contact your Infinity consultant to apply the update to your tag, or leverage the upcoming Data Collection Management UI to deploy the latest tag version. This strategy means that customers can test new versions of the tag before applying them to a production site. It is not required to touch the deployed JavaScript to update a tag (including deploying new product modules, or enabling/disabling plugins).
Next steps
Parameters Collected by Default