Single customer view

Less than 10% of companies manage to create an accurate 360-degree view of customers – according to Gartner. On top of this, just 5% can use this single customer view to systemically grow their businesses. Despite this, successfully achieving a complete view of your customers can have profound effects across the business.

Who is the article for?

We designed this content for two audiences:

The first section of this article is designed for anyone to get a broad understanding of the benefits and challenges of obtaining a single customer view.

The second section is for data teams who want to explore different types of user identifiers and SQL queries that can be used to obtain a customer 360.

What is a single customer view?

Each user leaves a unique footprint when they interact with your digital ecosystem in the form of a behavioral event. Once collected, these events need to be ordered and attributed to an individual user in order to understand the customer journey.

A single customer view means collecting data from all your platforms, devices, and channels and unifying this data at a user level.

For behavioral data, this generally looks like this:

This data would generally be enhanced in a central storage location, such as a data lake or warehouse, to include other data sources, including financial data, CRM data, and so on. 

Here’s an example of similar data before modeling and after modeling to a session level.

The benefits of a single customer view

Getting a customer 360 is often the starting point for other use cases, as effectively attributing digital events to users is necessary in order to create a well-understood data set.

A single customer view can facilitate:

• Marketing attribution
• Content and product personalization
• Customer service analytics
• And many more.

In terms of the business outcomes, the benefits are hardly quantifiable – how much is it worth for a business to understand their customer touchpoints from beginning to end?

The challenges with creating a single customer view

1. Consent and tracking restrictions

Restrictions such as Apple’s ITP as well as cookie blockers mean that browsers can restrict your tracking to days, rather than years. This makes creating a single customer view for longer buyer journeys can be very challenging.

2. Technical challenges

For data teams, unifying users across devices and touchpoints is not an easy task, it can mean using advanced techniques such as probabilistic methods to estimate user identity. This can be outside the scope of less data-mature companies. 

3. Data structures

The data from your data sources needs to share a common, well-structured format, so your data team doesn’t waste precious time cleaning and preparing data. 

This presents a challenge as many data tools do not validate data before it reaches your destination, meaning what arrives needs to be prepared for usage – reducing time to value. 

According to a recent report, data teams can spend over 65 days a year cleaning data.

Read the full report: The State of Behavioral Data 2022

A technical guide to identifying users and customers using Snowplow

Snowplow allows you to easily create a single customer view through its unique and highly-organized event structure. 

Snowplow also offers a fully first-party approach to tracking.

But rather than just list the benefits, we’d love you to have a go for yourself. 

Here’s a guide that allows any company to effectively identify users with freely available Snowplow data. 

Download our free trial to try this SQL out on your own site or app.

Table of contents

1. The user IDs available with Snowplow 
2. The benefits of aggregating and filtering user IDs for data analysts
3. The benefits of having multiple user IDs
4. Advanced user identification: login events

The user IDs available with Snowplow

Every line in a Snowplow table includes placeholders for three different user IDs:

The benefits of aggregating and filtering user IDs for data analysts

1. You can view a user’s complete engagement record

Analysts can quickly zoom in on a user’s complete engagement record, including every action they have taken on every single visit to your website(s). Fetching this history is straightforward:

/* PostgreSQL / Redshift */

SELECT 

*

FROM "atomic".events

WHERE domain_userid = '{ENTER USER ID HERE}'

ORDER BY dvce_tstamp

E.g. executing the query in Navicat:

2. You can track users over multiple sessions

Often a user will visit a website several times before completing a particular goal. Whereas traditional web analytics programs only provide analysts with data on the visit when the goal was completed, Snowplow lets analysts zoom back in time to see all the actions that led up to a goal. 

This makes it possible, for example, to see which referrer first drove a user to a service, who only converted after 3 visits. 

As a result, the analyst can accurately attribute a return on that marketing spend, which would not be possible if you were only to look at data on a per-session basis. 

Each time a user visits a site, Snowplow sets a session counter (domain_sessionidx): this is set to 1 on the user’s first visit, 2 on the user’s second visit, etc. 

So to view how many visits a customer makes before purchasing, we can execute a query like this:

/* PostgreSQL / Redshift */

SELECT

domain_sessionidx,

COUNT(DISTINCT(domain_userid))

FROM "atomic".events

WHERE ev_action = 'order-complete'

AND domain_sessionidx IS NOT NULL

GROUP BY 1

ORDER BY 1

Plotting the results in ChartIO:

3. You can categorize users by cohorts

Because we can easily slice data by user (rather than session), it is easy to define cohorts to use in cohort-analysis. 

