Never let a signup go cold again.
Turn emails into revenue with Brew. No credit card, free credits to try.
Turn emails into revenue with Brew. No credit card, free credits to try.
rudderstack.com · newsletter
Explore this email design and adapt it to your own brand. Review the copy, links, and offer before sending.
Data flow deep dive: how we used RudderStack to send you this email
Did you know the data used to trigger this email originated in the RudderStack Node.js SDK in our app when you signed up? It's true.
One of the best ways to explain how RudderStack makes data flows easier for you is to walk you through an end-to-end process, from data collection to data activation.
In this email, we're going to show you exactly how we used RudderStack data to trigger this email.
Here’s a high-level overview of the steps with detail below:
We collected your signup event via the Node.js SDK running in our app
We routed that event to Customer.io and Snowflake
A dbt model running on Snowflake materialized a table of users in the cohort "active users who signed up 3 days ago" (this uses a variety of data points in the warehouse)
We sent that table with the cohort flag Customer.io through our Reverse ETL pipeline
Customer.io picked up the cohort flag and added you to the list of users who qualify to get this automated email
Pretty cool, huh?
Here are the step-by-step details:
1. Sending the signup event via the Node.js SDK
This is really straight forward with Event Stream. The Node.js SDK runs in our app and we triggered both a .track call and .identify call when you signed up, which sent a JSON payload into the RudderStack data plane.
Your .track signup event payload looked like this (we simplified the payload it to make it more readable):
.track('User Signed Up',
{
email: "thomas+rudderstack@brew.marketing"
});
2. Routing the event to Customer.io and Snowflake
These destinations were already set up in our account, but adding new integrations is as easy as entering credentials in the RudderStack UI - which is extremely helpful for new destination requests from your team.
In Customer.io, you were created as a contact (via .identify) and the 'User Signed Up' event was associated with you (more on using that data in email content below).
In Snowflake, the 'User Signed Up' payload was flattened and added to a table of .track calls. The .identify payload also went to the warehouse and added you to the Users
table.
3. Building the "active users who signed up 3 days ago" cohort in Snowflake
If we just wanted to send an email to users who signed up 3 days ago, we could create that logic in Customer.io, but our product team wanted to use additional data that indicates active users.
That data comes into Snowflake via our telemetry system, so the easiest way to build a cohort of active users is to join the table of users who signed up 3 days ago with the table of currently active users.
Here's a sample of the baseline SQL for building the cohort:
WITH signups_in_last_3_days
AS (SELECT email,
timestamp
FROM rudderwebapp.identifies
WHERE first_login = true
AND timestamp >= Dateadd(day, -3, CURRENT_DATE()))
SELECT a.email,
a.timestamp
FROM signups_in_last_3_days a
LEFT OUTER JOIN rudderwebapp.active_users b
ON a.email = b.user_id
Now, you might be thinking, “couldn’t you figure out a way to send telemetry data to Customer.io?” Great question! Yes, we could, but there are a few reasons we don't. First, telemetry for app usage applies to both users and workspaces that have multiple users—that logic is much easier to build in the warehouse.
More importantly, when we build key cohorts, other teams want them to be available in their tools as well, like Salesforce (so you don’t get bothered by a rep before you’re ready to talk) and Marketo (so you don’t get added to the wrong marketing email lists).
We use this wisely to avoid having tons of custom fields in downstream tools, but it is really helpful build the business logic once in the warehouse, not 5 separate times in downstream tools.
4. Sending the cohort table to Customer.io with RudderStack Reverse ETL
Because these cohorts live in Snowflake, we can use our Reverse ETL pipeline to translate the table back into JSON payloads and update contact records across the stack.
So, once you entered the "active users who signed up 3 days ago" cohort table in Snowflake, a job ran on a schedule and fired an identify call to Customer.io that updated your contact record.
Here’s an example of what these calls look like in our Reverse ETL JSON editor (we also have a Visual Data Mapper):
(If you want to try our Reverse ETL pipeline, it's available in in every version of RudderStack Cloud, including Free.)
5. Triggering this email in Customer.io
And finally, we’ve arrived at this specific email. You entered a campaign in Customer.io because you had the "active users who signed up 3 days ago" flag and were sent the automated email you’re reading right now.
Now it’s your turn!
Log into your account to set up a connection, or, if you have questions, feel free to reply to this email or book
time with an onboarding specialist below.
Github Docs Pricing
©2026 RudderStack | View in Browser | unsubscribe
