キャンペーン配信前チェックリスト・ジャーニー運用ルール

配信事故の大半は文面ではなく対象から生まれます。セグメントを保存したあと条件を声に出して読み直し、対象数が想定した桁かを確認します。桁が食い違うときは、条件が一つ逆に掛かっている場合が多いものです。除外セグメントも同じ場で見ます。受信拒否者、決済を終えたばかりの顧客、社内アカウントとテスト端末が抜けているかを確認します。対象と除外を確定してから素材を当てます。順序を入れ替えると素材に合わせて対象を広げることになり、そのとき入ってきた人たちが後に受信拒否として抜けていきます。直前の配信で同じメッセージを受け取った人が再び入っていないかも、この場で取り除きます。

プレビュー画面は置換変数とディープリンクの失敗を映しません。チャネルごとに実機でテスト受信を一度ずつ受け取ります。プッシュはロック画面でタイトルが切れる位置を、メールは画像が止められた状態の本文を、アプリ内メッセージは表示条件が掛かる画面を見ます。置換変数が空の値のときに何が見えるのかも、このとき確認します。リンクは実際に開いて到達先まで辿ります。アプリが入っている端末と入っていない端末でディープリンクの着地は異なるので、両方で受け取ります。アプリ審査やストア配信が掛かる素材なら、配信の前にリリースが先に届くかも併せて確認します。

予約配信は、アカウントのタイムゾーンと顧客のタイムゾーンが違うと深夜に出ていきます。予約を保存したあとどのタイムゾーンで保存されたかを確認し、海外の購読者がいれば到着時刻を別に計算します。同じ時刻に別のジャーニーがすでに掛かっていないかもカレンダーで確認します。プロモーションと取引通知が同じ時刻に重なると、本来読むべき取引通知のほうが埋もれます。夜間配信の制限を設けているなら、予約時刻がその区間に掛かるかも見ます。大量配信は一度に出ず時間をかけて広がるので、開始時刻ではなく最後の一通が届く時刻を基準に置きます。

ジャーニーごとに進入条件と終了・除外条件を定義し、ジャーニー間の優先順位を決めます。顧客一人が受け取るメッセージ総量の上限も運用ルールに含めます。ただし、OneSignalのPush frequency cappingはプッシュのみに適用され、メール・SMS・アプリ内メッセージは合算しません。複数チャネルの総量を制限するには、チャネル別の配信履歴と除外条件を結び付ける別の設計が必要です。取引通知など例外扱いにするメッセージも定義します。上限を回避して送ったプッシュも、その後の上限計算には含まれます。上限に達して送られなかったメッセージは、待機列に残らず省略されます。ルールの変更者と日付、適用チャネル、例外条件を記録します。OneSignalのプッシュ頻度制限の動作と実際の運用ルールを照合します。

配信は取り消せませんが、止めることはできます。すでに出たプッシュは回収されず、予約配信と進行中のジャーニーは中断できます。ですから最初の30分は到達数とエラー率、受信拒否の増加を見ます。いつもと違う値が見えたら、残りの予約をまず止めてから原因を切り分けます。確認した値と判断は次の配信のために同じ文書へ書き留めます。止める人と止める権限も配信前に決めておきます。異常が見えた瞬間に承認手続きを踏み始めると、残りの予約はその間に出ていきます。担当者がまず止め、そのあとに報告する順序でルールを書きます。ここまで終えれば、その記録が次のキャンペーンのチェックリストになります。項目は事故が起きたときに増やし、二回続けて掛からなかった項目はそのままにします。