Frank van Puffelen
エンジニア

本記事では、Firebase Database、Cloud Messaging、Node.js を使用して Android 端末間で通知を送信する方法を説明します。

Firebase Database は、マルチユーザー モバイル アプリケーション構築のためのすばらしいバックエンドです。複数のユーザーがアプリケーションを開いていれば、あるユーザーによる変更はすべての接続中のユーザーにミリ秒以内に同期されます。


チャット アプリケーションがその良い例です。あるユーザーが送信したメッセージは即座に他のユーザーに同期されるため、たいへんスムーズな使用感を実現できます。

しかし、Android 端末上でアプリを実行していないユーザーはどうなるでしょうか。その場合、端末は Firebase Database サーバーに接続されていないため、変更を自動的に受信することはできません。通常のチャット メッセージの場合はそれでも大丈夫ですが、ほとんどのチャットアプリで @ をつけて誰かを呼び出すときは、そのユーザーを引き戻したいことがほとんどでしょう(例: 「@puf ちょっといいかな?」)。

通常、そのような場合は、Firebase Cloud Messaging を使ってそのユーザーの端末に通知を送ります。このような通知は端末の通知エリアに表示され、何かおもしろいイベントが起こったときにユーザーをアプリに引き戻す手段となります。



本記事では、Firebase Cloud Messaging を使って端末に通知を送信してみます。API キーを Android 端末に公開しなくてもいいように、FCM と通信する Node スクリプトを記述します。しかし、まず最初に、Android 端末から通知を 送信 するコードがどのようなものかを理解しましょう。

Android アプリからプッシュ通知を送信する

ユーザーに通知を送信するには、Android アプリで次のようにします。
sendNotificationToUser("puf", "Hi there puf!");
sendNotificationToUser() メソッドは、次のように実装されているヘルパー メソッドです。
public static void sendNotificationToUser(String user, final String message) {
    Firebase ref = new Firebase(FIREBASE_URL);
    final Firebase notifications = ref.child("notificationRequests");

    Map notification = new HashMap<>();
    notification.put("username", user);
    notification.put("message", message);

    notifications.push().setValue(notification);
}

おそらく、これは予想とは異なるものでしょう。このコードは、通知データをデータベースに書き込んでいるだけです。これでどうやって通知を送信しているのでしょうか。
実は、通知の送信は行っていません。ここでは、データベースをキューとして使用しています。Android アプリは通知を送信するリクエストをデータベースに書き込みます。それを Node スクリプトがピックアップして、Cloud Messaging 経由で通知を送信します。そのスクリプトは後ほど見てゆきます。まずは、このアプリのデータ構造について少しお話ししましょう。

データ構造

他のアプリケーションと同じく、Firebase をバックエンドとしたアプリケーションでもデータ構造は特に重要な部分の 1 つです。通知を送信するためのデータ構造は既に見ています。
  notificationRequests
    $pushid
      message: "Hello there"
      username: "puf"

これが Android アプリが書き込んだノードです。各通知リクエストは、送信するメッセージと通知対象のユーザー名で構成されています。ユーザー名を実際の通知にどのようにマッピングするかは、アプリケーションによって異なります。この場合は、トピックベースの通知を使用します。つまり、ユーザー名は/topics/user_ というトピックにマッピングされます。この場合、メッセージは /topics/user_puf に送信されます(Android アプリは、このトピックをサブスクライブします)。
では、先ほどお話しした Node コードを見てみましょう。

Node コード

ここまでで、Android アプリからデータベースに通知リクエストを書き込む方法と、データベース構造がどのようなものかがわかりました。それでは、実際に通知を送信するコードを書いてゆきます。
これは、先ほど確認した通知キューを監視する Node プロセスになります。このキューに子供が追加されるたびに必要な情報を取り出し、Cloud Messaging REST API を呼び出して通知を送信します。処理が成功した場合、キューから通知リクエストを削除します。

var firebase = require('firebase');
var request = require('request');

var API_KEY = "..."; // Your Firebase Cloud Server API key

firebase.initializeApp({
  serviceAccount: ".json",
  databaseURL: "https://.firebaseio.com/"
});
ref = firebase.database().ref();

function listenForNotificationRequests() {
  var requests = ref.child('notificationRequests');
  ref.on('child_added', function(requestSnapshot) {
    var request = requestSnapshot.val();
    sendNotificationToUser(
      request.username,
      request.message,
      function() {
        request.ref().remove();
      }
    );
  }, function(error) {
    console.error(error);
  });
};

function sendNotificationToUser(username, message, onSuccess) {
  request({
    url: 'https://fcm.googleapis.com/fcm/send',
    method: 'POST',
    headers: {
      'Content-Type' :' application/json',
      'Authorization': 'key='+API_KEY
    },
    body: JSON.stringify({
      notification: {
        title: message
      },
      to : '/topics/user_'+username
    })
  }, function(error, response, body) {
    if (error) { console.error(error); }
    else if (response.statusCode >= 400) {
      console.error('HTTP Error: '+response.statusCode+' - '+response.statusMessage);
    }
    else {
      onSuccess();
    }
  });
}

