2015-11-11

1. Dimensions vs. metrics
   1. Dimensions are the ‘rows’, metrics are the ‘columns’.
   2. Dimensions are how you GROUP the data, metrics ARE the data.
2. Creating a custom dimension: “Business Unit”
   1. Determine ‘key’ field. In this case, the hostname is the key. Show data example.
   2. Admin -> Select Property -> Custom Definitions -> Custom Dimensions -> New custom dimension
   3. Enter name -> Set scope (hit) -> Create -> View javascript code
3. Populating custom dimension data
   1. directly in google analytics javascript code
      • must manually edit webpage analytics code
      • must be present on all pages
      • high potential for oversight/misapplication
   2. filter
      • Would need multiple filters (one per business unit)
      • Would have to implement all filters correctly on all views
   3. data import (preferred in this case)
      • only have to import once, and will then apply the custom data to all hits
      • a new data import would have to be done each time a new subdomain is created, but that’s manageable
      • Admin -> Select Property -> Data Import -> New data set -> Custom Data -> Name -> Choose views
4. Viewing custom dimension
   1. secondary dimension in default reports (less ideal)
   2. custom report: “Business Unit Report”

1. Add hostname (subdomain) to request URI (page path)
   1. Why?
      1. In this case, we have multiple websites feeding into the same analytics account. By default, pages with the same path, even if on different websites (subdomains) will be aggregated into a single line-item. By including the hostname in the request URI field, we can disambiguate the data.
   2. Why not?
      1. If you had multiple domain names which resolved to the same website: for example, if testwebsite.com and test website.org domain names were really the same website. In this case, you may not want to split the data up by hostname, but instead to aggregate all path data together, regardless of hostname (google analytics default behavior).
      2. However, in this case, you should probably have two views to do both to see if there were traffic differences between your domain names.
   3. Review setup on Roll-up view profile
2. Lowercase URI
   1. Why?
      1. Generally, page paths are not case-sensitive. “testwebsite.com/page1” is the same page as “testwebsite.com/PAGE1”. In this case, you would not want to arbitrarily split these request URIs into different line-items.
      2. See example -> Roll-up view -> Behavior -> Site Content -> All Pages -> Date Range -> September 2014 -> Filter: admissions.gmu.edu/[Aa]pply[Nn]ow/(default.asp)?$
   2. Why not?
      1. It is possible on some servers (Unix) to have page paths be case-sensitive (i.e. “testwebsite.com/page1” would not be the same page as “testwebsite.com/PAGE1”). In this case, you wouldn’t want to change the case as it would group different pages together incorrectly. This is obviously not a common configuration.
   3. Exclude internal traffic.
      1. Review discussion from last week
   4. Remove querystring parameters (not a filter)

Filter: Include Hostname in Request URI
Filter: Lowercase URI
Filter: Exclude Internal Traffic
Property setting: Remove querystring parameters