Google Analytics Import Data (2019)

Google Analytics Import Data 2018

Google Analytics Import Data 2018

Google Analytics supports importing dimension and metric values in bulk, based on one or more key dimensions that already have values in Google Analytics. This can be used to join Google Analytics data with other systems, reduce the amount of data that needs to be sent from the website or protect sensitive information from being exposed on the site.

 

Data import works by creating a data set associated with a property in Google Analytics and then uploading files to the data set. The upload can be automated if it is updated frequently.

 

There are a number of different types of data import supported by Google Analytics, for e-commerce transaction refunds and product data, user data, campaign tagging, and cost data, geographic data, content data, and custom data.

 

you learned about using custom dimensions and metrics in Google Analytics to fill in additional data about your users and their behavior. You supplied those custom dimensions and metrics as additional data sent along with a hit in Google Tag Manager. Google Analytics provides another option to fill in these values, through its data import features.

 

Data import allows you to fill in the data using files uploaded directly to Google Analytics. This can be useful in situations such as the following: The data isn’t available to the site at the time the hit occurs—for example, because it’s stored in a separate system. You can upload data from such systems to Google Analytics.

 

The data is extensive, and including it directly on the site would be a development burden, or would exceed the character limits for data included in a hit. You can reduce the data sent from the site to certain key dimensions and fill in other values later. The data is sensitive and you wouldn’t want to include it on the site, such as certain kinds of the user or product data.

 

You’ll look at the process for importing data in detail in the next section, and then examine the several types of data import available and their applications.

 

Data Import Process

import process

The basic process for data import works like this:

  • You create a data set associated with a property in Google Analytics, to configure the dimensions and metrics that will be imported.
  • You upload a text file with the data to be imported. Google Analytics takes this and processes it into the data in reports.
  • You update the data set as necessary to update the data going forward.

 

Later in the blog, you’ll take a look at the specific types of data import possible in Google Analytics, but the basic process for each is the same. Let’s walk through it.

 

Creating a Data Set

Creating a data set in a Google Analytics property configures the dimensions and metrics that will be imported and creates a schema for the text files you will use to upload data. The data set acts as a container for the uploaded files and controls how the imported data is applied to Google Analytics.

 

The different types of data set available in Google Analytics each support one or more keys (a dimension that already has a value in Google Analytics that the imported data will be associated with) and one or more imported dimensions or metrics (the data that will be added by the import).

 

SET UP A DATASET FOR IMPORT

Data sets are created in a property in Google Analytics.

In the Admin area of Google Analytics, with the appropriate account, property, and view selected, choose Data Import in the middle column to see the data sets for the property. Select the New button to add a new data set.

 

  • Choose a type for the dataset. Select the Next Step button.
  • Enter a name for the data set to describe the data being imported.

 

  • (For some data import types only) Choose the views within the property where the imported data.
  • Select the dimensions and metrics for the import. 

 

  • Depending on the data import type selected, different options will be available for the key dimension(s) and the imported data.\
  • Choose options for overwriting data (this is discussed shortly, with the individual data types).
  • Select the Save button.

 

After you save the dataset, Google Analytics displays two buttons with links to get the schema for uploading data, or to get the ID for use with the API. You’ll take a look at how to use these shortly.

 

Google Analytics allows you to create up to 50 datasets per property. There are additional limitations on the number and size of uploads. Google Analytics Premium subscribers are allowed higher limits.

Once the data set is created, you’ll be able to upload data for import.

 

Data Import Schema

schema

The text files you’ll use to import data into Google Analytics are in CSV (comma-separated value) format, which is a text file format used to represent the rows and columns of a spreadsheet. CSV files are easily generated using a spreadsheet application like Google Sheets or Microsoft Excel, and they are also widely supported as an export format from many applications.

 

As you saw earlier, when you create a data set, Google Analytics offers a sample schema file that you can download. The schema file contains the headers that describe the dimensions and metrics included in the data set and shows the appropriate file format.

 

(Note that the headers used in dataset schemas match the way that dimensions and metrics are labeled in Google Analytics’s APIs; see the Appendix for more details.) Here’s a sample upload file with a few lines of data to be imported:

 