// start listening
listenForNotificationRequests();
child_added イベントをリッスンしているため、キューの各通知リクエストに対して sendNotificationToUser() が呼び出されます。送信が成功すると、キューからリクエストを削除します。今回の単純なスクリプトでは、自動リトライは行っていません。そのため、スクリプトを再起動した場合のみ、失敗した通知がリトライされます。もう少し拡張性があるアプローチをとる場合は、firebase-queue ライブラリの使用を検討してください。

スクリプトに API_KEY 定数が含まれていることにお気づきかもしれません。これは、メッセージを送信するために Firebase Cloud Messaging から取得したキーです。まさにこの点が、Android アプリでこのコードを実行しない理由です。API キーがわかれば、そのアプリの名前でメッセージを送信することができるので、悪用される可能性があります。このキーをサーバー上の Node スクリプトで保持することによって、Android アプリのユーザーがキーを入手できないようにしています。

Android アプリで通知を受信する

Firebase Cloud Messaging SDK が通知メッセージを扱う方法のおかげで、Android のコードは最低限で済みます。アプリがバックグラウンドで動作している際に通知メッセージを受け取ると、システム通知エリアにメッセージが表示されます。ユーザーがメッセージをクリックすると、アプリが自動的に開きます。こういった形でアプリを再び開いてもらうことは、まさにこのアプリで実現したかったことです。そのために行う必要があるのは、Firebase Messaging ライブラリをインクルードしてユーザー名のトピックをサブスクライブすることだけです。

トピックのサブスクライブ


あるユーザー宛てのメッセージを識別するために、ユーザー名に一致するトピックを使用します。

String username = "puf";
FirebaseMessaging.getInstance().subscribeToTopic("user_"+username);

この部分はアプリに依存する処理であるため、このスニペットではユーザー名をハードコードしています。しかし、一度ユーザー名さえ決まってしまえば、通知の登録に必要なのは 1 行のコードだけで済むことはわかるでしょう(あとは、アプリがバックグラウンドである場合に通知を表示する部分だけです)。
アプリがフォアグランドである場合に通知の処理を行いたい場合や、メッセージとともに他のデータも送りたい場合は、Firebase Cloud Messaging とメッセージ タイプのドキュメントをご覧ください。

まとめ


本記事では、Firebase と Node スクリプトを使用して Android アプリにプッシュ通知を送る方法を説明しました。今回は Android コードから通知を送信しましたが、Firebase Database にアクセスできる他のアプリケーションからも同じように簡単に送信することができます。iOS サポートを追加することも簡単で、依存性を追加してリモート通知用の登録を行うだけです。


Posted by Yoshifumi Yamaguchi - Developer Relations Team


Daydream Labs では、VR を使ったソーシャル インタラクションの実験を行っています。実際の現実世界と同様に、VR の中でも、人は本質的に誰かと何かを共有したり、つながりを感じたいものです。Daydream Labs のデベロッパーやデザイナーは、楽しく簡単に使えるソーシャル エクスペリエンスを構築できることを楽しく思っています。しかし、関わるすべての方にとって安全で快適であることも同じくらい重要です。昨年を通して、人々を好意的なソーシャル エクスペリエンスに向かわせるいくつかの方法がわかってきました。

明確なソーシャル ルールがなければどうなるか

人々は VR エクスペリエンスの限界に興味を持っており、それを試したくなるでしょう。たとえば、マルチプレイヤー型のアプリやゲームに参加した人は、手が他人の頭を通り抜けるかどうか、別のアバターの体の中に立つことができるかどうか、といったことに疑問を抱くかもしれません。たとえ悪意がなかったとしても、こういった行動によって他の人々は危険を感じたり、不快な思いをするかもしれません。
たとえば、HTC Vive 向けに作った買い物の実験があります。この実験では、2 人の人がバーチャル店舗に入り、いろいろな帽子、サングラス、アクセサリーを試着することができました。仮想アクセサリーの配置方法や配置場所には何の制限もなかったため、友人の目のすぐ前など、帽子がくっつくことができるあらゆる場所にくっつけようとする人がいました。これでは、視界が妨げられて不快な思いをすることになってしまいます。コントローラを使って目から帽子を取り除くことができなければ、ヘッドセットを外して VR 体験を終了するしかなくなります。



ユーザーの安全性の確保

VR では、すべての人が安全で快適であるべきです。他人のアクションが予想できれば、否定的なソーシャル活動が始まる前にそれを思いとどまらせることができるかもしれません。たとえば、それぞれのユーザーのまわりに個人スペースを作成することによって、他人が個人スペースに侵入してくることを防ぐことができます。

実験で、ポーカーゲームをする場所を作成し、荒らし行為を思いとどまらせる新しい方法を試しました。誰かがポーカー卓を離れた場合、その人の環境は白黒になり、アバターは他のプレイヤーの視界から消えます。個人スペースを青く光るバブルによって示すことで、席に戻る方法がわかるようにしました。これによって、プレイヤーが相手に近づいてチップを盗んだり、個人スペースに侵入することを十分防げることがわかりました。




好意的な行動に対する報酬

