Skip to content

Commit

Permalink
md version of file
Browse files Browse the repository at this point in the history
  • Loading branch information
nballenger committed Feb 10, 2020
1 parent a68e821 commit 37b9a7f
Show file tree
Hide file tree
Showing 11 changed files with 2,303 additions and 122 deletions.
11 changes: 0 additions & 11 deletions Analytics/GeospatialPriorities.md

This file was deleted.

137 changes: 137 additions & 0 deletions Analytics/GoogleAnalytics/NotesOn_GA_CustomDimensionsMetrics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
# Notes on Google Analytics Custom Dimensions and Metrics

## Custom Dimensions and Metrics Feature Reference

From [https://support.google.com/analytics/answer/2709828](https://support.google.com/analytics/answer/2709828)

### Overview

* Custom dimensions and metrics let you combine analytics data with non-analytics data. Examples:
* If you stored gender in a CRM, you could combine that with your analytics data to see pageviews by gender
* If you're a game dev, metrics like "level completions" or "high score" may be useful.
* Custom dimensions can appear as primary dimensions in custom reports, and be used as segments and secondary dimensions in standard reports

### Prerequisites

* Only available for properties that have been enabled for Universal Analytics or contain at least one app reporting view.
* Supported by SDKs, analytics.js, and the Measurement Protocol
* Require additional setup in your Analytics account and tracking code

### Limits and Caveats

* 20 indices available for custom dimensions, 20 for custom metrics
* 360 accounts have 200 indices each
* Custom dimensions cannot be deleted, but can be disabled
* Don't try to reuse custom dimensions.
* Editing the name, scope, and value of a custom dimension, both old and new values can be paired with either the old or new dimension name, which conflates data in reports in a way that can't be filtered away.

### Lifecycle of custom dimensions and metrics

* Four stages: Configuration, Collection, Processing, Reporting
* Configuration - define dimensions/metrics with an index, name, and other properties like scope
* Collection - send custom dimension and metric values to Analytics
* Processing - data processed using custom dimension/metric defs and reporting view filters
* Reporting - build new reports using custom dimensions and metrics

### Configuration

* Before you can send values, they have to be defined in a property.
* Defining it means setting values for the following, and getting an index number from which to reference it.
* Dimension config:
* Name - name as it will appear in reports
* Scope - which data the custom dimension/metric will apply to
* Active - whether it will be processed
* Metric config:
* Name - name as it will appear in reports
* Type - how the custom metric value will display in reports
* Min/max value - min and max values to process and display
* Active - whether it will be processed
* Once you define a custom dimension or metric, don't edit the name or scope.

### Collection

* Dimensions and metrics are sent to GA at collection time as a pair of index and value parameters.
* The index corresponds to the index of the custom dimension/metric as assigned during configuration
* Unlike other data types, custom dimensions and metrics are sent to Analytics as parameters attached to other hits, like pageviews, events, etc.
* They therefore need to be set before a tracking call is made for the value to actually be sent to Analytics
* Example of setting a custom dimension value:

```javascript
ga('create', 'UA-XXXXX-Y', 'auto');

// set value for custom dimension at index 1
ga('set', 'cd1', 'Level 1');

// send custom dimension with a pageview
ga('send', 'pageview');
```

* Custom metrics with an Integer or Time type should be sent using integers
* Custom metrics with a Currency type should be sent as fixed decimal values appropriate to local currency.

### Processing

* During processing, scope determines to which hits a particular custom dimension value will be applied.
* View filters determine which hits and associated values are ultimately included in Reporting
* Scope and Precedence
* Four levels of scope:
* Product - value applied to the product (Enhanced Ecommerce only)
* Hit - value applied to the single hit for which it is set
* Session - all hits in a single session
* User - all hits in current and future sessions, until value changes or custom dimension becomes inactive
* Product level scope - because multiple products can be sent in a single hit, multiple product-level scoped dimensions can be sent in a single hit
* Hit-level scope - Value applied ONLY to the hit with which value was set
* Session-level scope - if two values are set at the same index in a session, the last value gets precedence and is applied to all hits in the session, overwriting any previous value set for that index in that session. Applies retroactively, since these are post-processed on the GA side, so if you change mid-session they all get the last value set.
* User-level scope - same deal, but for future sessions too
* Filters
* View filters can interact with custom dimensions/metrics in diff. ways:
* Custom dim/metric values are each associated with the hit with which they were received, regardless of their scope.
* If that hit is filtered by a view filter, the custom dimension or metric may also be filtered, depending on scope
1. Hit-scope - both custom dimensions with hit scope and all custom metrics will be filtered even if the hit they are associated with is also filtered
1. Session/user scope - dimensions not filtered even if the hit they were attached to is filtered. Values will still be applied to all hits in the current session / future sessions, respectively.

### Reporting

* After data gets through the processing pipeline, it's available in reports
* Custom dimensions/metrics are available in custom reports and available for use with advanced segments
* Custom dimensions can be used as secondary dimensions in standard reports
### Examples
* Shows how dims/metrics can be used by a game dev to measure player behavior
* Hypothetical:
* Game dev has a new game
* Current Analytics implementation tracks a screen view each time a user plays a level. Dev already knows how many times each level is played.
* Want to answer:
1. How many times are easy levels played versus medium/hard?
1. How many levels played each day in 3 day trial?
1. How many levels played in the trial vs paid users?
* To answer, creates new custom dimensions are used to create new groupings of hits, sessions, and users.
### Hit level scope
* Use to find out how many levels of each difficulty level are played
* Already tracking number of times a level is played by screenview hits
* Report will count screen views by difficulty level
* Use hit level scope because the difficulty level should only be associated with the screenview for the level
* Configuration--create a custom dimension def like:
* Index: 1
* Name: Difficulty
* Scope: Hit
* Active: true
* Collection:
* Dev already tracking screen views, just needs to set the dimension value just prior to the screen view hit being sent:
```javascript
ga('create', 'UA-XXXXX-Y', 'auto');
ga('set', 'cd1', 'easy');
ga('send', 'screenview', '/level_1/');
```
* Processing - Data gets processed and aggregated by screen name and dimension value
* reporting - Assuming three levels and three difficulties, you'd get nine rows of output, with a count of screen views per screen/difficulty combination; could also get a custom report that uses Difficulty as a primary dimension, to get aggregated counts per difficulty

### Session-level scope

* Track how many levels are played per day in a three day trial

132 changes: 132 additions & 0 deletions Analytics/GoogleAnalytics/NotesOn_GA_Events.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,132 @@
# Notes on Google Analytics Events

From [https://support.google.com/analytics/answer/1033068](https://support.google.com/analytics/answer/1033068)

# About Events

* Events - user interactions with content that can be measured independently from a web-page or screen load
* Examples:
* downloads
* link clicks
* form submits
* video plays

## See Event data in reports

* In GA, go to your view, then Reports → Behavior → Events

## Anatomy of Events

* Components of an Event, which are included in an Event hit:
* Category
* Action
* Label (optional but recommended)
* Value (optional)
* Example:
* Category: "Videos"
* Action: "Play"
* Label: "Baby's First Birthday"

### Category

* Name that groups objects to analyze together
* Typically used multiple times over related UI elements
* How you intend to analyze the data sets up how you record the hit
* The Event object model is flexible, but you should plan your desired reporting structure before deciding on category names
* Be very careful not to accidentally create duplicate categories via typo: "Video" and "Videos" are treated as separate

### Action

* Typically used to name the type of event or interaction you want to measure for a particular web object
* For a single "Videos" category, you could look at:
* time the video completes load
* Play button clicks
* Stop button clicks
* Pause button clicks
* The name for an action is up to you, but important to keep in mind the features of how an event action is used in reports:
* All actions are listed independently from their parent categories (so you can segment them without having to subsegment their category)
* A unique event is determined by a unique action name. If you use duplicate action names across categories, that can affect how unique events are calculated

### Label

* Lables give additional info for events you want to analyze, like movie titles, names of downloaded videos, etc.
* Example:
* Category: "Downloads"
* Action: "PDF"
* Label: "/salesForms/orderForm1.pdf"
* There is a report for all labels you create.
* Use it as an additional reporting dimension for user interaction with page objects
* Important features of how labels are used in reports:
* All labels are listed independently of their parent categories and actions
* A unique event is determined in part by a unique label name

### Action and Label best practices

* Action names should be relevant to your report data
* Using "Click" as the action name in "Downloads" and "Videos" categories lets you subsegment those categories by that action. However, if you use "Click" everywhere as the action, the usefulness of that segmentation is diminished.
* If you're going to use Event measurement extensively, choose action names that relate to the data categories, like "Play/Pause/Stop" for videos
* Use action names globally to either aggregate or distinguish user interaction
* If you use "Play" and "Stop" across all videos, that's all you can aggregate/disaggregate on
* If you use "Play - Mac" and "Play - Windows", you can further disaggregate
* Action does not always mean "action"
* Any string can be the action
* The actual event or action the user takes may not be what you're interested in, so you can use the Action parameter to analyse other events
* If you wanted to analyze downloads, you could provide the doc type as the action parameter
* Unique events are incremented by unique actions
* When a user interacts with an object tagged with a particular action name, the initial interaction is logged as a unique event for the action name. Additional interactions with the same trigger won't contribute to the unique event calculation for that action, even if the user leaves that object and starts interacting with another tagged with the same action name.
* Example: A user interacts with the Play action from two unique video players tagged with separate categories. Top Actions report for "Play" lists that as one unique event. Each category's Action report lists one unique action (since there's one unique action/category pair).

### Value

* It's an integer, can mean whatever you want it to mean.
* Value interpreted as a number, report adds up total values baed on each event count
* Also gives you the average per category
* No negative values

### Non-Interaction Events

* Optional boolean you can send to the method that sends the Event hit
* Determines how you want bounce rate defined for pages on your site that also include event measurement
* Example: A hoem page with a video embed
* You would want to know the bounce rate for the home page, but how to define that?
* Is interaction with the home page video an important engagement signal?
* If yes, you would want video interaction to be included in the bounce rate calculation, so sessions including only the home page with clicks are not calculated as bounces
* If no, you might want a stricter calculation, in which case you want to know the percentage of sessions including only the homepage regardless of if they watch the video
* A bounce is a session containing only one interaction hit
* Setting the non-interaction param to true means a session containing a single page tagged with non-interaction events is counted as a bounce, even if the visitor also triggers the event during the session.
* Omitting the option means a single page session where the event measurement happens will NOT be counted as a bounce if the visitor triggers the event.

### Implicit Count

* Each interaction with a targeted page object is counted and associated with a given user session.
* In reports, Total Events are calculated as the total number of interactions with a targetd object.
* If one user clicks the same button on a video 5 times, the total number of events associated with the video is 5, and the number of unique events is 1.
* An event gets credit for "session with event" only if that event was the first event of a session. Unique event count may not be equal to session with event.

### Implementation Considerations

* Bounce Rate Impact
* Bounce - a single-page session on the site
* For GA, a bounce is a session that triggers only a single request, such as when a user comes to a single page on the site and exits without causing any other request to send to the Analytics server for that session
* If you use Event measurement, you may notice a change in bounce rate metrics for those pages with Events, because Event measurement like page measurement is classified as an interaction request
* Bounces mean something slightly different for event enabled pages: a single-page session that includes no user interaction on targeted events
* Events Per Session Limit
* for `ga.js`, first 10 event hits are processed immediately, after that rate limited at 1/s, and absolute limit of 500 events per session
* For `analytics.js` and `gtag.js`, first 20 are processed immediately, then 2/s, max 500 total
* To stay below session limits:
* avoid sending extremely repetitive events
* avoid measuring mouse movement
* avoid time-lapse mechanisms that generate high event counts

### Event-implementation best practices

* Design model for events is very flexible, can be extended behond user-triggered events
* Useful event measurement reports require careful planning:
* Determine in advance all elements you want data for; having a sense of the overall number of events / objects to monitor will help establish your report structure that scales with an increase in the number and variety of events
* Work with report users to plan the reports.
* Adpot a consistent and clear naming convention. Every name you supply for categories, actions, and labels appears in the reporting interface.

### Events vs. event goals

* An event is a user interaction
* An event goal is a goal you define in GA that identifies a specific event as a conversion
Loading

0 comments on commit 37b9a7f

Please sign in to comment.