Google Analytics:userId,Google Analytics:dimension2,Google Analytics:dimension3

alice0214,Student,7.5

madhatter13, Milliner,35

queenofhearts<3,Royalty,65

 

As long as you provide the data in this format, Google Analytics doesn’t care where it comes from or what tools were used to create it. It could be assembled by hand, reformatted from an export from another system or tool, or generated by a script that automates the data import.

 

Uploading Data to a DataSet

Data_upload

Files for data import can be uploaded to Google Analytics manually, through the Admin area, or they can be automated through the API. This section describes the manual process. See the Appendix for more details on Google Analytics’s APIs.

 

Let’s take a look at how to manually upload data for import to Google Analytics. Let’s assume you already have your data file, properly formatted to the schema as described earlier.

 

  • In the Admin area of Google Analytics, with the appropriate account, property, and view selected, choose Data Import in the middle column to see the data sets for the property.

 

  • In the listing of data sets, select the “Manage uploads” link on the right for the data set you’d like to upload. Google Analytics displays a list of previous uploads.

 

  • Select the “Upload file” button at the top of the list.
  • Choose the file(s) from your computer to upload and select the Upload button.

 

The file will be uploaded and the status marked Pending until Google Analytics has completely processed the file. If there are no formatting errors, the status will be updated to Complete. Once this occurs, Google Analytics will begin applying the data import.

 

Updating Data Sets

Once uploaded, the data will be applied to data going forward. Some types of data import may rarely need updating after the initial upload, and for those, the manual upload process described earlier is an easy solution.

 

Other data import types may need regular updates, however—potentially even daily, for certain kinds of data that may change frequently. The manual upload process could be cumbersome for these kinds of applications, so using the API (see the Appendix) is recommended.

 

Tip There are a number of off-the-shelf tools that already exist to use the Google Analytics API to import data from other systems, such as cost data from advertising platforms. You should seek out tools that help you automate these repetitive tasks.

 

Updating or deleting data sets generally only affects data going forward, like all changes in Google Analytics’s Admin area. Historic data is unaffected. The different types of data import behave slightly differently in how they are affected by updates; see the next section for details by type.

 

Data Import Types

data_upload

There are three basic categories of data import available in Google Analytics: hit data (directly import hits to Google Analytics), extended data (import several kinds of dimension or metric values to be applied to existing hits in Google Analytics), and summary data (import metrics for data already aggregated in certain dimensions). You’ll take a look at the potential uses of each in the following sections.

 

Hit Data Import

Hit data import lets you directly import hits to Google Analytics. Once imported, they are treated like any other hit and are processed according to the filters applied to the property’s views. There is only one type of supported hit data for import: refund data for e-commerce transactions.

 

Refund Data

Refund data is used to import full or partial refunds of e-commerce transactions. You can use this to add data to Google Analytics about refunds that occur outside the context of the website, using the e-commerce or order-processing platform to supply the data.

 

Once a refund is added to Google Analytics, the transaction it corresponds with is updated to show the appropriate revenue and products after the refund is applied. Refund data must include the Transaction ID dimension. For a full refund, only the Transaction ID is needed.

 

The entire transaction, including all products, is refunded in Google Analytics. For a partial refund, there are two options:

 

  • Specify a Product SKU and Quantity from the transaction to be refunded. All listed products will be refunded and subtracted from the transaction revenue.

 

  • Specify an amount of refunded Transaction Revenue to be refunded. That portion of transaction revenue will be refunded, but all products will remain in the transaction.

Warning  Once refunds are imported into Google Analytics, there is no way to remove or modify them. Be careful and test refund data in a test property first to ensure that you know how the process works before applying to your production data.

 

Extended Data Import

Extended data import lets you extend existing hits in Google Analytics with additional information. They include one or more “key” dimension values from existing data to match up with imported values for dimensions or metrics. Most often, this is used to fill in values for custom dimensions or metrics, but it can also be used to overwrite values for existing dimensions.

 

Extended data import occurs during Google Analytics’s processing, which means that the data import is applied as new hits are collected. You can choose which of the property’s views the data will appear in. Because the data is incorporated during processing, if you make changes to a data set, those changes will only take effect going forward, not on historical data.

 

