Google Analytics
Step-by-step guide to send your event data from RudderStack to Google Analytics
Last updated
Was this helpful?
Step-by-step guide to send your event data from RudderStack to Google Analytics
Last updated
Was this helpful?
Google Analytics is the world's most popular analytics service that lets you track and report your website traffic across a variety of sources.
RudderStack supports Google Analytics as a destination and makes requests to its endpoints through the Google Analytics Measurement Protocol.
Find the open-source transformer code for this destination in our GitHub repository.
Before configuring Google Analytics as a destination in RudderStack, verify if the source platform is supported by Google Analytics by referring to the table below:
Connection Mode
Web
Mobile
Server
Device Mode
Supported
-
-
Cloud Mode
Supported
Supported
Supported
To know more about the difference between cloud mode and device mode in RudderStack, refer to the RudderStack Connection Modes guide.
Once you have confirmed that the source platform supports sending events to Google Analytics, follow these steps:
From your RudderStack dashboard, add the source. Then, from the list of destinations, select Google Analytics.
Assign a name to the destination and click on Next.
To successfully configure Google Analytics as a destination, you will need to configure the following settings where Tracking ID is the only required field:
Once the destination is set up, events from RudderStack will automatically start flowing to Google Analytics. You can see the events in Google Analytics' real-time view.
RudderStack sends a pageview
hit to Google Analytics whenever you make a page()
call using the SDK.
From our JavaScript libraries, we automatically collect the following page properties with the page()
call just after the load()
call:
path
url
title
search
referrer
For a page loaded at
http://localhost/test_browser.html?param1=true
with title "Page Load"
path
/test_browser.html
referrer
""
search
?param1=true
title
Page Load
url
http://localhost/test_browser.html?param1=true
You can also override these values and call page()
with properties as shown below:
It is important to send a path
or url
property with page call, otherwise Google Analytics will reject the event.
There are other variants of the page()
call that you can send, which involve giving your page's name
and category
:
For a server-side page call, the application name is passed from RudderStack's context.app.name
as an
, otherwise the event will be rejected by GA. If the Include the Querystring in Page Views option is enabled in the RudderStack destination settings, then the entire URL with the querystring will be sent as dp
(Document Path). Otherwise, the querystring will be removed from the URL.
Personally Identifiable Information (PII) cannot be sent to the Google Analytics reporting interface. Thus nothing is passed to Google unless specifically directed.
Google Analytics' universal tracking allows you to set a user ID to the identified visitors if Send User ID to GA is enabled in the destination settings by the user. Also, the userid
property must be enabled in Google Analytics, and user-id view needs to be created.
A sample identify
call is as shown:
In the above snippet, the userid
will be set to user123
for Google Analytics, but the name and email will not be shared with Google. Traits along with custom dimensions, metrics, and content groupings can be set in the SDK.
For server-side, Google Analytics needs a customer identifier for each call to be made. RudderStack passes an internally generated ID as the cid
parameter for Google Analytics to understand every unique user. Traits are not mapped to custom dimensions, metrics and content grouping yet from our side in server-side.
You can call identify
once in order to set the userId
and user traits
for all subsequent calls that you make from our SDK for a particular user. If userId
is not set, RudderStack sends a generated ID (called anonymousId
) from its SDKs with every call made to the RudderStack servers. This id
is used as the cid
in Google Analytics. And if Send User ID to GA setting is enabled, the user ID property will be set as uid
and will be sent as well.
In Google Analytics, you can configure custom dimensions in the Admin page.
There are multiple scopes for custom dimensions, such as hits
, session
, user
, and products
(If Enhanced eCommerce is enabled). Once these are set up in Google Analytics, the traits and properties can be mapped to custom dimensions as set by the user in the RudderStack destination settings page (as seen in the Getting Started section).
A custom dimension should be set as dimension{index}
. For example, dimension1
and it will map accordingly when the user sets the dimension in GA settings as shown below.
Similar activity is to be done for metrics.
An identify
call with custom dimensions will be recorded after the next track
or page
call.
RudderStack captures any user activity whenever a track()
call is made.
A simple track
call is as shown:
This will send the following Event Category
and Event Action
:
Event Category
All
Event Action
Track me
We do not populate the Event Category
field by default. If you face such a requirement, use our custom transformations to populate the event payload with a category
property.
A more verbose track
call is shown:
The following properties are sent to the Google Analytics event:
Event Category
category
Event Action
Track me
Event Label
label
Event Value
value
If the non-interaction setting is enabled in the RudderStack destination settings, nonInteraction
with value 1
will be sent.
In Google Analytics, some events can be tagged as non-interaction events. On the server-side, it is set in ni
.
RudderStack supports basic E-Commerce tracking for Google Analytics.
The required steps are:
For every order completed, orderId
is required. For each product in the order, there must be an id
and name
. Other properties are optional.
The E-Commerce tracking should be enabled otherwise it will not be shown in the reports.
Enhanced E-Commerce allows you to derive insights on the E-Commerce events by combining impression data, product data, promotion data and action data. This is a necessity for product-scoped custom dimensions.
Enhanced E-Commerce must be enabled in Google Analytics, and should follow RudderStack's E-Commerce Tracking API.
The required steps are:
Similar to E-Commerce tracking, for every order completed the orderId
is required. For each product, id
and name
are required.
The product ID or name must be passed for all the events that has the product details. product_id
will check if properties.product_id
is present or not. Else properties.sku
will be picked.
order_id
is required for refunded orders.
To send Enhanced E-Commerce events, please enable it in the RudderStack destination settings page.
The Checkout steps feature is a key difference between the regular E-Commerce and Enhanced E-Commerce tracking, and a major feature of the latter.
You can configure the checkout funnel in the Google Analytics admin interface as shown below:
The checkout flow can be implemented by calling track
with checkout step viewed
and checkout step completed
for the steps you have added in Google Analytics.
An example of this is as shown:
For more information, please check our guide on the RudderStack E-Commerce Events Specification.
You can add the coupon
property if you want to send coupon data to order completed
.
Information related to impressions of the users who have viewed or filtered through the product can be collected through Enhanced E-Commerce. The product impressions are mapped to product list viewed
and product list filtered
events.
For full refunds :
For partial refunds:
clientId
(cid) is used to keep a track of the unique visitors to your website.
A Google Analytics universal cookie will look like the following:
The clientId
is 476220681.159039102
which can be cross-checked by running the following snippet:
For server-side calls, if clientId
is passed manually by sending anonymousId
and if the Send User ID setting is enabled in the destination settings along with cid
, then RudderStack passes the userId
as the uid
.
clientId
RudderStack takes the clientId
in the following decreasing order of priority:
From the integrations
object while initializing the SDK, as shown:
From the gaExternalId
by setting it as the clientId
, if specified in the payload.
From anonymousId
, if present.
On the server-side, user_agent
is set from context.userAgent
.
On the client-side tracking, the IP address of the HTTP request is sent automatically to determine the location of the visitor. However, on the server-side, the visitor's IP has to be included in the track
call.
The UTM parameters need to be passed manually to the server.
UTM parameters are passed in the context object in context.campaign
. campaign.name
and campaign.mediums
must be sent together to show up in the report. Also, campaign.term
and campaign.content
are optional.
You can also send data to Google Analytics using the measurement protocol. It provides parameters which are automatically collected by the device mode Google Universal Analytics tracker. You can collect the value of the parameter as a RudderStack trait or property when sending server-side events to Universal Analytics.
RudderStack supports the following measurement protocol parameters:
context.screen.width x context.screen.height
context.screen.innerWidth x context.screen.innerHeight
context.campaign.campaignId
from externalID googleAdsId
from externalID googleDisplayAdsId
The sample code below shows how to send gclid
and dclid
using externalID
:
There are some other important features associated with Google Analytics integration, as described in the sections below:
If you turn on the named tracker in RudderStack destination setting under the Other Settings option, Rudder will push the events to a GA tracker named as rudderGATracker
instead of the default tracker.
For more information on creating trackers follow this guide.
If it is turned off default tracker which is internally given the name t0
will be set.
A 2nd tracker can be set in the ready callback function of RudderStack SDK.
An example of sending events to GA with another tracking id:
You can turn on Anonymize IP Address in the RudderStack destination settings under the Other Settings option. Once this setting is enabled, Google Analytics anonymizes the address at the earliest possible stage of the collection network.
The default value of this is set to auto
. However, you can change it in the destination settings. You can get more information on this feature by referring to Google documentation.
There are two ways to do this:
Tracking visitors with userid
: If the Send User ID destination setting is enabled, it will be sent to identify the user, However, this only works for the identified users. Anonymous visitor sessions will not be maintained.
Tracking Anonymous Visitors: allowLinker
is enabled automatically by RudderStack as Google Analytics provides an auto-linking plugin that allows you to track cookies and anonymous visitors when moving from one page to the other.
For Universal profiles, this can be edited in Google Analytics directly.
This feature is used to tag visitors for remarketing campaign. Enable the Remarketing, Display Ads and Demographic Reports option in the Reporting section of the destination settings to utilize this feature.
When someone searches the site, the search term has to be added to the URL query. This feature comes in handy in such a case.
To enable this feature, turn on Include the Querystring in page views option in the destination settings
In your Google Analytics account, enable Site search Tracking and put the parameter query.
If the query is abc.com/s=xyz
the setting should be as follows:
Add your Optimize Container ID in the destination settings.
If the container ID is specified in the destination settings and Optimize is linked to your Google Analytics property, then it will be automatically enabled the next time analytics.js
is loaded. Note that this is applicable only if you are using the integration in the web device mode.
You can set the content group mapping in the RudderStack dashboard and Google Analytics, as shown in the images below:
When you send a page
call with the custom properties, RudderStack will use the value of the property you designate as the value of the specified content grouping.
For more information on content grouping, refer to this guide.
This feature specifies what percentage of users should be tracked. The default value is set to be 100.
This feature defines the sample size for Site Speed data collection. The default value is set to 1.
If enabled, the identify
calls will be made only from the server-side.
If any action is specified, it will go as ea
otherwise it will default to User Enriched
If any category is specified, it will go as ec
otherwise it will default to All
If enabled, Google’s AMP Client ID API will uniquely identify users who engage with your content on the AMP and non-AMP pages.
If the specified dimension is set in the properties of the page
call, it will be reset to null and a new value will be set.
The tracking ID can be found in your Google Analytics account:
Navigate to your account and go to Apps. The tracking ID will be present there.
Custom metrics and custom dimensions are fields that allow you to track custom properties associated with your events using RudderStack.
Metrics is for event properties having numeric data type while dimensions is for event properties having string data type. Both are used to track custom data properties in Google Analytics.
Please refer to the Getting Started section above in this document to know how to specify these fields on the RudderStack platform.
Yes. In the Property Setup, please change the website URL from HTTP (default) to HTTPS as shown:
Yes, you can. Please check the Real-time reports in Google Analytics. A sample dashboard is as shown:
Please adjust the Google Analytics' default reporting time frame from a month ago to the required date, in order to view the processed events of that day.
There could be 2 reasons for this:
There can be ad blockers enabled in the user's browser while visiting your site. This blocks the Google Analytics requests from being sent directly from the browser.
For the cloud mode, RudderStack is not blocked by ad blockers presently. If the events are sent to Google Analytics via the cloud mode, the actual number of events intended to be sent to Google Analytics are forwarded by the RudderStack server. So, the number of requests from the native mode or device mode is expected to be lower than cloud mode.
The RudderStack JavaScript SDK provides a way of detecting how many page view requests are potentially being blocked by the ad blockers throughout your site pages. Please check the section on Detecting Ad-blocked Pages for more information.
If you come across any issues while configuring Google Analytics with RudderStack, please feel free to contact us. You can also start a conversation in our Slack community; we will be happy to talk to you!
If the Disable MD5 encryption from Client ID setting is disabled in the dashboard, RudderStack passes the userId
as the clientId
in the MD5-hashed format.
Content Group Mapping in RudderStack
Content Grouping Settings in Google Analytics