イベントのリマインドメール重複送信を防ぐ自動化QA

各リマインドへ至る経路を列挙する

同じイベントメールを送る可能性があるトリガーをすべて記録します。登録完了、リストやタグの変更、日付ルール、手動キャンペーン、別のフローなどです。各経路が対象とする開催回と受信者の状態も明記します。個別には妥当な2経路が、1人には重なることがあります。Dotdigitalは、重複した登録処理、複数プログラムへの参加、誤った除外設定による重複送信を説明しています。再参加の扱いは提供元ごとに異なるため、フロー間で自動的に重複排除されると決めつけず、現在の設定を確認します。[1][2]

管理された連絡先ケースで試す

ワークシートに、新規の対象登録者、登録済みの連絡先、キャンセル済み記録、以前にフローへ入った連絡先をテストケースとして用意します。リマインドがイベント日付フィールドに依存する場合は、日付変更ケースも加えます。管理されたテスト記録と許可されたテスト環境、または厳密に限定した実運用セグメントを使い、実際の参加者を試験目的だけで登録しないでください。各ケースに想定メッセージID、送信回数、除外結果を書きます。テンプレートのテスト送信は表示確認には役立ちますが、受信者別のトリガー動作は証明しません。例えばMailchimpは通常のテスト送信では連絡先固有の差し込みタグが機能しないと説明しています。[3]

想定経路と実際の送信記録を照合する

各ケースの後、想定経路と提供元で確認できるフロー活動・送信履歴を比較します。2つのプログラムへの参加、同じプログラムへの再参加、自動リマインドと別キャンペーンの両方からの送信を調べます。件名が似ているだけでは判断できないため、キャンペーンまたはメッセージIDを記録します。連絡先単位の経路が表示されない場合は「未検証」とし、送信担当者と安全な試験方法を確認します。個人のメールアドレスは権限のあるサービス内に留め、共有シートにはケース参照だけを記します。[1]

検証済みのフローだけを公開する

想定外の送信、必要な除外の失敗、重要なケースの証拠不足があればフローを保留します。入口や除外ルールの修正担当を決め、影響したケースを初期化したテスト状態から再実行します。承認したフローバージョン、イベント情報、公開責任者、公開後の監視期間を記録します。トリガー、対象者、日程を変更したら再確認してください。この確認は文面とリンクの送信前点検を補うもので、一方に合格しても他方の合格にはなりません。[1]

自動リマインドQAマトリクスをダウンロード（Markdown、英語）