Note  Google Analytics Premium subscribers have the ability to designate data import to occur at processing time or at query time, meaning the imported data can be applied to historical data in reports and updated at will. There are six different kinds of extended data import. Let’s take a look at applications for each.

 

User Data Import

Google Analytics

User data can be imported to Google Analytics to enhance the information about individual users. You could use it to import user data from a CRM or other system with information to aid in user segmentation, like demographics, lifetime value or purchase information, and so on. 

 

The only difference between user data import is that you are simply passing in a single dimension on the site to identify users, and importing the rest of the dimensions later, in Google Analytics. User data can be imported based on the User ID or a user-scoped custom dimension.

The imported data can be a user-scoped custom dimension.

 

Campaign Data Import

Campaign data import can be used to fill in campaign-related dimensions such as source, medium, and campaign. It uses a key dimension called Campaign ID, which can be provided through campaign URL tagging.

 

Campaign data import can be used to accomplish one of the following:

Simplify campaign URL tagging by enabling you to provide a single parameter (utm_id) in campaign URLs, rather than each individual parameter for the source, medium, and so on (utm_source, utm_medium, etc.). The full set of descriptive dimensions can then be imported based on the Campaign ID value.

 

Fill in campaign-related fields that don’t have corresponding campaign URL parameters, such as the Ad Group or Referral Path dimensions, or a custom dimension. The imported dimensions can include Medium, Source, Campaign, Ad Group, Ad Content, Keyword, Referral Path, or a session-scoped custom dimension.

 

Geographical Data Import

Geographical data import can be used to create custom geographical regions or groupings with Google Analytics’s geographic data. For example, in the United States, maybe you’d like to group cities by county, or states into regions such as “New England” and “Midwest”. The key dimension for geographic data can be any one of the following, from broadest to most specific:

 

  • A subcontinent code according to the UN M.49 standard. These are numeric codes corresponding to subcontinent regions such as “Western Europe” or “Caribbean”.

 

  • A country code according to the ISO 3166-1 alpha-2 standard. These are two-letter codes corresponding to countries, such as “US” for the United States or “UK” for the United Kingdom.

 

  • A region ID from Google’s list of geographical criterion IDs. These are the geographic divisions used in Google advertising targeting, but they must correspond to an area in the Region dimension in Google Analytics.

 

  • Regions in Google Analytics are sub country divisions, such as the states of the United States, the provinces of Canada, and so forth.

 

  • A city ID from Google’s list of geographical criterion IDs. These IDs must correspond to locations in the City dimension in Google Analytics. The imported values can be any session-scoped custom dimension.

 

Tip  You can find the Subcontinent Code, Country Code, Region ID, and City ID in the list of dimensions available in custom reports in Google Analytics. If you’re not sure if you’re using the right values, create a custom report to check.

 

Content Data Import

Google Analytics

Content data import can be used to import hit-scoped custom dimensions based on the Page (URL). discussed a number of potential hit-scoped custom dimensions, such as a page’s author, publication date, and so forth. Content data import provides an alternative method to bring these data into Google Analytics.

 

Product Data Import

Product data import can be used to import product-related data based on the Product SKU. Imported data can include product dimensions such as the Product Category or Product Brand, or product-scoped custom dimensions or metrics. Product data import can be useful for the following situations:

 

Simplifying the site’s e-commerce tracking. Rather than including all the data about products in the e-commerce data in the data layer, you could simply include the SKU (along with quantity and price) and then fill in the additional descriptive fields later, using import.

Importing dimensions or metrics that are too sensitive to include in data directly on the site, such as the product’s profit margin.

 

Custom Data Import

Custom data import can be used for other associations between dimensions and metrics to be imported (typically custom dimensions and metrics, but also supporting certain built-in dimensions). As the key dimensions, you can select up to two dimensions from a variety of built-in dimensions, as well as custom dimensions of any scope. The imported values can also be a variety of built-in dimensions and custom dimensions or metrics of any scope.

 

Summary Data Import

data_import

