I’m not a data engineer, analyst, or scientist, and I strongly believe that you don’t need a background in data to understand the data lifecycle or to improve the outcomes of your everyday efforts using data.

Understanding what data is collected how is a prerequisite for anyone who works with data in their day-to-day.

However, with a plethora of tooling options and the complexities of adhering to privacy regulations, companies need to be very intentional about what data they collect, and how they make that data available in the tools used by various teams.

Keeping that in mind, I wanted to share this guide (originally published on the Airbyte blog) that offers an in-depth overview of the technologies available to collect behavioral data from primary and secondary data sources.

Ready to take notes? Cool, let’s dive in!

So your company is launching a new product and you’ve been tasked with setting up the behavioral data infrastructure? Or maybe you need to revamp the existing setup using modern tools? 

There are a few different technologies (CDI, CDP, ELT/ETL) that can be used to collect behavioral data, and at the same time, there are several tools with capabilities that span multiple technologies.

Navigating this maze and making an informed decision is daunting and time-consuming — this guide aims to change that.

Before going into tools and technologies though, I’d like to shed some light on why collecting behavioral data is important and where exactly behavioral data comes from.

Why collect behavioral data?

Behavioral data is collected when users perform actions or events while interacting with a product.

Behavioral data, also referred to as event data or product-usage data, serves two main purposes for teams — understanding how the product is being used or not used (user behavior) and building personalized customer experiences across various touchpoints to influence user behavior.

Understanding product usage requires prior instrumentation of the features whose usage you’d like to measure — tracking the events a user performs and sending those events to third-party tools for analysis. Additionally, events also help trigger campaigns and experiences via downstream activation tools.

Launching new features without instrumenting them beforehand is a classic mistake — it takes away the opportunity to analyze how those features are used (if at all) and to trigger in-app experiences or messages when relevant events take place (or don’t).

Where does behavioral data come from? 

Although the events I’m referring to take place within your product, the actual source of behavioral data can be an external tool or service that’s embedded within your product.

For the love of simplicity, I like to categorize behavioral data sources as primary and secondary.

Primary data sources

Your core product — web app, mobile apps, a smart device, or a combination — powered by proprietary code is a primary or first-party behavioral data source.

If your product is built using no-code tools, you won’t have a primary source for your behavioral data — you’d rely on the no-code tools to make behavioral data available to you (either via webhooks or integrations with data collection tools).  

To collect data from your primary sources, you can use the client and server-side SDKs or the APIs provided by data collection tools. 

Secondary data sources

Third-party tools that your customers interact with directly or indirectly — tools used for authentication, payments, in-app experiences, support, feedback, engagement, and advertising are secondary data sources.

Customers interact with third-party tools indirectly or unknowingly when they are embedded within your core product experiences.

Examples include Auth0 for authentication, Stripe for payments, and Userflow for in-app experiences — from a user’s point of view, they are using your product even when interacting with these external tools.

Customers also interact with external tools that are evidently not part of the core product experience but are integral touchpoints.

Creating a support ticket via Zendesk, leaving feedback via Typeform, opening an email sent via Intercom, or engaging with an ad on Facebook — these are all interactions that help understand the customer journey. 

It’s also helpful to keep in mind that third-party tools generate a lot of data but not all of it is event data. What exactly you can collect in terms of events and objects depends on the integrations offered by the data collection tool you use.

To collect data from secondary sources, you can either use source integrations offered by data collection tools or write your own code.

Technologies and tools to collect behavioral data

Just like all the layers of the modern data landscape, the data collection layer has experienced a lot of activity in the last couple of years, with the launch of several open-source products that have become popular very quickly.

The overlap between products is also increasing as core capabilities are being extended to cover adjacent use cases.

Customer Data Infrastructure or CDI

CDI is a less common term that’s often confused with CDP (Customer Data Platform).

A platform cannot exist without infrastructure, and CDP is essentially a layer on top of CDI — an additional component that offers a visual interface to do some stuff with data (collected via the CDI). 

