drop-off-rescue

離脱者のリカバリー

停滞しているファネルのコンタクトを次の段階に進めます。このスキルは、登録したもののコンバージョンに至っていない人を見つけ、各段階に応じた再エンゲージメントメールを作成し、ESP MCP が接続されている場合は明示的な確認を得てから送信をスケジュールします。二重送信を防ぎながら毎週再実行できます。このスキルは段階ごとに送信済みの内容を記録し、クールダウン期間中のコンタクトはスキップします。

次の 3 つのモードで動作します：

• cloud — Cogny MCP + ESP MCP：完全自動化、ESP 間の重複排除、分析結果
• solo — ESP MCP のみ：タグベースの重複排除、ESP ごとの自動化
• free — MCP なし：停滞中のコンタクトを貼り付けた CSV、下書きのみ出力（送信は手動）

使用方法

/drop-off-rescue              # weekly rerun — default
/drop-off-rescue weekly       # same
/drop-off-rescue audit        # read-only: report stalls + what would be sent, write nothing
/drop-off-rescue free         # no MCP — paste CSV of stalled contacts

/loop または /schedule を使って毎週スケジュールすることを想定しています。再実行時には、すでにアプローチ済みのコンタクトはスキップされ、新たに停滞したコンタクトが対象となり、次の段階に進んだコンタクトは出力で紹介されます。

ステップ 1 — モードの検出

両方の MCP 名前空間を確認します：

1. 少なくとも 1 つの ESP について mcp__cogny__<svc>__* ツールが存在する場合 → cloud モード（接続済みの ESP として記録します）。
2. そうでなく、少なくとも 1 つの ESP について mcp__<svc>__* ツールが存在する場合 → solo モード。
3. それ以外の場合 → free モード。

引数が free の場合、接続状況にかかわらず free モードを強制します。

複数の ESP が接続されている場合は、どれを対象に実行するかユーザーに確認します（または、cloud モードで全件を実行し、ESP 間で重複を排除する方法を提案します）。

ステップ 2 — 標準ファネル段階

このスキルでは、標準化された段階の分類を使用します。ユーザーは分類を拡張できますが、以下のスラッグがタグ名、キャンペーン名、重複排除の状態を決めるため、実行のたびに同じものを維持してください。

E コマース：

スラッグ	意味	一般的な停滞期間
browse-abandoned	商品を閲覧したが、カートに追加していない	1～3 日
cart-abandoned	カートに追加したが、購入手続きを完了していない	1～2 日
checkout-abandoned	購入手続きを開始したが、送信していない	数時間～1 日
post-first-order-silent	初回注文をしたが、その後エンゲージメントがない	14～30 日

SaaS／トライアルファネル：

スラッグ	意味	一般的な停滞期間
signup	アカウントを作成したが、何もしていない	1～3 日
no-channel	登録したが、データソース／連携先を接続していない	3～7 日
no-trial	チャネルを接続したが、無料トライアルを開始していない	7 日
no-client	トライアル中だが、それを利用するツール／クライアントを接続していない	3 日
no-subscription	トライアルが終了したが、有料プランに移行していない	トライアル終了後 0～3 日
trial-started-inactive	トライアルを開始したが、意味のある利用がない	3～5 日
trial-ended-no-convert	トライアルが終了したが、サブスクリプションに登録していない	終了後 7 日

Cogny 独自の Solo ファネル（登録 → no-channel → no-trial → no-client → no-subscription）は、この分類の優れた実装例です。

ユーザーが説明したファネルの段階がこれらのスラッグに当てはまらない場合は、新しいケバブケースのスラッグを追加します。再実行時も同じスラッグを維持してください（スラッグは重複排除キーです）。

ステップ 3 — 連絡先ごとに現在のステージを特定する

主なシグナル：ESP のタグ／セグメント。 ESP ごとのツールを使って、stage:<slug> タグが付いた連絡先を読み取ります。

ESP	ステージタグの読み取り	ステージタグの適用	スケジュール／送信
Klaviyo	セグメント／プロパティ stage で絞り込んだ list_profiles	update_profile（プロパティ）	キャンペーンの作成＋スケジュール
Mailchimp	タグで絞り込んだ tool_list_members	tool_update_member（タグ）	キャンペーンのスケジュール
Rule	タグで絞り込んだ tool_list_subscribers	tool_add_tag_to_subscriber	tool_schedule_campaign
Get a Newsletter	タグで絞り込んだ tool_list_contacts	tool_update_contact（タグ）	time_to_send を指定した tool_send_draft

