Analyzing Data with Adobe Analytics: Where the Data Comes From

You may not know this, but Adobe Analytics users perform data analytics on things beyond their websites. Adobe also captures data on behalf of their customers in mobile apps, tablet apps, and more. Plus, Adobe has built significant flexibility into Adobe Analytics to handle a more digitally connected consumer world that seamlessly switches from voice assistant to phone to laptop.

Perceptions of the nature of data analysis were defined in the realm of popular culture by the Jonah Hill character in the movie adaptation of the book Moneyball. In that true story, a small-market baseball team (the Oakland A’s) managed to dramatically outperform teams with much larger payrolls by innovatively identifying and acting to acquire underpriced players based on statistical measures of a player’s effectiveness beyond and in many ways going against traditional metrics, such as batting averages, home runs per season, and RBIs (runs batted in).

Since that movie came out, new and ever more complex challenges in collecting and analyzing data have emerged. (Check out this article for more on data trends.)

For example, users of online devices have been conditioned to quickly navigate from one place to another, requiring more nuanced and detailed metrics to accurately track user activity. And users are increasingly conscious of privacy considerations and making more informed decisions about how they want to manage the relationship between the convenience provided by having their activity tracked versus maintaining confidentiality in their online activity.

On the other side of the data analysis coin, vastly more sources of user data exist than just a few years ago. Today, Adobe has a number of mechanisms to import information for data analysis from digitally disconnected sources such as call centers, customer relationship management (CRM) systems, and in-store commerce engines.

Before diving into the details of how data is collected, it’s important to understand that capturing data and pumping it into Adobe Analytics is not normally the domain of data analysts. Your job as an analyst is to, well, analyze the data captured from user activity.

But the following basic overview of how data is collected is important to analysts for two reasons. One, it’s good to know where data comes from when you want to assess its validity; and two, having a basic grasp of the process of mining and sending data into Adobe Analytics allows you to have more productive interactions with the folks who set up the tools that extract data.

Using Adobe Analytics to capture data from websites

Let’s start with the most common Adobe Analytics data source: websites. Web data was originally analyzed based on server logs. Server-log data is automatically generated by servers that host websites and provide a count and timestamp of every request and download of every file on the site. Unfortunately, the data is highly unreliable because server logs don’t have the capability to distinguish bots from humans.

Bots are automated computers that scan websites. These bots are often friendly and used to rank websites for search engines or product aggregator websites. Some bots, however, are unfriendly and used for competitive intel or worse.

Because server logs can't tell a human from a bot, the industry quickly migrated to tags, which are now the industry standard. Generally, tags are JavaScript-based lines of code that append an invisible image to every page and action on your website. These images act as a beacon to analytics tools, where several things happen in just a few milliseconds:

1. JavaScript code runs to identify browser and device information as well as the timestamp of the page view.
2. More JavaScript code runs to look for the existence of a cookie, which is a piece of text saved on a browser. Cookies can be accessed only by the domains that set them and often have an expiration date.
3. If it exists, a visitor ID is extracted from the cookie to identify the user across visits and pages. If a visitor ID doesn’t exist, a unique ID is created and set in a new cookie. These IDs are unique for each visitor but are not connected to a user’s personal data, thus providing a measure of privacy for users.
4. More JavaScript is used to capture information about the page: the URL, the referrer, and a slew of custom dimensions that identify the action and behavior of the visitor.

After all that JavaScript logic runs, the image beacon is generated to send data into the collection and processing engine in Adobe’s analytics.

Intimidating isn’t it? Well, that’s how web developers felt. When web analytics first came onto the scene, one of the toughest jobs was teaching developers how to write and test all this JavaScript to ensure that our tags fired accurately. Teaching developers to develop — not a fun job.

Lucky for us, an even smarter developer came up with an idea to move all that JavaScript into a single UI (user interface). web developers only had to add one or two lines of code to every page of the site, and the marketer could then manage their tags in this new platform named a tag management system, or TMS. It wasn’t long before the tag management industry exploded, leading to dozens of vendors, and then acquisitions, mergers, and technology pivots.

The good news is that the tag management system industry has become commoditized and is available for free from Adobe in the form of Dynamic Tag Manager (DTM) and Adobe Launch. You may already be familiar with Google’s TMS, Google Tag Manager, or one of the independent TMS players such as Tealium, Ensighten, or Signal.

