モバイル アプリケーションのプッシュ通知、SMS、電子メールに関するベスト プラクティス
このポストは、12 月 11 日に投稿された Best practices for using push notifications, SMS and email in your mobile app の翻訳です。
今年 10 月、モバイル サービスに iOS クライアント ライブラリを追加して以来、iOS のプッシュ通知のサポート予定時期について、たくさんのお問い合わせを頂いておりましたが、Scott Guthrie が今週水曜日にブログ (英語) (日本語訳 : NOKI SATO ブログ Windows Azureモバイル サービスのiOSサポート – プッシュ通知サポートを追加 に掲載しています。) で発表したように、このたび、モバイル サービスで iOS プッシュ通知のサポートが開始されました。また iOS クライアント API の改良に伴い、より簡単なログイン メソッドが追加され、たった 1 行の Objective-C コードでユーザー認証を構成できるようになりました。
今回のアップデートにより、モバイル サービスは Windows ストア アプリ、Windows Phone 8 アプリ、iOS アプリを完全にサポートするようになりました。
3 つのプラットフォームにおいてサポートされるユーザーとの通信手段には、プッシュ通知、Twilio 経由の SMS、SendGrid (英語) 経由の電子メールといった、3 つのチャネルがサポートされています。そこでこの記事ではまず、iOS プッシュ通知の基本について説明した後、どの手段がどういった用途に適しているかについて一般的なガイドラインを紹介します。
iOS プッシュ通知の構成の基本
プッシュ通知を使い始めるにあたって必要な情報はすべて、Scott のブログ記事 (英語) (日本語訳 : NOKI SATO ブログ Windows Azureモバイル サービスのiOSサポート – プッシュ通知サポートを追加 に掲載しています。) に既に記載されているため、重要なポイントを 2 つ挙げます。
1.モバイル サービスでは、プッシュ通知を驚くほど簡単に送信できる。
2.期限切れのデバイスやチャネルに対するフィードバックを処理するツールをポータルで提供。無効なトークンのデータベースを定期的に排除することで、アンインストールしたアプリケーションに通知を送信せずに済み、コスト抑制が可能です。
モバイル サービス チームの Josh Twist による、新機能のデモ動画は原文内でご確認ください。
モバイル デベロッパー センターでは、2 つのチュートリアルが公開されています。1 つ目のチュートリアル (英語) は、iOS アプリにプッシュ通知を構成して送信する基本の手順について、もう 1 つのチュートリアル (英語) では、テーブルを使用して APNS トークンを保存し、アプリケーションのユーザーにプッシュ通知を送信する方法について詳しく説明しています。
APNS オブジェクトを使ってプッシュ通知を送信する方法についての詳細は、参考資料 (英語) を参照してください。
プッシュ通知、電子メール、 SMS 、それぞれの用途
プッシュ通知を使用する方法はもちろん、プッシュ通知、SMS、電子メールをどういった用途で使い分けるか理解することも同じく重要です。一言で言ってしまえば、最適な手段はアプリケーションによって異なります。
しかしもう少し掘り下げて、ベスト プラクティスとして採用している一般的なガイドラインとその例外をいくつかご説明します。他にも独自のベスト プラクティスをご存じの方がいらっしゃいましたら、ぜひコメント欄に投稿してくださるようお願いします。また、改善案などのご意見もお待ちしております。
プッシュ通知: 標準的な既定のチャネル
プッシュ通知は、スマートフォンやアプリケーションを念頭に置いて開発されています。ユーザーとつながる、最も強力かつ効率的な通信手段です。
ここで気をつけなければならないのは、多くのユーザーが最初のうちはプッシュ通知を許可していても、その強力さゆえ負担となり、すぐに無効に設定してしまうおそれがあることです。
プッシュ通知を無効にされる危険性の高い例
- 実際に招待した友人や普段からやりとりのある友人に限らず、Facebook の友人がサインアップするたびにアラート通知を送信するような、ソーシャル コンポーネントを含むアプリケーション
- 興味のないトピックであっても、カテゴリに新しい記事が公開されるたびにバッジ通知の数値が増えるような、ニュース アプリケーション
- 関心のないユーザーを対象としたセールス用のあらゆる通知 (真っ先に無効にされてしまいます)
トースト通知のベスト プラクティス
- 短く、簡単な内容にすることが重要です。小さい画面に表示するということに留意しながら、なるべく省略せずに収まるようにしましょう。トースト通知画面に表示される内容だけで、情報を明確に伝える必要があります。
やむを得ず省略された内容のトースト通知でも、それだけでアプリケーションを開くメリットをユーザーに十分伝えられる場合は例外です。強い興味を引くティザー広告的なものであれば省略を活かさない手はありません。その最たる例が Facebook 投稿のトースト通知です。
- 特定の動作を行う、または行わないきっかけとなる内容を明確に通知します。To-Do アプリなどのシンプルな通知であっても、「新しいタスクがあります。 “牛乳 1 ガロンを購入” が追加されました」と表示するより「To-Do: “牛乳 1 ガロンを購入”」とする方が、はるかに分かりやすいでしょう。
バッジ通知のベスト プラクティス
- 3 回以内のジェスチャ (タップ、スワイプなど) で、バッジの数値に関連した操作を実行して数値をリセットできるようにします。
- バッジ通知に表示させる数値を制限します。チャット コンポーネントを含むゲームを例に考えてみましょう。ゲームのアップデート数と、ゲーム内チャットの受信した新規メッセージ数の両方がバッジの数値に加算されてしまうと、何を意味する数字なのか分かりにくくなってしまいます。
- バッジの数値が 2 桁にならないようにします。いったん 2 桁に達すると、ユーザーはアプリケーションを開かなくなり、すぐにアンインストールするとは言わないまでも、プッシュ通知を無効化してしまいやすくなります。
しかし、メール アプリは例外です。バッジの数値が 10 を超えることは日常茶飯事であり、100 を上回ることも決して珍しくありません。膨大な未読メールがある状態は、ユーザーにとって長年見慣れた光景であり、違和感はないようです。開発したアプリケーションがそれほど長い歴史を持っていない場合は、やはりバッジの数値は多くなりすぎないほうがよいでしょう。
SMS: 必ず読んでほしいメッセージ
アプリケーションに SMS を使用する方法は無数に存在します。Twilio には Doers (英語) という開発者集団があり、シンプルな SMS がさまざまな用途に利用できることを証明しています。ただ、ユーザーとの通信チャネルとしての SMS という観点に絞ってみると、SMS は、必ず読んでほしいメッセージを送信する場合のみに限定する必要があります。SMS は無効にすることができず、同じくアンインストールされる危険性を高めてしまうためです。使用するときには、慎重に検討しなければなりません。
電子メール: 基本コンテンツおよび重要コンテンツ
電子メールは、SMS と同様に、最新のアプリケーションにおいて多種多様な使い方があり、SendGrid (英語) を使用する開発者は、日々そうした場面に遭遇しています。ユーザーとの通信手段としての電子メールに焦点を合わせてみると、1 つのシナリオが浮かび上がってきます。何日、何週間、何か月が経っても、ユーザーが内容をさかのぼって探せるようにしたいコンテンツを送信する場合に、電子メールは有効です。
確認メッセージや認証成功通知は、もちろん当てはまります。また、スクラブルのようなワード ゲームの最終ステージで、最高得点を打ち出したときのスクリーン ショットも電子メールがふさわしいでしょう。ですが、アプリケーションへ友人を招待するリクエストは、おそらく適切ではありません。
Uber は、この特性をうまく利用しました。新しい領収書が発行されると、トースト通知ではなく、利用明細と併せて電子メールで送信します。領収書は、再確認する可能性の高いコンテンツであるため、電子メールは非常に相性が良いと言えます。
モバイル サービスの利用を検討中で Windows Azure をまだお使いでないお客様は、Windows Azure の 90 日間の無料評価版をぜひご利用ください。共有インスタンスで 10 個のモバイル サービスを無料で実行することができます。
Windows Azure モバイル デベロッパー センター (英語) にて、モバイル サービスを活用したアプリケーション開発に関する各種資料がご覧いただけます。
ご意見、ご感想がございましたら (またはアプリケーションを披露したい開発者の方も)、Windows Azure モバイル サービス チーム (mobileservices@microsoft.com) までメールにてお送りください。
ご質問はフォーラムまで、機能に関するご要望はモバイル サービス ユーザーの声ページ (英語) までお寄せくださるようお願いします。
また、私の Twitter アカウント @kirillg_msft にもぜひご意見をお寄せください。