たとえば、ハイタッチ 🙌 のような好意的な行動をとってもらうには、インセンティブを与えてみるとよいでしょう。ある実験で、2 つの別のアバターがお互いの手にすばやく「触れる」ことを検知しようと試みました。その際に大きな音を出し、花火のアニメーションを表示しました。これはシンプルなものですが、とても好評でした。一方で、アバターの体を殴るなど、これより攻撃的なことをしても、何も起こらないようになっています。どちらの動作が人々に好まれるかは想像できるでしょう。




Posted by Takeshi Hagikura - Developer Relations Team


Andrew Brogdon
Mobile Ads 担当 DPE

Firebase が統合モバイル プラットフォームになったことにともない、モバイル デベロッパーは新しい Gradle アーティファクトと CocoaPods から Mobile Ads SDK をインポートできるようになりました。それによって、各プラットフォームにインポートするいくつかの代替手法が使えるようになっています。皆様からリクエストをいただきましたので、どれが私たちのお勧めであるか、それぞれにどのライブラリが含まれているかについて、少しばかりの情報をお伝えしたいと思います。それでは、1 項目ずつ見ていきましょう。

Android & Gradle


firebase-ads(推奨)

プロジェクトに Mobile Ads SDK を導入する方法としては、これが一番お勧めです。firebase-ads アーティファクトを使用すると、AdMob、DFP、AdX、ビルトイン Firebase Analytics で広告をロードして表示するために必要なすべてのものがそろいます。firebase-crashfirebase-config のように、使用したい Firebase サービスのクライアント コンポーネントが他にもあれば、それを追加することもできます。Firebase なしで SDK のみを使いたいなど、特別なニーズがなければ、これが一番簡単です。
firebase-ads を使って AdMob の準備をして動作させる方法をスクリーンキャストで見たい場合は、次の Firecasts シリーズのエピソードをご覧ください。


play-services-ads

Firebase を使わない方は、Mobile Ads SDK を含むこの Gradle アーティファクトをご利用ください。AdMob、DFP、AdX のクライアント コードを入手できますが、Firebase サービスは含まれていません。

play-services

Firebase が含まれていない完全な Google Play サービス クライアントです。これには、Mobile Ads SDK に加えて、Maps、Drive、Fit などのすべての Google Play サービス SDK が含まれています。おそらく、Play サービスで提供されている すべての API を使うことはないと思うので、個別にインポートを行う方がよいでしょう。たとえば、モバイル広告と Play ゲームが必要な場合は、play-services-adsplay-services-games だけを含めます。

play-services-ads-lite

SDK チームは、特定のユースケースのために、新しい Gradle アーティファクトを開発しました。これに含まれるのは Mobile Ads SDK をスリム化したもので、Google Play サービスがインストールされている端末上でだけ動作するように設計されています。アプリのサイズを削減することが非常に重要になる場合、これによって Mobile Ads SDK の影響を最低限にとどめることができますが、Play サービスに対応していない端末では広告のロードや表示ができなくなります。このトレードオフは、アプリのインストール ベースをよく理解した上で検討してください。詳細については、Lite SDK ガイドをご覧ください。

iOS & CocoaPod


Firebase/AdMob(推奨)

AdMob と Mobile Ads SDK 用の Firebase CocoaPod です。「AdMob」という名前がついていますが、この pod からは DFP と AdX 用の iOS クライアント コードもインストールでき、この 3 つのソースとビルトイン Firebase Analytics で広告をロードして表示するために必要なすべてのものがそろいます。この CocoaPod は、Firebase/CrashFirebase/Database などのアプリに必要な他の Firebase の pod とも簡単に組み合わせることができます。ほとんどのデベロッパーには、この方法がお勧めです。
Firecasts シリーズには、Firebase/AdMob を使って AdMob と Firebase をアプリにインポートする方法を説明しているエピソードがあります。詳しくは、次のスクリーンキャストをご覧ください。


Google-Mobile-Ads-SDK

Firebase を使っていないデベロッパーの方には、Mobile Ads SDK だけを含むこの pod をご利用ください。AdMob、DFP、AdX から広告を表示するために必要なすべてのものを入手できますが、Firebase サービスは含まれていません。

GoogleMobileAds

これは CocoaPods 経由で Mobile Ads SDK をインポートする別の古い方法ですが、現在は推奨されていません。Firebase を使わない場合は、Google-Mobile-Ads-SDK がお勧めです。

詳細情報


Firebase や、Firebase を使い始める方法などについて質問がある場合は、Firebase サポートページをご覧ください。たくさんの役立つ情報が掲載されています。Mobile Ads SDK 自体について技術的な質問がある場合は、SDK サポート フォーラムをご覧ください。


Posted by Khanh LeViet - Developer Relations Team

Android 7.0 Nougat

今週から Nexus 端末のユーザーへの Android 7.0 Nougat のロールアウトが開始されています。また、Android 7.0 のソースコードを Android オープンソース プロジェクト(AOSP)にプッシュして、この新バージョンの Android を幅広いエコシステムに公開いたします。