CDI is a standalone solution that can exist without a CDP, whereas a CDP is sold as an add-on by some CDI vendors. Learn more about the differences between the two.

Key aspects of a CDI are as follows:

1. CDI is purpose-built to collect behavioral data from primary or first-party data sources but some solutions also support a handful of secondary data sources (third-party tools).

2. Data is typically synced to a cloud data warehouse like Snowflake, BigQuery, or Redshift, but most CDI solutions have the ability to sync data to third-party tools as well.

3. All CDI vendors offer a variety of data collection SDKs and APIs

4. Some CDI solutions store a copy of the data, some make it optional, and some don’t.

5. CDI solutions that store a copy of the data also offer out-of-the-box identity resolution. 

The core capabilities of a CDP, on the other hand, include identity resolution and the ability for users to build and sync audiences to external tools using a drag-and-drop UI (without writing SQL). 

CDI and CDP solutions

Segment offers multiple products — Connections is their CDI offering, Profiles is an identity resolution add-on, and Twilio Engage includes CDP capabilities. Segment also offers Protocols, a data governance tool.

mParticle takes a slightly different approach — it offers CDI capabilities along with identity resolution in its Standard edition whereas audience building is available on the Premium plan. mPartice also offers additional products for product analytics (Indicative) and predictive analytics (Cortex).

Both Segment and mParticle support data warehouses and a host of third-party tools as destinations, as well as store a copy of your data that can be accessed later if needed. 

RudderStack (Event Stream) and Jitsu are open-source CDI solutions positioned as alternatives to Segment Connections. Both products support warehouses and third-party tools but RudderStack offers a more extensive catalog of destinations.

Snowplow is the only CDI solution that literally calls itself a behavioral data platform. It is also open-source and unlike the others, Snowplow doesn’t support third-party tools as — it is focused on warehouses and a few open-source projects as destinations.

Other CDI solutions worth looking into are Freshpaint which offers codeless tracking and MetaRouter which is a server-side CDI that only runs in a private cloud instance. 

The links below will take you to the integration catalogs of the respective tools: 

• Segment: Warehouses and third-party destinations

• mParticle: All integrations (note that Feed refers to data sources)

• RudderStack: Warehouses and third-party destinations

• Jitsu: All destinations

• Snowplow: All integrations

• Freshpaint: All integrations

• MetaRouter: All destinations

ELT solutions

ELT solutions are purpose-built to extract all types of data from a large number of third-party tools (secondary sources) and load the data into cloud data warehouses. That said, not all integrations offered by ELT tools support behavioral data or event data. 

ELT tools don’t store any data and don’t support third-party tools as destinations. 

Airbyte is an open-source ELT tool that offers source connectors with 150+ tools like Zendesk, Intercom, Stripe, Typeform, and Facebook Ads, many of which generate event data. Airbyte also offers a Connector Development Kit (CDK) that you can use to build integrations that are maintained by Airbyte’s community members.

Other ELT vendors include Fivetran, Stitch, and Meltano (also open-source). 

As mentioned earlier, CDI solutions also offer source integrations with a few third-party tools but those are not as comprehensive and deep as the integrations offered by ELT tools. 

When contemplating whether to use an ELT tool or a source integration of a CDI tool to extract data from a third-party tool, consider the following:

• CDI is best-in-class to collect behavioral data from primary or first-party data sources — web and mobile apps, and IoT devices

• ELT is best-in-class to collect all types of data including behavioral data from secondary data sources — third-party tools that power various customer experiences.

Product analytics tools 

Amplitude, Mixpanel, Indicative (by mParticle), Heap, and PostHog (open-source) are product analytics tools purpose-built for behavioral data analysis. At the same time though, all of these offer SDKs and APIs to collect data from your primary data sources. 

Product analytics tools by nature store a copy of your data and allow you to export the data via APIs. Additionally, if you’d like to export data from these tools to your data warehouse, you can either use native integrations that some of these tools offer, or leverage Airbyte’s integrations with Amplitude, Mixpanel, or PostHog. 