Summary data import differs from extended data import because rather than importing data corresponding to individual hits, data is imported for aggregate measures. Summary data import is applied to Google Analytics’s reports after processing, so it can be updated at a later point in time to apply data retroactively.

There is only one type of supported summary data for import: cost data for advertising and marketing campaigns.

 

Cost Data Import

Google Analytics’s integration with AdWords and DoubleClick platforms to import impression, click, and cost data for advertising on those platforms.

Similarly, you might wish to import data for advertising on other networks. Although there’s no automatic integration with Google Analytics for other advertising networks and platforms, you can use cost data import to bring in this data.

  • At a minimum, cost data import must contain the following
  • The Medium and Source dimensions.
  • At least one of the metrics Impressions, Clicks, or Cost.
  • The dates to which the data apply.

 

Additionally, you can be more specific by including more dimensions such as Campaign, Ad Group, Keyword, and so forth. Additional metrics are also calculated from this data, such as Cost per Click and Return on Ad Spend.

 

When you create a cost data import set, you can choose whether new data uploads should be added to any existing data for that date (summing the impressions, clicks, and cost), or whether it should overwrite existing data.

 

Collecting Data from Mobile Apps

mobile_apps

So far this book has focused on using Google Tag Manager to implement Google Analytics (and potentially other tags) to measure websites. But websites aren’t the only way our customers interact with us. Another important channel is the use of native apps for mobile devices—the kind you can download and install on a phone or tablet, rather than visiting a website in a browser.

 

Google Tag Manager and Google Analytics can be used to collect data from mobile apps as well—specifically, from Android and iOS apps (on any devices using those operating systems). Using these tools for measurement provides a number of advantages:

  • A single reporting tool (Google Analytics) for websites and apps, using all the same data cleanup and reporting functions that you already know.

 

  • A single deployment tool (Google Tag Manager) for websites and apps, using the same structure and publication mechanisms that you already know.

 

  • A way of updating between published versions of the app. (Typically, apps must be updated through an app store in a publication process, which can be cumbersome.)

 

There are, of course, some differences in the data collected in Google Analytics and the ways you can collect it in Google Tag Manager since we’re talking about different environments from websites. This blog looks at these differences, the platforms on which Google Analytics and Google Tag Manager can be used, and the process for deploying these tools through their software development kits (SDKs) in mobile apps.

 

Note  Keep in mind that this blog isn’t intended to teach you how to develop an Android or iOS app. While the implementation within Google Tag Manager for apps is similar to websites, implementation in the app’s code is best left in the hands of a capable Android or iOS developer. This blog is designed to give you the necessary knowledge to interact with that developer to achieve a successful implementation.

 

Google Analytics for Mobile Apps

Google Analytics

Before you take a look at how to collect data in mobile apps, let’s examine the data itself that will be collected in Google Analytics. The data is similar to website data, with some differences:

Rather than the pageview hit type, mobile app data contains screen views, which represent a screen loading within the app. The screen views are identified by a dimension called Screen Name (rather than the Page dimension containing URL for pageviews).

 

Mobile apps also support an additional hit type for exceptionsthat is, errors and crashes that occur within the application that you’d like to capture. Additional dimensions such as Application Name, Application ID, and Application Version are available in mobile apps, whereas other website-specific dimensions like Hostname may not apply to app data.

 

The hit types for the event and social interactions are available in mobile apps, just as in website data, to track interactions such as video plays, button clicks, or social media interactions. E-commerce and enhanced e-commerce features are available in mobile apps, just as in website data, to track in-app purchases.

 

Campaigns work somewhat differently in apps. Campaigns can be used in two distinct ways:

  • Tracking the original installation source of an app—how a user arrived at the Google Play Store (for Android) or the iTunes Store (for iOS) to download and install the app.
  • Tracking app launches from URLs—when a link in a web browser launches the app for a user.

 

Because of these differences, in Google Analytics you can create app-specific properties and views, which rearrange the default reports to better reflect the data for apps.

 

App Properties and Views

When creating a new property or view in Google Analytics, you can make the choice of whether the property or view should be for an app or a website. This choice affects the structure of reports available in the view. (Making this choice when creating a property affects the default view created with the property, but subsequently created views can be for either website or app data.) Choosing a view for mobile apps rearranges reports in the view to focus on app data.

 