Chances are your company is already using one of these technologies to deploy marketing tags on your website. All of them can deploy Adobe Analytics, although Adobe’s recommendation for best practice is to use Adobe Launch.

Using Adobe Analytics to capture data from mobile devices

If standard websites delivered to a laptop are the natural place to start with our data collection discussion, moving to a smaller mobile screen is the logical next step.

You may already know that at this stage of the evolution of web design, mobile websites are fully functioning web pages, not afterthought appendages to laptop, desktop, or large monitor sites. These smaller-scale websites are created by using an approach to web development called responsive design, in which the code used to create website content is the same regardless of the size of the web visitor’s screen and browser. Your company is most likely already leveraging responsive design.

When responsive design is applied, the same tags that fire on the desktop site should work on mobile- and tablet-optimized websites because they're essentially the same thing, which is good news in the tag management world. However, the world of responsive-design-based mobile apps is completely different than that of native apps.

Mining data from native apps with Adobe Analytics

Native apps present particular challenges for data collection. These mobile and tablet applications are programmed in a different way than responsive websites.

In general, native apps don’t run in browsers, don’t use HTML, and can’t run JavaScript. In fact, applications built for iOS are built in a different programming language (Objective C) than Android apps (Java). These technical programming languages are mentioned for one important reason: A tag management system is not going to work on your mobile and tablet applications.

Some tag management system vendors have hacked the capability to incorporate JavaScript into apps, but the result has limited capabilities and is far from a best practice. The most complete, accurate, and scalable way to deploy Adobe tools is to use the Adobe mobile software development kit (SDK). The Adobe mobile SDK is built to work as a data collection system, like a tag management system, but uses the app’s native programming language (Objective C for iOS or Java for Android).

The Adobe SDK is important because it has deeper access into the code that runs the app and therefore can be used for more than just data collection. In addition to sending data to Adobe Analytics, the Adobe SDK is required to do the following:

• Capture geographic location data based on GPS.
• Utilize geofences based on that GPS data for analysis or action.
• Send push notifications to users.
• Update content in the app via in-app messaging, personalization, and testing.

Access to these capabilities may be limited to the SKU, or version, that your company has purchased from Adobe. Work with your Adobe Account Manager to understand which of these capabilities is included with your contract.

Using Adobe Analytics to capture data from IoT and beyond

Now that you understand collection standards for the two biggest use cases (web and mobile), it’s time to branch out to a more generic set of the Internet of Things (IoT). Everyone who asks questions about data needs to be thinking about digital kiosks, smart watches, connected cars, interactive screens, and whatever other new devices our tech overlords have announced since this sentence was written.

Vendors such as Adobe find it difficult to stay on top of every new device because building SDKs takes time, money, research, engineers, code, quality assurance, and more. But don’t worry: Devices that don’t have native-built SDKs can still send data to Adobe Analytics.

The best practice for sending data from one of these devices is through an application programming interface (API). In short, this means the developers of the IoT application can write their own code to create a connection to your Adobe Analytics account and then send data to it.

APIs have become the default way in which data is sent from any device connected to the Internet either full time or part time. Adobe has some recommendations to share too, especially for some of their big bets when it comes to these new devices, such as voice and connected car. At the time of this writing, SDKs are not available for voice-activated devices or connected car applications. However, Adobe does have best practices for data customizations, variable settings, and code options for both of these technologies.

Enterprise software — software licensed to institutions — is updated regularly, and Adobe releases best practices for tracking data associated with new digital mediums such as voice and the connected car.

You’ve now explored all types of data generated by devices that have part-time or full-time access to the web: computers, phones, tablets, and IoT.

People’s digital experiences and interactions on those devices are captured by some combination of TMS, SDK, and API. According to marketers and analysts, that list is missing something: data that isn’t based on behavior.

Perhaps the best example of nonbehavioral data comes from your customer relationship management (CRM) tool. CRM tools are used to organize, categorize, and manage your prospects and customers. Other examples of nonbehavioral data that marketers and analysts would be interested in include the following:

• Call center
• Offline or in-store purchases
• Returns or cancellations
• Product cost of goods sold
• Ad campaign
• Customer satisfaction

Adobe Analytics can import any of these data types along with plenty of others. In general, this data is imported into Adobe Analytics via either File Transfer Protocol (FTP) or API.