ここ数か月にわたり、今回のリリースに関して皆様からいただいたフィードバックをもとに、ユーザーが Nougat 端末で皆様のアプリをいつでも実行できるよう作業を進めてきました。

Nougat に含まれる機能

Android Nougat には、世界中のたくさんのファンや皆様のようなデベロッパーからの声が反映されています。Android Nougat には、Android での VR モードなど、250 以上の主要な機能が搭載されています。Nougat では、Android スタックのすべてのレベル、具体的には、オペレーティング システムによるセンサーデータの読み取りから、ディスプレイにピクセルを送る方法にまで手が加えられており、高品質モバイル端末 VR 体験の実現に特化した作りになっています。

さらに Nougat には、Android を今まで以上に強力にし、生産性やセキュリティを向上させる多数の新機能も追加されています。新しい JIT/AOT コンパイラを導入して、ソフトウェア パフォーマンスの向上、アプリ インストールの高速化、および消費ストレージの削減を図りました。また、低オーバーヘッド、高パフォーマンスの 3D グラフィック用クロス プラットフォーム API である Vulkan がプラットフォームでサポートされるようになっています。マルチ ウィンドウ サポートによって 2 つのアプリを同時に実行できるようになり、アプリを開かずに直接通知に応答できるダイレクト リプライも導入されました。今までと同様、Android は何層もの強力なセキュリティと暗号化によって作り上げられており、プライベートなデータをプライベートな状態で保つことができるようになっています。それによって、Nougat ではファイルベースの暗号化、シームレスなアップデート、ダイレクト ブートなどの新機能が実現できるようになっています。

詳細な動作の変更点や、アプリで使うことができる新機能など、すべての Nougat デベロッパー リソースはこちらから参照できます。デベロッパー向けの新機能の概要は、こちらからご覧いただけます。また、Nougat の新しいユーザー機能は、こちらからすべてご覧いただけます。

Android Nougat のマルチ ウィンドウ モード
Android Nougat のマルチ ウィンドウ モード

次にアップデートされるユーザー

本日(*原文公開当時)以降数週間をかけて、Nexus 6、Nexus 5X、Nexus 6P、Nexus 9、Nexus Player、Pixel C、General Mobile 4G(Android One)に Android 7.0 Nougat への OTA ソフトウェア アップデートがロールアウトされます。Android ベータ版プログラムに登録している端末も、この最終版を受信します。

また、Android Nougat を搭載したたくさんの魅力的な端末がパートナーから発売されます。Android Nougat をすぐに使うことができる最初の新しいスマートフォン LG V20 もその 1 つです。

このような新しい端末で Nougat が動き始めるため、今こそ Google Play でアプリのアップデートを公開する絶好のタイミングです。API 24 を対象にコンパイルを行うことをお勧めします。まだ最終的な変更に対するテストを行っている場合、Google Play のベータ版テスト機能を使うのがお勧めです。まずは Android 7.0 Nougat のユーザーを含む少人数のユーザーから初期段階におけるフィードバックを得て、その後、アップデートしたアプリを段階的にユーザー全員にリリースすることができます。

Nougat のこれから

Nougat は、これから数四半期にわたる新たな定期メンテナンス スケジュールに移行します。最初の Nougat メンテナンス リリースに向けた作業はすでに開始されています。このリリースには継続的に行われている調整や改善を反映する予定で、秋には Developer Preview を提供したいと考えています。ご期待ください。

Developer Preview ビルドに対して報告されたバグでまだ未対応のものは、まもなく対応が完了する予定です。しかし、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.0 に対して新しく問題を送信してください。

プレビューに参加いただいた皆様、どうもありがとうございました。プレビュー版は、今回新たにリリースする Android バージョンを強化する機会をすべての皆様に提供したいと考え、今年の初めに公開いたしました。皆様の継続的なフィードバックは、ユーザーだけではなく、Android エコシステム全体にとっても非常に貴重なものであり、この最終リリースの仕上げを行う上でとても役立ちます。

Posted by Yuichi Araki - Developer Relations Team


Posted by Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook



Posted by Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook


Autotrack は analytics.js と合わせて使用するために作られた JavaScript ライブラリで、現在のモダンなウェブに関連する一般的なユーザー インタラクションをトラッキングする幅広いプラグインを提供するものです。

analytics.js 用の Autotrack の最初のバージョンは今年初めに Github でリリースされ、その後のデベロッパーの反応と採用は驚くべきものでした。プロジェクトのスターは 1000 個を超え、Autotrack を使用しているサイトは毎日数百万件のヒットを Google Analytics に送信しています。

本日(*原文公開当時)はうれしいことに、Autotrack バージョン 1.0 のリリースを発表することができます。これにはいくつかの新しいプラグインや既存のプラグインの改善、そして皆様のニーズに応えるために Autotrack をカスタマイズするたくさんの方法が含まれています。

注: Autotrack は公式な Google Analytics 製品ではなく、Google Analytics 360 のサポート対象にはなりません。Autotrack のメンテナンスは Google Analytics デベロッパー プラットフォーム チームが行っています。また、Autotrack は主にデベロッパーを対象としています。


新しいプラグイン