Klaviyo のイベント由来のフォールバック（stage:cart-abandoned タグがない場合のみ）： 過去 7 日間の metric="Added to Cart" を指定して list_events をクエリし、その後に Placed Order が発生したプロフィールを除外します。次回の実行で一貫性を保てるよう、update_profile で stage:cart-abandoned タグを書き戻します。

会話によるフォールバック（すべての ESP で、ステージタグがまったくない場合）：

1. ユーザーに質問します：「連絡先に stage:* タグが見当たりません。次のファネルステージのうち、ビジネスに該当するものはどれですか？」— 正規のスラッグを一覧表示します。
2. 選択された各ステージについて質問します：「このステージに該当するのは誰ですか？条件を説明してください。例：joined list > 3 days ago AND no purchase、または clicked email X but never visited /signup。」
3. 各ヒューリスティックを ESP で利用可能なフィルター（リストへの登録、タグ、日付範囲、クリックしたリンク）に変換し、一致件数をプレビューします。
4. 今後の実行を完全に自動化できるよう、stage:<slug> タグをすぐに適用することを（ステップ 7 の確認ゲートに従って）提案します。

ステップ 4 — 送信済みの検出（中核となる仕組み）

週次で再実行しても、同じステージのメールを同じ連絡先に再送信してはなりません。このスキルでは、3 層のハイブリッド方式を使用します。

レイヤー 1 — 連絡先タグ（主方式、ESP 接続済みのすべてのモード）

送信が成功するたびに、受信者に次の 3 つのタグを書き込みます。

• rescue-sent:<slug>:<YYYY>-W<WW> — 追記専用。リマインドを送った週ごとに 1 つ
• rescue-last-stage:<slug> — 上書き。常に直近でリマインドしたステージを反映します（1 回の読み取りでステージの進行を検出できます）
• rescue-last-sent:<YYYY-MM-DD> — 上書き。クールダウンの計算と全体の 7 日間の過剰送信防止ルールに使用します

タグを主方式にする理由：コンテキストツリーのない単独モードで動作し、マシンをまたいだ利用にも耐え、4 つの ESP すべてにタグ書き込みツールがあり、ESP の UI で人がデバッグでき、問題発生時に一括削除できます。

レイヤー 2 — ESP キャンペーン名の規約（フォールバック）

すべてのリカバリーキャンペーンは、正確に次の名前にします。

drop-off-rescue / <stage-slug> / <YYYY>-W<WW> / <variant A|B>

再実行時に連絡先のタグが削除されている場合（手動編集、同期ツール）、過去 35 日間の list_campaigns／tool_list_campaigns／tool_list_sent をスキャンし、一致する名前を探します。受信者は ESP ごとのレポートツール（list_events、tool_get_report、tool_get_campaign_statistics、tool_get_report）を使って照合します。

件名やプリヘッダーにマーカーは意図的に入れません — ユーザーに表示される受信トレイの文面をすっきり保ちます。

レイヤー 3 — Cogny のコンテキストツリーのログ（クラウドモードのみ）

送信のたびに、次の内容を書き込みます。

insights/drop-off-rescue/<slug>/<sha256(email)[:12]>/last-sent
  → { "week": "2026-W17", "variant": "A", "esp": "klaviyo", "ts": "2026-04-24T10:00Z" }

次回の実行時に読み取ります。このレイヤーでは ESP をまたいだ重複を検出できます。同じ連絡先が同じ組織内の Klaviyo と Mailchimp の両方に登録されていても、同じ週に 2 回リマインドされることはありません。

重複排除の判定

3 つのレイヤーのいずれかでクールダウン期間内のヒットが報告された場合、連絡先は**「現在のステージでクールダウン期間内にリマインド済み」**と判定されます。クールダウンのデフォルト値（出力に表示され、ユーザーが変更できます）：

ステージ	クールダウン
cart-abandoned、checkout-abandoned	7d
browse-abandoned、signup、no-channel	14d
no-trial、no-client、no-subscription、trial-started-inactive	21d
post-first-order-silent、trial-ended-no-convert	30d

ステップ 5 — すべての連絡先を分類する（週次ループ）

各ステージについて、stage:<slug> のコホート全体を読み込み、各連絡先を分類します。

