Customer.ioとStripe 課金イベント連携とメールジャーニーの考え方
目次 クリックで開く
SaaSやサブスクリプションビジネスにおいて、決済状態と顧客コミュニケーションを同期させることは、チャーン（解約）防止とLTV（顧客生涯価値）向上の生命線です。世界中のスタートアップで採用されているメッセージングプラットフォーム「Customer.io」と、決済インフラのデファクトスタンダード「Stripe」を高度に連携させることで、エンジニアの手を借りずにマーケターが決済イベントに応じた柔軟なメールジャーニーを構築できるようになります。
本記事では、Customer.ioとStripeを実務レベルで連携させる手法と、収益に直結するメールジャーニーの設計思想について、公式ドキュメントの仕様に基づき徹底的に解説します。
Customer.io×Stripe 連携の全体像と方式選択
Customer.ioとStripeを連携させるには、大きく分けて「ネイティブ連携（Direct Integration）」と「データパイプライン/Webhook」を利用する2つのアプローチがあります。
ネイティブ連携（Direct Integration）のメリット
Customer.ioにはStripeとのネイティブな接続機能が備わっています。これを利用すると、Stripe上の「Customer」や「Subscription」のデータが自動的にCustomer.ioのプロパティ（Attributes）として同期されます。最大のメリットは、ノーコードでセットアップが完了し、Stripe側のステータス変更（active, past_due, canceledなど）をトリガーに即座にメールを配信できる点です。
Webhook経由による詳細イベント取得
特定の支払い成功（invoice.payment_succeeded）や、クレジットカード情報の更新（customer.source.updated）など、より粒度の細かい「イベント」をトリガーにしたい場合は、StripeのWebhookからCustomer.ioのData Source（API）へ直接データを飛ばす設計が有効です。これにより、決済に紐づく動的な変数（購入した商品名や正確な決済金額など）をメール文面に挿入しやすくなります。
連携方式の比較（ネイティブ vs Webhook）
| 比較項目 | ネイティブ連携（Direct） | Webhook / Data Pipelines |
|---|---|---|
| 設定難易度 | 非常に低い（APIキーのみ） | 中（イベント定義が必要） |
| 同期されるデータ | 顧客属性、購読ステータス | 課金発生などの特定アクション |
| 主な用途 | セグメント作成、ステータス変更メール | 領収書送付、個別課金トリガー |
| リアルタイム性 | 高い | 極めて高い |
多くの実務現場では、基本的なユーザーセグメント管理には「ネイティブ連携」を使い、詳細なアクション通知には「Data Pipelines」を併用するハイブリッド構成が推奨されます。このデータ統合の考え方は、他のプラットフォームでも同様です。例えば、高額MAツールを使わず、データ基盤から直接メッセージを駆動するアーキテクチャと同様、必要なデータを必要なタイミングで届ける設計が重要です。
【実践】StripeからCustomer.ioへのデータ連携設定ステップ
具体的な連携手順を解説します。作業前に、Stripeの管理者権限とCustomer.ioのワークスペース設定権限を用意してください。
Step 1: Stripe APIキー（制限付きキー）の発行
セキュリティを担保するため、Stripeではフルアクセスのシークレットキーではなく、「制限付きキー（Restricted Keys）」を作成することを推奨します。以下のリソースへの読み取り権限が必要です。
- Customers: Read
- Subscriptions: Read
- Invoices: Read
- Charges: Read
Stripeのダッシュボード（Developers > API keys）から発行したキーをコピーします。
Step 2: Customer.ioでの接続設定
Customer.ioにログインし、Data Pipelines > Sources へ移動します。「Connect Source」からStripeを選択し、先ほど発行したAPIキーを入力します。
ここで重要なのは「どのメールアドレスをキーにするか」です。StripeのCustomer ID（cus_xxx）と、Customer.ioのID（またはEmail）が一致している必要があります。
Step 3: 連携すべき主要なStripeイベント
全てのデータを流すとノイズになるため、以下のイベントを優先的に同期対象とします。
customer.subscription.created: 新規購読開始時customer.subscription.deleted: 解約完了時invoice.payment_failed: 決済失敗（dunning対策に必須）checkout.session.completed: チェックアウト完了時
決済イベントを起点にした「メールジャーニー」4つの鉄板シナリオ
データの同期が完了したら、次は「どのような体験を顧客に提供するか」というジャーニー設計に移ります。
1. 【Churn防止】支払失敗時のリカバリー・ジャーニー
クレジットカードの有効期限切れや限度額オーバーによる決済失敗は、意図しない解約（Involuntary Churn）を招きます。
トリガー: invoice.payment_failed
ジャーニーの構成:
- 失敗直後：カード情報更新をお願いする丁寧なメールを送付。
- 3日後：再試行が失敗している場合、サービスが停止するリスクを強調。
- 7日後：最終通告。支払い方法変更URLを直接貼付。
この際、Stripeが提供する「Customer Portal」へのリンクを活用すると、ユーザーはログイン不要でカード情報を更新でき、離脱率を大幅に下げられます。
2. 【アップセル】トライアル終了直前の有料転換促進
無料トライアル中のユーザーに対して、終了3日前に「あなたのデータはこうなっています。有料版へ移行して継続しませんか？」とパーソナライズされたメッセージを送ります。
トリガー: customer.subscription.updated かつ trial_end プロパティに基づく計算。
ポイント: 既に有料プランを選択済みのユーザーには送らないよう、セグメントの除外条件を徹底します。
3. 【オンボーディング】初回収回完了後の初期設定ガイド
決済が完了した直後こそ、最もユーザーの熱量が高い瞬間です。SFA・CRM・MAを統合した全体設計図でも述べた通り、決済完了（売上確定）をCRMに反映させるだけでなく、即座にMA（Customer.io）を動かして「使いこなしガイド」を送ることが成功の鍵です。
4. 【リテンション】年払いプランへの移行提案
月払いプランを3ヶ月継続している優良ユーザーに対してのみ、2ヶ月分お得になる「年払いプラン」への切り替えを提案します。
セグメント条件:
- Stripe Subscription Status: active
- Monthly Plan: true
- Account Created: 90日以上前
Customer.io内でのセグメンテーションとLiquid活用術
Customer.ioの強みは、取得したStripeデータを「Liquid」というテンプレート言語で自在に加工できる点です。
Liquidを用いた動的表示の例
メール内で「次回の決済日」や「決済金額」を表示することで、情報の信頼性が高まります。
次回の更新日は {{ customer.stripe_subscription_current_period_end | date: “%Y年%m月%d日” }} です。
ご請求金額は {{ customer.stripe_subscription_plan_amount | divided_by: 100 }} 円となります。
※Stripeから送られる金額データは通常「最小通貨単位（日本円ならそのまま、米ドルならセント）」であるため、必要に応じて計算（divided_by）が必要な点に注意してください。
運用上の注意点とトラブルシューティング
実務で必ず直面するトラブルを事前に回避するためのチェックリストです。特にバックオフィスシステムとの整合性は重要です。例えば、Salesforceとfreeeの連携でも問題になる「前受金」や「期間」の概念と同様、Customer.io側でも「いつの時点のデータか」を意識する必要があります。
1. 二重送信を防ぐための「Entry要件」の設計
一度「支払失敗」のメールを送った後、ユーザーがカード情報を更新し、再度失敗した場合にジャーニーが重複して動かないよう、ジャーニーの終了設定（Exit Conditions）と再入場（Re-entry）の制限を正しく設定してください。
2. タイムラグの考慮
StripeからCustomer.ioにデータが反映されるまでに、数秒〜数十秒のラグが発生することがあります。アプリケーション側から送るイベントと、Stripe経由の同期データが競合しないよう、Customer.ioのワークフロー内で「1分待機」のステップを挟むのが実務上のTipsです。
まとめ：決済とコミュニケーションの完全同期を目指して
Customer.ioとStripeの連携は、単なる「メールの自動化」に留まりません。それは、顧客の支払状態という「最も純度の高い行動ログ」を起点に、顧客体験をパーソナライズする収益エンジンを構築することを意味します。
本記事で紹介した手順とジャーニー案を参考に、まずは「支払失敗時の自動リカバリー」から着手してみてください。それだけで、数パーセントのチャーン削減が期待でき、導入コストは即座に回収できるはずです。より詳細な仕様については、Customer.io公式のStripe連携ドキュメントを併せて参照してください。
【補足】実務導入前に確認すべきチェックリストと技術仕様
Customer.ioとStripeの連携を本番運用するにあたり、エンジニアとマーケターが共通認識を持つべき「技術的な仕様」と「運用設計」の補足資料をまとめました。
1. Stripeデータの「通貨単位」と「タイムスタンプ」の変換
Stripeから送出されるデータは、システム処理に最適化された形式になっています。Customer.io側でLiquidを使用して表示する際、以下の変換が正しく行われているか必ずテストしてください。
| 項目 | Stripeの仕様 | Customer.ioでの対応 |
|---|---|---|
| 金額（Amount） | 最小通貨単位（日本円はそのまま、米ドルはセント） | 通貨種別（JPY/USD）に応じて計算式を切り分ける |
| 日付（Date） | Unixタイムスタンプ（例: 1672531200） | Liquidの date フィルタで可読形式に変換 |
| メタデータ | Key-Value形式で最大50個まで保持可能 | Customer.ioに同期するフィールドを個別に指定 |
2. テスト環境と本番環境の分離
Stripeの「テストモード（Test Mode）」で発行したAPIキーをCustomer.ioに接続すると、テスト用の顧客データがワークスペースに混入します。本番環境のワークスペースにテストデータを入れると、セグメントのカウントが狂うだけでなく、誤送信の原因にもなります。必ずCustomer.ioの「Workspace」を本番用と開発用で分け、それぞれに対応するStripeのAPIキーを紐づけるようにしてください。
3. 会計・バックオフィスツールとの役割分担
Customer.ioは「顧客とのコミュニケーション」を最適化するツールであり、売上集計や正式な証憑管理を目的としたものではありません。例えば、月次売上の正確な計上や前受金の管理が必要な場合は、MA側ではなく会計システム側での制御が必要です。このあたりの責務分解については、「とりあえず導入したシステム」が経理業務を圧迫しないための設計を参考に、データが流れる先の整合性を確認してください。
4. 公式リソースと実装リファレンス
設定の詳細やAPIの仕様については、常に最新の公式ドキュメントを参照してください。特にWebhookのシグネチャ検証などは、セキュリティ上の重要事項です。
- Stripe API Reference（Stripe公式・英語）
- Customer.io Data Pipelines: Stripe Source（Customer.io公式・英語）
また、決済データを起点としたCRMの高度な名寄せやID連携については、WebトラッキングとID連携の実践ガイドも併せて確認することで、より解像度の高いジャーニー設計が可能になります。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。