OneSignal ユーザー識別・イベント仕様キット

OneSignal Userはユーザープロファイル、Subscriptionは端末やメールなどのチャネル受信単位です。サービスの安定した会員IDをExternal IDとして紐付けると、複数の端末とチャネルの関係を扱えます。内部のuser_id、OneSignalのユーザーID、Subscription IDは別々の項目にします。OneSignal Users

一つの組織に複数人が属する場合、workspace_idをExternal IDに使いません。組織の識別子では個人を区別できないためです。内部会員のuser_idを基準に、組織・招待・作業の関係は業務の相関キーとして管理します。連携ガイドと導入点検表をもとに、既存のログインと会員データの関係から確認します。

認証済み会員の安定したIDが用意できたら、OneSignal.loginでユーザー関係を紐付けます。Web SDKのlogoutは現在のブラウザーの識別関係を解除し、匿名の状態へ戻します。別端末の購読や会員全体を削除する処理ではありません。OneSignal Web SDK reference

サービス登録、SDKのデータ収集設定、マーケティング同意、OSの通知権限、チャネル購読は別の状態です。登録やloginの成功だけで他の状態を許可済みにしません。それぞれの正本、更新担当、配信対象から除外する時点を仕様書に記述します。

アカウント変更中のイベントには、発生時点の会員IDを残します。遅れて処理する際に現在ログイン中の会員で上書きすると、別人の行動になります。退会時にはOneSignalの削除範囲に加え、送信待ちキューと再処理ジョブの担当を定義します。残った連携処理がユーザーを再作成する経路も確認します。OneSignal Delete users

IXC-DEMO-01は、架空のB2B共同作業サービスで、チーム招待を承諾したユーザーに共同作業完了を案内する設計です。会員はusr_demo_01、ワークスペースはws_demo_01、招待はinv_demo_01です。招待サーバーの承諾保存確定をinvitation_accepted、作業サーバーの該当共同作業完了保存確定をshared_task_completedとします。実アカウントへのイベント送信・メッセージ受信テストは未実施です。

この例では、ユーザーごとに有効な招待を一件に制限します。共同作業を作成する際、どの招待から始まった業務かをサーバーに保存します。二つのイベントのuser_id、workspace_id、invitation_idを一致させ、開始と完了を結び付けます。別組織での完了や招待との関係が不明な作業は、この招待の完了に集計しません。

現在のメンバー資格や個人化に使う状態はユーザープロパティ、特定時点の承諾と完了はイベントとします。名前には行動の意味を固定し、組織IDやキャンペーンIDはpropertiesに入れます。OneSignal Custom eventsはイベントと永続的なプロファイル状態を区別しています。全体の流れはジャーニー設計ワークブックにつながります。

内部仕様の共通項目は、文字列のuser_id・workspace_id・invitation_id、事象ごとのUUIDであるevent_id、UTC日時のoccurred_at・received_at、整数のschema_versionです。occurred_atは業務確定時刻、received_atは中継サーバーの受信時刻です。遅延と順序逆転を確認できるよう、発生時刻を受信時刻で上書きしません。

承諾イベントの記入例はname=invitation_accepted、user_id=usr_demo_01、workspace_id=ws_demo_01、invitation_id=inv_demo_01、campaign_id=IXC-DEMO-01、schema_version=1です。event_idは0a16ce21-7e35-4f9e-a5ac-9a331944ab01、occurred_atは2026-09-10T01:00:00Zとします。同じ承諾の再送には同じevent_idを使います。作業完了では、同じ業務関係と新しい事象ID・完了時刻を使います。

OneSignalリクエストのevents配列内で、user_idをexternal_id、occurred_atをtimestamp、event_idをidempotency_keyへ対応付けます。nameはイベント名とし、workspace_id・invitation_id・campaign_id・schema_versionはpropertiesに入れます。received_atは中継サーバーの観測記録に残します。作業本文や招待トークンは、このキャンペーンの判定項目に含めません。Create custom events API

会員IDや招待IDが欠けた入力は、共通の代替値で埋めずに隔離します。同じevent_idが再び届いたら処理記録を参照し、業務を重複実行しません。OneSignalの同じidempotency_keyによる重複抑止は4時間のベストエフォートであり、内部処理記録の代わりにはなりません。HTTP 202にも個別のerrorsが含まれるため、ステータスだけで一括成功にしません。Create custom events APIのエラー・重複処理

完了が承諾より先に到着した場合の期待結果は、完了状態の維持と案内の除外です。遅れた承諾で状態を未完了へ戻してはいけません。timestampを付けただけで順序の問題が解決したとは判断せず、正本の最終状態、発生時刻、受信時刻、処理履歴を照合します。

別組織の完了は現在の業務に影響させません。退会後に残るイベントは送信を止め、整理結果を記録します。ユーザー紐付け失敗から復旧した場合も、現在の完了・同意状態を再評価します。復旧だけを理由に古い案内を直ちに再生しません。

イベントごとに意味、発行主体、必須項目と型、利用するジャーニーと指標、正常・異常例を記述します。期待結果と実際の結果、ログの場所を結び付けます。未実行の試験は未実施とし、確認者と次の作業を残します。ダウンロードPDFと記入用シートの言語は日本語です。

項目の名前・型・意味の変更はschema_versionと変更履歴に反映します。旧版と新版が混在する期間、影響するジャーニー条件と測定クエリ、適用・復帰手順を合意します。CRMキャンペーンQA資料の入力例で検証し、未解決条件をREADY、READY WITH CONDITIONS、HOLDで判定します。

IXCの顧客データ連携設計では、必要なイベントとプロパティを定義し、識別子・イベント送信を実装するか開発チームの実装をレビューします。仕様書から正本と担当、エラー処理、測定ツールの役割、受入試験を協議します。初期SDKの準備はOneSignalオンボーディングにつながります。