Tajo と Brevo を連携する完全ガイド
顧客データの同期、Shopify のデータ、自動化のトリガー、メール、SMS、WhatsApp、ロイヤルティのワークフロー、セグメンテーション、安定したキャンペーン運用まで、Brevo と Tajo の連携方法を解説します。
Brevo と Tajo の連携は、単に API をつなぐ作業ではありません。信頼できる情報源を決め、Brevo を安全に接続し、項目をマッピングし、顧客と注文のデータを同期し、同意を尊重し、イベントのトリガーをテストし、価値の高いワークフローをいくつか立ち上げ、同期の健全性を監視します。Brevo のキャンペーンに最新の Shopify、顧客、ロイヤルティ、エンゲージメントの文脈が必要なとき、Tajo が最も役立ちます。
Brevo と Tajo を連携すると、顧客データの基盤とマーケティングやメッセージングのプラットフォームがつながります。
Brevo は、多くのチームがメールキャンペーン、SMS、WhatsApp メッセージ、トランザクションメッセージ、CRM のワークフロー、リスト、セグメント、マーケティング自動化を構築する場所です。そうしたキャンペーンに、Shopify や他の commerce システムから最新の顧客、注文、商品、ロイヤルティ、エンゲージメントの文脈が必要になったとき、Tajo が力を発揮します。
この連携に価値があるのは、マーケティング自動化がきれいでタイムリーなデータに依存しているからです。ウェルカムシリーズは単純なメール登録だけでも動きます。しかし成果の出るライフサイクル施策には、より多くの文脈が必要です。初回購入日、注文回数、生涯価値、最後に閲覧した商品、カート金額、ロイヤルティの階層、同意の状態、サポートの問い合わせ状況、キャンペーンへの反応などです。
このガイドでは、Brevo と Tajo の連携を計画し、接続し、テストし、運用する方法を説明します。
手早く知りたい方へ
次の順番で進めましょう。
- Brevo で動かしたいワークフローを決めます。
- 連絡先、注文、同意、商品データ、ロイヤルティ項目について、信頼できる情報源を決めます。
- Brevo の API キーを発行し、安全に保管します。
- Tajo で Brevo を接続します。
- 同期するオブジェクトとイベントを選びます。
- Tajo の項目を Brevo の連絡先属性、リスト、イベント、EC データにマッピングします。
- 小さなセグメントでテストします。
- 最初の Brevo の自動化を構築します。
- 同意、抑止、配信停止の挙動を検証します。
- 同期のエラー、重複した連絡先、キャンペーンの成果を監視します。
考えられるすべての項目をいきなり接続してはいけません。最初の 3 つのワークフローに必要なデータから始めましょう。
どの連携方法をいつ選ぶか
Brevo をほかの仕組みとつなぐ方法は、大きく 3 つあります。
| 連携の方法 | 向いているケース | 注意点 |
|---|---|---|
| Brevo の標準連携やプラグイン | 単純な連絡先の同期、基本的な EC 接続、素早い設定 | 高度なセグメンテーションに必要なデータ、イベント、ライフサイクルのロジックがすべて取得できないことがあります |
| Tajo ＋ Brevo | Shopify や顧客データを軸にしたマーケティング、ライフサイクルの自動化、ロイヤルティ、セグメンテーション、EC のトリガー | 項目のマッピング、イベントのルール、ワークフローの責任範囲を決める必要があります |
| 独自の Brevo API 連携 | 独自のアプリロジック、専用のデータモデル、カスタムイベント、社内システム | 開発、監視、再試行、セキュリティレビュー、保守が必要です |
Brevo に連絡先を保管させるだけでなく、顧客の文脈に基づいて動いてほしいときに Tajo を使いましょう。
例を挙げます。
- Shopify の顧客が 2 回目の注文をし、ロイヤルティの階層が上がった。
- 価値の高い顧客が、ある商品カテゴリを閲覧したあとでカートを放棄した。
- 休眠した購入者を、未解決のサポート案件がない場合にのみ呼び戻しのフローへ入れたい。
- 購入後のフローを、商品カテゴリと注文回数に応じて変えたい。
- VIP セグメントには、チャネルの同意がある場合にのみ WhatsApp メッセージを送りたい。
- 購入した顧客をナーチャリングの配信から外したい。
こうしたワークフローには、同期されたデータ、イベントのタイミング、同意、抑止のロジックが必要です。
Tajo が Brevo へ同期できるもの
正確な構成はアカウント、ストアフロント、連携の設定によって変わりますが、役に立つデータの種類は共通しています。
| データの種類 | 例 | Brevo での使いみち |
|---|---|---|
| 連絡先の識別情報 | メールアドレス、姓、名、電話番号、外部 ID | 連絡先プロフィール、重複排除、パーソナライズ |
| 同意 | メールのオプトイン、SMS のオプトイン、WhatsApp の同意、配信停止の状態 | コンプライアンス、抑止、チャネルの利用可否 |
| 顧客ライフサイクル | 新規、アクティブ、リピート、VIP、離反リスク、休眠 | セグメンテーションとジャーニーの振り分け |
| EC の注文 | 注文 ID、日付、合計金額、通貨、商品、カテゴリ | 購入後フォロー、再購入、呼び戻し、LTV のセグメント |
| 商品カタログ | 商品 ID、名称、カテゴリ、価格、状態 | レコメンド、商品ごとのメッセージ |
| カートと閲覧のイベント | カート金額、閲覧した商品、チェックアウトの開始 | カート放棄と閲覧放棄への対応 |
| ロイヤルティのデータ | ポイント、階層、特典、有効期限、達成度 | ロイヤルティのキャンペーンと階層アップの通知 |
| エンゲージメントのデータ | キャンペーンの開封、クリック、返信、イベント | 抑止、スコアリング、反応によるセグメント |
| カスタム属性 | ストア固有の項目、タグ、設定 | 高度なパーソナライズと振り分け |
まずは識別情報、同意、ライフサイクル、注文履歴、そして最初のワークフローに必要なイベントから始めましょう。項目を増やすのは、明確なキャンペーンや運用上の必要があるときだけにします。
事前に確認すること
Brevo と Tajo を接続する前に、次を確認しましょう。
- 対象となるストアや顧客データのソースが接続済みの Tajo アカウントがある。
- API キーを作成または利用できる権限のある Brevo アカウントがある。
- 使用する Brevo のリスト、属性、テンプレートが決まっている。
- メールアドレス、電話番号、同意、顧客 ID について信頼できる情報源が決まっている。
- EC のイベントを扱う場合、Shopify や commerce プラットフォームの管理権限がある。
- 安全に使えるテスト用の連絡先とテスト注文がある。
- 公開後に連携を管理する担当が決まっている。
最初の 3 つのワークフローもあわせて定義しておきましょう。
最初に取り組むのに適したワークフローは次のとおりです。
- 新規登録者や新規顧客へのウェルカムシリーズ。
- カート放棄からの回収。
- 購入後の使い方の案内。
- レビュー依頼。
- ロイヤルティ階層のアップ通知。
- 呼び戻しや再活性化。
- VIP 顧客向けのキャンペーン。
ステップ 1：信頼できる情報源を決める
信頼できる情報源とは、2 つのシステムの内容が食い違ったときに優先されるシステムのことです。
同期を始める前に決めておきましょう。
| 項目やオブジェクト | 推奨される情報源 |
|---|---|
| メールアドレス | 獲得経路に応じて EC プラットフォームまたは CRM |
| 電話番号 | SMS の同意を取得したシステム |
| メールの同意 | 同意を取得した経路、または設定センター |
| SMS／WhatsApp の同意 | 同意を取得した経路。電話番号の有無から推測してはいけません |
| 注文履歴 | EC プラットフォーム |
| 商品カタログ | EC プラットフォーム |
| ロイヤルティの階層とポイント | Tajo またはロイヤルティのシステム |
| キャンペーンへの反応 | Brevo |
| サポートの状況 | ヘルプデスクまたは顧客データの基盤 |
これを決めておくと、同期のループやデータの衝突を防げます。
例えば、顧客が Shopify で電話番号を更新した場合、Tajo が Brevo を更新できます。Brevo に古い電話番号が残っていても、その方向の更新を明示的に許可していない限り、最新の commerce 側の記録を上書きすべきではありません。
ステップ 2：Brevo の API キーを発行する
Brevo での操作です。
- アカウント設定を開きます。
- API キーの画面へ移動します。
- Tajo 連携用のキーを発行します。
Tajo production syncのように分かりやすい名前を付けます。- 安全に保管します。
- ドキュメント、表計算、チャット、チケット、公開コードに貼り付けないでください。
可能であれば、本番用とテスト用でキーを分けましょう。
キーの取り扱いで推奨される方針は次のとおりです。
- アクセスできるのは必要な管理者だけに限定します。
- 人員の変更や漏えいの疑いがあれば、キーを再発行します。
- テストと本番の認証情報は分けて管理します。
- 連携の管理者を明文化します。
- 使わなくなったキーは失効させます。
ステップ 3：Tajo で Brevo を接続する
Tajo での操作です。
- 連携の画面を開きます。
- Brevo を選びます。
- Brevo の API キーを登録します。
- 同期するストア、CRM、顧客データのソースを選びます。
- 同期するオブジェクトを選びます。
- 方向を設定します。Tajo から Brevo、Brevo から Tajo、または承認した項目については双方向にします。
- 接続を保存します。
- テスト同期を実行します。
まずは限られたテスト用の連絡先から始めましょう。全体の同期を有効にする前に、Brevo 側のデータを必ず確認します。
ステップ 4：項目をマッピングする
項目のマッピングは、Brevo が正しくセグメント化しパーソナライズできるかどうかを左右します。
実務的な出発点となるマッピングは次のとおりです。
| Tajo やストアの項目 | Brevo の項目やオブジェクト | 補足 |
|---|---|---|
| 顧客のメールアドレス | 主要な識別項目 | |
| 名 | FIRSTNAME | パーソナライズに使用します |
| 姓 | LASTNAME | パーソナライズと CRM に使用します |
| 電話番号 | SMS または電話番号の属性 | 同意があり形式が正しい場合のみ使います |
| 顧客 ID | 外部 ID またはカスタム属性 | 重複排除と突き合わせに役立ちます |
| メールのオプトイン | メールの同意またはリストへの所属 | 連絡先が存在することを同意とみなしてはいけません |
| SMS のオプトイン | SMS の同意またはカスタム属性 | SMS キャンペーンの前提条件です |
| 注文回数 | ORDER_COUNT | 新規と再購入のセグメント分けに有用です |
| 生涯価値 | TOTAL_SPENT または LTV の属性 | VIP 判定や抑止のルールに有用です |
| 最終注文日 | LAST_ORDER_DATE | 再購入や呼び戻しに有用です |
| ロイヤルティのポイント | LOYALTY_POINTS | 特典のリマインドに有用です |
| ロイヤルティの階層 | LOYALTY_TIER | VIP や階層別のキャンペーンに有用です |
| 直近の商品カテゴリ | LAST_CATEGORY | レコメンドに有用です |
| 顧客ライフサイクル | LIFECYCLE_STAGE | ジャーニーの振り分けに有用です |
命名は一貫させましょう。total_spent、TOTAL_SPENT、LTV のように、同じ概念に対して複数の属性を作らないようにします。
ステップ 5：イベントとトリガーを設定する
キャンペーンの自動化はイベントに依存します。
よく使うイベントは次のとおりです。
- 連絡先の作成。
- ニュースレターの登録。
- カートの放棄。
- チェックアウトの開始。
- 注文の完了。
- 注文のキャンセル。
- 返金の発生。
- 商品の閲覧。
- ロイヤルティ階層の変更。
- ポイントの獲得。
- 特典の利用。
- 顧客が休眠状態になった。
- サポートチケットの起票。
各イベントについて、次の内容を定義します。
| イベントの項目 | 重要な理由 |
|---|---|
| イベント名 | Brevo のワークフローのトリガーに使われます |
| 顧客の識別子 | イベントを正しい連絡先に結び付けます |
| タイムスタンプ | タイミングと遅延のロジックを制御します |
| プロパティ | 注文、商品、ロイヤルティ、カートの文脈を加えます |
| 重複排除キー | 重複したトリガーを防ぎます |
| 同意の状態 | そのイベントでメッセージを送ってよいかを判断します |
| 発生源 | イベントの出どころを調べるのに役立ちます |
テストイベントが正しい連絡先とプロパティで 1 回だけ届くことを確認するまで、イベントからキャンペーンを起動してはいけません。
ステップ 6：最初の Brevo のワークフローを構築する
ウェルカムシリーズ
トリガー：新規登録、新規アカウント、または最初の顧客同期。
推奨する流れは次のとおりです。
- すぐに送るウェルカムメール。
- ブランドのストーリーや価値提案。
- 商品、サービス、ロイヤルティの説明。
- 社会的証明。
- 初回購入や次のステップの案内。
Tajo のデータは次の用途で使います。
- 顧客の獲得経路。
- 登録日。
- 最初に関心を示した商品。
- ロイヤルティへの登録状況。
- チャネルごとの同意。
カート放棄からの回収
トリガー：カートの放棄、または注文に至らないチェックアウトの開始。
推奨する流れは次のとおりです。
- 短い遅延のあとに送るメールのリマインド。
- SMS の同意がある場合のみ送る SMS のリマインド。
- カートの中身を載せた商品ごとのメール。
- 利益率が許すなら、最後の後押しや特典。
Tajo のデータは次の用途で使います。
- カート金額。
- 商品名。
- 商品カテゴリ。
- チェックアウトへのリンク。
- 顧客の価値。
- これまでの購入回数。
Shopify に特化した実装については、Brevo と Shopify の連携 と Shopify のカート放棄メール をご覧ください。
購入後のフロー
トリガー：注文の完了。
推奨する流れは次のとおりです。
- トランザクションメールでの確認。
- 商品の使い方やお手入れの案内。
- レビューの依頼。
- クロスセルや再購入のリマインド。
- ロイヤルティポイントの更新通知。
Tajo のデータは次の用途で使います。
- 商品カテゴリ。
- 注文回数。
- ロイヤルティの階層。
- 獲得したポイント。
- 顧客生涯価値。
- サポートの状況。
ロイヤルティ階層のアップ
トリガー：ロイヤルティ階層の変更。
推奨する流れは次のとおりです。
- 顧客をお祝いします。
- 新しい特典を説明します。
- 現在のポイントや特典を表示します。
- 次に取るべき行動を提案します。
- 未解決のサポート案件がある顧客には送信を抑止します。
呼び戻しのフロー
トリガー：一定期間、顧客の活動がないこと。
推奨する流れは次のとおりです。
- 役に立つ形での近況確認。
- 過去のカテゴリに基づくおすすめ。
- 利益率が許す場合の特典。
- 配信設定の見直し案内。
- 反応がない場合の配信抑止。
Tajo のデータは次の用途で使います。
- 最終注文日。
- 直近の商品カテゴリ。
- 反応の状況。
- 顧客の価値。
- 直近のサポート状況。
公開前の QA チェックリスト
本番のワークフローを有効にする前に、このチェックリストを使いましょう。
| 確認項目 | 合格の条件 |
|---|---|
| 連絡先の同期 | テスト用の連絡先が Brevo に 1 件だけ表示される |
| 属性のマッピング | 必要な項目がすべて正しく埋まる |
| 同意 | メール、SMS、WhatsApp の可否が正しい |
| 配信停止 | 配信停止した連絡先が抑止されている |
| イベントの到達 | 各テストイベントが 1 回だけ届く |
| イベントのプロパティ | 注文、カート、商品、ロイヤルティの項目が入っている |
| ワークフローのトリガー | テストイベントから正しいワークフローが始まる |
| 離脱ルール | 購入や条件を満たさなくなった顧客が離脱する |
| 抑止 | 未解決のサポート案件、返金、配信停止が尊重される |
| パーソナライズ | テンプレートの変数が正しく表示される |
| リンク | チェックアウト、商品、設定へのリンクが機能する |
| レポート | キャンペーンとワークフローの指標が見える |
| エラー処理 | 同期エラーが記録され、担当が決まっている |
QA を省略してはいけません。連携の不具合は、あっという間に恥ずかしい顧客体験を生みます。
よくある問題の切り分け
連絡先の重複
よくある原因です。
- システムごとに異なる識別子が使われている。
- 電話番号のみの連絡先に、あとからメールアドレスが追加された。
- 同期の設定前にインポートで連絡先が作られた。
- メールアドレスの正規化が一貫していない。
対処法です。
- 主となる識別子を 1 つに決めます。
- メールアドレスの大文字と小文字を正規化します。
- 利用できる場合は外部 ID を使います。
- 大量配信の前に重複を統合するか抑止します。
Brevo にデータが入らない
よくある原因です。
- 項目がマッピングされていない。
- 元のデータが空になっている。
- API キーに必要な権限がない。
- 同期ジョブが失敗した。
- 項目の型が合っていない。
対処法です。
- Tajo や Shopify 側の元データを確認します。
- マッピングが存在するか確認します。
- Brevo 側の属性が存在するか確認します。
- テスト同期を実行します。
- 同期のログを確認します。
ワークフローが起動しない
よくある原因です。
- イベント名が一致していない。
- 連絡先がまだ存在しない。
- イベントのプロパティが欠けている。
- ワークフローの条件が厳しすぎる。
- 遅延や参加条件のルールが連絡先を止めている。
対処法です。
- イベント名を正確に確認します。
- テストイベントを送信します。
- ワークフローへの参加状況を確認します。
- 条件を一時的に単純化します。
- 同意と抑止の状態を確認します。
SMS や WhatsApp が送信されない
よくある原因です。
- そのチャネルの同意がない。
- 電話番号の形式が正しくない。
- 国別や送信者のルールが設定されていない。
- 連絡先が抑止されている。
- チャネルのクレジットやアカウント設定の見直しが必要である。
対処法です。
- 電話番号の形式を検証します。
- 同意の取得元を確認します。
- 社内の番号でテストします。
- Brevo のチャネル設定を見直します。
- 代替となるメールの経路があるか確認します。
同期の遅延
よくある原因です。
- バッチ同期のモードになっている。
- API のレート制限に達している。
- Webhook の配信が遅れている。
- 一時的な提供側の障害が起きている。
- 大量の過去データの取り込みが進行中である。
対処法です。
- 同期の状態を確認します。
- レート制限を見直します。
- Webhook の配信を確認します。
- 価値の高いイベントを優先します。
- 過去データの取り込みにはバッチ同期を、リアルタイムのキャンペーンにはイベント同期を使います。
セキュリティとコンプライアンス
この連携は、顧客データを扱う基盤として扱いましょう。
最低限の管理策は次のとおりです。
- API キーを安全に保管します。
- 管理者権限を限定します。
- テストと本番で認証情報を分けます。
- メール、SMS、WhatsApp の同意を尊重します。
- 配信停止の状態を同期し続けます。
- 不要な機微情報の同期は避けます。
- 同期の失敗を記録します。
- 項目ごとの責任者を明文化します。
- 誰がワークフローを作成し有効化できるかを定めます。
利用できるからという理由だけで顧客データをキャンペーンに流してはいけません。実際のワークフローを支えるデータだけを同期しましょう。
監視すべき指標
公開後は、連携の健全性とキャンペーンの成果の両方を監視します。
連携の健全性です。
- 同期の成功率。
- 同期のエラー件数。
- 連絡先の重複率。
- イベント到達の遅延。
- 失敗した Webhook の件数。
- マッピングされていない項目の数。
- API のエラー率。
キャンペーンの成果です。
- ワークフローへの参加数。
- メールの到達。
- 開封率とクリック率。
- SMS や WhatsApp への反応。
- コンバージョン率。
- ワークフローごとの売上。
- 配信停止数。
- 苦情率。
- 再購入率。
- ロイヤルティへの参加度。
成果が振るわないとき、文章の書き直しだけで済ませてはいけません。データの品質、トリガーのタイミング、対象者、同意、オファー、抑止のロジックを確認しましょう。
導入の進め方
1 週目：計画と接続
- 最初のワークフローを決めます。
- 信頼できる情報源を選びます。
- Brevo の API キーを作成します。
- Tajo で Brevo を接続します。
- 主要な連絡先の項目をマッピングします。
- テスト同期を実行します。
2 週目：イベントとセグメントの追加
- 注文とカートのイベントを設定します。
- ライフサイクルの項目を追加します。
- 必要ならロイヤルティの項目を追加します。
- テスト用のセグメントを作成します。
- 同意と抑止を検証します。
3 週目：ワークフローの構築
- ウェルカムシリーズを作ります。
- カート放棄またはリード回収のフローを作ります。
- 購入後またはロイヤルティのフローを作ります。
- テンプレートの変数をテストします。
- リンクと離脱ルールを QA します。
4 週目：公開と監視
- 限定した対象者に向けて公開します。
- 同期ログを毎日確認します。
- キャンペーンの指標を確認します。
- マッピングの不具合を修正します。
- 安定を確認してから対象を広げます。
最後に
Brevo と Tajo の最良の連携は、項目ではなくワークフローを中心に設計されています。
最も重要なカスタマージャーニーから始めましょう。ウェルカム、カート回収、購入後フォロー、ロイヤルティ、呼び戻しです。そのジャーニーに必要なデータを同期し、丁寧にテストし、同意を尊重し、エラーを監視します。そのうえで、より豊かなセグメンテーションとマルチチャネルの自動化へ広げていきます。
Tajo が最も価値を発揮するのは、Brevo に連絡先リスト以上のものが必要になったときです。自動化をタイムリーで、具体的で、測定可能なものにするために必要な顧客、EC、ロイヤルティ、ライフサイクルの文脈を、Brevo のキャンペーンに与えます。