ここ数か月でデベロッパーから受け取ったフィードバックやさまざまな機能リクエストに基づき、以下の新しい Autotrack プラグインを追加しました。

Impression Tracker

Impression Tracker プラグインを使うと、ブラウザのビューポート内に要素が表示されたことをトラッキングできます。これによって、特定の広告やアクションにつながるボタンがユーザーの画面に表示されたかどうかを確実に判断できるようになります。

従来から、ウェブのインプレッション トラッキングは実装が難しいものでした。特に、サイトのパフォーマンスを悪化させないトラッキングは困難でした。このプラグインは、そういった種類のインタラクションを高パフォーマンスでトラッキングするためにデザインされた新しいブラウザ API を活用します。

Clean URL Tracker

URL を変更せずにページビューを Google Analytics に送信するようアナリティクスを実装している場合、レポートに同じ場所を指す別々のページパスが現れるという問題を経験することになるでしょう。以下に例を示します。
Clean URL Tracker プラグインを使うと、お好みの URL 形式(末尾のスラッシュの削除、index.html ファイル名の削除、クエリ パラメータの削除など)を設定し、Google Analytics に送信する前にプリファレンスに基づいて自動的にすべてのページの URL をアップデートすることでこの問題を回避します。

注: Google Analytics に送信する URL は、Google Analytics のビュー設定でビュー フィルタを設定することでも変更できます。


Page Visibility Tracker

ウェブサイトにアクセスしてから、未使用のブラウザのタブで何時間、場合によっては何日もページを開きっぱなしにするユーザーも珍しくなくなってきています。ユーザーがサイトに戻ったときにページをリロードすることはほとんどありません。サイトがコンテンツをバックグラウンドで取得するようになっていればなおさらです。

デフォルトの JavaScript トラッキング スニペットだけで実装している場合、この種のインタラクションをトラッキングすることはできません。

Page Visibility Tracker プラグインは、ページビューを認識するためにモダンなアプローチを利用します。これによって、ページのロードだけでなく、ページの可視性の変化(タブがバックグラウンドになったり、フォアグランドになった場合)もトラッキングできるようになります。こういった追加インタラクション イベントによって、ユーザーがサイトでどのように行動しているかをさらに詳しく分析できるようになります。

アップデートと改善

Autotrack に追加された新しいプラグインに加え、既存のプラグインにもいくつかの大きな改善が行われています。最もわかりやすいのは、ニーズに合わせてプラグインをカスタマイズできる機能です。

Google Analytics にデータを送信するすべてのプラグインは、どのフィールドを送信するかを 100% 正確に制御できるようになっています。また、送信したくないものを削除することもできます。これによって、高度なユーザーはヒットに対して独自のカスタム ディメンションを設定したり、インタラクション設定を変更して直帰率を測定する方法を改善することができるようになります。

以前のバージョンの Autotrack からアップグレードするユーザーは、アップグレード ガイドの完全な変更点リストを参照してください(注: 以前のバージョンと互換性のない変更もあります)。

Autotrack の利用効果が期待されるサイトとは

Autotrack を最初にリリースしてから一番多く受けた質問は、どのようなサイトで最も利用効果が期待できるかという質問かもしれません。とりわけ、さらに高度な Autotrack 機能を使用したい Google Tag Manager ユーザーは、そのような疑問を持つことが多かったはずです。

Autotrack は、Google Analytics で高度なトラッキング技術を活用して効率化を図りたいデベロッパー向けのプロジェクトであり、主にデベロッパーを対象としたものです。既にウェブサイトで analytics.js を使用している、またはコードで実装しているトラッキングの管理を改善したい小規模から中規模のデベロッパー チームには適するでしょう。

複雑なコラボレーションやテストが必要となったり、Google Analytics が対応していないタグ付けを行う必要がある大規模なチームや組織は、Google Tag Manager の利用をご検討ください。現在 Google Tag Manager は Autotrack に含まれるようなカスタムの analytics.js プラグインをサポートしていませんが、同じトラッキング技術の多くは Tag Manager のビルトイン トリガーを利用すると簡単に実現できます。また、その他の機能も、サイトのカスタムコードに基づくデータレイヤー イベントや Google Tag Manager のカスタム HTML タグをプッシュすることで実現できる可能性があります。Google Tag Manager ヘルプセンターの Google Analytics イベントをご覧いただくと、クリックやフォームの送信に基づく自動イベント トラッキングについて詳しく学ぶことができます。

次のステップ

現在 Autotrack を利用しておらず、新しく使ってみたいという方は、ドキュメントのインストールと使い方のセクションを参照してください。既に Autotrack を利用しており、最新バージョンにアップグレードしたいという方は、まずアップグレード ガイドをご覧ください。

Google Analytics のデモとツールのサイトには、Autotrack 利用データを示すレポートがいくつか掲載されているので、Autotrack でどのようなデータを取得できるかについてイメージを得られます。さらに理解を深めたい場合は、Autotrack ライブラリを直接参照してください。これはオープンソースで、学習に役立つ、優れたリソースです。プラグインのソースコードにひととおり目を通せば、そこで analytics.js の高度な機能が利用されていることが理解できるでしょう。

