アプリプッシュ 自前実装・ツール導入の判断ガイド

FCMとAPNsはそれ自体が配信インフラです。アプリにSDKを入れて端末トークンを受け取り、サーバーから呼び出せば通知はそのまま届きます。この構成だけで足りるサービスは少なくありません。送るメッセージが注文状況や予約確認のように取引に紐づいていて、受け取る人がその取引の当事者一人に既に決まっていて、送る時点が事象の起きた瞬間であれば、ツールが代わりにやることはほとんどありません。宛先も時点もコードの中で決まるからです。全体告知をたまに一件出す程度も同じです。この範囲でツールを載せると費用は増え、変わるものはありません。判断の出発点は機能一覧ではなく、いま送っているメッセージの性格です。この範囲は売り手の側からはあまり語られません。自前実装のままでよいという答えが相手の利益とぶつかるためです。検討を始める前に、この線は自分で引いておくほうが確実です。

判断は数えるところから始まります。直近三か月に出した通知を三つに分けます。取引に紐づく通知、サービス告知、マーケティング配信です。それぞれ月に何件出たか、宛先を誰が決めたか、失敗したとき誰が気づいたかを同じ表に書きます。マーケティング配信の欄が空で前の二つだけが回っているなら、今の構成が合っています。三つとも埋まっていて宛先を決める役がすべて開発なら、その表がすでに答えを出しています。ここでもう一つ書き添えます。出した通知のうち人が選んで送ったものと、事象が自動で出したものの比率です。前者の比重が増えている最中なら、その流れは戻りません。

限界はある日機能が足りなくなって来るのではありません。仕事の進み方に先に出ます。兆候はおおむね五つです。第一に、送る対象を決めるたびに開発者がデータベースに条件を書いて一覧を抜きます。第二に、送ったあと何人に届いて何人が押したかに答えられません。第三に、深夜に出ないようにする規則や同じ人へ一日何件までという規則がコードのあちこちに散らばっています。第四に、無効になったトークンを消して送り直す処理を自前で書いて維持しています。第五に、プッシュで始めた仕事がウェブプッシュとメール、アプリ内メッセージへ広がります。一つだけなら、まだ手を入れられます。三つ以上が重なれば、次の四半期も同じ依頼が同じ形で繰り返されます。

トークンはアプリを削除したり長く開かなかったりすると無効になり、再インストールで新しく発行されます。無効なトークンを残したままだと配信成功率が実態からずれ、失敗応答を読んで整理する処理がなければその値は膨らんだままです。一人が端末を二、三台使えば同じ通知が二、三回届きます。人単位でまとめる識別子を置かなければ、この重複を止める場所がそもそもありません。ログアウトと退会で購読をどう扱うか、権限を拒否した利用者をどこに記録するかも同じ場で決める必要があります。そこへOSとストアの通知ポリシーが変わるたびに追随する仕事が加わります。これらは機能要求として上がらないため、日程表にも載りません。自前実装の実費が最初の実装工数を数える場でいつも抜け落ちるのはそのためです。

キャンペーンを一本出すために対象条件を渡し、一覧を受け取り、文面を確認し、配信を依頼すると、実際に出るまで数日かかります。その数日のせいで、やろうとしたキャンペーンの半分は始まりもしません。ツールを買う判断の本当の根拠が機能ではなくここにあることは珍しくありません。ところがこの値は誰も数えないので稟議書に載りません。前の四半期に依頼した配信が何件あったか、それぞれ依頼から配信まで何日かかったか、そのうち中止になったり時期を逃したりしたものが何件かを書けば、その表は見積書より正確な判断材料になります。逆にその表を書いてみて依頼が四半期に二、三件なら、いまはツールを買う時期ではありません。リードタイムはツールを載せれば自然に消えるものでもありません。マーケターが自分で作る条件に必要なデータが入っていなければ、依頼はツールの画面の前でまた開発へ戻ります。そこでこの表には、依頼ごとにどのデータがなくて止まったかも併せて書きます。

