Reverse ETL

Wat is Reverse ETL?

Reverse ETL is het patroon waarbij je opgekuiste, verrijkte data uit je data warehouse terug pusht naar de operationele systemen waar je collega's elke dag in werken: het CRM van sales, de marketing automation van het marketingteam, de support-tool van customer success, de ad platformen van performance marketing.

Het bestaat omdat een data warehouse heel goed is in bewaren, modelleren en analyseren, maar geen plek is waar mensen werk doen. Wie elke ochtend in Salesforce zit, gaat niet eerst Power BI openen om te kijken welke 50 accounts vandaag prioriteit krijgen. Reverse ETL brengt dat antwoord naar de plek waar de actie gebeurt.

Tools als Hightouch en Census duwden de term rond 2020 in de markt, en sindsdien is Reverse ETL een vaste laag geworden naast ingest (ETL / ELT) en transformatie (dbt) in moderne datastacks.

Hoe verschilt Reverse ETL van ETL / ELT?

ETL / ELT brengt data van bronsystemen naar het warehouse. Reverse ETL doet het omgekeerde: het neemt het resultaat van je modellering en stuurt het terug naar diezelfde of andere bronsystemen. Samen vormen ze een gesloten lus.

Dat klinkt symmetrisch, maar de problemen verschillen sterk:

• Schrijven naar API's, niet naar databases
  Bij ETL / ELT schrijf je naar je eigen warehouse. Bij Reverse ETL schrijf je naar de API van een SaaS-systeem dat je niet beheert. Je moet rekening houden met rate limits, met velden die plots een andere naam krijgen, met API-versies die uitgefaseerd worden.

• Geen rollback
  In een warehouse kan je een mislukte run terugdraaien. In een CRM met 200.000 accounts is een verkeerd gesynchroniseerd veld niet zomaar ongedaan te maken. Sales zit dan met foute scores te bellen.

• Identity resolution wordt jouw probleem
  Een record matchen op e-mail, op customer-ID, op een externe identifier: dat moet jouw model klaarzetten voor je iets pusht.

Hoe ziet een Reverse ETL-pipeline eruit?

Een Reverse ETL-flow heeft vier vaste componenten:

1. Bron
   Het data warehouse of lakehouse waar je gemodelleerde data al staat. Snowflake, BigQuery, Databricks, Microsoft Fabric, Redshift.

2. Model
   De SQL-query (vaak een dbt-model of een view) die definieert wélke records, met wélke velden, naar buiten gaan. Dit is het contract: alles wat hier in zit, mag de bestemming raken.

3. Sync
   De koppeling tussen warehouse-velden en bestemmingsvelden, plus het schema (elke 5 minuten, ieder uur, dagelijks). De sync detecteert wat sinds de vorige run veranderd is en stuurt enkel die wijzigingen door (insert, update, soms delete).

4. Bestemming
   Het operationele systeem aan de ontvangende kant. CRM zoals Salesforce of HubSpot, marketing tools zoals Braze of Klaviyo, ad platformen zoals Meta Ads of Google Ads, support tools zoals Zendesk of Intercom, soms terug een ERP of een productie-database.

Concreet voorbeeld: het warehouse bevat een tabel account_health_scores die elk uur een score per account berekent op basis van support-tickets, login-frequentie en factuurstatus. Een Reverse ETL-sync mapt die score naar een custom field in Salesforce. Sales ziet bij elk account een actuele score zonder ooit het warehouse te raken.

Reverse ETL vs CDP: waar zit het verschil?

Reverse ETL en een Customer Data Platform (CDP) overlappen, maar lossen niet exact hetzelfde op.

Een klassiek CDP zoals Segment of mParticle vangt gebeurtenissen op vanuit websites, apps en bronsystemen, doet identity resolution (matchen welke acties bij welke persoon horen) en stuurt vervolgens audiences door naar marketing tools. Het verzamelen en koppelen van events zit daar centraal.

Reverse ETL vertrekt van de premisse dat de data al verzameld is, in het warehouse staat, gemodelleerd is door het datateam, en enkel nog naar buiten geduwd moet worden. Identity resolution doe je in dbt of in een aparte modelleerstap, niet in een eigen tool.

De grens vervaagt. Veel CDP's hebben tegenwoordig warehouse-syncs ingebouwd ("composable CDP"), en Reverse ETL-tools voegen identity-functies toe. Praktisch gezien: heeft je organisatie al een volwassen warehouse met dbt en een datateam, dan is Reverse ETL goedkoper en flexibeler. Heb je nog geen warehouse en wil je snel events vangen vanuit web en mobile, dan is een klassiek CDP wellicht een sneller startpunt.

Waar moet je op letten bij Reverse ETL?

Foute data verspreidt zich razendsnel
Een fout in je dbt-model trekt je dashboard scheef én belandt direct in elke aangesloten tool. Een verkeerd gefilterde audience kost binnen het uur ad-budget. Behandel modellen die data leveren aan Reverse ETL met dezelfde discipline als productiecode: tests in dbt, alerts op rij-aantallen, code review.

Rate limits van bestemmingen
Salesforce, HubSpot en de meeste ad-platformen tellen API-calls per dag, met limieten die per editie sterk verschillen. Een sync van een tabel met 2 miljoen contacten kraakt zo'n plafond snel. Tools lossen dit op met batching en throttling, maar reken zelf het volume uit voor je een sync aanzet.

Idempotente upserts
Een sync moet je veilig opnieuw kunnen draaien zonder dubbele records of overschreven velden waar dat niet hoort. Werk altijd met een unieke key (klant-ID, e-mail) en upsert-logica. Insert-only zonder match-key is hoe je 50.000 dubbele leads in een CRM krijgt.

Schema-drift aan de ontvangende kant
SaaS-systemen veranderen hun veldnamen, voegen verplichte velden toe, faseren API-endpoints uit. Zonder monitoring loopt je sync stilletjes vast. Zet een alert op fout-percentages per sync.

Eigenaarschap van velden
Als marketing handmatig een tag aanpast in HubSpot en de Reverse ETL-sync overschrijft die de volgende run, krijg je oorlog. Spreek per veld af door wie het beheerd wordt. Data lineage en duidelijke contracten met de ontvangende teams zijn geen luxe.