Filters in Google Analytics (The Complete Guide 2019)

Filter in Google Analytics

The filters in Google Analytics Search (The Complete Guide 2019)

Google Analytics and Google Tag Manager include a number of tools that help you clean up data to make it as useful as possible, including filters and view settings in Google Analytics and blocking triggers and overriding default values in Google Tag Manager.


The most common needs for cleaning up data include removing internal traffic and standardizing and organizing URLs. This guide explains the complete list of filters in Google analytics 2019. 


There are a number of approaches using the tools in Google Tag Manager and Google Analytics appropriate for different situations, as well as some specialized tools for dealing with specific kinds of content (such as URL query parameters & fragments and site search results URLs).


Types of Filters

Types of Filters

When creating a new filter, you have two main choices:

  • Predefined filters cover a handful of common use cases, with easy-to-use drop-down menus to define the filter options.
  • Custom filters allow more flexibility and the use of regular expressions to match patterns.


Predefined Filters

The predefined filters use a series of drop-down menus to specify data to include or exclude in the view that covers a few common use cases, such as excluding an IP address or including only a specific subdirectory of the site. (You’ll see both of those examples later in the blog.)


Custom Filters


For more complex needs, custom filters offer a variety of options. First, there are a number of different types of custom filters:

  • Exclude: exclude data that matches a regular expression
  • Include: include only data that matches a regular expression
  • Lowercase: convert a field’s alphabetic characters into lower case


  • Uppercase: convert a field’s alphabetic characters into upper case
  • Search and Replace: find a regular expression match in a field and replace it with text
  • Advanced: find regular expression matches in one or two fields and rearrange the text from those fields


You’ll see each of these filter types in action in applications later in the blog. When you choose one of these filter types, you’ll see that Google Analytics provides a very long drop-down list of fields to filter on.


This list includes all the fields you might expect, but there’s a little challenge: the names used for fields in this list don’t always match up very well with how corresponding dimensions are named in the reports in Google Analytics.


For example, this menu includes Request URI, which is the same as the dimension simply referred to as Page in GA’s reports. As you look at examples in this blog, you’ll see several of the most commonly used fields from this list that may be useful, and there’s a full accounting in the Google Analytics documentation if you can’t quite decide which field is the right one.


All of the filter types which allow you to match values in a field (Include, Exclude, Search and Replace, Advanced) use regular expressions as input. This allows you to be as specific (one exact value) or as broad (multiple values, or some common pattern across values) as you need to be.


Caution   In regular expressions, characters like the dot (.) and question mark (?) have special meaning. Sometimes these appear in the strings you are matching, however (consider a URL like /alice.html.potion=drink-me).


You need to be careful, and for any special regular expression characters, you’d like to use as the literal character, preface it with a backslash (\).