第一は課金の単位です。アクティブな利用者数を数える方式と配信量を数える方式は、同じ規模でもまったく違う値を出します。アプリのインストールが増えるサービスとメール配信が増えるサービスでは、見るべき軸そのものが違います。第二はセグメントが成立するかどうかです。ツールがどれほど良くても、利用者の属性と行動イベントが入ってこなければ条件は組めません。導入工数の半分はツールではなく、このデータを送るアプリとサーバーの側にあります。第三は自動化の深さです。開始条件と待機、分岐、終了条件を画面で決められなければ、マーケターは結局また開発者を呼びます。第四はアカウントとデータの所有です。アカウントが自社名義で開かれるか、設定と検証の結果が契約終了後も残るかを契約前に確認します。

FCMとAPNsはツールを載せても消えません。ツールはその上に載る層で、実際の配信は引き続きプラットフォームが担います。ですからストア証明書と配信用資格情報の管理、アプリで権限をいつどの画面で尋ねるか、トークンを人に結びつける識別子の設計は、ツールを買っても自社の仕事として残ります。ツールが肩代わりするのは対象の抽出と配信履歴、頻度と時間帯の制御、チャネルの拡張です。この境界を導入前に引いておかないと、ツールがやってくれると思っていた仕事が数週間後に開発のバックログへ戻ってきます。見積もりを受け取るとき、境界を文章にして確認してもらうほうが早く済みます。アプリ更新が必要な項目も同じ場で分けておきます。ストア審査を待つ項目が混じっていれば、導入日程はその周期に縛られます。

第一はトークンと受信同意です。既存SDKが持つ購読情報を保ったまま移せるか、移せずに利用者へ権限をもう一度尋ねる必要があるかで、移行費用は何倍にも変わります。第二は今動いている配信条件です。コードに散らばった条件をセグメントとトリガーに書き直す作業は移設ではなく再構築です。何がどの条件で出ているかを誰も全部は把握していない状態でこの作業が始まることがよくあります。第三はディープリンクです。通知を押したとき、アプリが入っている端末と入っていない端末がそれぞれどこへ着地するかの仕様が変わります。第四はストア証明書と配信用資格情報です。これらを新しいツールへ登録する権限を誰が持っているかを確かめておかないと、切り替えの週に配信が止まります。

自前実装とツールは二者択一ではありません。取引に紐づく通知はサーバーが直接送り、マーケティング性の配信だけをツールへ移す構成は実際によく採られます。このとき決めることは一つです。受信同意と頻度制限を最終的にどちらが判定するかです。二つの経路がそれぞれ判断すると、拒否した利用者に通知が出て、一日一件の規則が二倍で破られます。判定する場所を一か所に決め、もう一方はその結果を尋ねてから送る形にすれば、この構成は長く保ちます。分けるときはチャネルも併せて分けます。同じチャネルを二つの経路が使うと、成果の数字がどちらのものか読めなくなります。

見るのは三つです。第一に、ツールの契約と実装を同じ先が担うかどうかです。ライセンスだけを売る先はSDK連携とイベント設計から手を引き、実装だけを行う先はプランと契約条件に答えられません。第二に、自社のアプリとサーバーのコードにどこまで手を入れるかが範囲として書かれているかどうかです。イベントを仕込む作業が見積もりになければ、その作業は結局社内の開発日程に戻ってきます。第三に、終わったあと何が残るかです。イベントと属性の定義書、チャネル設定の記録、実際に配信まで終えたキャンペーンが自社のアカウントに残ってはじめて、担当が替わっても同じ作業を買い直さずに済みます。IXCはOneSignalという一つのツールでこの領域を担います。FCMの自前運用からの移行も取扱範囲に入り、国内契約とウォン建て決済、税金計算書の発行も同じ窓口で処理します。