最後に、この機能に関するフィードバックや提案があれば、遠慮なくお知らせください。バグや問題点は、Github から報告できます。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

[トップゲーム/アプリの保持率の時間経過を示すグラフ]

3. ピンポイント オファーによって購入客へのコンバージョンを増加させる

プレイヤーが初回購入を行うと、以降の離脱率は大きく下がり、費やした時間によらず比較的一定の割合で推移するようになります。そのため、購入客への最初のコンバージョンは最重要です。また、過去の購入にまつわる行動から、将来の購入をかなり正確に予測することもできます。初回購入客や有料購入客へのコンバージョン率は、デベロッパー コンソールから直接確認できます。 
たとえば、Kongregate のゲームである Spellstone では、30 日にわたって毎日少しずつプレイヤーにシャード(プレミアム通貨)を渡すというシャードボットと呼ばれるプロモーションにおいて、2 種類の価格を設定しました。それによって、プレイヤーは高価な価格パックの方を好むことがわかりました。最初のパックであるシャードボットは 4 ドルで毎日 5 シャードを提供、2 つ目のパックであるスーパー シャードボットは 8 ドルで毎日 10 シャードを提供しました。



[収益性の高い高価なパックが好まれるという結果を示す 2 週間のテスト結果]


どちらのパックも似たような保持率を示す結果となりましたが、Kongregate は高価な方のスーパー シャードボットの販売を継続することにしました。

4. どのような収益化機能を実装するかと合わせて、なぜ、いつ、どうやってそれを行うかも考慮する

[BattleHand のスターター パックのオファー例]
強力なプロモーションのおかげで、50% 以上のプレイヤーが通常のジェムのオファーではなく、スターター パックを購入するようになっています。
[Raid Brigade のボックスでのランダム報酬の例]
[Adventure Capitalist の時間制イベントの例]

この取り組みの後、イベント未開催期間には影響を与えることなく、イベント開催時のリピート率と収入が定期的に上昇するようになりました。

[時間制イベントによって、時間経過による平均ベースラインが低下することなく、リピート率と収入が大幅に向上]

5. 地域の価格と価格モデルを考慮する

人が異なれば支払いに対する考え方が異なるように、マーケットが異なれば購買力も異なります。
ドル未満の価格戦略を採用することによってゲームの収入を 3 倍に改善したゲーム デベロッパー Divmob の Android デベロッパー ストーリーをご覧ください。また、何十億人のユーザーに向けたアプリやゲームを作成するためのベスト プラクティスをご覧いただくと、さらに収益化のヒントを得ることができます。 
Playbook for Developers アプリを入手すると、Google Play のビジネスを成功させる最新の機能やベスト プラクティスに常にアクセスできるようになります。


Posted by Yoshifumi Yamaguchi - Developer Relations Team
Share on Twitter Share on Facebook




Michael Bleigh
エンジニア
本番環境へのデプロイはいつも神経を使うものです。新しいバージョンのサイトに見つけられなかったバグがあったら何が起こるでしょうか。Firebase Hosting の 1 クリック ロールバックを使えば、動作していた最終バージョンに戻すことができますが、そもそもそれで問題が確実に起こらなくなると言えるでしょうか。

答えは簡単です。ミラーリングした本番環境でサイトのテストを行えばよいのです。うれしいことに、Firebase CLI を使うと複数環境のセットアップやデプロイを簡単に行うことができます。


新しい環境の追加

Firebase CLI では、firebase use というコマンド 1 つで環境を追加して切り替えることができます。

最初に firebase init で Firebase Hosting プロジェクトをセットアップするときに、アプリをどのプロジェクトにデプロイするかを指定します。これがデフォルトのプロジェクトになります。use コマンドを使うと、別のプロジェクトを追加できます。

$ firebase use --add

このコマンドを実行すると、既存のプロジェクトを 1 つ選ぶよう求められます。
$ firebase use --add
$ ? Which project do you want to add? (Use arrow keys)
  my-production-project
> my-staging-project
  my-dev-project

別の環境として使いたいプロジェクトを選択し、それに別名をつけます。この別名は何でも構いませんが、"development"、"staging"、"production" といった別名をつけるのが一般的です。
$ firebase use --add
$ ? Which project do you want to add? (Use arrow keys)
  my-production-project
> my-staging-project
  my-dev-project
? What alias do you want to use for this project? (e.g. staging) staging
Created alias staging my-staging-project.
Now using alias staging (my-staging-project)

新しく別名をつけたものが、デプロイの対象となるカレントの環境になります。firebase deploy を実行すると、アプリをその環境にデプロイできます。

環境の切り替え

別の環境に切り替えたい場合は、別名を指定して use コマンドを実行します。
$ firebase use default # sets environment to the default alias
$ firebase use staging # sets environment to the staging alias
コマンド内で -P フラグで環境を指定することもできます。
$ firebase deploy -P staging # deploy to staging alias

とても簡単

これだけで Firebase Hosting を使って環境を切り替えることができます。セットアップについてのガイドが必要な場合は、スクリーンキャストをご覧ください。フィードバックをお待ちしています。