However, it’s important to keep in mind that beyond analysis, there are plenty of activation use cases for behavioral data. 

Custom tracking solutions

If readymade solutions are not for you, you can always build a custom tracking service that collects data from your apps and syncs it to your warehouse and downstream applications. That said, having first-hand experience with such a solution, I can tell you that maintenance and troubleshooting are not trivial and the frustration is real.

More importantly, with so many different flavors of CDI and ELT solutions available, building one’s own is just not the best use of engineering resources. In fact, engineers generally hate building integrations — if you’re one, let me know if I’m wrong. 

Conclusion

Using purpose-built data collection tools (CDI and ELT) is more efficient, prevents vendor lock-in, and just makes more sense.

I recommend adopting a CDI to collect data from primary or first-party data sources, and sticking to your ELT tool to collect data from secondary or third-party sources. 

Now that you have a better picture of the tools needed to collect behavioral data for analysis and activation, don’t forget to collaborate with stakeholders from various teams when it comes to deciding which events to track and what data to send to which destination. 

Continue Learning

data beats

How To Decide Which Events to Track?

This guide is part five of the series on understanding customer data for product analytics; it was originally published on the Amplitude blog. To decide which events to track, you need to first list down all the questions you’d like to answer about your users and their product usage…

Read more

4 years ago · 1 like · Arpit Choudhury

A typical conversation about data often brings up the privacy practices of big tech — the fact that they gather too much data and the growing concerns over the opaqueness of their data policies have given birth to stringent privacy laws such as the EU’s GDPR and California’s CCPA. 

Privacy laws and the fact that browsers are making third-party cookies obsolete are making companies more accountable, forcing them to take a hard look at their data collection practices. As a result, a snowball effect is taking place — companies are embracing transparency and creativity while trying to stay compliant, and the awareness about data is increasing amongst individuals. 

Customer data is the centerpiece that enables personalization and automation at scale — it provides context on the user as well as the user’s behavior in terms of using a product.

Customer data is best described when broken into the following two types: 

• User data: It provides context on a user and their traits, and is also referred to as entity data (user being the entity)

• Interaction data: It provides context on how the user interacts with a product and is also referred to as event data, behavioral data, or product-usage data

Customer data is also gathered when users interact with your brand outside of your core product experience via secondary data sources or third-party tools used for advertising, engagement, and support, to name a few. However, this guide focuses on customer data that comes from a primary or first-party data source — a website, app, smart device, or a combination of these — and comprises entity data and event data. 

P.S. The “customer” in “customer data” includes free users of a paid product as well as users who pay with personal data to use a product. 

Entity data

Entity data includes personally identifiable information (PII) such as name, email, and phone number, as well as other details such as age, country, and preferences. 

It is often referred to as user data since a user is the main entity or object. It comprises user properties or user attributes, each of which stores information or traits about a user. 

Entity data is stored in tables where columns represent user properties like name and email, while each row represents a user. One of the properties acts as an identifier and has to contain a unique value for each row (user).

In the table above, email can act as an identifier by ensuring no two users have the same email. However, it is a better practice to assign a unique ID to each user since an email address can change but the user_id remains fixed. 

Accounts or groups as entities

A group of users or an account is also an entity with distinct attributes generally referred to as organizations or workspaces in the case of B2B SaaS products.

From a hierarchical point of view, accounts are groups that comprise users. Thus, the data about an account or group comprises group properties that store information about an account such as the subscription type or the number of users. If accounts are known as organizations, the associated properties should be referred to as organization properties.

It is common to gather data about both users and groups at the same time. This is, once again, particularly true for B2B SaaS tools where a user is part of an account or organization with multiple users.

How do you collect entity data?

Entity data where user is the entity is gathered as a result of users sharing data directly or indirectly. 

Users share data directly when they input details in a form, respond to an email or a survey, or when they interact with conversational interfaces like chatbots and voice bots.

