顧客同期
Tajo は 2 つの方法で顧客データを Brevo に取り込みます。継続的な同期（接続したプラットフォームの変更が Brevo に流れ続ける方式）と、一括移行（Mailchimp、Klaviyo、HubSpot、Salesforce、Shopify、WooCommerce、Stripe などからの、大容量に対応した再開可能な転送）です。どちらも同じエンジンで動作し、譲れない性質を 1 つ共有しています。同意はレコードごとに証明され、決して前提にはされません。
同意の判定方法
すべてのレコードは、マーケティングのオーディエンスに入る前にフェイルクローズドな同意ゲートを通過します。
| 判定 | 何が起きるか |
|---|---|
同意が証明された（例: Mailchimp の subscribed、Klaviyo の SUBSCRIBED、Shopify のマーケティング同意） | 選択した Brevo のリストにインポートされます |
| 明示的に拒否された（配信停止、オプトアウト） | 破棄されません。 ブラックリスト登録の連絡先として Brevo に引き継がれ、do-not-contact レジスタにも記録されるため、新しいプラットフォームからメールが届くことはありません |
到達性の理由で抑制された（ハードバウンス、迷惑メール報告。例: Mailchimp の cleaned、Klaviyo の HARD_BOUNCE/SPAM_COMPLAINT） | ブラックリスト登録として引き継がれ、解除されない状態として記録されます。別のプラットフォームで後からオプトインがあっても、バウンスや報告が解除されることはありません |
| 証明されていない（同意のシグナルがまったくない） | 拒否されます。「同意を証明できなかった」と「同意がある」は、決して同じ結果にはなりません |
「拒否された」と「証明されていない」の区別は重要です。配信停止は移行後も残さなければならない意思表示ですが、項目が存在しないことは意思表示ではまったくありません。
プラットフォーム別の同意ソース
| プラットフォーム | 同意の証明 | 抑制のシグナル |
|---|---|---|
| Mailchimp | メンバーステータス subscribed | unsubscribed（オプトアウト）、cleaned（ハードバウンス） |
| Klaviyo | プロフィールのマーケティング同意 SUBSCRIBED | 理由付きの抑制リスト (UNSUBSCRIBE、USER_SUPPRESSED、HARD_BOUNCE、INVALID_EMAIL、SPAM_COMPLAINT) |
| Shopify | email_marketing_consent.state / accepts_marketing | 明示的な not_subscribed |
| HubSpot | 購読ステータス（バッチ API、1 回の呼び出しで 100 件） | hs_email_optout |
| Salesforce | Sales Cloud から一括では証明できません。identity は移行しますが、オーディエンスへの登録は閉じたままです | HasOptedOutOfEmail、EmailBouncedDate |
| WooCommerce / Stripe | 購買からは推測しません。顧客レコードはマーケティングへの同意ではありません | なし |
移行中の競合解決
同じアドレスについて移行元と Brevo の内容が食い違う場合、選択したモードに従って解決されます。
- 最新の判断を優先（デフォルト）: 同意の判断のタイムスタンプが新しい側が優先されます。解釈できるタイムスタンプがない側は、ある側に必ず負けます。どちらにもタイムスタンプがない場合は、到達しにくい方の状態が優先されます。
- 信頼できる情報源を指定: 移行において権威となるプラットフォームを指定します（「移行元が正しい」または「Brevo が正しい」）。ワークスペースですでに基準データを宣言している場合は、そのプラットフォームが自動的にデフォルトの権威になります。
- すべてのモードに共通: ハードバウンスと迷惑メール報告は好みではなく到達性の事実です。新しいオプトインによって抑制が解除されることは決してありません。また、エンジンが処理を見送った競合はすべて件数が数えられて報告され、黙って飛ばされることはありません。
大容量での信頼性
- カーソルベースの抽出がチェックポイントを取りながら移行元のテーブル全体（10 万件以上の連絡先）を走査します。クラッシュしても最後に完了したバッチから再開し、再試行が二重書き込みになることはありません（レコードごとの冪等キー）。
- Brevo への書き込みは、Brevo のレート制限の範囲内で一括インポート API（1 チャンクあたり 10,000 件）を使います。抑制の状態はインポートと一緒に運ばれるため、到達可能な状態を経てから抑制されるという隙間は生じません。
- 実行ごとに、移動したものとしなかったものが報告されます。インポートされた連絡先、引き継がれた明示的な拒否、伝播した抑制、保留された競合、レコードごとの失敗理由です。
移行後に同期が加えるもの
移行が終わったあとも、同じ接続が Brevo を最新の状態に保ちます。プラットフォームの Webhook（Shopify、WooCommerce、WordPress、Mailchimp）がほぼリアルタイムで変更を流し込み、ポーリング対象のソースはスケジュールに従って更新されます。移行元で観測された配信停止は台帳の同意を反転させ、いつ、どこから、どの証拠にもとづくかという監査証跡も残ります。
セットアップ
- 移行元のプラットフォームを Tajo に接続します（コネクタに応じて API キーまたは OAuth を使います）。
- Brevo を接続し、対象のリストを選びます。
- 競合解決のモードを選びます（デフォルトのままでもかまいません）。
- 移行を実行し、保留された競合を含むレポートを確認してから自動化を有効にします。
同意と抑制の扱いは、設定でオフにできません。配信停止した連絡先を送信可能な状態でインポートする設定は存在しません。