セールのピーク時も、すべての注文通知を遅れず届け、すべてのキャンペーンを迷惑メールフォルダーから遠ざけます。
セール当日にも耐える注文・カートのメール。AIが配信タイミングと文面作成を支援
セール当日の送信量でスロットリングされる
プロバイダーに合わせたスロットリングとウォームアップ済みの処理能力が、ピークを吸収します。
注文メールがプロモーションと混在する
ストリームを分けることで、確認メールを信頼できる経路に保てます。
プラグインの設定は原因の特定が難しい
標準のSMTPは一般的なプラットフォームで動作し、ログで何が起きたかを確認できます。
購入者は、注文の各段階がすぐに確認されることを期待しています。以下の流れにより、これらのメッセージを迅速かつ追跡可能に保ちます。
EC向けメール配信とは、ストアの注文確認、配送通知、カート放棄のリマインダー、プロモーションを、お客様の受信トレイへ確実に届けるプロセスです。ここには、性質の大きく異なる2種類のメールが含まれます。購入後にお客様が待っているトランザクションメールと、迷惑メールとみなされるリスクが高いプロモーションメールです。適切な配信設定は、前者を守りつつ、後者の成果も引き出します。注文数が最も多く、お客様の我慢が最も少ない日にこそ重要になります。
オンラインストアは、プラットフォームの標準機能やプラグインで送信していることが多く、送信量が跳ね上がるまでは問題ありません。フラッシュセールでは数分で何千件もの確認メールが発生し、ウォームアップされていない送信者はプロバイダーにスロットリングされ、お客様から注文メールが届かないという問い合わせが入ります。領収メールと同じドメインからプロモーションを送ると、状況はさらに悪化します。プラグインの設定は分かりにくく、問題が起きるたびに何が起きたのか推測するしかありません。共有プラグインでは、根本原因が見えにくいものです。
MigoSMTPは標準のSMTPで一般的なストアのプラットフォームに接続し、注文メールを専用のストリームで処理し、繁忙期の前に処理能力をウォームアップし、キャンペーン中はプロバイダー別の配信状況を表示します。AIは、お客様自身の行動に基づいてカート放棄メールの文面と配信タイミングを提案したり、特定の注文メールが遅れた理由を説明したりできます。文面と自動化は、実行前に必ず販売者が承認します。キャンペーンの実行中でも、注文メールは速く届きます。
支払いが成功した瞬間に、保護されたストリームで確認メールを送信するため、フラッシュセールで領収メールが急増してもプロモーションキャンペーンに遅れさせられません。サポートはどの注文メールも確認できます。
配送業者のイベントをお客様への通知に変換し、配信の追跡によって、発送メールが実際に購入者へ届いたかどうかをサポートが確認できます。発送通知の遅れも見つけやすくなります。
一定時間後にリマインダーを発動し、注文が完了した時点で停止します。また検証を使って、チェックアウト時に入力ミスのあったアドレスへの送信を防ぎます。購入後はリマインダーが止まります。
商品が再入荷したら購読者にお知らせし、ウォームアップ済みのドメインで季節のキャンペーンを実施します。送信は、各メールボックスプロバイダーの受け入れ率に合わせて調整されます。プロモーションの頻度は控えめに、相手に配慮して設定しましょう。
商品が再入荷したら、登録している購入者にお知らせし、購入または配信停止された時点でアラートを止めます。
配達後の適切なタイミングでフィードバックを依頼し、未解決のサポート案件があるお客様は対象外にします。
どちらもストアにとって重要ですが、性質が異なるため、分けて扱う必要があります。
セール当日に備えましょう。両方のストリームが同時にピークを迎えるため、1つのパイプラインを共有してはいけません。
ブランドの語り口と商品情報に合った、カート放棄や再入荷の文面を下書きします。自動化で使う前に、販売者が各バージョンを編集・承認します。
お客様の過去のエンゲージメントに基づいて、リマインダーやプロモーションを送るタイミングを提案します。提案された時間帯をそのまま採用することも、変更することも、注文メールは即時送信のままにすることもできます。
過去のキャンペーンから、予定しているセールの想定送信量を見積もり、あらかじめ処理能力をウォームアップできます。予測はあくまで目安であり、最終的な計画はお客様が決定します。
お客様の注文メールが遅れた理由を尋ねると、ログから保留と再試行の状況を平易な言葉でまとめます。データの読み取りのみで、変更は行いません。
AI機能はあくまで支援です。販売者はすべての提案メッセージ、スケジュール、予測を確認し、お客様に届く内容を自分で管理できます。
大型セールの数週間前から新しいIPのボリュームを段階的に引き上げ始めれば、トラフィックが急増したときには、プロバイダーがすでにお客様の送信量を信頼している状態になります。
入力中に形式とドメインをチェックし、タイプミスの可能性があれば修正案を提示します。確認メールの未達やバウンスを防げます。
領収メールは1つのサブドメインから、キャンペーンは別のサブドメインから送信すれば、マーケティングで苦情が急増しても注文メールの配信には影響しません。
注文が確定したら、すぐにリマインダーを抑止します。すでに支払い済みのカートについて送信すると、苦情を招きます。
プラットフォームやプラグインの更新で、メール設定がリセットされることがあります。変更後はテスト注文を行い、配信イベントが引き続き届いていることを確認してください。
大型セールの準備中ですか?ピークへの備えをお手伝いします。
認証済みのドメインから専用のトランザクション用ストリームを通じて、支払いが成功した時点で送信します。プロモーションの内容は含めず、プレーンテキストのパートを付け、配信イベントを追跡することで、サポートがどのお客様の確認メールも検証できるようにします。変更後は、実際の注文でテストしてください。
よくある原因は、SPF、DKIM、DMARCの未設定、評判の悪い共有送信者の利用、プロモーションメールと同じドメインの使用です。ストアのドメインを認証し、注文メールとマーケティングを分離し、プロバイダー別のバウンスと苦情のデータを確認してください。まず認証を整えるのが最優先です。
SMTP認証情報を作成し、ホスト、ポート、ログイン情報をストアのプラットフォームまたはメールプラグインに入力して、送信ドメインを検証します。その後、テスト注文を行って配信イベントを確認します。まずステージング環境のストアからテストメールを送ってください。
数週間前にIPをウォームアップし、想定送信量を予測し、プロモーションの送信をずらし、注文メールは専用のストリームに保ちます。セール中はプロバイダー別の保留状況を監視し、確認メールを遅らせずにキャンペーンの送信を減速できるようにします。セール中に保留が増えたら、優先度の低いキャンペーンを一時停止してください。
注意して運用すれば問題ありません。検証済みのアドレスに送信し、注文が完了したらリマインダーを止め、リマインダーの回数を制限し、配信停止を尊重してください。評判を損なうのは、不注意な自動化による高い苦情率です。シリーズは数通までに抑えましょう。
送信量によります。安定して多くの送信がある、またはセールのピークが急激なストアは、ウォームアップ済みの専用IPが有効なことが多く、小規模なショップならマネージド共有プールで十分な場合もあります。この選択は毎年見直してください。
AIは、商品情報とトーンに基づいて、リマインダーや再入荷の文面を下書きできます。自動化を開始する前に、必ず人が各下書きを確認して承認してください。商品の詳細や価格が正確かどうかも確認しましょう。
過去のキャンペーンに基づく予測により、想定送信量を見積もり、間に合うように処理能力をウォームアップできます。これは計画の補助であり、スケジュールと制限はお客様が決定します。キャンペーンの履歴が増えるほど、予測の精度は向上します。