For example, to divide users into cohorts based on the month that they first used a service, we can execute the following query:

/* PostgreSQL / Redshift */

SELECT 

domain_userid,

DATE_TRUNC('month', MIN(collector_tstamp)) AS "cohort"

FROM "atomic"."events"

GROUP BY 1

We can then aggregate results for each individual user_id by cohort (group by cohort), to compare different metrics (e.g. engagement levels) between different cohorts as a whole. 

The benefits of having multiple user IDs

Most web analytics systems (notably Google’s Universal Analytics) only accommodate a single user ID. 

We’ve deliberately supported three as we believe there are pros and cons of each type of user identifier, and having a combination available gives analysts maximum flexibility to identify users as reliably as possible. 

100% reliability is not the goal, but vastly improved reliability is very attainable.

1. Managing consent 

For businesses that wish to track users across multiple domains (notably content networks and ad networks), there are significant advantages to using the network_userid over the domain_userid: namely that it is straightforward to analyze a user’s behavior across multiple sites.

However, a growing proportion of browsers and users are dropping support for third-party cookies.

By maintaining support for both first-party cookies (domain_userid) and third-party cookies (network_userid), Snowplow makes it possible to use the network_userid to identify users where users are happy to be tracked using third-party cookies. 

For users who are not (whom it is easy to identify because they do not have values set for network_userid), it is possible to fall back on domain_userid.

This makes it possible to perform statistical analyses on network behavior based on the subset of users who are comfortable with third-party cookies. It makes it clear which users are and are not covered by the sample.

It also leaves open the possibility of joining domain identifiers from different domains using cookie sync technologies.

2. Including your company’s own customer IDs

Enabling businesses to set their own user ID where it is available is a very powerful feature: it makes it possible, for example, to join Snowplow behavioral data with other customer data sets e.g. CRM, marketing, etc.

Rather than override the domain_userid and/or network_userid, however, we have a separate field called user_id set aside for this purpose. 

This is to give analysts maximum flexibility when analyzing user behavior over the user’s entire event record. 

To illustrate this with an example:

• Consider the case of an online retailer with a long sales cycle. (I.e. it might be common for a user to make multiple visits to the site before making a purchase.)
• A user looking at making a purchase will typically visit the site multiple times before purchasing. In this case, it is possible to track his / her behavior using either the domain_userid or network_userid
• Once the user has bought an item, they will have created an account. At that stage, the retailer might ascribe that user a user ID, based on the user’s name/address
• It will be possible for the company to perform attribution analytics (e.g. tracking the user from them clicking on an ad to make a purchase) using the domain_userid
• Going forwards, however, the user may make several more purchases. Because they use the same account, it is possible to use the user_id to identify that it really is the same user making multiple purchases over time. This is true even if that user makes those purchases from different computers/devices, and hence different browsers. (So different domain_userid and network_userid.)

More details on best practice in user identification is explored in the following section:

Advanced user identification: login events

Relying on cookies to reliably identify users is risky for a number of reasons:

1. Users may delete cookies between sessions: in which case two or more user_id’s can actually represent the same user
2. Users may access your website from different browsers (e.g. a home computer and a work computer, or a mobile device and a desktop): in which case again, two or more user_id’s really represent one user

Websites where users login, however, have the opportunity to identify users much more reliably. It is straightforward to incorporate this additional data into Snowplow, to make customer identification more robust:

When a user logs in to a website, the Snowplow event tracker should be fired to capture the login event. The user’s login ID (as defined in whichever system is used to manage the login process e.g. the CMS, Facebook etc.) should be captured and passed to Snowplow using the setUserId call:

_snaq.push([‘setUserId’, ‘[email protected]’]);

It is then possible to map user_id to e.g. domain_userid by executing the following query:

/* PostgreSQL / Redshift */

CREATE VIEW business_to_cookie_id_map AS

SELECT

domain_userid,

user_id

FROM "atomic".events

WHERE domain_userid IS NOT NULL

AND user_id IS NOT NULL

GROUP BY 1,2

This type of mapping table is reliable and flexible because it can accommodate many-to-many relationships between user_id and domain_userid. Consider the following two cases:

1. A user logs in to his / her account from multiple devices. In that case, there would be many domain_userid to each user_id. That is fine, because we can aggregate data by user_id to capture the user’s behavior across all those different devices.
2. Multiple users log in and out of their account from a single shared computer. In that case, there would be many user_id to each domain_userid. In that case, we’d need to be careful to aggregate records between log in and out events and ascribe them to a single user, so that we can differentiate actions performed by different users on the same computer.

To test this for yourself, try Snowplow for free