リバースETLとは、データウェアハウスからCRM、広告プラットフォーム、セールスエンゲージメントなどの運用ツールにデータを移動するパターンです。分析のためにデータをウェアハウスに移動する従来のETLの逆です。リバースETLは、ウェアハウスをGTMモーションのシステム・オブ・レコードとして使えるようにするものです。
なぜ存在するか
アナリティクスの歴史の大部分において、ウェアハウスは行き止まりでした。データエンジニアが顧客行動、プロダクト使用状況、収益をSnowflakeまたはBigQueryにロードし、アナリストがダッシュボードを作成し、運用ツール（Salesforce、HubSpot、Marketo）は別の世界に存在しました。マーケティングが「先週3回ログインしたユーザー」を必要とする場合、誰かがカスタム統合を書くか、CSVを待つ必要がありました。
リバースETLはそのループを閉じます。Hightouch、Census、Polytomicのようなツールを使えば、ウェアハウスに対してSQLを一度書き、宛先へのシンクを定義し、数分以内にSalesforceのフィールドまたはFacebookのオーディエンスとしてデータが表示されます。
いつ重要か
リバースETLは3つの条件が成立する場合に適切なパターンです：対象となるデータがすでにウェアハウスに存在し、他の場所で再計算が難しい場合。宛先ツールに使えるAPIまたはネイティブコネクタがある場合。シンクを操作するチームがSQLモデルを所有するのに十分なデータリテラシーがある場合。
典型的なユースケースは、プロダクト適格リード（プロダクト使用シグナルをリードスコアとしてCRMにシンク）、オーディエンスターゲティング（ウェアハウスセグメントを広告プラットフォームにプッシュ）、顧客ヘルス（サポート、請求、プロダクトデータをCSMツールにシンク）です。
何を置き換えるか
リバースETLは3つの古いパターンと競合します：手書きのAPI統合（遅く、脆弱）、ZapierやWorkataのようなiPaaS（シンプルなワークフローには良いが、大規模ではコスト高）、パッケージ化CDP（より意見が強く、柔軟性が低い）。コンポーザブルCDPパターンは本質的にリバースETLにアイデンティティモデルを加えたものです。
よくある落とし穴
- 粒度が間違っている。 すべてのプロダクトイベントをSalesforceにプッシュすると壊れます。シンクの前に適切な粒度（アカウント・週、ユーザー・日）に集計してください。
- モデルのドリフトを許す。 リバースETLのシンクは上流のdbtモデルに依存します。モデルが変わると、宛先が静かに壊れます。テストと所有権を追加してください。
- 同意なしでのアクティベーション。 リバースETLはウェアハウスが把握している同意を尊重します。同意がウェアハウスでモデル化されていない場合、コンプライアンスに反するデータをプッシュしています。
関連
- データウェアハウス対CDP — アーキテクチャの選択
- CDP — 代替パターン
- RevOpsテックスタック — リバースETLが収まる場所