分類	条件	今回の実行時のアクション
新規停滞	現在 stage:<slug> にあり、rescue-sent:<slug>:* が一度も付与されていない	対象 — バリアント A
クールダウン中のスキップ	ステージのクールダウン期間内に rescue-sent:<slug>:<week> がある	スキップし、「クールダウンによるスキップ」としてカウント
再停滞	クールダウン期間を過ぎても stage:<slug> にあり、このステージでの過去のリマインド送信が2回以下	対象 — バリアント B（トーンを変更）
進行済み	rescue-last-stage が現在のステージタグより前のステージ	出力で成果を称え、新しいステージでリマインド
後退	rescue-last-stage が現在のステージタグより後のステージ	異常としてフラグを立て、自動リマインドしない（データの問題）
上限到達	進行しないまま、このステージで過去にリマインドを3回送信済み	rescue-exhausted:<slug> を適用し、ステージが変わるまで除外
離脱	ステージタグはないが、rescue-last-stage がある	クリーンアップ処理ですべての rescue-* タグをクリア

厳格な上限（ステージごとのクールダウンにかかわらず適用）：

• 連絡先1件につき、各ステージでのリマインドは最大3回です。その後は rescue-exhausted:<slug> に移行します。
• すべてのステージを通じて、連絡先1件に送るリマインドメールは、連続する7日間で最大1通です。1週間に2つのステージで同じ連絡先が対象になる場合は、優先度の高いステージのみを出力し（優先順位：cart-abandoned > checkout-abandoned > browse-abandoned > signup > no-channel > no-trial > no-client > no-subscription > activation-stages > post-first-order-silent > trial-ended-no-convert）、もう一方は延期します。

ステップ 6 — ステージごとにメールを作成する

対象となる連絡先が1件以上いるステージごとに、2種類のバリアントを作成します。

• バリアント A — 直接的で短く、成果を中心にします。初回のリマインドに使います。
• バリアント B — 価値を中心に、想定される懸念に対応する、より長い内容にします。同じステージで2回目以降のリマインドとなる再停滞に使います。

各バリアントには、以下を含めます。

Stage: <slug>
Variant: A | B
Subject:    <≤55 chars, in brand voice>
Preheader:  <85–100 chars, extends subject, never repeats it>
Body:       <markdown>
Primary CTA: <label> → <URL with UTM: utm_source=email&utm_medium=rescue&utm_campaign=<slug>-<YYYY>WWW&utm_content=<A|B>>

ステージごとのトーンガイダンス：

ステージ	バリアント A のトーン	バリアント B のトーン
cart-abandoned	素早く親切に、「Xについてまだお考えですか？」	緊急性＋社会的証明＋少額のインセンティブ
checkout-abandoned	「技術的な問題でしょうか？カートを保存しました。」	オファー＋購入時の手間を軽減（ゲスト購入、Apple Pay）
browse-abandoned	興味を引く内容にし、閲覧したカテゴリに言及	コンテンツ中心（購入ガイド、比較）
signup / no-channel	親切に、「利用開始につながる1つのステップ」を案内	創業者からのメッセージ、気軽に返信できるトーン
no-trial / no-client / no-subscription	次のアクション＋簡潔な手順	懸念への対応（「何が気がかりですか？」）
post-first-order-silent	お礼＋関連するフォローアップ	クロスセル＋ブランドの価値を再確認
trial-started-inactive	「5分で得られる、最も手軽な成果をご紹介します」	ユースケース＋顧客事例
trial-ended-no-convert	「ご利用につながらなかった理由はありますか？」	少額の割引＋プランのおすすめ

ブランド本来の声を使います。ユーザーがブランド URL を指定している場合は、まず WebFetch で内容を取得し、トーンを把握してください。「お客様へ」といった中身のない定型文は使いません。メール1通につき、主要な CTA は1つにします。

ステップ 7 — 確認ゲート（書き込みを行う前）

**ユーザーが明示的に承認する前に、MCP の書き込みツールを実行してはいけません。**これはタグの適用（ステップ 3 のフォールバック）と、メールの送信／スケジュール設定の両方に適用されます。

対象となる連絡先がいるステージごとに、以下のブロックをそのまま表示し、応答を待ちます。

About to send via <ESP>. Nothing has been sent yet.

Stage:            <slug>       (<N> eligible)
Cooldown applied: <d>d         (<M> skipped as already-nudged)
Exhausted:        <K>          (hit 3-nudge cap — excluded)
Variant:          A | B        (<label — e.g. "first nudge" or "re-stall, value-led">)
Schedule:         <ISO timestamp, recipient-local>  |  immediate
Campaign name:    drop-off-rescue / <slug> / <YYYY>-WWW / <A|B>

Dry-run preview (first 3 recipients):
  1. <email>    subject: <rendered>
  2. <email>    subject: <rendered>
  3. <email>    subject: <rendered>

