正確な商品情報、誠実なオファー、配信許諾の確認、送信のたびに最新の購入状況を確かめる仕組み。カゴ落ちのリマインダーを作るポイントを解説します。
カゴ落ちメールは、購入を完了しなかった人に、もう一度その買い物に戻ってきてもらうためのメールです。領収書のような通知としてではなく、マーケティングメールとして扱いましょう。顧客は気が変わったのかもしれませんし、ほかで答えが見つかったのかもしれません。単に時間がなくなっただけということもあります。
役に立つリマインダーは、買い物に戻る手間を減らします。でっち上げのカウントダウンも、「残りわずか」といった主張も必要ありません。
そのアドレスにマーケティングメールを送る許諾を得ているかを確認します。カートがまだ存在するか、商品がまだ購入できるか、顧客がすでに購入していないかもチェックしましょう。配信停止と配信除外のルールも適用します。
カートにある実際の商品、価格、リンク先を使いましょう。カートが作成された後にオファーが変わった場合は、現在の条件をはっきり伝えます。ストアが実際に取り置いていない限り、価格や商品を確保していると約束してはいけません。
完了していない購入が注文確認メールとどう違うのかは、トランザクションメールのガイドで説明しています。
米国のCAN-SPAM法は、メールをその主な目的によって分類します。その判断の仕方は、FTCによるCAN-SPAM法のコンプライアンスガイドで説明されています。顧客がまだ注文していない買い物についてのリマインダーは、販売を促すためのものです。ほかのマーケティングメールと同じ配信停止リンクと住所を記載しましょう。
リマインダーの正確さは、その裏にあるデータの正確さで決まります。コピーを書く前に、カゴ落ちしたカートごとに、ストアが次のフィールドを送っていることを確認してください。
イベントIDがあれば、リクエストが再試行されたときに、連携側で重複を見分けられます。IDは、1通のリマインダーを何度再試行しても変わらない値、つまりカート、カゴ落ち、ステップから組み立てましょう。送信時に生成するタイムスタンプは再試行のたびに変わるため、重複を検出できません。Brew のAPIでイベントを送信する場合は、そのIDを Idempotency-Key ヘッダーに入れて送ります。同じキーと同じリクエストボディで再試行すると、2回目の実行は始まらず、最初の結果が返されます。キーは保存されたその実行に1日よりずっと長く紐付いたままなので、同じカートで再びカゴ落ちした顧客には、新しいIDが必要です。
以下は説明用の下書きです。実際の差し込みタグではなく、編集用のプレースホルダーを使っています。
件名：[ストア名]のお買い物カート
[商品名]がカートに入ったままになっています。ご注文いただくかどうかを決める前に、商品と現在の合計金額をご確認いただけます。
[カートに戻る]
サイズ感やお届けについてご不明な点はありますか？ このメールにご返信いただければ、担当チームがお手伝いします。
最後のサポート案内は、返信が実際に回答できるチームに届く場合にだけ入れましょう。各プレースホルダーは、プラットフォームが対応しているフィールドを使って、確認済みのデータに置き換えます。商品画像や商品名が欠けているときの代替値もテストしてください。
2通目を送るなら、そのメールを送る理由を持たせましょう。商品についてよくある質問に答えたり、実際のポリシーを説明したりします。割引はビジネス上の判断であって、2通目で必ず出すべきものではありません。
多くのストアは、次のような待機時間から始めています。自社の注文データで検証すべき、一般的な慣習として扱ってください。ベンチマークではありませんし、このタイミングがほかのタイミングより多くのカートを回収できることを示すものは、ここには何もありません。
| メール | よくある初期設定の待機時間 | 担える役割 |
|---|---|---|
| 1通目のリマインダー | カゴ落ちから1〜2時間後 | 訪問の記憶が新しいうちにカートを見せる |
| 2通目 | 約24時間後 | サイズ感、配送、返品についてよくある質問に答える |
| 3通目 | 48〜72時間後 | もう一度リマインドする。オファーを出すと決めた場合は、実際のオファーを伝える |
| 任意の最終メール | 5〜7日後 | カートがまだ有効なら、じっくり検討している購入を後押しする |
4通すべてを送る必要はありません。安価な商品なら、リマインダー1通で十分なこともあります。2通目以降のメールには、それぞれに送る理由が必要です。また、後述する購入状況のチェックは、その1通1通の前に毎回実行してください。
お客様の声は、承認済みのものを、実際の発言者名と掲載許可とともに使いましょう。下書きにお客様の声が必要なのに使えるものがない場合は、社内向けのプレースホルダーを置き、送信前に削除します。生成した名前と星5つの評価を、本物の顧客の声のように見せることは絶対にやめましょう。
同様に、期限は実際のオファーの有効期限と一致していなければなりません。在庫についての警告は、現在の在庫を反映している必要があります。どちらかの事実を偽ったリマインダーは、クリックは得られても、ストアの信頼を損ないます。
よくある失敗は、終了条件のないシーケンスです。顧客が購入した後も、すでに支払いを済ませたカートについて、リマインダーがさらに2通届いてしまいます。次のいずれかに当てはまったら、すぐにシーケンスを止めましょう。
フローを作る前にこれらを書き出し、テスト用のカートでひとつずつテストしましょう。Brew からリマインダーを送る場合に、このチェックをどこで行う必要があるかは、次のセクションで説明します。
Brew では、待機の後も、イベントのペイロードのフィールドには元のカートの内容が残っています。contact.<name> を使う条件では Brew のコンタクトフィールドの現在の値を読み取れますが、ストアのカート、注文、在庫の記録を取得するわけではありません。
リマインダーを送るタイミングが来たら、その時点で対象条件を満たしているかを、ストアのアプリケーション側で確認します。顧客のカートがまだ対象で、マーケティングメールを受け取る許諾もあるなら、現在のカートの内容を含む新しいリマインダーイベントを送信します。購入済みなら、イベントは送信しません。イベントを送る連携処理での再試行に備えて、一意に決まるイベントIDを使いましょう。
「購入後は停止」のようなプロンプトを書けば、ストアの最新データとリアルタイムにつながる、と思い込まないでください。実際に設定したイベントと連携のワークフローを確認しましょう。
アトリビューション期間と、メールがなくても発生していたはずの注文の扱い方を決めておきましょう。売上とあわせて、割引のコスト、返品、配信停止、迷惑メール報告も追跡します。十分な配信数があるなら、ホールドアウト（メールを送らない対照群）を設けると、メールによって上積みされた回収分を見積もりやすくなります。
このシーケンスで約束できる回収率はありません。関連性の高いリマインダーから始め、状態のチェックを検証し、自社の結果をもとに改善していきましょう。より広い測定の考え方については、ROIガイドを参考にしてください。
