判断の出発点
決済直後に「カートに商品が残っています」と通知が来ます。顧客は注文失敗を疑い、CRM担当は購入者を除外したのになぜ送ったか調べます。これは誤配信の仕組みを説明する設計例です。
まずJourneyに入る資格と今メッセージを受け取る資格を分けます。カート作成時に未購入でも待機終了時に未購入とは限りません。購入反映の遅延、購入とカートの顧客・業務対応のずれ、同じイベントによる再参加を個別に調べます。OneSignalのイベント型Journeyは同時参加を許し、ShopifyのWebhookは順序どおりとは限りません。「購入者除外」という設定名だけでは解決しません。[1][5]
購入完了の定義、どのカート案内を終えるか、いつ再確認するかを決め、終了・分岐機能とアプリの配信判断を結びます。ただし直前照会でも外部注文・メッセージングが一つの取引として同時確定するわけではありません。 どこまで防げ、どこから送信済みの可能性があるかを定めます。
購入完了と案内を止める時点は一致しない場合があります
Shopify Classic Webhooksのorders/createは注文作成、orders/paidは支払済みの出来事です。現在の決済状態にはPENDING、AUTHORIZED、PAIDなどがあります。PAIDには自動・手動キャプチャと管理者の支払済み設定も含みます。決済ボタンのクリックや注文作成だけを資金処理完了の証拠にしません。[3][4]
しかしカート案内は決済完了まで送り続ける必要のある内容ではありません。注文受付後の決済中に「まだ購入していない」と案内するのも不適切な場合があります。
この設計例はログイン顧客のオンライン前払い注文に次の方針を選びます。実際の決済・顧客対応に合わせて調整する基準で、ShopifyやOneSignalの既定動作ではありません。
- 該当カートの注文作成または決済中は保留し、購入完了確認後はそのカートの既存案内を終了します。
- 注文・顧客・カートの関係や現在状態が不明なら、未購入とせず保留します。
- 取消・部分返金・全額返金でも終了済み案内は復活させません。新カートや再購入キャンペーンは別条件で判断します。
Shopifyはorders/cancelledとrefunds/createも区別します。後者は返金レコード作成であり、実資金移動とは独立しています。これを未購入への復帰や広告の再許可と解釈する根拠はありません。[3]
判定単位も記録します。顧客UがC1を買っても新カートC2が完了したとは限りません。顧客単位のpurchased=true/false一つでなく、顧客–カート–注文の対応で終了を判定します。接続できない場合は推測で送らず、その顧客の案内を保留します。
顧客の行動に合わせてつながるメッセージ — 顧客段階と行動を条件にチャネルと待機時間をつなぎ、実験結果からジャーニーを調整します。
購入時刻とCRM反映時刻の間に配信が入ります
以下はC1の判断を10時30分に予約した仮定の時系列です。遅延実測値や製品の処理速度保証ではありません。
| 時刻 | 出来事 | 記録で分けるもの |
|---|---|---|
| 10:00:00 | C1候補を作り待機開始 | 参加理由とカートID |
| 10:29:58 | 注文正本に購入完了を記録 | 購入発生時刻 |
| 10:30:00 | 配信処理実行。CRMは未反映 | 判断時刻と読んだ状態版 |
| 10:30:01 | 古い状態で許した要求を事業者が受付・送信開始 | 受付・送信時刻とメッセージID |
| 10:30:02 | 購入Webhookがアプリに到着 | Webhook受信時刻 |
| 10:30:03 | アプリがC1を除外保存 | 内部資格の反映時刻 |
| 10:30:05 | 終了用状態・イベントが基盤に反映 | 基盤反映と実際のJourney終了確認 |
最終行で終了しても先の送信は取り消されません。OneSignal Cancel message APIは予約・送信中メッセージを止めますが、開始後には全受信を防げない場合があると説明します。[10]
10時30分に注文正本を読み購入を確認すれば要求を作らない設計は可能です。逆に照会後、事業者へ渡す直前の購入では競合区間が残ります。照会一回の追加だけで購入後の誤配信ゼロにはなりません。
購入発生、Webhook受信、内部反映、基盤反映を一つの時刻にまとめません。時刻の意味とサーバー時計差を確認し、取得できない値は未確認とします。表の全項目が各基盤に自動記録されるわけではなく、既存ログと追加計測を分けます。
OneSignalの設定と別途の判断を分けます
2026年9月26日確認の公式文書では次の制御を使えます。名称より読むデータと適用箇所を確認します。
| 制御 | 公式機能と範囲 | アプリ・運用に残る仕事 |
|---|---|---|
| 参加・終了・再参加 | セグメントまたはCustom Eventで参加。一般Re-entry rulesはセグメント型、イベント型は再参加を許す。[1] | 同じ出来事の重複参加と新カートの正当な参加を分ける |
| 待機後の再分岐 | Waitは時間待ち、Wait Untilは条件待ち、Yes/Noは所属やメッセージ行動で分岐。[2] | 経過時間を未購入確認に代えず、期限後の経路も決める |
| 該当業務の完了対応 | イベント参加のWait Untilには開始・待機イベント属性を結ぶEvent Matchingがある。[2] | C1完了がC2を終えないよう対応。全Exit ruleの個別対応と解釈しない |
| 他Journeyとの衝突 | タグ・除外セグメントで参加を調整可能。[1][2] | 複数Journeyの同時参照を原子的ロックと考えない |
出典：OneSignal Journey settings・Journey actions。[1][2]
特に購入済みの人が参加・終了条件を同時に満たす場合を試します。最初のステップ後に終了する場合があるため、OneSignalは先頭の待機やセグメント参加の明示除外を案内しています。同じ参加規則にイベントとセグメントを同時併用できるとも考えません。[1]
公式カートチュートリアルはcart_updatedを参加・終了に使い、最新内容で再開する型を示します。再参加フィルターと空カート処理も必要です。購入後に古い更新が届く問題まで、この型一つで解決はしません。[12]
厳密な除外は配信要求を作る場所で判断します
既存Journeyの購入終了、先頭ステップ、識別接続の誤りなら、まずその設定を修正します。すべてのサービスに別配信システムが必要ではありません。
複数注文システムや反復する遅延があり、誤案内削減のため一部の正常配信を見送れるなら、アプリが最終配信要求を所有する方式を検討します。以下は実装方向の設計案です。
候補→注文正本または検証済み最新状態→顧客・カート対応→同意・購読・重複・頻度→許可記録→メッセージAPI
進行中・完了注文は除外、照会失敗・関係不明は保留します。判断時刻、根拠状態、キャンペーン設定版、チャネル、対象を記録します。長く待ったジョブは実行時に再判断します。アプリに移した区間は旧Journeyが別に送らないよう主体を一つにします。
二つの処理が同時に「未送信」と読む場合も試します。顧客・カート・案内段階の権利確認と予約を、重複制約とトランザクションで一度に行います。再試行は新許可を作らず既存記録とキーを再利用します。これは自社配信処理の競合制御で、外部注文の購入をロックするものではありません。
前にJourney webhookを置くだけでは完成しません。公式機能は外部へのHTTP要求であり、応答・次のメッセージ・注文正本までの原子性は確認されていません。別の利用条件も確認が必要です。この関門は自社キュー・スケジューラーとAPIによる別設計で、既定Journeyの自動保証ではありません。[13]
最終照会と外部送信の競合は残ります。 決済中を早く検知して保留し、待機遅延を減らし、不確実なら送らないことで縮小します。ただしShopifyとOneSignalを一つのトランザクションにできない構造で、購入後の全受信停止は約束できません。「最終確認で購入を確認した要求は作らない」と「引渡し済み要求は完全取消できない場合がある」の両方を運用条件にします。
キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。
重複処理・頻度制限・識別は別問題です
Shopify Webhookは逆順・重複になり得て、必ず届くとも限りません。公式文書は欠落補完に定期照合を勧めます。遅い「カートあり」が確定した購入終了を戻さない状態遷移と、欠落購入の正本照会が必要です。[5][6]
受信と配信の重複を別に防ぎます。X-Shopify-Webhook-Idは個別配信重複、X-Shopify-Event-Idは同じ店舗行動からの配信対応に使います。別に顧客・カート・案内段階の配信記録を管理します。イベント重複だけでは別Journeyが同じ目的で送る問題が残るからです。[6]
OneSignal API再試行は同じ論理要求のidempotency_keyを維持します。通知作成キーは30日保存されます。一方Custom Eventsは4時間内のbest-effortで、永続的・厳密な重複排除ではありません。どちらも「今送ってよいか」は判断しません。[7][8]
頻度制限は過剰配信削減の機能です。OneSignalではプッシュが対象で、メール・SMS・アプリ内を含む統合上限ではありません。上限に達した通知は後送用に保存せず破棄します。購入判定や全チャネル優先順位と分けて設計します。[9]
複数端末の同一顧客はサービス顧客IDで判断しますが、配信判断一回と一端末だけの受信は別条件です。一端末なら対象選択規則も必要です。共用端末ではlogoutも確認します。OneSignalモバイルSDKのlogout()は現在のモバイル購読を切り離し、他購読までログアウトはしません。[11]
その呼出しで引渡し済み通知の露出まで解決すると考えません。ロック画面には不要な購入情報を載せず、リンクを開いたら現在アカウントのカート権限を再検証します。チャネル購読と自社マーケティング同意も別に確認し、拒否を他チャネルで自動迂回しません。
正常配信より送るべきでない条件を先に試します
以下は仮定サービスが選んだ方針で、自動保証や完了済み試験ではありません。顧客一人につき有効案内一件、案内段階一回、事前選択の許可チャネル・対象を使います。新カートも既存終了と別途の配信上限を確認して候補にします。
| 例外・入力 | 期待動作 | 主責任 | 確認信号 |
|---|---|---|---|
| 正常未購入・同意と対象有効 | 最終確認を通った一件だけ要求 | CRM・配信開発 | 許可理由、カートID、記録・メッセージID |
| 参加時に購入済み | 最初の要求なしで終了・除外 | CRM・QA | 開始・除外経路、要求未作成 |
| Webhook遅延、正本には購入あり | 最終関門で除外 | 注文連携・配信開発 | 照会結果・時刻・除外理由 |
| 購入を二回受信 | 状態遷移一回、案内再作成なし | データ連携 | 重複ID・業務処理記録 |
| 購入後の古いカートイベント | 終了C1を未購入に戻さない | データ連携 | 発生時刻・状態版・逆行拒否 |
| 最終照会前購入／照会後の競合 | 前者は除外、後者は引渡し状況と残余リスクを記録 | 配信開発・運用 | 照会・要求・購入時刻、取消試行・結果 |
| 二Journeyが同時要求 | 共通配信記録で一件だけ許可 | CRM・配信開発 | 重複予約拒否と選択キャンペーン |
| 同一顧客の複数端末・プロファイル | 顧客で重複防止し選択先だけ使用。不明は保留 | 識別連携 | 顧客–プロファイル–購読と選択記録 |
| 共用端末でA退出後Bログイン | 以後A候補から端末除外、旧リンクのAデータも遮断 | アプリ・QA | 切替、購読接続、リンク権限結果 |
| 待機中の配信拒否 | 最終判断反映済みは除外、引渡し済みは別追跡 | CRM・アプリ | 同意・購読変更時刻、除外・残存送信 |
| 取消・部分・全額返金 | 旧カート案内を再開しない | CRM・注文運用 | 終了維持、新キャンペーン承認 |
| 照会失敗・購入欠落 | 確認まで保留し正本照合で復旧。正常未購入に数えない | 連携運用 | 保留理由・照合作業・未確認件数 |
実試験は所有・許可済みテスト店舗・アカウント・端末で行います。キューで購入を遅らせたり同じテストイベントを再送し、正常経路と比較します。要求未作成、基盤未送信、端末非表示は別の検証結果です。
実データ・観察・再試験はCRMキャンペーンQAシナリオ・結果記録集に残せます。参加・終了・再参加方針の合意にはOneSignal顧客Journey設計ワークブックを使います。
次の配信前に確認する一つの問い
運用中のカート案内を一つ選び、次を問います。
「この顧客が購入したら、どの記録がいつこの配信を止めるか？」
「購入者除外セグメントがある」だけなら、更新時点、顧客・カートの対応、待機済みメッセージへの適用まで追います。設定不足なら既存ツールを直し、遅延や複数経路の衝突なら開発・CRM・QAが同じ時系列で判断します。
誤配信削減に必要なのはJourney数より、明確な終了方針、確認可能な状態、実際に送らなかった証拠です。
設計・実装・検証の責任を合わせて整理する場合は、IXC CRMマーケティング自動化に支援範囲があります。