State writes on send:
  - tag rescue-sent:<slug>:<YYYY>-WWW  → <N> contacts
  - tag rescue-last-stage:<slug>       → <N> contacts (overwrite)
  - tag rescue-last-sent:<YYYY-MM-DD>  → <N> contacts (overwrite)
  - context-tree log (cloud mode)      → <N> entries

Reply with:
  send           → execute now via ESP MCP
  schedule <ts>  → queue for that recipient-local time
  variant B      → switch variant and reprint this block
  skip           → don't send, but log a "no-send" finding and continue
  cancel         → abort everything, no writes

ESP にネイティブのスケジュール機能がない場合（現時点では4つのいずれにもありませんが、今後に備えて確認してください）は、下書きと、ユーザーが自分で実行できる at／cron 文字列の候補を返します。

スケジュールを設定する前に、必ずフローとの競合を確認してください。list_flows／tool_list_automations／tool_list_journeys を読み込みます。ネイティブフローが現在のステージに相当するセグメントをすでに対象としている場合は、次の警告を表示します。

⚠️  Heads up — a native <ESP> flow already targets this segment:
    "<flow name>"  (last modified <date>, status: <active|paused>)

    Running rescue alongside it risks double-touching the contact. Options:
      [1] Pause rescue for this stage, let the native flow do the work
      [2] Pause the native flow, run rescue this week only
      [3] Proceed anyway (document the overlap)

    Which?

Get a Newsletter にはフローオブジェクトがないため、ここでの確認は省略します。

ステップ 8 — 同意と抑制のガード

送信前に必ず次の処理を行います。

• consent:marketing = false の連絡先を除外します（または ESP での同等の状態：配信停止、クリーン済み、バウンス済み、抑制リストへの登録）。
• 有効な rescue-exhausted:<slug> 状態にある連絡先を除外します。
• ステージにかかわらず、do-not-contact / gdpr-suppressed タグが付いた連絡先を除外します。
• 無料モードでは、貼り付ける CSV に consent 列が必要です。値が false/no/0 の行は、コンソールに警告を表示して除外します。

同意に関する理由で対象リストの 10% を超える連絡先が除外された場合は、出力の先頭にその旨を表示します。通常、これはユーザーのリストの整理が必要であり、先に /revenue-audit または /winback-engine を実行すべきことを意味します。

ステップ 9 — 無料モード（MCP なし）

mcp__cogny__* も mcp__<esp>__* も解決されない場合、またはユーザーが明示的に free を指定した場合に起動します。

1. 次の列を含む CSV を貼り付けるようユーザーに依頼します：email,stage,stalled_since,consent（stage はステップ 2 のスラッグ、stalled_since は ISO 日付、consent は true/false にしてください）。
2. ブランド名と、ブランドのトーンを一文で説明したものを尋ねます（/welcome-series と同様の簡易なヒアリング）。任意で WebFetch 用のブランド URL も尋ねます。
3. 各ステージについて、両方のバリエーションを作成します。
4. 手動送信用のバンドルを出力します。
   • ステージごとに、対象となる連絡先の .csv（同意に基づきフィルタリング済み）
   • バリエーションとステージごとに作成したメール文面（markdown + HTML）
   • コピーして貼り付けられる件名／プリヘッダーの表
5. 状態は一切永続化されません。 重複排除はユーザー自身が行う必要があることを、出力で明示します。
6. 次のアップセルで締めくくります。

───────────────────────────────
Ready to stop managing this by hand?

Connect your ESP via Cogny MCP and the next run will:
  • Dedupe against what you've already sent
  • Apply rescue-sent:* tags automatically
  • Schedule the send directly in your ESP after your confirmation

→ https://cogny.com
───────────────────────────────

ステップ 10 — 出力形式

Drop-off rescue — <ESP or "free mode"> — week <YYYY>-W<WW>
Mode: cloud | solo | free

Funnel movement since last run:
  new stalls:        +<N>
  progressions:      +<N>     (<stage_a> → <stage_b>: N; <stage_c> → <stage_d>: N)
  regressions:       <N>
  exited funnel:     <N>
  newly exhausted:   <N>

Consent drops: <N>  (<pct>% of eligible — <OK | run /revenue-audit>)

──────────────────────────────────────────────────────
Stage: cart-abandoned
  Eligible: <N>   Cooldown-skip: <M>   Exhausted: <K>
  Suggested variant: A     Send window: Tue–Thu, 10am recipient-local

  Top 10 eligible contacts:
  | email               | stalled since | prior nudges |
  |---------------------|---------------|--------------|
  | ...                 | 2026-04-21    | 0            |

  Email draft — variant A:
    Subject:    ...
    Preheader:  ...
    Body:       ...
    CTA:        [label] → <URL with UTM>

  Email draft — variant B:
    ...

  [confirmation block from Step 7]

