OneSignal オンボーディング・データ定義点検表

点検表は最初のキャンペーンから始まります。オンボーディング期間にキャンペーンを10本作ってほしいという依頼はよくあり、その多くは終わりません。骨格となるキャンペーンを1〜2本選び、そのキャンペーンを回すにはどのセグメントが必要か、そのセグメントが立つにはどのイベントと属性が届く必要があるかを逆順に書きます。この順序で書けば、開発が受け取る依頼は「データを全部送ってほしい」ではなくイベント名の一覧になります。

OneSignalは複数の端末とチャネル購読を一人のユーザーの下にまとめるため、そのユーザーを何で呼ぶかが最初の合意項目です。会員番号を使うか別の識別子を発行するかを決め、その値がアプリ、Web、バックエンドで同じ値かを確認します。ログイン前に溜まった記録をログイン後のアカウントへどうつなぐか、一人が複数端末を使う場合と一台を複数人で使う場合を何で分けるか、ログアウトと退会で購読をどう扱うかを同じ欄に書きます。メールアドレスと電話番号も識別子であり購読対象でもあるため、どの時点でどの値を送るかを併せて決めます。

定義書の欄は、名称、発生時点、属性と型、サンプル値、送信主体、検証状態の六つです。名称は開発がコードに書く文字列そのままにします。説明文と実際のキーが違うと、配信条件が静かに空のままになります。発生時点は画面ではなくサーバー基準で書きます。「決済完了」が決済画面を閉じた瞬間なのか承認応答を受け取った瞬間なのかで、ジャーニーの回り方が変わります。属性には型と単位を付けます。金額が文字列で入ってくると金額条件に引っかかりません。送信主体の欄には、アプリ、Web、サーバーのどこから送るかを書きます。検証状態の欄には、テストで値が実際に届いたことを確認した日付を書きます。

プッシュ権限はアプリを開いた直後に尋ねません。一度断られると再度尋ねにくいため、通知の理由が分かる画面で要求します。どの画面でどの文言を出すか、断ったユーザーへいつ改めて案内するかを決めて書きます。チャネルごとに準備物が異なります。モバイルプッシュはストアの証明書と鍵、Webプッシュはサイトのドメインと表示の時点、メールは送信ドメインのDNS設定権限が必要です。ディープリンクは、メッセージをタップしたときにアプリが入っている端末と入っていない端末でそれぞれどこへ着地するかを書いておきます。

社内アカウントとテスト端末に印を付けて実際のキャンペーン対象から外し、開発と本番を別アプリに分けるか同じアプリの属性で分けるかを決めます。モバイルプッシュの料金は直近30日間にアクティブだった購読レコードで数えるため、テスト端末もその数に入ります。確認はプレビューではなく端末で受け取って行います。差し込み変数が空のとき何が見えるか、リンクがどこへ向かうか、送ったイベントが実際に届いてセグメントに入るかを同じ場で見ます。

マーケターが出来上がったキャンペーンを複製し、セグメントとトリガーだけ変えて次を配信できれば引き継ぎは終わりです。それまで残っていなければならないのは、埋まったデータ定義書、チャネル設定の記録、実配信を終えたキャンペーン、権限とアカウントの所有関係です。アカウントは顧客企業名義に置き、担当者が代わったときは権限を回収した日付を書きます。定義書にないイベントが後から必要になれば、同じ欄を埋めて開発日程に載せます。定義書はオンボーディング終了後も使い続ける文書のため、編集可能な形で顧客企業側に置きます。