For example, you’ll find that rather than the Behavior ➤ Site Content ➤ All Pages report (which focuses on pageviews), instead, you have Behavior ➤ Screens report for screen view data.

 

In the Acquisition reports, you’ll find reports for the iTunes and Google Play stores. Although this list of reports differs for apps, you’ll find that all the familiar Google Analytics reporting functions are available, such as segments, dashboards, and many other tools.

 

Like website data, you can use the view and property settings to customize mobile app data, including creating goals, using filters and content groupings, and so on.

 

COMBINING OR SEPARATING WEB AND APP DATA

Google Analytics

 

Note that it’s possible to include both website and mobile app data in the same property. (They can then be separated when desired using filters.) Should you combine data for mobile apps or keep it separate? For websites and apps where users log in, you can use the User ID features of Google Analytics to connect their activity across these platforms.

 

However, a drawback of combining mobile app and website data is that Google Analytics doesn’t contain reports where data about content (pageviews and screen views) can be easily combined, milti casting some of the advantages of this approach. Ultimately, the choice is up to you. You should evaluate your needs for analysis and the utility of combining these types of data together in Google Analytics.

 

Google Analytics Premium subscribers can use Roll-Up Properties to combine data from separate properties, giving additional flexibility. Mobile app and website data can remain in separate properties, but be combined in a roll-up property for analysis together.

 

Other solutions for combining the data include using the Google Analytics APIs to extract data from properties and combining them in reports outside of Google Analytics.

 

Mobile App SDKs

Google Tag Manager has official SDKs for the Android and iOS platforms. Additionally, Google Analytics has an SDK for the Unity Game engine.

 

Note  For any platform you’d like to track outside those with an official SDK, data can be sent to Google Analytics via the Measurement Protocol

 

Android and iOS

The Google Tag Manager SDKs for Android and iOS share many similarities. Although the details of their implementation will differ (in Java for Android apps and Objective-C or Swift for iOS), conceptually they both follow the same basic framework:

 

The Google Tag Manager SDK is included in the app.

The Google Tag Manager SDK for Android comes bundled with the Google Play Services SDK, a collection of SDKs for Google services such as Google Drive, Google Maps, and others. The Google Tag Manager SDK allows the developer of the Android app to embed a Google Tag Manager container in the app’s Java code to push events and values to the data layer.

 

The Google Tag Manager SDK for iOS can be loaded into an iOS app. Objective-C or Swift code can be used to push events and values to the data layer. Unlike a website, which fetches a new copy of the container every time it loads, a default container is included with the application. Apps can run on devices that aren’t guaranteed to be online, so it’s important that a default container is included for tracking functionality if the container cannot be updated over a network connection when the app launches.

 

Code embedded in the app pushes events and values to the data layer. Note that, unlike a website where the data layer is re-created with each page load, the data layer in an app persists for the entire session. Just like with websites, Google Tag Manager can trigger tags based on data layer events. According to the tags and triggers you’ve set up in the container, data is dispatched to Google Analytics (or other tools with other tags).

 

As noted earlier, apps may run on devices that may not currently have a network connection. Google Tag Manager attempts to send hits to Google Analytics or other tools, but if there is no network connectivity, it queues hits to send later. (In the case of long delays, hits older than four hours may not be processed by Google Analytics.) Even with network connectivity, Google Tag Manager batches hits to dispatch at regular intervals to preserve battery life.

 

Unity

In addition to iOS and Android, Google Analytics also provides an SDK for the Unity platform. Unity is a Game engine in which a single set of code can be compiled into apps on multiple platforms.

 

Although there is a Google Analytics SDK for Unity, there is no Google Tag Manager SDK. This means you won’t be able to manage tags via Google Tag Manager.

 

Instead, code within your Unity app directly specifies to send screen view, event, or exception data to Google Analytics (akin to implementing Google Analytics directly in the JavaScript of a website, for example).

 

Google Tag Manager Containers for Mobile Apps

Google Analytics