Posted by Khanh LeViet - Developer Relations Team
Share on Twitter Share on Facebook



ぜひ今すぐお試しいただき、どれだけのことができるようになるかご覧ください。


すべてのデベロッパーの皆様、デベロッパー プレビューを今すぐお試しください!

以上からもわかるように、Android アドオンは画期的な統合アプリを作成し、世界中の Docs や Sheets のユーザーに使っていただく大きなチャンスになります。Android アドオンは、基本的にはサーバーサイドの Google Apps Script プロジェクトに接続された Android アプリです。これによって、標準の Apps Script 技術を使って Google Docs や Sheets のデータにアクセスしたり、それを操作することが可能になります。簡単に開発を始めることができる UI ガイドラインサンプルコードが含まれているドキュメントもご覧ください。Apps Script エディタでアプリを公開することも簡単にできるようになっています。

Android アドオンは、デベロッパー プレビューとして本日から利用可能です。皆様が作るアプリを楽しみにしています。


Posted by Yoshifumi Yamaguchi - Developer Relations Team
Share on Twitter Share on Facebook

皆さんのアプリのリリースを楽しみにしています。

著者の画像

Peter について: オープン ビーコン フォーマットの Eddystone や、ビーコン技術とファースト パーティやサード パーティのアプリを結びつける Google のクラウド サービスを担当する Google ビーコン プラットフォームのプロダクト マネージャー。Google で働いていない時は、飼い犬のオスカーとハムステッド ヒースを散歩している。


Posted by Takeshi Hagikura - Developer Relations Team
Share on Twitter Share on Facebook

例 1: APK の新しい「ダウンロード サイズ」の表示


例 2: APK の新しい「アップデート サイズ」の表示


ダウンロード サイズを減らすためのヒント

1. 正しいサイズ計測のための最適化: ユーザーは、ダウンロード サイズ(アプリのインストールやアップデートでどのくらいのバイトが転送されるか)やディスクサイズ(アプリがどのくらいのディスクを使用するか)を気にしています。このどちらもが元の APK ファイルサイズと同じではなく、相関性があるとも限らないことを知っておくことが重要です。


Chrome の例:
圧縮済みのネイティブ ライブラリ 未圧縮のネイティブ ライブラリ
APK サイズ 39 MB 52 MB(+25%)
ダウンロード サイズ(インストール) 29 MB 29 MB(変更なし)
ダウンロード サイズ(アップデート) 29 MB 21 MB(-29%)
ディスクサイズ 71 MB 52 MB(-26%)


Chrome では、APK のネイティブ ライブラリを圧縮していないので初回ダウンロード サイズは同じですが、Google Play ではダウンロード用の圧縮が既に行われているため、APK のサイズは増加しています。未圧縮ファイルでは差分の効率が上がっているためアップデート サイズが減少し、圧縮済みネイティブ ライブラリをコピーする必要がなくなっているためディスクサイズも減少しています。

2. APK サイズの減少: 使用されていないリソースやコードなど、不要なデータを APK から削除します。

3. APK の構成要素のサイズを減らすことによる最適化: たとえば、JPEG ではなく WebP を使用するなど効率的なファイル形式を使ったり、未使用コードを削除するために Proguard を使用したりします。
APK サイズの削減についての詳細情報はこちらをご覧ください。また、I/O 2016 セッション「アプリをダイエットする」を見て、Wojtek Kaliciński がどのように APK サイズを削減しているかを学ぶこともできます

Posted by Yoshifumi Yamaguchi - Developer Relations Team
Share on Twitter Share on Facebook


Todd Kerpelman
デベロッパー アドボケート

Firebase Dynamic Links を使うと、iOS と Android の両方で動作する 1 つのリンクを生成し、アプリ内のコンテンツへのディープリンクを簡単に共有できます。このリンクは、App Store や Google Play でアプリのインストールを行っても、そのまま動作できます。ダイナミック リンクはメールやソーシャル メディアのキャンペーンなど、さまざまな用途に活用できます。強力な活用方法の 1 つとして、アプリ内のコンテンツを友だちと共有できることがあげられます。たとえば、ゲームであれば、Firebase Dynamic Links を使用してあるレベルのリプレイを共有し、プレイヤーが友人とスコアを競い合うことができます。


アプリを見つけてもらう効果的な方法の 1 つは依然として口コミであるため、このようなユーザー間の共有はとても効果的です。しかし、ダイナミック リンクを生成してユーザーが簡単に SMS やメールのメッセージとして友だちに送れるようにするには、かなりの作業が必要になります。ほとんどのデベロッパーの皆さんは、こういった作業よりもアプリの構築などの他の作業に時間を使いたいと思うでしょう。

Firebase Invites が生まれた背景には、SMS やメールでダイナミック リンクを共有する作業を切り出し、それをデベロッパー向けに効率化するという考え方があります。現在、いくつかの事例で Firebase Invites が実際に使われ始めています。ここでは、Firebase Invites をうまく利用し、その魅力を今まで以上に引き出すためのヒントをいくつか紹介します。

特別なものを共有する

