What it is.
Reverse ETL reads from your warehouse and sends the results to your connected tools. It supports both event and object data, so you can push a computed score onto a record as well as firing an event.
This is how a health score, a propensity model, or a product-usage rollup ends up somewhere a rep or a marketer can act on it. Without it, that model stays in a dashboard nobody filters by.
You define the query, pick the destinations, and schedule the sync.
What you get.
- Warehouse queries syncing out to your GTM tools on a schedule.
- Support for object data as well as events, so scores land on records.
- One place to manage which destinations receive which model.
- A path from a SQL model to a CRM field your team can filter on.
How to set it up.
Write the model in the warehouse first and check the numbers before syncing anything.
Decide whether each output is an event or a field on an object, since that changes what you can do with it.
Add the warehouse as a Reverse ETL source and give it read access only.
Map columns to the destination fields deliberately, because a wrong mapping is hard to unpick later.
Set the sync schedule to match how fast the data changes, since hourly syncs of a daily model waste warehouse spend.
Confirm the first sync landed in the destination before you tell anyone to use it.
Use cases
Get the model out of the dashboard
Sync the analyst's work into the tools where people act on it.
Send account fields too
Push account-level fields your CRM needs for routing.
Keep it on a schedule
Run the sync so the tools stay current without anyone exporting.
Best for
Models stuck in dashboards
A health score is only useful where somebody works, and that is rarely the BI tool.
Product-led sales
Usage data has to reach the CRM before a rep can act on it.
Teams with a warehouse already
If the data is modeled, this is the last mile.