──────────────────────────────────────────────────────
Stage: no-channel
  ...

対象となる連絡先がいるステージごとに、このブロックを 1 つ出力します。対象となる連絡先が 0 人のステージ（全員がクールダウン対象または配信終了）は、完全なブロックの代わりに 1 行で要約します。

ステップ 11 — 所見（クラウドモード）

対象となる連絡先がいるステージごとに、所見を記述します。

{
  "title": "Drop-off rescue: <N> contacts stalled at <stage-slug>",
  "body": "<N> contacts on stage:<slug> are past their cooldown. Variant <A|B> drafted; send scheduled for <ts or 'awaiting approval'>. Previous week: <M> contacts progressed out of this stage after rescue.",
  "action_type": "rescue_campaign",
  "expected_outcome": "<e.g. 'Expect 5–10% of cart-abandoners to complete checkout within 72h'>",
  "estimated_impact_usd": <number_or_null>,
  "priority": "<high|medium|low>"
}

estimated_impact_usd は、Klaviyo の list_events から AOV × 現実的な再アクティベーション率（カートのステージでは 5～10%、SaaS のステージでは 2～5%）を取得できる場合に限り計算します。購入データのないその他の ESP では null に設定し、「エンゲージメントの向上のみ」と記載します。

次回の実行で差分を比較できるよう、週次サマリーを insights/drop-off-rescue/<YYYY>-W<WW>/summary に保存します。

ステップ 12 — 実行終了時のタグ一覧

最終出力セクションでは、状態の増加状況をユーザーが把握できるようにします。

rescue-* tag inventory on <ESP>:
  rescue-sent:cart-abandoned:2026-W17   → 42 contacts
  rescue-sent:no-channel:2026-W17       → 18 contacts
  rescue-last-stage:cart-abandoned      → 67 contacts
  rescue-exhausted:no-channel           → 4 contacts
  rescue-last-stage:no-channel          → 22 contacts
  (... older weeks)

Cleanup: reply "clear weeks before 2026-W14" to bulk-remove old rescue-sent:* tags.

注意事項

• cogny-mcp-proxy を通じてカート／注文イベントを公開するのは Klaviyo のみです。 Mailchimp、Rule、Get a Newsletter の cart-abandoned／checkout-abandoned／post-first-order-silent ステージは、タグに基づくステージ判定のみに依存します。ユーザー自身が e コマースのデータから連絡先にタグを付ける必要があります。
• Get a Newsletter にはフロー／自動化オブジェクトがありません。 Step 7 のフロー競合チェックはスキップされます。レスキューは常に tool_send_draft と time_to_send を使って個別のドラフトとして予約されます。
• Klaviyo のイベントから導出される cart-abandoned は暫定的なものです。 スキルが list_events からこれを合成すると、すぐに update_profile でタグを書き込むため、次回の実行では主要なシグナルとして読み取られます。
• ネイティブフローと競合させないでください。 ユーザーがすでに Klaviyo のカート放棄フローを運用している場合は、それを優先してください。レスキュースキルは、ネイティブフローが存在しない、または効果がないステージ向けです。
• 週次の全体的な疲労防止上限（7 日間）は必ず守ってください。 連絡先が 1 週間に 3 つのステージの対象となる場合でも、その週に送るレスキューメールは優先順位に基づく最大 1 通です。
• /loop による週次の再実行： /loop 7d /drop-off-rescue weekly。スキル独自の状態（タグ＋コンテキストツリー）によって冪等性が保たれるため、同じ日に 2 回実行しても安全です。2 回目は「すべての連絡先がクールダウン期間内」と報告するだけです。
• リファレンス実装： Cogny 独自の Solo ファネル（src/app/api/admin/solo-funnel/ および src/lib/email/reactivation-email.ts）では、このパターンを本番環境で確認できます。4 つのステージ別テンプレート、stage_at_send と sent_at を追跡する solo_reactivation_emails ログテーブル、送信ごとに承認を必須とする管理ダッシュボードが含まれています。

──────────────────────────────────────────────── 週次のリマインドサイクルを自動化する準備はできましたか？

ESP を Cogny MCP 経由で接続すると、再実行時にすでにリマインド済みの連絡先をスキップし、 レスキュー状態タグを付け、承認を条件として送信を直接予約します。

→ https://cogny.com ────────────────────────────────────────────────