Firebase Invites は Firebase Dynamic Links の上に構築されています。そのため、ユーザーは特定のディープリンク情報を友人と共有することができます。つまり、招待を受け取った方は、アプリのホーム スクリーンではなく、クリックした招待に関連づけれられたエクスペリエンスによってアプリの利用をすぐに開始できます。

このメリットを活用すると、一般的な「このアプリを友だちと共有」機能を構築できるだけではなく、アプリについての特定の情報を確実に共有できるようになります。エクササイズ アプリなら、最後に行ったトレーニングやジョギングのルートを友だちと共有できるようにしましょう。紹介コードを使って相乗りをサポートするアプリなら、そのコードを友だちと共有できるようにしましょう。

このような考え方にしたがって、共有プロセスを始めるためのボタンなどをユーザーが共有したいコンテンツの近くに置くようにします。設定メニューのどこかに一般的な共有オプションを置くだけでは、使用頻度やインストール率は大きく改善することはないでしょう。逆に、ジョギングのルートや紹介コードなど、ユーザーが共有したいものの近くに「これを共有!」ボタンを置けば、ユーザーは共有に対して一層魅力を感じるはずです。

メールのカスタマイズ

Firebase Invites から招待メールを送る場合、Play Store や App Store に掲載されているアプリの情報を直接取得してメールにその画像やテキストを自動的に設定することができます。もちろんこれはとても便利な機能です。わずか数行のコードで、多彩な内容がきれいに整形されたメールを作ることができるからです。

一般的なアプリ共有機能として Firebase Invites を使うのであれば、これで十分かもしれません。しかし、先ほどお勧めしたような特定のコンテンツの共有に Firebase Invites を使う場合、Android の setEmailHtmlContent メソッドで送信メールの内容をカスタマイズすることができます。これによって、ユーザーは任意の HTML を送信メールのメッセージとして使えるようになり、ユーザーが共有しようとしているコンテンツに密接に関連したメールのメッセージを表示できるようになります。

たとえば、Yummly は Firebase Invites を使ってユーザーが特定のレシピを友人と共有できる機能を強化しています。クライアント側で送信メールをカスタマイズできるため、すべての受信者はそれぞれのレシピの詳しい説明や画像を受け取ることができます。あらかじめ関連性の高い情報が提示されるので、受信者は強い興味を持つようになります。それによって、標準の Firebase Invite のメールを使う場合よりも積極的にアプリを利用してもらえるようになるでしょう。

さらに、Firebase App Invites とともに Remote Config を使うと、さまざまな内容のメールをすばやく繰り返して試すことができます。送信メールのテキストをアプリにハードコードするのではなく、Remote Config に接続してそこから取得できるようなアプリにすれば、アプリをアップデートしなくても新しいメールを試してみることができます。少しばかりの実験によって、どのようなメールの内容にすれば最も説得力があるかを突き止めることができます。

iOS ユーザーへの適切なサポート

Firebase Invites を理解する際に重要になる 1 つの制限があります。Android ユーザーはいつでも招待の送信や受信ができ、iOS ユーザーも自由に招待を受信することはできますが、iOS から招待を送信する場合は、ユーザーが Google にログインしている必要があります。

多くのデベロッパーは、これはあまり問題になることはありません。なぜなら、デベロッパーログインを推奨しており、Google はとてもよく利用されるプロバイダであるからです。しかし、ログインの必要性がないアプリや、Google へのログインをサポートしていないアプリもあるでしょう。そのような iOS アプリでは、Firebase Invites はあまり魅力的に感じられないかもしれません。多くのデベロッパーは、この時点で「まあいいか。Firebase Invites は Android アプリだけでサポートしよう」と考えてしまいがちです。

このアプローチで問題になるのは、Android 端末で招待の送信がサポートされていると、ユーザーは iOS ユーザーも Android ユーザーも含め、すべての友だちに招待を送信しようとすることです。iOS 側で招待を読み込むために使う Firebase Invites ライブラリが利用できないと、対応するディープリンク データ(およびすべての Firebase Invite 機能)は失われてしまいます。

そのため、iOS で招待を送信する機能をサポートしない場合でも、招待を受信する機能はサポートすることをお勧めします。そうすることによって、iOS ユーザーが招待を受信した際にすべてのディープリンク情報を取得し、共有を受ける機能をフル活用できるようになります。

共有にあたっての注意

ほとんどすべてのアプリには、ゲームのクールなリプレイ、おもしろい写真、紹介コードなど、共有することでメリットが生まれるコンテンツが存在します。皆さんのアプリ開発の ToDo リストのどこかには、「ユーザーが(何かの)コンテンツを友だちと共有できるようにする」という項目が載っており、余った時間があればすぐにでも実装したいと考えていることでしょう。

Firebase Invites を使えば作業の大半が削減できるので、その項目を「そのうち検討」から「すぐに対応可」の区分に変えることができます。少なくとも、少しばかりの作業で実現できるようになります。ぜひ、Firebase Invite をお試しください。また、ドキュメントや招待を行うにあたってのベスト プラクティスもご覧ください。


Posted by Khanh LeViet - Developer Relations Team
Share on Twitter Share on Facebook