Migrating from Segment Part 2: Personas & SQL Traits in RudderStack

We've helped many of our customers migrate from Segment to RudderStack.  This is the second post in a series where we step through the process.  The post will detail the steps involved in transitioning Personas functionality to RudderStack Reverse ETL.

As the name implies, the goal of any customer data platform (CDP) is to create a unified view of your customers’ profiles and activity.  Both RudderStack and Segment do this and both allow you to reconcile anonymous activity with known users. Both can also collect identifiable information and characteristics about the user or group, which can subsequently be sent to other downstream tools to activate the data. This however, is where the similarities end and the flexibility of RudderStack’s warehouse-first design truly shines.

So what’s the difference between Segment’s Personas and RudderStack’s Identities?

Since not every Segment user leverages every part of Personas, let’s review the structure of the product. We’ll quickly cover the features of Personas, then explain how those features are handled in RudderStack. I’ll go ahead and give you the spoiler: instead of doing everything in a black box in the cloud, RudderStack does everything on your data warehouse.

Segment Personas overview

Segment Personas can be broken down into two distinct functions, Personas Spaces and Audiences.   Personas Spaces are where inbound identify calls (and their traits) are aggregated to create and update individual user profiles.  Segment also allows for calculated, or “computed traits” to be defined (i.e., “has logged in more than 3 times”) as well as SQL traits, which allow you to import warehouse derived attributes and add them to user profiles.

“Segment Audiences” define cohorts of users, based on the above traits, that you can send to downstream tools for activation (email campaigns, etc.).

The Main Differences Between Segment Personas and RudderStack

Black box VS your warehouse

The most important difference between Segment and Rudderstacks is that Segment stores everything in a black box in their cloud, whereas  RudderStack builds and stores your user profile and audience data in your warehouse.

Ability to transform and enriching user traits

A second (and almost as important) differentiator is the scope of transformations that can be applied to user traits in identify calls.

With Segment, you are limited to renaming individual traits on their way to populate audiences. In RudderStack, you have full control to modify, filter, or even transform entire payloads of any type, including identify calls, as well as call 3rd party or internal APIs to enhance/enrich the user profile prior to sending it to your warehouse and cloud destinations.

Building, storing, combining and modifying audiences and cohorts

On the audience side, Personas relies entirely on individual traits, so your ability to combine, modify or build more complex cohorts is limited. Also, your audiences are stored in Segment’s cloud, meaning you can’t access, much less work with, the raw data.

RudderStack not only allows flexibility to transform traits to deliver more complex audiences on arrival, but the user profiles and audiences themselves live in your warehouse, meaning you can use tools like dbt or even ML (like continual.ai or BigQuery ML) to build or modify audiences in any way you want. As far as storage goes, because you own the audiences, they are portable. You can even populate different audiences in different destinations—even warehouses—if you want.

Computed & SQL Traits vs RudderStack Reverse ETL

With Segment computed traits and SQL traits, you can derive single traits using the Segment UI. For computed traits, you can use data stored in Segment to create single traits using other data points, i.e., logins_greater_than_3: true. You can also create traits from your warehouse data, albeit in a limited way. You write SQL in Segment’s UI to add data points from your warehouse as user traits.

In RudderStack, the only limit to your ability to create custom attributes is your team’s SQL or dbt capabilities. Because you do the work directly in your warehouse, you can compute traits across any and all of your data (not just RudderStack data) and update any combination of users. This is particularly useful when the traits you're after come from ML models or other places in the stack.

Personas Audiences vs RudderStack, dbt & Reverse ETL

For many marketing teams, the appeal of Segment and willingness to pay extra for the Personas feature is the ability for non-technical teams to create custom audiences within a user interface, then pass those audiences to other third-party tools like Facebook, Marketo, etc.

The problem we hear about over and over, though, is that those teams are ultimately limited by the inflexibility of Personas and the “audience silo” that results from everything living in Segment’s black box.

With RudderStack, we believe you should not only own your data (and not pay extra for us to store a copy), but that you should have the flexibility to build on your data for any use case that drives value for your business, not just a limited set of marketing value-adds. That’s why we turn your warehouse into your customer profile and audience store.

The big question, though, is how you activate those profiles and audiences, and that’s where our Reverse ETL feature comes in. With Reverse ETL, you can send all of the valuable profile and audience work to your entire stack.

While we do have some UI features in the roadmap, most of our customers use dbt to create a variety of different audiences that live as tables in the warehouse schema. That’s incredibly valuable because those audiences are always valuable beyond a single use case and are widely used across the business, not just in downstream marketing and product tools.

Also, these tables can be destination and/or audience specific and adhere to the same security and data encryption requirements as the rest of the warehouse.  The dbt output tables are then called by RudderStack Reverse ETL to create source events (or audiences) which are sent to downstream destinations.

In the next post, we’ll dig into a practical example of how to build an audience with RudderStack, dbt and your warehouse, then send it to your entire stack.