You can create a container for a mobile app by creating a new container from the account overview screen. When creating a container, Google Tag Manager allows you to choose whether the container is for a website, an Android app, or an iOS app.

 

Differences from Website Containers

A Google Tag Manager container for mobile apps works in basically the same way as with websites, containing tags, triggers, and variables. However, there are some differences in the options available and in the testing processes with mobile apps. Let’s take a look.

 

Tags

Like website tags in Google Tag Manager, for mobile apps, there are a number of built-in tags, as well as custom tags.

The tags include the following:

  • Built-in tags for Google Analytics, AdWords, and Double Click. These have the same options as with websites.
  • A Custom Image tag for custom tracking pixels. Again, this tag has the same options as with websites.
  • A Function Call tag that can be used to call a function within the app, including arguments if necessary.

 

Note that, unlike Custom JavaScript tags on a website, custom code (Java for Android, Objective-C or Swift for iOS) cannot be directly included in a tag. However, the Function Call tag can be used to call to a function that already resides in the app.

 

Triggers

There is only one kind of trigger in Google Tag Manager mobile app containers, the Custom Event trigger. As with websites, this is used to trigger tags when an event value is pushed to the data layer.

 

Tip  As with web traffic, you should employ triggers (and blocking triggers) to separate testing data on mobile apps. Specifically, using the {{App Version Code}} or {{Advertiser ID}} variables may be especially useful for mobile app testing triggers.

 

Variables

Mobile app containers include built-in variables that provide commonly used values. These include the following:

App-related variables, including the app ID, name, and version, and the version of the Google Tag Manager SDK being used.

 

Utility variables that are identical to website containers, including the Google Tag Manager container ID and version, the custom event value from the data layer, and a random number variable. Additionally, mobile apps offer a variable that indicates whether the user has advertising tracking enabled or has opted out. (Android and iOS both offer system-wide options to opt out of interest-targeted advertising.)

 

Device-related variables, including platform (Android or iOS), OS version, device type, language, screen resolution, and advertiser ID, which is a persistent but user-resettable device identifier (which differs from the permanent device hardware identifier) that both Android and iOS offer to track devices.

 

This value—often referred to as “IDFA” or ID for Advertising from its name in iOS—takes the place of a cookie (as for the Google Analytics cookie for client ID) for device identification for mobile apps.

 

Additionally, you can create custom variables of the following types:

  • Constant and Data Layer Variable types work identically to website containers.
  • The Function Call variable type allows you to call a function within the app and use the returned value.
  • The Value Collection variable type allows you to specify a list of key-value pairs that can be used in the app.
  • The Google Analytics Content Experiment variable allows use of Google Analytics’s content experiment features to switch among several sets of values for value collection variables.

 

APP CONTENT DELIVERY VIA Google Tag Manager

Google Analytics

Like with websites, Google Tag Manager in mobile apps can provide tracking capabilities (via tags like Google Analytics or AdWords conversions), as well as actual content or functionality for the app (via variable values and custom tags). It’s generally recommended not to provide content or functionality for websites via Google Tag Manager, for several reasons:

 

  • It muddies the purpose of Google Tag Manager (providing a system for managing tracking tags) when there are other options (content management systems, web servers) for providing such data dynamically to websites.
  • It leads to bloating of the Google Tag Manager container (which has a maximum size of 200 kilobytes) with content that would be better managed elsewhere.

 

If critical functionality depends on the content in Google Tag Manager and the container is for some reason unavailable, the website cannot work properly.

 

However, the balance of factors is somewhat different in apps. The app update process (via app stores) tends to be lengthy and cumbersome, and as a result, you’d want to update apps as seldom as possible. Thus, the ability to make minor changes via Google Tag Manager between app store updates can be very valuable, but unfortunately, there’s no such thing as a “content management system for apps,” which is a role that Google Tag Manager can help fill.

 

Additionally, unlike websites, apps always incorporate a copy of the container as a fallback, even if a refreshed container can’t be retrieved from Google Tag Manager, so the risk of an unavailable container is mitigated.

 

