最初のキャンペーンに必要なデータ条件
CRMには顧客も購入イベントも表示されています。しかし「購入から約1か月の顧客に再購入案内を送ろう」とすると、対象の抽出から止まります。購入者をどの会員に結び付けるか、取り消された注文を購入に含めるか、今その人に送ってよいかが不明だからです。
この場合は収集項目を増やすより、一つのキャンペーンの条件を書き、その判定データが同じ顧客に結び付くかを確認することから始めます。イベント、現在属性、ユーザー識別子、端末・購読識別子、受信状態を分けると欠けている箇所が分かります。OneSignalも、ユーザーを表すUserとチャネルごとの接点を表すSubscriptionを区別します。[1][2]
データが準備できても実行できない場合は、機能提供や設定権限を確認します。以下では先にデータ準備度を診断し、その後にOneSignalの実際の提供条件を確認します。別途記載がないフィールド名と再購入シナリオは説明用の設計例です。
名前が似ていてもデータの役割は異なります
設計時には次の質問を別々の欄に置きます。customer_idなどの名称がすべてのツールの共通規格だとは考えません。
| 区分 | 答える質問 | 設計例 | 混同による問題 |
|---|---|---|---|
| イベント | 何がいつ起きたか？ | 購入確定、注文取消 | 購入画面を見た行動を実購入と扱う |
| 現在の顧客属性 | 今はどの状態か？ | アカウント有効、直近の有効購入時刻 | 古い会員ランクや購入時刻で選ぶ |
| ユーザー識別子 | 自社サービスのどのアカウントか？ | 内部会員キー customer_id | 同一人物を複数として数える、別人を統合する |
| 端末・購読識別子 | どの接点に送るか？ | ブラウザー別プッシュ購読ID | 一人の複数接点を同じ購読として扱う |
| 技術的な受信状態 | このチャネルで受信できるか？ | プッシュ購読状態、トークン有効性 | 顧客が存在するだけで配信可能とみなす |
| 目的・チャネル別の配信許可根拠 | この案内をこの顧客に送ってよいか？ | マーケティング同意と変更履歴 | OSの通知許可をマーケティング同意の代わりにする |
OneSignalのTagsはユーザーに付くキー・値の属性で、Custom Eventsは時点のある行動を伝えます。Tagの値は文字列であり、入れ子のオブジェクトや配列をそのまま格納する場所ではありません。注文履歴は元システムに置き、必要な現在値をどのルールで計算・更新するかを定めます。[3][4]
プッシュを受信できることと、広告案内を送る根拠があることも別です。 OneSignalのSubscription Statusはチャネルの受信可能状態を表し、モバイルとウェブプッシュでも解釈が異なります。この値だけで韓国の法的なマーケティング同意要件を満たすかは判断しません。目的・チャネル別の許可基準、撤回状態、確認時刻を別に管理します。[1][2]
キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。
ログイン前後に同じ顧客だと判断する根拠はあるか
識別の接続は登録時の一度の確認では終わりません。以下はウェブサービスの設計例です。モバイルアプリでは利用SDKのログイン・ログアウト動作を別途確認します。
匿名訪問。 誰か不明なブラウザーを特定会員に結び付けません。OneSignalの自動識別子を使っても、すべての匿名訪問者に共通のExternal IDを与えてはいけません。認証済みアカウントの確認後だけ内部会員キーを接続します。内部キー、OneSignalのUser識別子、Subscription IDは別の値として対応関係を管理します。[1][2]
会員ログイン。 OneSignal Web SDKのlogin(external_id)は現在のブラウザーのウェブプッシュ購読をそのユーザーに接続します。ただし既存External IDへの切替では、ログイン前の匿名データは統合されません。初めて接続するExternal IDとは動作が異なるため、「ログインすれば過去の全行動が会員履歴に入る」とは想定しません。[5]
複数端末。 同じアカウントと確認できた接点は同じ内部キーに結び付け、購読IDは個別に保存します。Custom Aliasは他システムの識別子を参照するためのものです。Aliasが一致するだけでは複数Subscriptionは接続されず、External IDが必要です。 アカウントキーはメール・電話番号の不要な露出を避けられる値にします。[6]
ログアウトと共用端末。 Web SDKのlogout()は現在のウェブプッシュ購読を従来ユーザーから切り離し、匿名ユーザーの文脈に変えます。他端末の接続まで切る処理ではありません。AがログアウトしたブラウザーでBがログインした後もAの購入情報が残らないか、旧購読ID宛ての予約済み個別メッセージがないかを検証します。ログアウト、プッシュ停止、アカウント削除を一つの処理と考えないようにします。[5]
会員退会。 OneSignalのUser削除と一つのSubscription削除では範囲が異なります。削除後もアプリ・ウェブの再登録やメール・SMSの再追加でレコードが復活する場合があります。退会時には正本の会員状態を確認し、待機イベント・再試行・再登録が退会アカウントを復活させないようにします。削除応答だけでなく、後続同期後にも完了を確認する設計にします。[7]
最初のキャンペーンの準備度診断表：再購入案内
以下は消耗品の再購入キャンペーンの仮定例です。実際の顧客事例や特定製品の標準機能ではありません。
毎日午前9時にAsia/Seoul基準で対象を確認します。選定時刻をTとし、同じ商品群の直近有効購入から30日以上37日未満の有効会員を候補にします。1日は24時間です。取消・返金で無効になった購入は基準から除外します。ウェブプッシュの受信可能状態と目的別許可を確認し、同じ基準注文への重複配信を防ぎます。この例は顧客ごとに確認済みのウェブ購読を一つ選びます。一人の重複処理防止と、その人の複数接点への同時送信防止は別ルールです。
まず担当者が業務ルールを確定し、各条件の情報源・責任者・送信時点・証拠を以下のようにつなぎます。許容遅延は例のチームが決めた運用目標で、OneSignalのSLAや一般推奨値ではありません。
| 必要なデータ | 目的 | 情報源・担当 | 識別の接続 | 遅延・時点 | 検証方法 | 欠落時の対応 |
|---|---|---|---|---|---|---|
| 購入確定イベント・取消／返金状態 | 有効な基準購入を選ぶ | 注文台帳・注文バックエンド | 注文ID→会員キー | 変更後15分以内の反映目標。選定時に最新の正本と照合 | 同じ注文の金額・商品群・状態・イベント受信を比較 | 購入の有効性が不明な顧客を除外 |
| 直近有効購入時刻・商品群 | 30日以上37日未満の判定 | 注文台帳の計算結果・データ担当 | 会員キー＋商品群 | 候補抽出前に計算し、基準時刻を記録 | 一部イベントでなく台帳の最新購入と比較 | 再計算まで顧客を保留 |
| 会員キーと購読の接続 | 別人への送信防止 | 認証システム・ウェブ開発 | 会員キー→External ID→ウェブ購読 | ログイン・切替結果の確認後に利用 | テストアカウント二つ・ブラウザー二つで接続と分離を検証 | 衝突は保留。推測で統合しない |
| 発生・収集時刻と送信範囲 | 遅延・欠落を未購入と誤認しない | 発行・収集ログ・連携担当 | 情報源＋イベントID | 15分目標とは別に正本照合済み時刻を記録 | 時間帯、欠落、再試行、台帳に対する反映範囲を確認 | 範囲不明なら全候補を確定しない |
| アカウント有効・退会状態 | 無効・退会アカウントの除外 | 会員台帳・会員バックエンド | 会員キー | 対象確定前に最新正本を確認 | 状態変更と同期後の再登録を点検 | 最新状態の確認まで除外 |
| ウェブプッシュ購読状態 | 利用できる配信接点の選択 | 購読状態・チャネル連携 | 購読ID→現在ユーザー | 確定時に最新確認値を使い変更を反映 | テストの許可・拒否・接続解除状態と照合 | 状態不明の接点を除外 |
| 目的・チャネル別の同意・撤回 | この案内の許可根拠 | 同意台帳・個人情報／CRM担当 | 会員キー＋目的＋チャネル | 確定前に確認。撤回判明後は同期待ち中も送らない | 現在状態、変更時刻、取得経路を正本と比較 | 根拠不足・衝突なら配信禁止 |
| キャンペーン処理・配信履歴 | 同じ基準注文の重複実行防止 | 実行台帳・CRM運用 | キャンペーンID＋会員キー＋基準注文ID | 再試行・再実行前に照会し重複防止 | 同じ候補を再処理するテストの結果を確認 | 不明なら再送せず手動確認 |
注文データの「15分」は処理を監視する目標です。15分前の状態だけで今送ってよい意味ではありません。 確定時の正本状態が確認できなければ、確定を延期するか確認できる対象だけを残します。配信直前の購入・撤回変更とJourneyの例外には別の実行制御が必要です。
準備度を平均点にまとめないことも必要です。八項目中七つを通過しても、残りが会員接続や配信許可なら実行できません。「連携率が高い」ではなく、何を根拠に判断し、何が不明なため誰を除外したかを記録します。
データがないことと購入していないことは異なります
再購入キャンペーンでは過去購入に加え、その後にもっと新しい有効購入がないことも確認します。送信が途切れた期間のイベント欠落を「未購入」とみなすと、データ障害を顧客行動と取り違えます。
以下は製品機能ではなくキャンペーンの設計基準です。発生時刻は業務の出来事が起きた時点、収集時刻は収集層が受け取った時点とします。2026-09-26T09:00:00+09:00と2026-09-26T00:00:00Zは同じ時刻です。00:07:00Zで収集したなら差は420秒です。時間帯付き表現はRFC 3339で統一できます。ただし元の時計が誤っていれば差にも誤差が出るため、時計異常を別に確認します。[8]
内部仕様のoccurred_atやreceived_atは説明用名称です。送信先の実フィールドに対応付ける必要があります。OneSignal Custom Eventにはtimestampやidempotency_keyなどがあり、内部名を追加しただけでは同じ意味で処理されません。[9]
重複は出来事のIDで確認します。同じ購入イベントの再送ではIDを維持しますが、その注文の取消は別イベントです。CloudEventsもsourceとidの組合せで識別します。購入・取消・返金のすべてに注文ID一つを重複排除キーとして使わないようにします。[10]
受信順序が変わる場合は、遅れて届いた過去イベントが現在状態を戻さないかを確認します。最後に届いた値で上書きする代わりに、正本のバージョンや最新照会結果で判断します。欠落は当該期間の注文台帳と照合し、遅延イベントの再投入でも処理済みかを確認します。
スキーマ変更では名前の管理だけでは不足です。「購入完了」の意味が決済承認から配送完了に変われば、同じ名前でも30日の計算が変わります。意味・型・許容値・発行時点の変更を承認する責任者とバージョンを残し、新旧が同時に入る場合の処理を決めます。
チャネル接続からキャンペーンと引継ぎまで — SDKとチャネルを設定し、主要キャンペーンを検証して、社内担当者が継続できる形で引き継ぎます。
OneSignalの送信・保存・対象化を別々に確認します
OneSignalではデータ準備度に製品条件を加えます。2026年9月26日確認の公式文書によれば、Custom Event収集には有料プランが必要です。受信してJourneysなどに使うことと、保存して過去行動のセグメントや履歴を照会することは異なります。保存機能は段階提供中のため、実際のアプリで使えるかを確認します。[11]
保存は有効化した時点から始まり、保存期間を延ばしても有効化前の記録は復元されません。公式文書の上限は90日で、保存量の制限もあります。このキャンペーンでは必要な購入期間を実際に照会できるかを確認します。CRMに履歴がなくても、注文元システムで対象を計算し既存経路で渡す代案があります。過去イベントの再送はJourneyを再開する可能性があり、単純な履歴復元とは扱いません。[11][12]
API応答も確認します。Create Custom Events APIはHTTP 202と同時に個別イベントのerrorsを返すことがあります。ユーザー特定に失敗したイベントが混ざっていても、ステータスコードだけの記録では見落とします。同じidempotency_keyの重複抑止は4時間のbest-effort処理であり、保存期間全体の完全な重複排除と解釈しません。[9]
SDKの導入だけでは、注文確定の業務的意味やサーバーの返金状態まで自動連携された証拠にはなりません。SDK・API・連携ツールのどこからCustom Eventsを送るかを決め、複数経路が同じ出来事を送るなら重複処理の責任を合意します。[12]
分析ツールのイベントはどこまで再利用できるか
GA4の購入イベントを再利用するとします。GA4のUser-IDは自社サービスが一貫した値を設定し、purchaseのtransaction_idはユーザーではなく取引を識別します。イベント名や件数が同じというだけでは、CRM会員に接続済みとはいえません。[13][14]
「どのアカウントのどの注文がいつ確定したか」を元データまで追います。既存計測の意味が正しければ維持し、CRMへの送信経路と識別子対応を別に確認します。分析画面の総購入件数の比較だけでは足りません。取消、匿名訪問、アカウント切替を含むテスト記録も正しい顧客に結び付くことを確認します。
準備不足なら保留・対象縮小・手動検証を選びます
すべてのデータ接続まで何もできないわけではありません。ただし都合のために識別衝突や配信拒否を迂回してはいけません。以下を実行判断基準として提案します。
| 選択 | 条件 | 次の行動 |
|---|---|---|
| キャンペーン保留 | 顧客接続の衝突、許可根拠不明、退会・撤回未反映、正本の反映範囲不明 | 原因と責任者を定め、確認できるまで配信しない |
| 対象縮小 | 一部接点・集団だけ不完全で、残りは全必須条件を独立して検証可能 | 検証済み顧客・チャネルだけ残す。個別化用の付加属性がなければ表現は省けるが、必須条件は省かない |
| 手動検証後の限定実行 | 小規模で正本が正確、担当者が実配信対象全員の条件と最新状態を確認可能 | 抽出基準、確認時刻、承認者、重複確認結果を記録。一部標本だけで全員を承認しない |
再購入案内のために氏名・電話番号・注文原文全体をCRMへ複製する必要はありません。会員キー、商品群、基準購入時刻、状態、根拠参照から決め、用途のない項目は送りません。同意原文と詳細履歴は責任を持つ元システムで管理し、CRMには必要な判定値と参照だけを渡せます。保存期間と閲覧権限も項目別に定めます。
正本と責任者が明確で最初の範囲が小さければ、既存照会と統制された対象抽出から始められます。別の顧客データ基盤や新収集ツールを先に追加する必要はありません。一方、複数システムが同じアカウントや同意状態を別々に解釈するなら、拡大前に接続規則と運用責任を整理します。
診断を実装仕様に移す際は、OneSignalユーザー識別・イベント仕様キットを利用できます。この表は「今実行できるか」を判定し、仕様キットは確定ルールを開発・検証項目に整理するためのものです。
最初のキャンペーンの準備完了基準は項目数ではありません。顧客ごとの包含・除外理由を説明でき、その判断の正本・確認時刻・担当者を特定できる状態です。一つのキャンペーンに必要なデータから接続・検証し、その後に広げます。
システム別の正本と実装責任を合わせて整理する支援が必要なら、IXCの顧客データ連携設計に公開の支援範囲があります。
