同じテスト連絡先を2回送ってみてください。2回目に別のレコードができたり、配信停止が取り消されたりするなら、処理量を増やす前に接続を見直す必要があります。
「2つのアプリをつなぐだけ」は出発点として自然です。重要なのは、最初のリクエストの後に接続が何を覚えているかです。
ソフトウェアを選ぶ前に確認する3点
転送はシステム間でリクエストやイベントを運びます。マッピングは項目の意味を決めます。状態は処理済みの送信元バージョン、失敗した内容、対応する宛先レコードを記録します。
最初の有用な結果に必要な送信元、宛先、項目を書き出し、項目ごとに管理元を決めます。営業システムがライフサイクル段階を管理し、Brevoが現在のメール配信停止を管理することもできます。1件のレコードの全項目を同じシステムが管理する必要はありません。
Brevoへの4つの経路
標準アプリ
Brevoマーケットプレイスで保守されているアプリと公開元を確認します。必要な項目とイベントについて設定手順を読みます。掲載されているだけでTajo連携があるとは判断できません。
Shopifyなら、まずBrevo PushOwlの設定と移行経路を確認します。2本目の接続を作る前にマッピングを試します。標準アプリだけで足りる場合もありますが、対応項目と復旧方法はアプリごとに異なります。
自動化サービス
フォーム送信を受け取り、項目を対応付け、Brevoを呼び出せます。選ぶ前に、実際の再実行機能、タスク費用、保存内容を確認します。処理量が少ないことや画面操作が簡単なことは、登録の取りこぼしを許容する理由になりません。
サイトからの登録なら、WebflowガイドでBrevo埋め込みフォームとサーバーで処理する標準フォームを区別しています。必要な送信と確認の動作を保てる経路を選びます。
連携基盤
複数のマッピング、永続的な処理記録、協調した復旧が別サービスを正当化する場合に使います。失敗レコードの表示と、拒否された1件の再実行を見せてもらいます。分類名から機能を推測しないでください。
Tajoは早期アクセス段階です。連携レビューには具体的な送信元、宛先、合格条件を持ち込みます。利用可能なコネクターと実行経路を確認してから頼ってください。組み合わせを説明する文書はレビューの出発点であり、作業環境で使える証拠ではありません。
直接APIを使うコード
既存の経路では本人照合、変換、復旧を制御できない場合に選びます。その場合、認証情報、制限、処理状態、運用手順も自分たちで管理します。
連絡先の書き込みと失敗の扱いはBrevo APIガイドを参照してください。送信元が表計算ならApps Scriptの例は別のスクリプト経路であり、TajoのSheets標準コネクターを前提としません。
同じ判断表で比較する
| 判断項目 | 標準アプリ | 自動化サービス | 連携基盤 | 直接API |
|---|---|---|---|---|
| 必須項目 | アプリの対応付けを確認 | アクションの入力を確認 | 提案されたマップを確認 | マップを実装 |
| レコード識別 | 照合規則を確認 | 照合を明示的に設定 | IDの取り決めを確認 | 宛先IDを保存 |
| 復旧 | アプリの機能を確認 | 再試行と再実行を検証 | レコード単位の復旧を実演 | 構築して運用 |
| 件数と制限 | 提供元の制限を確認 | タスク数と制限を見積もる | 想定負荷を検証 | 宛先の制限に従う |
| 運用責任者 | アプリ提供元と運用者 | シナリオの担当者 | 提供元と同期担当者 | 自チーム |
実際の要件を満たす経路はどれですか？
-
標準アプリが項目と確認項目を満たす
標準アプリを使う
文書化された設定から始めます。
-
フォームやイベントに小さな対応付け処理が必要
自動化サービスを評価
確認と再実行の動作を検証します。
-
複数のマッピングに協調した復旧が必要
連携基盤を評価
失敗と再実行の実演を求めます。
-
必要な変換に対応していない
最小限のAPI経路を書く
初回実行だけでなく運用費も見込みます。
1件で最初の同期を証明する
隔離した宛先と、自分で管理する連絡先を使います。データ経路の確認中はキャンペーンの自動化を無効にします。
- 送信元ID、宛先リスト、必須属性、現在の同意の証拠を記録します。書き込み前に属性の型を作成します。
- 一度実行し、ジョブ状態だけでなく宛先レコードを調べます。実際の値とマーケティング配信資格を別々に確認します。
- 同じ送信元バージョンを再実行します。本人は1件のままで、確認メールや歓迎メールが再送されないことを期待します。
- 通常項目を変更して同期します。次に送信元項目を空にし、値の保持か消去について文書化された規則を確認します。
- その後の配信停止を記録し、古い登録を再実行しても停止が維持されることを確認します。
- 拒否されるリクエストを再現します。IDと結果を保存し、そのレコードを復旧して確認してから保存済みカーソルを進めます。
これは合格手順であり、すべてのコネクターに同じ機能があるという主張ではありません。必要な確認を実演できないなら、それが解決すべき不足です。
再試行で意味を変えない
Brevoの連絡先エンドポイントは送信元のext_idを受け付け、updateEnabledをサポートします。それでも照合の責任は利用側にあります。競合するIDは確認が必要です。forceMergeはレコードを削除し得るため、標準の復旧操作にしないでください。
データの再書き込みと副作用の繰り返しは別の問題です。連絡先が1件でも確認メールが2通届くことがあります。送信IDと各副作用の結果を保存します。タイムアウト後は結果が不明なので、再送する前に宛先を確認します。
エンドポイントと契約プランごとの現行レート制限表を読みます。制限は異なり、時間当たりと秒当たりの両方が適用される経路もあります。単一の数値をすべての操作に当てはめないでください。
Webhookにも管理責任者が必要
イベントは変化を知らせますが、項目の管理元の競合を解決したり、完全な双方向同期を自動で維持したりはしません。
提供元が対応する方法で配信を認証し、有効な作業を保存して取りこぼしを照合します。コネクターが自分の更新を受け取ったら、記録した送信元バージョンと意図した項目値を比較してから再度書き込みます。独自の発信元マーカーがすべての提供元から返ると決めつけないでください。
新しい購読者については、マーケティング対象に入れる前にダブルオプトインガイドを参照してください。住所がコピーされたことと、確認済みで現在も購読中であることは別の結果です。
2回目の実行も1回目と同じように説明できるなら、その接続は準備ができています。
よくある質問
Brevoコネクターとは何ですか？
Brevoと別のシステムの間でデータを動かす仕組みです。転送、項目の意味付け、処理状態の保存を確認し、本人照合、失敗、同意の扱いを評価してください。
どのBrevo連携から始めればよいですか？
必要な作業を満たす、保守された標準アプリから検討します。具体的なマッピングや復旧要件が残る場合は、自動化サービス、連携基盤、独自APIコードを比較します。
Brevoのマーケットプレイス掲載はTajoで利用できる証拠ですか？
いいえ。アプリの公開元と対応する作業を別々に確認してください。マーケットプレイス掲載、ドキュメント、動作するTajoコネクターは異なる証拠です。
連絡先の重複を避けるには？
安定した送信元IDを選び、照合後の宛先IDを保存し、IDの競合は書き込み前に解決します。通常の再試行でforceMergeを使わないでください。
Brevoが429を返したら？
該当する制限ヘッダーに従って待機し、失敗した作業を保持して、上限を決めた方針で再試行します。レコードごとの結果を追跡し、無関係な副作用を繰り返さないでください。
同意を双方向で同期できますか？
チャネルと目的ごとに権威あるシステムを一つ決めます。古い登録で後の配信停止を上書きしてはいけません。双方向移動には明示的な競合規則とループ防止が必要です。