%20(1).png?width=2500&height=1667&name=Portal%20Drop%20Down%20(1)%20(1).png "Take a Tour of Adswerve Connect")
Share
While digital analytics has become a vast world filled with myriad computer science knowledge, data science insights, and business acumen…there was a moment in time where merely counting pageviews was considered a big deal. Over time the tools advanced to help answer more complicated questions. One problem that can be difficult to solve is how to connect in-store conversions to web and app behavior. In-store conversions have traditionally been separate from web/app analytics. The following is a high-level strategy for connecting the data in a way to start examining interactions between these different sources.
A user can be reached through a wide range of mediums. We'll be covering three of the most important mediums in this post: web, app, and in-store. Users have behavior that can be tracked on each of these mediums. A user may click through a remarketing email that leads them to the website. This user could also buy something in-store. Or the user could open a push notification about a particular sale on their app. While tracking this behavior is not difficult, unifying this data in a meaningful way can be troublesome—especially with in-store conversions. A User ID can be used to help tie together information from each of these three mediums.
The User ID (explained more
here
) is a unique identification string that represents each user. Every tracked interaction should have that user’s User ID also sent along with that analytics hit. This allows for all interactions from one user to be bucketed under one User ID. If we can ensure that all three platforms have access to the same User ID for a single user, then we can begin to marry the data across these three mediums. We can then start answering questions about how online web and app experience connects to in-store conversions.
The following graphic outlines this approach assuming Google Analytics is the final destination for our data and we are using Google Tag Manager on the website and mobile app.
Now that we understand the overall goal, let's dig into what the User ID value can be. The User ID needs to be consistent per user across web, app, and in-store. The User ID should be passed into analytics when the user is authenticated for both web and apps. A typical place to start passing this value in is on a successful login event. For in-store conversions, this User ID can be associated with some type of membership ID. It's on in-store transaction that this User ID is passed into analytics. Now that all three mediums have access to the same User ID value, we can address how to attach the User ID onto all tracked interactions.
Next, we need to create a Universal Analytics tag. For this example, it can be a PageView, Event, or ScreenView/AppView.
There is a section called "Field to Set" upon opening a Universal Analytics tag. We will set the Field Name to the value of "userId" and the value to the User ID dataLayer variable we generated above.
Once this is added to all Universal Analytics tags, the User ID should be sent to Google Analytics on all hits when the user is authenticated. Now that we've covered how to properly setup hits for Web and Apps, we'll cover how to handle the in-store transactions.
This marriage of data between different mediums allows for many questions to be answered.
So, let's recap what we've done so far. We've made sure that the User ID is consistent across all mediums. We've also passed User ID into the dataLayer for web and apps, as well as setup GTM to handle the User ID. For in-store transactions we've made sure that the backend server makes a Measurement Protocol analytics hit with the User ID appended onto it when a conversion occurs. At this point, a user should have the same User ID value across all three mediums. Any interactions that are tracked will be bucketed under the user’s User ID. This gives us the ability to analyze how interactions on web and app affect in-store conversions.
Feel free to ask any questions below in the comments.
That said, the limitation of this strategy is that the user must make the in-store transaction with some type of loyalty ID. In this example we used a membership card. This is limiting but there are other ways to get around this (beacons). That is for another time. Also, the same strategy could be used for other offline interactions.
Now that we understand the overall goal, let's dig into what the User ID value can be. The User ID needs to be consistent per user across web, app, and in-store. The User ID should be passed into analytics when the user is authenticated for both web and apps. A typical place to start passing this value in is on a successful login event. For in-store conversions, this User ID can be associated with some type of membership ID. It's on in-store transaction that this User ID is passed into analytics. Now that all three mediums have access to the same User ID value, we can address how to attach the User ID onto all tracked interactions.
Web and Apps: DataLayer Push
First, the User ID should be pushed into the dataLayer when the user is authenticated. This will allow GTM to add it to any tag. This dataLayer push might look like the following: Web:dataLayer.push({ 'event':'login-success', 'userId': <USER ID> });iOS:
[dataLayer push:@{ @"event": @"login-success", @"userId": <USER ID> }];Android:
dataLayer.push(DataLayer.mapOf( "event", "login-success", "userId", <USER ID> ));Note: The above code snippets are for GTM for Web and Legacy GTM for iOS and Android. However, the same idea would apply for Firebase GTM for iOS and Android. Legacy GTM was selected to avoid confusion around syntax differences. Where <USER ID> represents where the User ID will be passed into the dataLayer. Next we'll look at how Google Tag Manager needs to be configured to handle the User ID.
Web and Apps: Google Tag Manager
Once the User ID is getting passed into the dataLayer, GTM must be configured to properly handle the User ID. This involves generating a dataLayer variable to handle the User ID and assigning this User ID to all Universal Analytics tags.- Generate DataLayer Variable to Reference User ID
- Generate Universal Analytics Tag
- Set userId in Field to Set
Next, we need to create a Universal Analytics tag. For this example, it can be a PageView, Event, or ScreenView/AppView.
There is a section called "Field to Set" upon opening a Universal Analytics tag. We will set the Field Name to the value of "userId" and the value to the User ID dataLayer variable we generated above.
Once this is added to all Universal Analytics tags, the User ID should be sent to Google Analytics on all hits when the user is authenticated. Now that we've covered how to properly setup hits for Web and Apps, we'll cover how to handle the in-store transactions.
In-Store: Measurement Protocol
Both the previous web and app implementations were using GTM for the Google Analytics implementation. For in-store conversions we don't have that option. We need a different mechanism to send hits to Google Analytics. Measurement Protocol is the solution of choice in this situation. Measurement Protocol is a HTTP/HTTPS request that is formatted in a specific way to be handled by Google Analytics. The analytic information of interest is carried in query parameters. One of these parameters is specific to the User ID. This query parameter is &uid. When an in-store transaction occurs from a user with a membership, the backend server that handles the transaction will need to generate an HTTP/HTTPS request that confirms to Measurement Protocol and contains the User ID. An example of this request is below: www.google-analytics.com/collect?v=1&t=event&tid=UA-XXXXXX-YY&cid=12345&ec=ecommerce&ea=transaction&el=red_socks &uid=<USER_ID> See this link for more information on Measurement Protocol or this link for examples. Once all of this implementation work has been done, we can start to understand how a user's interactions on the web, app, and in-store combine together. For example, we can start to understand how push notifications can drive in-store conversions.
This marriage of data between different mediums allows for many questions to be answered.
So, let's recap what we've done so far. We've made sure that the User ID is consistent across all mediums. We've also passed User ID into the dataLayer for web and apps, as well as setup GTM to handle the User ID. For in-store transactions we've made sure that the backend server makes a Measurement Protocol analytics hit with the User ID appended onto it when a conversion occurs. At this point, a user should have the same User ID value across all three mediums. Any interactions that are tracked will be bucketed under the user’s User ID. This gives us the ability to analyze how interactions on web and app affect in-store conversions.
Feel free to ask any questions below in the comments.
That said, the limitation of this strategy is that the user must make the in-store transaction with some type of loyalty ID. In this example we used a membership card. This is limiting but there are other ways to get around this (beacons). That is for another time. Also, the same strategy could be used for other offline interactions.