ウォーターフォール型エンリッチメントとは、同じ項目を複数のデータプロバイダーに決まった順番で問い合わせ、最初に結果を返したところで止める手法です。ある連絡先の勤務先メールアドレスが欲しいとします。まずプロバイダー 1 に問い合わせ、何も返らなければリクエストはプロバイダー 2、次に 3 へと落ちていき、いずれかが結果を返すかリストを使い切るまで続きます。Clay の勤務先メール用ウォーターフォールのドキュメントは、これをプロバイダーを順番にたどるカスケードだとし、「stopping as soon as one returns a valid result」と説明しています。出力は 1 本のカラムで、その充足率は単一プロバイダーが単独で出せる水準を大きく上回ります。
これはデータプロバイダーでは ありません。どのプロバイダーのデータも良くはしません。ウォーターフォールは、すでに支払っているプロバイダー群の上に乗るルーティングロジックであり、上がるのはカバレッジであって正確性ではありません。重複排除でもなければ検証でもありません。カスケードが決めるのは 誰に聞くか だけで、すべてのメールをはね返す企業の、文法的には正しいアドレスも平然と返してきます。埋まったセルを検証済みのセルとみなすことが、このパターンで最も高くつく誤りです。ウォーターフォールと検証ステップが別々のコスト項目である理由もそこにあります。
カスケードの実際の挙動
ウォーターフォールが金を節約するか燃やすかは、3 つの設定で決まります。
順番。 プロバイダーは設定したシーケンスどおりに走るので、自社の セグメントで妥当なヒット率を出す最も安いプロバイダーを先頭に置きます。テンプレートからコピーした順番は、他人の ICP に合わせて調整された順番です。
停止条件。 カスケードは最初の許容可能な結果で止まります。何を許容とみなすかは設定可能で、Clay はメール用ウォーターフォールに Conservative、Balanced、Aggressive、Advanced の検証戦略を用意し、さらにウォーターフォールが「only accepts an email if the validation provider explicitly confirms it as valid」となるトグルも提供しています。これを厳しくすれば 1 行あたりのクレジット消費は増え、緩めればクレジットは減って送信レピュテーションが減ります。
投入条件。 どのエンリッチメント基盤にも、そもそもどの行をカスケードに入れるかを決めるゲートがあります。Clay では run settings の「Only run if」式がそれです。条件を満たさない行はプロバイダーを一度も呼ばず、これが請求額に対する単独で最大のレバーです。
有用な診断が 1 つあります。結果が返った 後 もウォーターフォールがプロバイダーを呼び続けているなら、その結果は検索ではなく検証ゲートで落ちています。これはバグではなく、あるプロバイダーについてのデータ品質シグナルです。
メーターは 1 つではなく 2 つ
エンリッチメント基盤はたいてい 2 つの別々の軸で課金しており、この 2 つを混同することが予算超過の入口になります。Clay が計測するのは、テーブルが実行するステップである actions と、プロバイダーマーケットプレイスからレコードを買う data credits です。2026-08-07 時点で、Free プランは月 500 actions と 100 data credits を含み、Launch は月 15,000 actions で月額 167 ドルから、Growth は月 40,000 actions で月額 446 ドルから、年間コミットは年 180,000 actions が月額 54 ドル、年 120 万 actions が月額 261 ドルまで用意されています。マルチプロバイダーのウォーターフォールは Launch 以上で使えます。
プランの段階よりも課金ルールのほうが重要です。Clay は「if an enrichment returns no result, you’re not charged Data Credits or Actions」と明記しており、自前のプロバイダー API キーを持ち込めば data credits を完全に回避できるとしています。つまり、外れは基本的に無料で当たりは有料であり、多くのチームが最初に抱く直感とは逆です。請求額を決めるのは 何行分のデータを見つけたか であって、どれだけ熱心に探したかではありません。
単価の実際
公開されている単価を並べるとトレードオフが具体的になります。25+ のソースを走らせる専用ウォーターフォールの FullEnrich は、Pro プランを月額 55 ドル・1,000 クレジット、つまり 1 クレジット 0.055 ドルで販売し、勤務先メールを 1 クレジット、個人メールを 3 クレジット、携帯番号を 10 クレジットで課金します。
この価格表は 2 度読む価値があります。携帯番号 1 件は、勤務先メール 10 件と同じコストです。 全行で電話番号エンリッチメントを黙ってオンにしたリスト構築は、メールのみの構築より 10% 高いのではありません。ヒット率が同じなら、到達できる連絡先 1 件あたりでおよそ 1 桁分高くつきます。
ここに検証を並べてみます。MillionVerifier は 50,000 件のメール検証を 89 ドル、1 件あたり 0.00178 ドルで掲示しており、クレジットは無期限で、キャッチオール検証も追加費用なしで含まれます。アドレスを検証するコストは、それを見つけるのにかかったコストの約 3% です。チームが節約のために飛ばすステップは、すでにほぼ無料のステップだということです。
自社の数字で計算してみてください。5,000 行、勤務先メールのみ、見つかったアドレス 1 件あたり 0.055 ドル。まず 200 行のサンプルで実際のヒット率を測ります。この 1 つの入力値が、どのプロバイダーを選ぶかよりも合計額を大きく動かします。ヒット率 60% なら、エンリッチメントは約 165 ドル、結果の検証はそこに約 5 ドルを足すだけです。
注意点と、それぞれの防御策
すでに持っている行を再エンリッチしてしまう。 行が増え続けるテーブルで auto-update を有効にしていると、すでにその項目を持つレコードにもカスケードが再度走ります。防御策: 構築中は auto-update を切り、カラムに「項目が空であること」を要求する「Only run if」条件を付け、プロバイダーに金を払う前に lookup カラムで CRM や別テーブルにすでにあるデータを引いてきます。
電話クレジットが予算を飲み込む。 クレジット比 10:1 では、携帯番号の検索が支出を支配する一方で、実際に支えているコールモーションははるかに小さいのが普通です。防御策: 電話番号は独立したウォーターフォールに切り出し、今四半期に人が実際に架電するアカウントだけに限定します。リスト全体には決して当てません。
埋まったセルを配信可能なセルとして扱う。 見つかっただけで検証していないアドレスは、自社ドメインに紐づけられるのを待っているバウンスであり、バウンスは走らせているすべてのシーケンスの送信レピュテーションを削ります。防御策: 検証をウォーターフォール下流の必須カラムにし、キャッチオール結果の扱い、つまり送るか、保留するか、別チャネルに回すかを、最初のキャンペーンの後ではなく前に明文化します。
上限がなく、プログラムから見えない。 Clay にはクレジット残高を取得する公開 API エンドポイントがなく、使用量は Settings の credit usage ダッシュボードにテーブル別・インテグレーション別・期間別で表示されるだけです。クエリできない数値にアラートは張れません。防御策: このダッシュボードの週次確認を担当者 1 人に割り当て、1 テーブルが処理できる行数に上限を設け、新しい設定はカラム全体を走らせる前に 10 行でテストします。
クレジットに見合うのか
見合います。連絡先カバレッジが制約になっていて、レコードが欠けるコストが高い場合です。1 社のプロバイダーがリストの半分しか埋められないセグメントへのアウトバウンドや、指名した 300 アカウントを完全に埋める必要がある ABM モーションが該当します。この条件下では、成功したプロバイダーにしか支払わないカスケードが、入手できる最も安いカバレッジです。
見合いません。問題がカバレッジではなくターゲティングにある場合です。定義の甘いリストをエンリッチしても、フィットの悪いアカウントの連絡先が速く増えるだけで、クレジットはどちらにせよ消えます。まず ICP の定義 を直し、それからエンリッチします。単一プロバイダーがすでに自社セグメントを 80% 以上カバーしている場合も、これは間違った道具です。そのプロバイダーに直接支払い、オーケストレーション層は省きましょう。
より広いデータプログラムの中での位置づけは データエンリッチメント戦略 を、悪いアドレスの下流で何が起きるかは コールドメールをスパムに落とさない方法 を参照してください。Clay が一般的なオーケストレーション層で、Apollo や ZoomInfo は他社のカスケードの中に入る個別プロバイダーであることのほうが多いツールです。