For these reasons, it’s more common to use Google Tag Manager to provide configuration data or to launch functions in mobile apps. Value collection variables are often used for providing configuration settings or other content to the app. For example, suppose you have a valuable collection variable with the following values:

  • {
  • "suit": "hearts",
  • "card": "queen"
  • }

Our app can retrieve these values (via the container.getString() function in Android or [container stringForKey:@{}] in iOS) and use them in the app:

 

Value collection variables can be used to contain configuration values or URLs that are inputs to functions in the app, text strings used in the app’s interface, or any other pieces of information useful for altering the content or behavior of the app. This functionality is one of the key advantages of using Google Tag Manager in mobile apps.

 

The Data Layer in Mobile Apps

The data layer in a mobile app works much the same way as on a website: a running queue of events and values used to trigger tags and supply variable values.

 

On websites, each new page loading causes the browser to clear away any JavaScript from the previous page. As a result, the data layer is renewed on each page. In mobile apps, however, the data layer persists until the app quits. This has several consequences:

 

It’s useful to have a persistent data layer because you don’t need to refresh persistent values continually throughout a user’s session (like you would with a website). For example, user- or session-scoped custom dimensions, user ID, or other values that stay the same throughout the session remain in the data layer and need not be re-added.

 

On the other hand, you need to manually clear transient values that shouldn’t apply later. Enhanced e-commerce values, for example, apply to a specific hit, but not to subsequent hits. You need to clear those values (or overwrite them with new ones) to send the appropriate data for each hit.

 

Also note that there are no default data layer events (Google Tag Manager.js, Google Tag Manager.dom, Google Tag Manager.load) as there are for websites. Everything you’d like in the data layer needs to be explicitly pushed from the app’s code. The Android and iOS SDKs provide functions for pushing information to the data layer.

For Android, use the DataLayer.pushEvent() function, and for iOS, use the [dataLayer push:@{}] function.

 

Deployment and Testing

Deployment and testing follow a somewhat different flow on mobile apps because our update processes are different from websites and different tools are available to us.

 

First of all, the debug panel you’ve used with websites isn’t available in mobile apps. The Google Tag Manager SDKs do have built-in logging that can be enabled to view detailed logging information during the development phase. Enable this in Android with TagManager.setVerboseLoggingEnabled(true) or in iOS with [self.tagManager.logger setLogLevel:kTAGLoggerLogLevelVerbose].

 

When making changes in Google Tag Manager, you have two ways of previewing the changes to the container in an app. If the app is still in development, you can download a binary file representation of a container to be included in the app. The Download option can be found in the list of actions in the version list for a mobile app.

 

Note  You should include a copy of a testing, fully functional container in the compiled app binary before submitting to the app store or distributing to users.

 

As with websites, you can use a preview link (or a QR code) to preview changes to a container in an app—including a published, live app. Before using this link, you must register the URL scheme in your app’s code. Then you can select the Preview option in the list of actions in the version list to obtain the link 

 

For testing mobile app containers on live apps on devices, a packet sniffer (monitoring the outgoing network traffic from the device) may be useful (similar to the use of browser developer tools for websites). And of course, you can monitor incoming data to Google Analytics to ensure that it matches up to what you expect.

 

Note  When using Google Analytics’s Real-Time reports to monitor testing activity, remember that the mobile app SDKs batch hits and dispatch them on an interval. As a result, you won’t quite see things in real time—instead, several hits will arrive in a burst after a short delay. This is normal behavior for app data.

 

Collecting Data from Mobile Apps

Google Analytics

Google Analytics can collect data from mobile apps using the screen view hit type, in addition to the event, social, and other hit types discussed previously, plus some additional dimensions that apply specifically to mobile apps. Google Tag Manager provides SDKs for Android and iOS to enable the use of containers in mobile apps, including Google Analytics tags.

 

Mobile app containers include tags, triggers, and variables. The selection of tags and variables differs from websites, and the only types of available triggers are for events pushed to the data layer.

 

Google Tag Manager can be especially valuable for mobile apps when the Value Collection variable type is used to provide updates to content or provide configuration values to a mobile app between app store versions.

 

Mobile apps use a data layer that persists throughout the session, unlike websites.

 

Mobile app testing tools include a preview mode and also the ability to download a container to be compiled into the app.

 

