Makeで
Make のシナリオは、マーケティングを支えるフォーム、CRM、メールツールの間でコンタクトを受け渡すため、不正なアドレスが広がる前に食い止めるのに最適な場所です。HTTP モジュールを使えばシナリオの途中で VeriMails API を呼び出し、すべてのコンタクトをリアルタイムで検証し、Router で結果ごとに適切な行き先へ振り分けられます。このガイドではその構築手順を説明します。
要約
Make シナリオ
シナリオはゲートとして設計します。トリガーからデータが入り、VeriMails がメールアドレスをチェックし、Router のフィルターが先に進めてよいものを判断します。
| 判断項目 | Make の設定 | 運用メモ |
|---|---|---|
| トリガーの範囲 | 最初にコンタクトのバンドルを受け取るモジュールから始めます。フォームの監視、カスタム Webhook、CRM レコード、シートの行などです。 | Formatter やエンリッチメント用のモジュールがデータ構造を変える前に、元のメール値をマッピングします。 |
| HTTP リクエスト | トリガーの後に HTTP モジュールを追加し、メールを VeriMails のエンドポイントに送信します。API キーは、モジュールの接続設定またはアカウントで利用できる安全な認証情報の設定に保存してください。 | この API検証の呼び出しは、購読者、リード、オーディエンスメンバーを作成するどのモジュールよりも前に置いてください。 |
| Router の設計 | 配信可能なコンタクト用、却下するコンタクト用のルートをそれぞれ作成し、想定外または空のステータス用にフォールバックルートを用意します。 | Make のルートはそれぞれ独立してフィルタリングされるため、各ルートに結果別のラベルを付け、テスト中はフォールバックルートを見える状態にしておきましょう。 |
| 保留レコードのログ | 無効、使い捨て、キャッチオールのコンタクトは、ソースと理由のフィールドを付けてシート、データストア、または通知に書き出します。 | シンプルなログがあれば、ノイズの多いリードソースがひと目でわかり、運用担当者がロールバックする際の記録にもなります。 |
| 有効化前のテスト | シナリオをスケジュールまたは有効化する前に、すべてのルートを通るサンプルバンドルで一度実行してください。 | シナリオの履歴を確認し、解析された VeriMails のレスポンスと、それを処理したルートを確かめます。 |
Make の
Make はコンタクトデータを取得・活用するアプリ同士をつなぐため、検証ステップが最も効果を発揮する位置にあります。シナリオ内でアドレスをチェックすれば、下流でつながるすべてのアプリに不正なデータが引き継がれるのを防げます。
シナリオは、
一般的な Make シナリオは、新しいフォーム送信や CRM レコードを受け取り、メールプラットフォーム、広告オーディエンス、営業ツールへ送り込みます。そのコンタクトが無効なら、不正なアドレスが課金対象や送信対象となるシステムに残ってしまいます。作成ステップの前に VeriMails の HTTP モジュールを置けば、つながっている各アプリをクリーンに保てます。
フォームや
新しいフォーム送信、Webhook のペイロード、新しいスプレッドシートの行といった、最もよく使われるシナリオトリガーは、メールデータのソースとしても最もノイズが多いものです。入力ミス、使われなくなったアドレス、偽の登録が絶えず届きます。トリガーの出力に検証モジュールを置けば、自動化の入り口でそれらを捕捉できます。
リアルタイム
シナリオ内で検証すれば、各コンタクトは数週間後の一括エクスポートではなく、流れてきたその瞬間にチェックされます。リストは継続的にクリーンに保たれ、バウンス率が上がる余地はなく、最初から誤っていたアドレスへの送信も避けられます。
不正な
フォームと受信箱の間にいくつモジュールがあっても、無効なアドレスは最終的にバウンスします。バウンス率が5%を超えると、リスト全体でキャンペーンが迷惑メールに振り分けられやすくなります。シナリオに VeriMails のステップを入れれば、メールプラットフォームにリスクを負わせるのではなく、発生源でそのリスクを取り除けます。
VeriMailsが
HTTP モジュールがコンタクトについて VeriMails API を呼び出すと、VeriMails は一連のチェックをすべて実行し、Router で分岐に使える構造化された結果を返します。すべてのアドレスは次のようにテストされます。
構文検証で、アドレスの形式が正しいかを確認します。 MXとDNSレコードを照会し、ドメインが存在してメールを受信できることを確認します。ライブのSMTPハンドシェイクでは、受信側のメールサーバーに接続し、何も送信せずに、そのメールボックスがメールを受け付けるかを確認します。キャッチオール検出は、送られたすべてのアドレスを受け付けるドメインを特定します。使い捨ての検出は、一時的な受信箱のドメインを検出します。ロールベースの検出は、info@、sales@、support@ のような汎用アドレスを特定します。
VeriMails はわかりやすい検証結果を高速に返すため、リアルタイムのシナリオにそのまま組み込めます。キャッチオールのドメインは曖昧なスコアではなく明確な検出結果として返されるので、Router のフィルターで意図的に扱えます。
Make ユーザー
リアルタイム検証シナリオでは、新しいコンタクトが通過するたびにVeriMailsのクレジットが消費されるため、支払いは検証したアドレス分だけです。クレジットパックは1件あたり$0.0019からで、10,000クレジットは$19です。大量のシナリオ向けには、最大5,000,000件で$1,499までのクレジットパックがあります。
安定したコンタクトの流れに対して予測しやすい請求をご希望なら、年間プランは年払いで月額$12.50からです。新規アカウントには登録時に100クレジットが無料で付与され、クレジットカードは不要、クレジットに有効期限もないため、導入を決める前にシナリオを構築してテストできます。
ワークフローの
このフローで、Make シナリオ内に VeriMails を品質ゲートとして追加します。
- トリガーの範囲：フォーム、シート、Webhook、CRM のモジュールがコンタクトのバンドルを作成した直後に、メールフィールドをマッピングします。
- API ステップ： VeriMails のキーを安全に保管し、API レスポンスのフィールドをシナリオにマッピングしてルーティングに使います。
- 結果への対応：配信可能なコンタクトは作成/更新ルートへ送り、無効や使い捨てのコンタクトはレビュー用に記録します。
ステップバイステップ
新しい
新しいシナリオを作成し、コンタクトを取り込むトリガーモジュールを追加します。フォーム送信の監視モジュール、カスタム Webhook、新しい CRM レコード、新しいスプレッドシートの行などです。このトリガーが、以降のシナリオで検証・振り分けを行うメールアドレスを出力します。
HTTP モジュールを
HTTP モジュールを追加し、VeriMails の検証エンドポイントにリクエストを送るよう設定します。トリガーのメールフィールドをリクエストにマッピングし、認証用に VeriMails の API キーを含め、レスポンスの解析を有効にして、Make が JSON の検証フィールドを後続モジュールで使えるようマッピングするようにします。
Router を
HTTP モジュールの後に Router を置きます。Router はシナリオを複数のルートに分け、それぞれに独自のフィルターを設定できます。VeriMails の結果が配信可能な場合にのみ実行されるルートを1つ設定し、配信不可、使い捨て、キャッチオールの結果用に別のルートを追加します。どれにも当てはまらないものに対するフォールバックルートも設定できます。
配信可能な
配信可能ルートには、メールプラットフォーム、CRM、広告オーディエンスでコンタクトを作成または更新するモジュールを追加します。このルートを通るのは検証済みの配信可能なアドレスだけなので、つながっているアプリのリストやオーディエンスは自動的にクリーンに保たれます。
不正な
配信不可ルートには、配信不可や使い捨てのアドレスをシートに記録するか、通知を送るモジュールを追加してレビューできるようにします。サンプルデータでシナリオを一度実行して各ルートが正しく動くことを確認したら、スケジュールまたは有効化して、すべての新しいコンタクトをリアルタイムで検証しましょう。
結果
Make のシナリオは、すべての検証ステータスに明示的なルートがあると運用しやすくなります。結果が欠落していたりリスクがあったりするものを、検証済みコンタクトと同じモジュールへ流さないでください。
- 配信可能： CRM、メールツール、広告オーディエンスの作成/更新モジュールへ送り、必要に応じて検証日のフィールドを書き込みます。
- 配信不可：クリーンなルートを止め、レコードを配信停止用またはクリーンアップ用のテーブルに書き込みます。
- キャッチオール：慎重に扱うレビュー用ルートへ送ります。これらのコンタクトは高単価の営業フォローには役立つ場合がありますが、通常のキャンペーン送信には混ぜないでください。
- 使い捨て：ライフサイクルキャンペーンから外し、リードソースに確認用のタグを付けます。
- ロールベース：ワークフローの目的に応じて振り分けます。共有の受信箱は業務連絡には有効でも、パーソナライズしたアウトリーチには不向きです。
- フォールバックまたはエラー：運用担当者に通知し、リクエストやマッピングの問題が解決するまで下流への書き込みを止めます。