On the other hand, users share data indirectly when they use a product. When listening to music on Spotify, a user shares data about their music preferences including genres, artists, and even specific songs they like. Similarly, when a user creates reports on Amplitude, they share data about the type of reports they find useful. 

Since Amplitude is a B2B SaaS tool where multiple users are part of an organization, the number of reports created under an organization is data associated with an organization and not a particular user. Hence, in this case, Organization is another entity, number_of_reports is an organization property, and the value of this property changes when any user in an organization creates or deletes a report.

It’s important to not confuse entity data that changes as a result of product usage (number of reports) with event data that is generated when a user interacts with a product (report created)

Event data

An event refers to a unique action performed by a user while interacting with a product, and the data generated in the process is called event data or interaction data. 

Clicks and hovers on the web, taps and swipes on mobile, and text or voice commands on chat and voice interfaces — all such interactions are actions performed by a user or events that take place inside an app. 

Event data enables you to understand user behavior and is therefore often referred to as behavior data. Additionally, event data enables you to take action on data or activate the data in external tools where the data is made available. 

A common use case is event-based contextual messaging (in-app or email) where a campaign is triggered when a certain event X takes place. Or when a certain event Y doesn’t take place within a specified timeframe after X takes place — the possibilities are endless. 

Event data comprises three key elements: 

• The action or the event that took place

• The timestamp or the precise date and time when the event took place

• The state or all other properties associated with the event (known as event properties)

Add to Cart, Buy Now, and Complete Payment are all actions or events. The exact moment when an event takes place is recorded as a timestamp.

The properties that provide more context about the event Add to Cart could be user_id, product_id, price, and quantity—all of which provide information related to the event or the state of the event. 

How do you collect event data?

Collecting event data requires you to create a tracking plan specifying the events to track and the associated properties for each event. Then you get your data engineering team to implement the tracking plan using either of the following: 

• CDI (customer data infrastructure) or CDP (customer data platform)

• Custom tracking service

Once event tracking is implemented, event data collected is made available in the configured destinations (product analytics and engagement tools) and typically, a copy of this data is stored in a data warehouse. 

Learn more about event data or behavioral data collection tools in this guide.

What data to track vs how to track it

While it is good to know about the event-tracking process, as a data-led professional, you should focus on what to track rather than how to do it.

Why so? 

I won’t disagree if you argue that defining what data is to be tracked and the tracking process itself are equally important. However, these two activities should ideally be owned by different people and depending on the size of your organization, maybe even different teams that collaborate closely. 

To engineer or not to engineer

Typically, a data engineer takes care of implementing the tracking and collaborates with product and growth teams to decide which tools and technologies to use. The company stage, the scope of work and rework, available resources, priorities, and several other factors influence this decision.

Many companies, however, leave the entire tracking process to the data/engineering team, keeping marketing and product folks completely out of the loop—doing so invariably results in data that is inaccurate, inconsistent, and often redundant when too many events are tracked just for the sake of tracking.

Deciding what to track is simply not an engineer’s job and expecting engineers to know how other teams wish to use what data is, well, disastrous.

Putting customer data into action

Now that you know what customer data is and what your role is in the process of gathering it, the next step is to be able to answer the following questions:

• What purpose does event data serve?

• How Event Data Enables Data-powered Growth?

• What do event and entity data look like in the context of customer data?

• How to decide which events to track and what data to gather?

Lucky for you, each question above links to a guide in the 5-part series on customer data. 

Once you have answers to the above, you will be equipped to gain a clear understanding of how to create a data tracking plan and will be able to do the following with confidence:

• Lead the implementation of event-driven analytics and engagement tools with confidence

• Gather clean and consistent customer data and overcome challenges that crop up along the way

• Ask the right questions of your data in order to better understand user behavior

• Identify opportunities to collect and act upon data to elevate the customer experience

• Build better products, provide better experiences, and have better conversations

Lastly, it is incredibly useful to have a good understanding of various data types before you begin working on your tracking plan, so whenever that is, this guide on data types will be helpful.

Now move on to part 2 to understand the purpose of collecting event data.