Google Tag Manager and Google Analytics can be used to collect data from mobile apps as well—specifically, from Android and iOS apps (on any devices using those operating systems). Using these tools for measurement provides a number of advantages:

 

  • A single reporting tool (Google Analytics) for websites and apps, using all the same data cleanup and reporting functions that you already know.
  • A single deployment tool (Google Tag Manager) for websites and apps, using the same structure and publication mechanisms that you already know.
  • A way of updating between published versions of the app.

 

There are, of course, some differences in the data collected in Google Analytics and the ways you can collect it in Google Tag Manager, since we’re talking about different environments from websites.

 

This blog looks at these differences, the platforms on which Google Analytics and Google Tag Manager can be used, and the process for deploying these tools through their software development kits (SDKs) in mobile apps.

 

Note  Keep in mind that this blog isn’t intended to teach you how to develop an Android or iOS app. While the implementation within Google Tag Manager for apps is similar to websites, implementation in the app’s code is best left in the hands of a capable Android or iOS developer. 

This blog is designed to give you the necessary knowledge to interact with that developer to achieve a successful implementation.

 

Google Analytics for Mobile Apps

Before you take a look at how to collect data in mobile apps, let’s examine the data itself that will be collected in Google Analytics. The data is similar to website data, with some differences:

 

Rather than the page view hit type, mobile app data contains screen views, which represent a screen loading within the app. The screen views are identified by a dimension called Screen Name (rather than the Page dimension containing URL for page views).

 

Mobile apps also support an additional hit type for exceptions; that is, errors and crashes that occur within the application that you’d like to capture. Additional dimensions such as Application Name, Application ID, and Application Version are available in mobile apps, whereas other website-specific dimensions like Host name may not apply to app data.

 

The hit types for the event and social interactions are available in mobile apps, just as in website data, to track interactions such as video plays, button clicks, or social media interactions.

  • E-commerce and enhanced e-commerce features are available in mobile apps, just as in website data, to track in-app purchases.
  • Campaigns work somewhat differently in apps. Campaigns can be used in two distinct ways:

 

  • Tracking the original installation source of an app—how a user arrived at the Google Play Store (for Android) or the iTunes Store (for iOS) to download and install the app.
  • Tracking app launches from URLs—when a link in a web browser launches the app for a user.

 

Because of these differences, in Google Analytics you can create app-specific properties and views, which rearrange the default reports to better reflect the data for apps.

 

App Properties and Views

When creating a new property or view in Google Analytics, you can make the choice of whether the property or view should be for an app or a website. 

 

This choice affects the structure of reports available in the view. (Making this choice when creating a property affects the default view created with the property, but subsequently created views can be for either website or app data.) Choosing a view for mobile apps rearranges reports in the view to focus on app data.

 

For example, you’ll find that rather than the Behavior ➤ Site Content ➤ All Pages report (which focuses on page views), instead, you have Behavior ➤ Screens report for screen view data. In the Acquisition reports, you’ll find reports for the iTunes and Google Play stores. 

 

Although this list of reports differs for apps, you’ll find that all the familiar Google Analytics reporting functions are available, such as segments, dashboards, and many other tools.

 

COMBINING OR SEPARATING WEB AND APP DATA

Note that it’s possible to include both website and mobile app data in the same property. (They can then be separated when desired using filters.) Should you combine data for mobile apps or keep it separate? For websites and apps where users log in, you can use the User ID features of Google Analytics to connect their activity across these platforms.

 

However, a drawback of combining mobile app and website data is that Google Analytics doesn’t contain reports where data about content (pageviews and screen views) can be easily combined, multi casting some of the advantages of this approach. Ultimately, the choice is up to you. You should evaluate your needs for analysis and the utility of combining these types of data together in Google Analytics.

 

Google Analytics Premium subscribers can use Roll-Up Properties to combine data from separate properties, giving additional flexibility. Mobile app and website data can remain in separate properties, but be combined in a roll-up property for analysis together. Other solutions for combining the data include using the Google Analytics APIs (see the Appendix) to extract data from properties and combining them in reports outside of Google Analytics.