Characters that require a backslash to be treated as ordinary characters are: \.?+*[(^$ Testing and Troubleshooting Views and Filters in Google Analytics. 


For the changes you make in Google Tag Manager, you can use GTM’s preview mode and other browser tools to inspect the data being sent to Google Analytics. But what about the changes you make with views and filters in Google Analytics? These are applied after the data is received, so browser-based testing tools don’t help you.



The critical characteristic of any changes you make in GA’s Admin interface is that they take effect only from the time you make the change going forward. Changes don’t retroactively affect the data in the reports in a view. This has important repercussions for testing changes.


Suppose you add a filter to a view, and later (an hour, a day, a week) you find there’s a typo, and you accidentally filtered out something you didn’t mean to. There’s no way to undo this retroactively in the view’s data.


You can correct the typo in the filter, which fixes data going forward, but for the intervening hour or day or week where the data was wrong, it stays wrong.


With this constraint in mind, to help with testing and troubleshooting filters and other view configuration settings, you’ll also want to create the following views:


An unfiltered view for troubleshooting and backup. If you’re filtering traffic out, how do you know what you’ve removed without an unfiltered set of data to compare it to?


An unfiltered view gives you a point of comparison. Create this view and don’t apply any filters to it. The other advantage of an unfiltered view is as a backup: if something goes wrong and you accidentally lose some data, you can always refer to the unfiltered view.


One or more test views to test changes to filters and other view configuration settings and ensure that they work properly. In this way, you have a place to try changes with no adverse consequences if you make a mistake (since you’re not actually using the data in these test views). These views would, of course, be in addition to any views you actually use for reporting and analysis of your site.


Tip  If you’re setting up a site from scratch, create these views at the same time you set up the site in Google Analytics so that the data goes back to the very beginning.


If you’re inheriting a site that has been previously set up, create these views right away so that they start gathering data to aid you as you make changes and updates going forward.

Once you’ve created a test view, you can use it to try out configuration changes in the Admin settings, and then look at the data in the reports of the test view to make sure they match your expectations.


Because the data in Google Analytics is typically reported on by day, and the changes only take effect going forward, changes made in the middle of a day can result in a mixed set of data (both before and after the change) for the day when the change was made.


To get a clear view of whether a filter is working correctly and the data is “clean,” you generally need to wait until the next day. The process typically goes something like this:


Make a change to a filter or other view configuration setting in the test view.

Wait until sometime in the next calendar day.

Check the relevant report(s) in Google Analytics, changing the date range to the current day.
Did you get it right?
If everything looks good, go ahead and apply the same filter or change the same setting in the reporting view(s).
If not, repeat this process from step 1.


Note  For certain types of data, you may be able to use the Real-Time reports to see the effect of a newly applied filter, but those reports don’t have full coverage of the types of data in Google Analytics and may be difficult to use in comparing two sets of data.

Partitioning Internal Traffic

Internal traffic

One of the most common desires is to separate website traffic by internal users from that of the general public, the customers and prospects whose website behavior is of interest to you.

Internal users have very different behavior from customers, are excluded from the targets of your marketing activities, and are often engaged in testing website functionality.


Although data about these activities may be useful to you, it’s useful in ways different from the activities of external users, so you’d like to be able to separate them.


The following sections explore two main topics connected to this challenge:

  • Removing (or separating out) traffic from internal users to avoid “polluting” your customer data.
  • Dealing with multiple versions of a site for development, testing, and staging to keep testing activity separate from your live website.


Removing Internal Traffic

“Internal traffic” includes your organization’s employees, as well as third parties who work on your website on your behalfs, like advertising agencies or web developers. Usually, you’re not interested in their usage of your website in the same context as external users—your actual audience—so you’d like to eliminate or separate them out.


There are several different ways to identify and block this internal traffic (by IP address in Google Tag Manager or in Google Analytics, or by Service Provider in GA), which you’ll explore in the following sections.


Different organizations define and treat internal traffic differently, so assess all of the options available to understand what will work best for your situation.

Note  None of these methods can be absolutely perfect: your employees sometimes travel, or work from home, or other situations in which it would be hard to identify them as “internal.” Do your best, but you should expect some data will leak through in any case.

[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


Separating Test and Production Environments


In many cases, you may already have taken care of excluding internal traffic in Google Analytics, which would typically include your employees’ or agency’s testing of your website.

However, you might want to be able to separately view such testing traffic to ensure that everything is working correctly—collecting test data about new site content or features before they go live on the website to ensure they’re working and recording data as expected.


Your exact setup will depend on your environments and how you’d like to be able to view the data. Let’s assume for example purposes that you have the following environments:



You’d like to keep the messy, internal testing data from the development and staging sites separate from the good, clean, customer-oriented data you use to analyze your site’s content and marketing on the production site.


You can accomplish this by creating additional properties in Google Analytics for the development and staging sites and using Google Tag Manager to route data to the correct property. The next section will walk through this process.


There’s another kind of testing traffic you should consider: when you use GTM’s preview mode for testing changes to tags and triggers on the live production website (, in this example). You might also want to separate this data into another property. A later section will look at that case later as well.


Cleaning Up and Grouping Content

Cleaning Up and Grouping Content

URLs are just one of many pieces of information captured in Google Analytics, but they’re often one of the messiest. In an ideal world, you have a site with URLs that:

  • are easy to interpret and grouped together in a logical hierarchy,
  • contain no extraneous or unnecessary information, and
  • uniquely represent a single page.


Often you don’t have complete control over the structure and format of URLs on your site (because of particular software being used or historical reasons, for example).


In many cases, you need to work with URLs on your website that are made for machines, not for people. By default, Google Analytics captures the URL that you see in the browser’s location bar, exactly as it appears. In GA’s reports, these URLs are broken up into two dimensions:


  • Hostname, which contains the domain name (which does not include the protocol and punctuation, such as http:// or https://)
  • Page, which contains the rest of the URL, including the path and query parameters, but not the fragment


So for example, in the following URL, Google Analytics shows these values for the Hostname and Page dimensions:



Since Google Analytics captures these pieces from the URL exactly as they appear, you can encounter inconsistencies in your data that aren’t ideal, where there are several variations of a URL that all correspond to what is essentially the same page on your site. 


These can include inconsistencies in capitalization, query parameters, and more. This section will take a look at each of these issues and some best practices for dealing with them, as well as methods for gathering URLs into groups, such as by topic categories or by internal search results pages.


Important  Changes to URLs can also affect goal conversions based on those URLs. Make sure to update your goal configurations if necessary after you have made changes to URLs through filters.


Enforcing Case in URLs

Technically speaking, URLs are case sensitive. That is, and don’t have to go to the same page.


However, in practice this is almost never how websites use URLs; usually, your web server or content management system will deliver the same page regardless of capitalization.


However, since Google Analytics simply captures the URL as it appears, it will potentially show the same URL capitalized in different ways in your reports


This isn’t very helpful—if you just want to know how many people viewed the page, you have to do the arithmetic yourself. Instead, you’d rather have one, consistent entry for each page in your reports, regardless of capitalization. To do that, you can apply a filter to this data in Google Analytics.




Default URLs

Another issue with consistency in URLs involves default pages. For your homepage or the default page of subdirectories on a site, a browser can often access the same page via multiple URLs. For example, your home page might be accessible through either of these URLs:



Note  The ending might differ depending on your content management system and web server: index.html, index.php, default.aspx, and so forth. Check your site to see what it uses. Now you again have a problem in your reporting


Similarly to the capitalization problems described in the previous section, you’d have to add up those rows to understand how many times this particular page was actually viewed.


Fortunately, you can fix this in Google Analytics as well. There are two options, depending on which version of the URL you’d like to consolidate on:


There’s a view setting that will append index.html (or whatever is appropriate) to the end of URLs that end in a trailing slash.

  • You can use a filter to remove index.html (or whatever is appropriate), leaving only the trailing slash.
  • Which you prefer is mostly a stylistic choice in the way you’d prefer to see the pages listed in your reports.



Google Analytics provides a setting that will automatically append text to the end of any URL that ends in a trailing slash.

In the Admin area of Google Analytics, with the appropriate account, property, and view selected, choose View Settings in the third column to edit the settings for the view.

  • Scroll down to the setting Default Page.
  • Enter the text you’d like to append to the end of any URL that ends in a trailing slash. (Do not include the slash.)
  • Save the changes to the settings.

Remember that this setting will only affect data going forward. Past data collected for URLs will not be affected.




In the Admin area of Google Analytics, with the appropriate account, property, and view selected, choose Filters in the third column to see the filters for the view. Select the New button to add a new filter.

  • Choose to create a new filter (rather than apply an existing one).
  • Give the filter a name: “Remove index.php” (for example).
  • Choose the Custom tab.
  • Choose Search and Replace as the filter type.
  • Choose Request URI as the field.
  • For the search string, enter a regular expression for the pattern you want to remove. This might be as simple as index\.html, or a more complex pattern if there are multiple possibilities—for example, (index|default)\. (php|html?)
  • For the replace string, leave it blank (to replace with nothing).
  • Save the filter.

Remember that this filter will only affect data going forward. Past data collected with index.php in URLs will not be affected.


Query Parameters

The “query string” or “query parameter” portion of the URL is the part after the question mark: id=123456


The query parameters consist of name-value pairs joined by equal signs, with multiple parameters separated by ampersands. Sometimes, they tell you something really valuable about the content of the page or the choices of the user (status=completed) but other times they’re unimportant (sort=az) or even detrimental to your data (sessionid=123456).


To see how query parameters can muck up your page data, consider that last example, sessionid. Web servers sometimes use a session ID or visitor ID to keep track of the user’s state in a process.


This number is used internally by the web server, but you don’t care about it, and furthermore, it’s different for every single browser session. This is like your capitalization problem from before, but instead of two ways to capitalize the URL, now there are hundreds or thousands!


Fortunately, you can remove query parameters you’d like to get rid of. There’s a view setting in Google Analytics that allows you to remove query parameters from the URL so that you can see one consistent URL with just the query parameters that you want to keep around. Or, if you want to do away with all query parameters, you could use a simple filter.


Tip  Sometimes it might make sense to have multiple views for the site with different settings or filters on the query parameters.


For example, one view could keep more detailed query parameter information for more specific reporting (when you really want to know if a user sorted from A to Z or Z to A), while another could remove those parameters for better high-level information about pages.


Before getting started, you’re going to need a list of the query parameters you’d like to eliminate. The part of the query parameter you are interested in is the name (that is, the part before the equals sign)—for example, status, sort, or sessionid in the example URL. How do you go about compiling this list?


If you have existing data in Google Analytics, that’s one place to begin. (It can be helpful to export the pages into a spreadsheet and use formulas to break apart the query parameters based on delimiters like ? &, and =.)


Looking into the documentation of your content management system or other software used to manage your website may also give insights into query parameters and how they are used. Once you’ve established a list of query parameters you’d like to eliminate, you can remove them.


Tip  One type of query parameter you might encounter are parameters relating to an internal site search. For example, in, the query parameter q=hats could indicate that the user searched for the term “hats” using your site’s search.


Don’t remove these with filters or the view setting—they’re valuable information, and Google Analytics has a special set of reports for dealing with them (and then you can strip them out of the URLs, too). You’ll see how in a later section in this blog.





After you publish this change to the Google Tag Manager container, your search results pages will send URLs to Google Analytics that look like /searchresults.php?q=hats. From here, you can simply proceed with the same setup as though you have query parameters discussed earlier in this section, using q as the query parameter set.


Grouping Content

In the previous section, you looked at a variety of ways to clean up URLs so that they correspond precisely well to a page, without needing to aggregate across variations of a URL.


Sometimes you also have a need to group pages at higher levels: by category, page type, or other classifications. Google Analytics has a number of tools to address this. Sometimes groupings may be obvious in the structure of URLs:


In this case, the Content Drilldown report (located in Behavior ➤ Site Content) groups URLs together based on these subdirectories. You can drill down through up to four levels of subdirectory in this report.


In other cases, you may wish to make groupings based on other information in the URL (such as a query parameter) or information not present in the URL at all. You can use a feature in Google Analytics called Content Grouping to accomplish this.


Content Groupings are created in a view. Each view can have up to five Content Groupings—that is to say, five different sets of categories for grouping pages (with an unlimited number of categories within each grouping).


Useful ways of grouping content will depend on your site and what kinds of content it contains, but common types of content groupings include the following:


  • By topic or product category
  • By content type or page template (landing pages, article pages, product pages, etc.)
  • By author, publication date, or other content metadata
  • By qualities of the page content (word count, contains a video, etc.)


Once the Content Groupings have been created, they are available to group pages in the Behavior ➤ Site Content ➤ All Pages report also other reports with Page as the primary dimension) as well as in the navigational reports such as the Behavior Flow report.


Content Groupings can be defined in three ways: by extraction, by rule definitions, and by tracking code. Extraction and rule definitions allow you to use patterns based on the page’s URL or title see while the tracking code option allows grouping based on categories you supply (often provided in the data layer).


The following sections explain each type of content grouping with examples of the situations in which it can be used.


Grouping by Extraction

Extraction uses regular expressions to extract group names from the page’s URL or title (or from custom dimensions). So, for example, in the following URLs, you might wish to extract the product type (hats, teacups, etc.):


The trick is to write a regular expression to match this pattern and to capture only the part of the URL you want. The portion to be captured is expressed in parentheses. In this case, the following regular expression might do what you need: /products?type=([^&]*)


Recall that GA’s Page dimension does not contain the hostname, so you begin with the URL path starting with /products. The [^&] matches all characters that aren’t ampersands, and the * says 0 or more of them. However, you should be careful: what happens if the category parameter isn’t always the first one?


Consider a URL like this: /products?id=123&type=hats


You want to be as specific as you need to be, and no more. A better choice for the regular expression, to match the earlier possibility, would be the following: type=([^&]*). Now you’re able to accommodate capturing the type parameter’s value no matter where it appears in the URL.


Notice that, with the extraction method, you are specifying the location in the URL where the content group label appears, but you never have to specify the labels themselves. They’re already there in the URL, and this pattern will match as many different category names as appear in the URLs.


Tip  The regular expression pattern shown earlier is especially useful in creating content groups by extraction. It’s known as “character class negation”: [^something], most often used with ampersands, slashes, and other common delimiters in URLs to match all characters except those listed.


Grouping by Tracking Code

In both of the previous methods, content groupings were based on information contained in the URL or other data already in Google Analytics. However, in some cases, you’d like to group by other information. Consider the following URLs:




This structure is pretty common on blog or news articles. If you were looking for the publication date, that would be easy enough to extract with a regular expression (see the earlier section). What if you wanted to group based on, say, the article’s author? Or what about article length?


Grouping based on tracking code allows you to supply the label in the page’s tags, by having a Google Tag Manager variable with the correct label. The source of this variable would typically be one of two options:


Data layer variable: For information that comes from the website’s content management system or another source. In the preceding example, the content management system knows the author of the article, and so you could include that in the data layer declaration for the page:

dataLayer = [{ 'author': 'Alice' }];


This approach can be used for any kind of content metadata that is available from the content management system or another source when the page is rendered.





Other Applications for Filters

The previous section looked at a number of the most common applications of filters and other settings for cleaning up data in Google Analytics, as well as a bevy of workarounds using Google Tag Manager to capture additional information. Filters have many potential uses, but the previous examples capture most of the common use cases.


The other most common purpose for filters is to create views with only a subset of the site’s data. This is useful especially when the parts of a site are operated or marketed semi-independently from one another.


For example, if there are separate marketing teams for different product lines or brands, each team may desire to have a view with reports that only contain the parts of the site under their influence.


Then they are also able to filter and group the data for the view in the ways that are most useful to them and set up conversion goals that are relevant.


Note  Keep in mind that the base limit for the number of views per property is 25. This limit can be raised for Google Analytics Premium subscribers and in some cases for other users of Google Analytics.


The most common ways to divide a site into these kinds of functional areas are by subdirectories or (sub) domains:


Subdirectories: You want to divide and into separate views.


(Sub)domains: You want to divide hotels.this scientist.command into separate views.

If more complex criteria are needed to specify the pages or hostnames in the view, the custom Include filter can be used with regular expressions.


Data Import 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

madhatter13, Milliner,35



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



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.


User Data Import

Google Analytics

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.


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.



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, multicasting 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.


Google Tag Manager Containers for Mobile Apps

Google Analytics



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.



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 the use of Google Analytics’s content experiment features to switch among several sets of values for value collection variables.



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 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 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 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.