[go: nahoru, domu]

この記事は Arudea Mahartianto、Google AMP スペシャリストによる Google Developers Blog の記事 "Google Developers Blog: How to set up Analytics on your AMP pages" を元に翻訳・加筆したものです。元の記事は Google アナリティクス ブログに投稿されました。詳しくは元記事をご覧ください。 

デジタルの世界では、忠実な読者向けの話を書いている方、ファンが愛するクリエイティブなコンテンツを作成している方、デジタル コミュニティを手伝っている方、お客様にアイテムやサービスを提供している方など、どのような方にとっても、対象者を理解することがすべての中心になります。そのために鍵となるのは、対象者を計測してその行動を理解するためのツールにアクセスできるかどうかです。Accelerated Mobile Pages(AMP)は、ページを高速に読み込めるようにすることに加え、パフォーマンス面で妥協する必要のない複数のアナリティクス オプションを提供しています。

AMP では、単純なトラッキング ピクセルとして動作する amp-pixel のようなソリューションを選択できます。amp-pixel はさまざまな変数置換を利用できる単一の URL なので、とても柔軟にカスタマイズできます。詳細については、amp-pixel のドキュメントをご覧ください。

一方、amp-analytics コンポーネントは、さまざまなイベント トリガーを認識し、特定の指標についての情報を収集できる強力なソリューションです。amp-analytics は複数のアナリティクス プロバイダがサポートしているため、amp-analytics を使って複数のエンドポイントやデータセットを設定することができます。AMP は、すべての計測データを管理して指定されたデータを作成し、アナリティクス ソリューション プロバイダと共有します。

amp-analytics を使用するには、ドキュメントの <head> にコンポーネント ライブラリを含めます。
<script async custom-element="amp-analytics"

src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>

そして、次のようにコンポーネントを含めます(この例では、プレースホルダの位置にアカウント番号を指定してください)。
<amp-analytics type="googleanalytics">

<script type="application/json">
{
  "vars": {
    "account": "UA-YYYY-Y" 
  },
  "triggers": {
    "defaultPageview": {
      "on": "visible",
      "request": "pageview",
      "vars": {
        "title": "Name of the Article"
      }
    }
  }
}
</script>
</amp-analytics>

JSON フォーマットは非常に柔軟なので、誤りが起こる可能性がある JavaScript コードを含めずに、いくつかの種類のイベントを記述することができます。

この例を拡張すると、別のトリガー clickOnHeader も追加できます。
<amp-analytics type="googleanalytics">
<script type="application/json">
{
  "vars": {
    "account": "UA-YYYY-Y"
  },
  "triggers": {
    "defaultPageview": {
      "on": "visible",
      "request": "pageview",
      "vars": {
        "title": "Name of the Article"
      }
    },
    "clickOnHeader": {
      "on": "click",
      "selector": "#header",
      "request": "event",
      "vars": {
        "eventCategory": "examples",
        "eventAction": "clicked-header"
      }
    }
  }
}
</script>
</amp-analytics>

リクエストできるデータセットの詳しい説明や、amp-analytics をサポートしているアナリティクス プロバイダの完全なリストについては、amp-analytics のドキュメントをご確認ください。Amp By Example サイトでは、実装例をさらにご覧いただくことができます。

AMP ページで A/B テストなどのユーザー エクスペリエンスの実験を行いたい場合は、amp-experiment 要素を利用できます。この要素で行った設定は、amp-analyticsamp-pixel にも反映されるため、実験の統計分析を簡単に行うことができます。

AMP アナリティクスでは、サイトのユーザー エクスペリエンスを AMP 化して増幅させる際に活用できる分析機能がさまざまに開発されています。チームが予定している作業の概要は、AMP プロジェクト ロードマップをご覧ください。何か足りない機能があると思った方は、GitHub でリクエストしてください。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Parul Soi、Developer Relations プログラム マネージャーによる The Firebase Blog の記事 "The Firebase Blog: Pirate Metrics (AARRR) with Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Parul Soi

Parul Soi
Developer Relations プログラム マネージャー

データを分析して適切な対応ができるかどうかによって、会社が成功するか失敗するかが決まる場合もあります。過去数年間、この分析するデータは大きく拡大し、それに関わるアプリ デベロッパーの数もトラッキングされるイベントの数も増え続けています。しかし、データが多すぎて何を探しているか自分でもわからなくなることが多いのが実情です。

では、製品を改善するためにどのような指標をトラッキングすればよいのでしょうか。

データ分析は非常に大きな分野であり、世界中でいくつかもの人気のある手法やフレームワークが使われています。特に技術製品に関連する分野で人気のあるフレームワークの 1 つが Pirate Metrics です。この用語は、500 Startups の設立者である Dave McClure が生み出したものです。この手法は製品ユーザーのライフサイクルをシンプルにかつ明細に表しているため、世界中のプロダクト マネージャーやグロース ハッカーの人気を集めています。

本投稿では、Pirate Metrics を構成する 5 つの指標を紹介し、その重要性について考えてみます。本シリーズの以降の投稿では、Firebase 製品を使ってこれらの指標を向上させ、製品をさらに魅力なものにする方法について考える予定です。
ステージ 1

どんな製品でも、ユーザー ライフサイクルの最初の要素はユーザー獲得です。これは、ユーザーが皆さんのアプリをインストールするということです。ユーザーの獲得はさまざまな方法で行うことができます。これには、ソーシャル メディア マーケティング、App Store の最適化、検索、ニュース、コンテンツ マーケティングなど、あるいは広告などの手法があります。

ステージ 2

ユーザーを獲得することができたとしても、仕事はまだ半分も終わっていません。次は、ユーザーが手元に置いておくべきアプリであることを確信してもらう必要があります。そのためには、アプリが特別なものであるということを経験してもらい、ユーザーを活性化させる必要があります。たとえば、ゲームであればユーザーにトレーニング レベルを終えてもらうこと、写真フィルタアプリであれば、1 つの画像で実験してもらうことがこれに当たるでしょう。

ステージ 3

ほとんどの製品にとって、最大の難関となるのが獲得したユーザーを維持することです。一般的なユーザーが毎日使っているのは、インストールしているアプリのわずか 26% です。ユーザーは、数日でアプリをアンインストールしたり、単にダウンロードしたことを忘れてしまう傾向があります。新しい健全な製品にとっての目標は、それを維持する戦略を見つけてリピート率を上げることです。

ステージ 4

また、ユーザーには最大のサポーターになってもらいたいと思うでしょう。紹介キャンペーンほど強力な獲得戦略はありません。製品を気に入ったユーザーは、友人にも試してみるよう心から勧めたくなります。もちろん、皆さんはユーザーにそうしてもらいたいと思うでしょう。それにはユーザーを阻害するような要素は取り除く必要があります。

ステージ 5

最終的に、企業を拡大させ、さらに多くのユーザーを獲得できるよう、アプリを収益化します。

この獲得活性化維持紹介収益化という 5 つのステージは、まとめて Pirate Metrics と呼ばれています。これはかなり汎用的で、ほとんどのデジタル製品に適用できます。プロダクト マネージャーは、これらの指標をトラッキングするためにさまざまなツールを使用しています。しかし、新しい Firebase を使うと、各指標を 1 か所でトラッキングできるだけでなく、それを向上させることができるさまざまなツールを活用することもできます。

この点については、今後の投稿で紹介します。ご期待ください。


Posted by Takuo Suzuki - Developer Relations Team

[この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "Announcing Real-time Exporting of your Analytics Data into BigQuery" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]



Frank van Puffelen


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

Firebase Analytics の非常に強力な機能の 1 つが、BigQuery からの Analytics データの直接参照や分析できることです。Firebase アプリと BigQuery をリンクさせれば、生のサンプリングされていないアプリデータを毎日 BigQuery にエクスポートでき、データに対して強力なクエリをアドホックに実行したり、Firebase Analytics データと別のアナリティクス ライブラリのデータを組み合わせたり、カスタム レポーティング ツールを直接実行できるようになります。

しかし、この機能はデベロッパーに非常に人気がある一方、時にじれったく感じるような制限もあります。通常、日々のアナリティクス データが収集されて BigQuery テーブルにエクスポートされるまで、24 時間待たなければならないことです。これは、開発とテストという視点から考えると不便に映ることが多い制限で、アプリのデベロッパーの対応スピードが落ちてしまうことにもなります。もし最新の A/B テストの影響でユーザーがアプリを使わなくなってしまった場合、24 時間ではなく 20 分でそれがわかればすばらしいとは思いませんか?

そこで、うれしいことに、今週より、Firebase Analytics データがほぼリアルタイムで BigQuery から参照できるようになることをお知らせいたします。

以下で、その仕組みについて説明します。既に Firebase プロジェクトと BigQuery をリンクさせていれば、デフォルトで Firebase Analytics はできるだけ早く BigQuery にデータを送信するようになります。通常の appevents_ テーブルに加え、その日の受信するすべてのデータを集めた特殊な appevents_intraday_ テーブルができます。


この intraday テーブルは、自由に分析を行ったりクエリを実行したりでき、他の BigQuery アナリティクス テーブルとまったく同じように扱うことができます。このテーブルにないデータは、生涯価値(LTV)データとキャンペーン情報(traffic_source レコード)のみです。1 日が終わると[1]、このデータは永続テーブルである appevents_ ホームに移動し、古い intraday テーブルは自動的にクリーンアップされます。

もちろん、BigQuery の使用量とストレージの料金はそのまま適用されます。つまり、このメリットを受けるには、Firebase プロジェクトを Blaze プランにアップグレードする必要があるということです。しかし、BigQuery へのエクスポートは、今までアナリティクス ユーザーが多額をつぎ込まなければならなかった機能だったため、これは十分よい条件だと言えるでしょう。

BigQuery を初めて使う方は、こちらから詳しい情報をご覧いただき、使い始めることができます。BigQuery で取得した巨大なデータセットに対して高速にクエリを実行するのはとても楽しいものです!

[1] デベロッパーのタイムゾーンで判断しています。


Posted by Khanh LeViet - Developer Relations Team

[この記事は Philip Walton、デベロッパー プログラム エンジニアによる Google Developers Blog の記事 "Autotrack turns 1.0" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


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 に送信するようアナリティクスを実装している場合、レポートに同じ場所を指す別々のページパスが現れるという問題を経験することになるでしょう。以下に例を示します。
  • /contact
  • /contact/
  • /contact?hl=en
  • /contact/index.html
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

[この記事は Russ Ketchum、Google Analytics & Firebase チーム担当グループ プロダクト マネージャーによる The Firebase Blog の記事 "Introducing Firebase Analytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]






Russ ketchum






Russ Ketchum
プロダクト マネージャー


既にご利用いただいているデベロッパーの皆さん、そして新しいデベロッパーの皆さん、Firebase へようこそ。Firebase プラットフォームにはたくさんの良さがあり、1 つのブログ記事ではとても説明しきれません。今まで Firebase の機能について紹介するブログ記事を数本出していますが、今日は無料で制限なく使えるモバイル デベロッパー向けアナリティクス ソリューション、Firebase Analytics について紹介したいと思います。

成功を収めているアプリでは、必ず分析が行われています。Firebase を拡張するにあたって、モバイル デベロッパーによるアプリの改善とビジネスの成功をサポートするために私たちが重要だと考えたことは、社員 2 名のスタートアップ企業から大手の会社まで、すべてのアプリ デベロッパーのニーズに応える分析ソリューションを構築することです。

Firebase Analytics は、モバイル アプリ向けにゼロから構築された、無料で制限なく使える分析 ツールです。ぜひこのツールをご利用ください。Firebase プラットフォームの中核を成す Firebase Analytics が、成功を収めるアプリの構築に必要な分析情報を提供いたします。


これ 1 つでアプリの分析をすべて実現

Firebase Analytics を活用すると、ユーザーがアプリ内で何をしているのかを把握できます。アプリの分析ツールに期待されるすべての指標(ユーザーあたりの平均収益(ARPU)、アクティブ ユーザー数、継続利用レポート、イベント回数など)が確認でき、それとデバイスタイプ、アプリのバージョン、OS のバージョンといったユーザー プロパティを組み合わせることによって、ユーザーがどのようにアプリを使っているかを分析できます。

このようなデータはすべて簡単に収集でき、すぐに利用可能です。アプリに Firebase を追加すると、初回起動(インストールと同等)、アプリ内課金などのキーイベントが自動的に計測されます。イベントは 500 種類近くあり(それぞれに最大 25 のキーと値のペア形式のパラメータが紐付きます)、数行のコードを追加するだけで、追加の推奨イベントやアプリ固有のカスタム イベントを計測できます。

イベントの中には重要度の高いものもあります。コンバージョン トラッキングでアプリ内の重要度の高いイベント(たとえば、アイテムの購入、アプリの共有など)を定義してイベントのファネルを構築し、そのプロセスのどこでユーザーが脱落したのかを調べることができます。



Firebase Analytics が分析できるのは、ユーザーの行動だけではありません。地理情報、属性、興味など、ユーザーについてのさまざまな情報も取得することができるため、アプリのチューニングやマーケティング活動の改善も可能です。

標準的な属性データも十分役立ちますが、アプリに固有のユーザー プロパティについて理解することも重要です。Firebase Analytics では、すべてのユーザーに対してカスタム ユーザー プロパティを定義できます。たとえば、フィットネス アプリならお気に入りのエクササイズを、ミュージック アプリならお気に入りのジャンルを記録できます。さらに、Firebase Analytics は Google のフルマネージド データウェアハウスである BigQuery とも統合されています。そのため、Firebase からローデータをエクスポートし、カスタムデータと結合してさらに詳しい分析を行うことができます。

アプリのマーケティングをさらにスマートかつ効率的に

ユーザーの行動を把握できることは、Firebase Analytics の重要な一側面に過ぎません。広告やマーケティング活動が、どのようにユーザーの行動に影響を与えているかについても理解する必要があります。Firebase Analytics は、アプリ内のユーザーの行動とトラフィック ソースを自動的にリンクさせるため、貴重なユーザーがどこからやってきたかを知ることができます。SDK を追加インストールしなくても Google AdWords をはじめとする 20 以上の主要な広告ネットワークと連携できるため、マーケティングや広告に使った費用の ROI を簡単に把握できます。また、Firebase Analytics のコンバージョン イベントを直接 Google AdWords にインポートできるため、数クリックでアプリ内で発生した特定のユーザー イベントに対して広告入札することもできます。

Firebase を最大限に活用する Firebase Analytics

Firebase Analytics は、実用的なデータ分析を行えるように設計されています。Audience 機能を活用すると、イベントデータやユーザー プロパティに基づいてユーザーのセグメントを作成できます。たとえば、カートにアイテムを追加したものの購入しなかったユーザーの Audience や、200 曲以上を聴いているクラシック音楽ファンの Audience を作ることができます。

作成した Audience は、その他の Firebase の機能と組み合わせて使うことができます。たとえば、Firebase Remote Config を使うと、特定の Audience のみを対象にアプリのルック アンド フィールを変更できます。ニュースレターをサブスクライブしているユーザーや、フィットネス アプリで特定のレベルに到達したユーザーにカスタムのホームスクリーンを作成することも可能です。以上のようなことは、Remote Config と Firebase Analytics の Audiences を使用して Firebase コンソールから直接実行することができます。

Firebase Analytics の Audience は、Firebase Notifications と連携させて使うこともできます。この機能を使うと、定義してある任意の Audience に対してアプリ内通知を送信できます。たとえば、ゲームのアプリ内ストアに新しい鎧を追加した場合、ゲーム内でアイテムを購入したことがあるユーザーだけに通知することができます。さらに、Firebase アカウントが AdWords にリンクされている場合、Audience を活用してしばらくアプリを使用していないユーザーに対して広告キャンペーンを行い、リピート率を上げることもできます。Firebase Analytics のアプリのアナリティクス機能の詳細は、次のビデオをご覧ください。


Firebase はスタンドアロン ツールとしても便利に利用できますが、Firebase Analytics の真の力は、他の Firebase 機能に顧客の分析情報を連携できる点にあります。この分析情報によって、モバイル アプリを成長、発展させ、収益を上げることができます。


Posted by Khanh LeViet - Developer Relations Team

[この記事は Google Cast サーバー基盤チームのソフトウェア エンジニア、Chris Dolan による Google Developers Blog の記事 "Introducing Analytics for Google Cast Applications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


Google Cast 対応アプリケーションのデベロッパーである皆さんは、アプリケーションにアクセスしているデバイスの数、それらのデバイスが開始しているセッションの数、それらのセッションがコンテンツを再生する時間数などを把握したいと思うことがあるでしょう。その場合、これまでは、自力でその情報を得るための仕掛けを実装しなければなりませんでした。しかし、もうその必要はありません。上記のデータはすべて Google Cast デベロッパー コンソールから直接参照できるようになりました。

この機能を試すには、まず通常どおりにデベロッパー アカウントでデベロッパー コンソールにログオンします。[Applications] テーブルで、[Statistics] 列に追加されている [View] リンクをクリックしてください。
キャプション: アプリケーションのページでは、個々のアプリに対して [View] リンクが表示されるようになりました


アナリティクス ページには、各メトリックへのタブ、時間の経過によるメトリックの値の変化を示すインタラクティブなグラフ、直近の 1 日のデータを示すテーブルなどが記載されています。[Devices] タブにはアプリを起動した Cast 対応デバイスの数、[Sessions] タブにはアプリの Cast セッションの数、[Avg. Playback] タブにはアプリ(*)の 1 セッションあたりのメディア再生時間の平均値がそれぞれ示されます。
アナリティクス ページにはタブ、グラフ、データのテーブルが表示されます


各タブのデータは、総計、国別、送信者のプラットフォーム別などのように、値の尺度を変えて表示することができます。特定の国やプラットフォームの値を参照するには、テーブル上で参照したい列を単純にクリックします。各タブのデータは 1 日 1 回のペースで更新され、これらの値の総計は 1 週間(7 日)、2 週間(14 日)、4 週間(28 日)の周期で集計されます。集計の周期を切り替えるには、画面右上に表示されている期間ピッカーから使用する周期を選択してください。

皆さんがこうしたアナリティクスから、Google Cast アプリケーションの利用状況に関する知見を得て、アプリケーションの改善に活用されることを願っています。詳細については、デベロッパー ドキュメントを参照してください。
* メディアの再生機能がないアプリについては、メディア再生時間の平均値は表示されません

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Google Play 事業開発マネージャー、Matteo Vallone による Android Developers Blog の記事 "Find success on Google Play: What app developers can learn from games" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

(より多くのアプリ デベロッパーに情報を伝えることで、Google Play でのビジネスを支援できるよう、この記事はこちらのウェブサイトで先行公開されました – Ed.)

フリーミアム アプリとゲーム事業の間には、事業として成功させるという点では、多くの共通点があります。しかしながら、コンソール ゲームの歴史から、ユーザーはアプリよりゲームに支払いをすることに、より慣れています。さらにモバイル ゲームでは、ユーザーに合わせて、幅広い価格設定の「仮想グッズ」を容易に提供できます。つまり、ゲームのデベロッパーは、どのようにユーザーの初期体験や、コンバージョン、生涯価値(LTV)を改善できるかを学ぶ機会がずっとありました。では、アプリのデベロッパーはゲームのデベロッパーから何を学べるでしょうか。成功したゲームのデベロッパーから得たベストプラクティスと知見の中で、アプリ開発でも大いに活用できそうなものをご紹介します。

ゲームのデベロッパーの手法を学んで、アプリも成功を目指しましょう。

1. 新規ユーザー獲得に投資する前に、ユーザー維持率を最適化する

ユーザー維持率は王様です。ユーザー維持率はコンバージョンの増加に寄与します。ゲームのデベロッパーにとって、ユーザー維持率は、ゲームの品質とゲームがユーザーにとって魅力的であるかの重要な指標です。

ほとんどの場合、ゲームのデベロッパーは、ベータ テストのコミュニティやテスト用の市場で「先行公開」を実施します。このフェーズの間に、チュートリアルの完了率、難易度、コンバージョン数といった具体的な項目を詳しく調査し、ユーザー維持率を最適化するための調整を行います。Google アナリティクスのコホート分析レポートを使うと、デベロッパーはユーザー維持率を追跡することができます。ユーザー維持率が満足いくものになると、デベロッパーは本格的なアプリの公開に踏み切り、ユーザー獲得のための投資を開始します。

2. 徐々にエンゲージメントを高めユーザーを保つ

ユーザー維持には、インストール直後の 1 週間が最も重要です。ユーザーはたくさんのアプリをインストールして試し、最初の数日間で、どのアプリを使い続けるかを決めます。もし、その期間残ることができれば、あなたのアプリはユーザーが日々使うアプリの一部になる可能性が高いと言えます。

段階的にユーザーのエンゲージメントを高める、簡単な方法がいくつかあります。主要な機能を紹介することに加え、そのアプリがユーザーにとって、どれほど価値があるか説得力のあるストーリーを提示することが大切です。そして、見つやすい場所に、ユーザーがすぐに価値を感じる機能を配置します。

これは、すべての場合にあてはまる方法はでありません。適切なソリューションを見きわめるために、デベロッパーはまず、どのようなユーザーフローにすればユーザー維持率を高められるかについて仮説を立て、A / B テストを実行し、その仮説が妥当であるか、修正が必要があるかを確認する必要があります。たとえば、サインインの処理をユーザーフローの中で後回しにすれば、ユーザー維持率が高まると考えるかもしれません。しかし、同時に、長期間のエンゲージメントを判定する指標(アップロードされた写真や閲覧された記事の数など)が何かという点にも注意し、アプリ利用開始時のフローの変更が長期指標へ与える影響を測定するする必要があります。

通常、アプリの導入の最適化に着手する場合、次の原則がよいスタート地点になります。
  • 煩雑な手順のセットアップをユーザーに強いるより、アプリをすぐに使ってもらえる方法を追求してください。
  • アカウントの登録、ビデオのアップロード、友達の検索など、「アクティベーションが必要な瞬間」は、少しずつ出すようにしましょう。
  • 最初にユーザーに求めることは最小限にし、より細かいことはユーザーがアプリの機能を必要とした時に求めるようにしましょう。
  • パーミッションはユーザーに対するサービスとして扱いましょう。たとえば、ユーザーに登録をしてほしい場合には、先に、登録をすることでアプリからより多くの価値が得られることを示してください。そのようにすることで、ユーザー体験はより個人的なものとなります。


この例では、アプリ「OkCupid」でアプリへの導入フローをいくつか試した結果、最もエンゲージメントが高かったバージョンでは、7 日間ユーザー維持率が 20 パーセント以上も向上しました。


最後になりますが、ユーザーに購入を求める前に、ユーザーがアプリの価値を確実に理解できるようにしてください。ゲームのデベロッパーは、限られた日数または回数の中で製品の一部または全ての機能を、無料でユーザーに体験してもらう、ということをとてもうまく行っています。

Google アナリティクスのユーザーフローレポートは、ユーザーがアプリをどのように使っているか(または使っていないか)を分析する際にとても役立ちます。このレポートを使うことにより、ユーザーがアプリ内をどのような経路で利用し、どこで離脱したかを知ることができます。これにより、アプリ内の潜在的な問題点を見つけることができます。

3. 適切なユーザーに適切なサービスを提供する

ユーザーにアプリ内購入を促すための戦略を立案する際は、アプリ内の購買行動の違うグループを理解することが重要です。

まず、どのように購入を行うかと購入金額によって、ユーザーのグループを見分けるところから始めましょう。ユーザーの年齢別かもしれませんし、インストール時に利用するチャネル別、あるいはアプリ内の行動別かもしれません。こうしたユーザー グループの発見と定義には、Google アナリティクスのセグメントの作成を使います。次に、ユーザーにアプリ内購入を勧める内容とタイミングを、ユーザーの購買行動にあわせて調整します。たとえば、購入するユーザーの割合が高く、1 回の購入額も大きいけれども、購入頻度が低いという傾向があるグループに対しては、アプリ内の有料機能をバンドルするようにします。

4. ユーザーが購入する可能性が高い時にアプリ内購入を勧める

ユーザーが購入をする確率が高くなるのは、購入の操作がスムーズな場合、そして、購入によりどのように価値が増すかがわかる場合です。なので、次をお勧めします。
  • ユーザーが必要な時、または、欲しいと感じる時にユーザーに購入を促します。そして、なぜ購入することが妥当であるかを説明します。
  • 購入の操作は、ユーザーがアプリの利用中に最小限のタップで完了できるように、できるだけ簡単な設計にしましょう。たとえば、適切な画面のフッターに「アップグレード」ボタンを追加します。



アプリ「TomTom」は、無料サービス期間が終了するまでのカウントダウンを追加しました(移動した距離でカウントされる)。カウンター画面には、ワンタップで有料機能にアップグレードできる、アプリ内購入のボタンが含まれています。


優秀なゲーム デベロッパーと同様に、TomTom のデベロッパーは、テストと分析を絶えず繰り返し、ユーザーの心をつかんで離さないような優れたユーザー 体験の構築を重視しています。第一印象は大切です。アプリ利用開始時に、ユーザーがすぐにアプリの重要性を理解し、簡単に使えるようにする必要があります。そして、収益を生み始める必要があります。アプリ内購入を実行しやすくすることに十分配慮することが肝心です。

私が「Google Playtime 2015」で開催したセッション「アプリに応用できるゲームのルール」(The rules of games, for apps)は、こちらからご覧になれます。このセッションではアプリのデベロッパーは、ゲームのベストプラクティスやデベロッパーの実例を学ぶことができます。

また、「Google Playtime 2015」の他のセッションでは、Google Play でビジネスを成功に役立つツールやベストプラクティスについてご覧になれます。

Posted by Ryuichi Hoshi - Developer Relations Team

[この記事は Philip Walton、デベロッパー プログラム エンジニアによる Google Developers Blog の記事 "Introducing Autotrack for analytics.js " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


Google Analytics 公開当初の頃と比べ、ウェブは大きく変化しました。当時は、ほとんどのウェブサイトは個別ページから構成されており、あるページから別のページに移動するためには、リンクをクリックしてページ全体をリクエストする必要がありました。そのため、ほとんどのサイトでは、JavaScript のトラッキング スニペットが 1 つあれば、大多数のユーザーの操作を追跡できました。

しかし昨今のウェブは、当時に比べるとずっと複雑で変化に富んだものになっています。旧来の静的なウェブサイトだけでなく、機能満載のウェブ アプリケーションも存在します。ユーザーが実行する操作は、リンクのクリックやフォームの送信に限定されなくなり、「ページビュー」も、必ずしもページ全体を読み込むとは限らなくなっています。

ウェブがこのように変化を遂げる一方で、アナリティクスの実装はさほど変わっていません。Google Analytics ユーザーのほとんどは、デフォルトのトラッキング スニペットをコピーしてサイトのページに貼り付けるだけで満足しています。Google Analytics にはデフォルト以外の機能もたくさんあることは知っていながら、そういった機能を学ぶための時間はつい後回しになってしまうのです。

この問題への新たな解決策となるのが、analytics.js 向けの Autotrack です。Autotrack は、Google Analytics の機能を最大限に活用しますが、実装のための手作業は最小限で済みます。このツールは、今日のモダンなウェブのデータを追跡する基盤をデベロッパーに提供します。

機能

Autotrack ライブラリは、analytics.js プラグインの集合体であるため、ライブラリ全体をそのまま利用することも、必要なプラグインのみを選んで使用することも簡単にできます。以下のセクションでは、Autotrack が実現する機能をいくつか取り上げて説明します。

サイト外へのリンクとフォームの追跡

あるサイトで、ユーザーが別のページを指すリンクをクリックすると、通常はそのページが開いた際にページビューが送信されます。一連のページビュー情報が存在しているため、Google Analytics はユーザーが(どのページから)どのページに移動したのかをバックエンドで判断できます。ただし、ユーザーがクリックしたリンク先やフォームの送信先が外部ドメインだった場合、Google Analytics に対して個別に情報を提供しない限り、そのアクションは捕捉されません。

かつては、外部ドメインへのリンクやフォーム送信の追跡の実装は困難でした。ほとんどのブラウザでは、新しいページの読み込みを開始すると、現在のページ上の JavaScript の実行を停止するからです。Autotrack がこうした複雑な問題に対処するため、自由に外部ドメインへのリンクやフォーム送信の追跡が行えるようになります。

シングルページ アプリケーション上の URL の変更追跡

コンテンツを動的に読み込み、History API を使って URL を更新するシングルページ アプリケーションを構築している場合、デフォルトのトラッキング スニペットでは不十分です。デフォルトのトラッキング スニペットは、最初のページ読み込みだけしか追跡しません。たとえ、新しいコンテンツを問題なく読み込んだ際にページビューを送信するようにしても、まだ厄介な問題が発生する可能性があります。

Autotrack は History API を使用した URL の変更を自動的に検出し、それをページビューとして追跡します。トラッカーは更新された URL に同期されるため、それ以降のヒット(イベント、ソーシャル インタラクションなど)もすべて正しい URL に関連付けられます。

宣言型のイベント トラッキング

手作業で JavaScript のイベントリスナを書くよりも、明示的にイベントを HTML に追加する方が容易な場合があります。最も典型的な例は、単純なクリック イベントの追跡です。Autotrack では、マークアップにデータ属性を追加するだけでクリック イベントを追跡できます。
 <button data-event-category="Video" data-event-action="play">Play</button>  

ユーザーが上記のボタンをクリックすると、対応するカテゴリやアクションとともに、イベントが Google Analytics に送信されます(オプションでラベルや値も含めることができます)。

メディアクエリのトラッキング

最近は、ほとんどのサイトでレスポンシブ デザインが採用されており、ユーザーが使っているデバイスの画面サイズや機能に応じてページ レイアウトが更新されるようになっています。メディアクエリを使ってページの外観や機能を変更する場合、メディアクエリの情報を取得することが重要です。そうすることによって、有効になっているメディアクエリに応じて使用方法がどう変わるのかをより深く理解することができます。

Autotrack を使用すると、使用されるメディアクエリの値のセットを取得できます。この値のセットは、カスタム ディメンション経由で自動的に追跡されます。さらに、値が変化したことも追跡できます(メディアクエリを使ったトラッキングを実行する場合は、Google Analytics でカスタム ディメンションを設定しなければならないことに注意してください。設定のプロセスはほんの数分で済みます。また、設定の手順は mediaQueryTracker プラグインのドキュメントで説明されています)。

以上で説明した機能は、Autotrack で実現できる機能のほんの一部です。すべてのプラグインの一覧とその使い方の説明は、Github にある Autotrack のドキュメントをご覧ください。

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

Autotrack は誰でも利用でき、どんなサイトにも効果がありますが、このライブラリは主に、現在のアナリティクスの実装をカスタマイズしておらず、ここまでで説明したような機能を利用したいサイトのために設計されています。

現在デフォルトのトラッキング スニペットだけを使用している場合、Autotrack の利用を検討してみる価値があるでしょう。Google Analytics の実装に既にカスタマイズを加えている場合は、まずドキュメントを参照し、その実装と Autotrack の機能が衝突しないかどうか、二重にカウントされるデータがないかどうかを確認してください。

次のステップ

Autotrack を利用する際は、ドキュメントの「使い方」のセクションを参照してください。Autotrack がどのようなデータを捕捉するのかについて関心のある方は、Google Analytics Demos & Tools サイトを参照してください。このサイトは Autotrack を利用しており、このサイト自身に対して Google Analytics を実行したデータをグラフで表示しているページがあります。

さらに理解を深めたい場合は、Autotrack ライブラリを直接参照してください。これはオープンソースで、学習に役立つ、優れたリソースです。プラグインのソースコードにひととおり目を通せば、そこで analytics.js の高度な機能が多用されていることが理解できるでしょう。

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

Posted by Eiji Kitamura - Developer Relations Team

[この記事は Jonathan Beri、プロダクト マネージャーによる Google Developers Blog の 5 月 28 日の記事 "Add Google to your iOS Apps with CocoaPods" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google は 5 月 28 日、iOS で Google SDK を入手する主要 チャネルを CocoaPods とすることを発表いたしました。 CocoaPods は人気の高い無料の iOS 向けの依存関係マネージャーで、ライブラリやフレームワークを Xcode にインポートするプロセスを大幅に簡素化し、Google のさまざまなライブラリの依存関係を管理することができるようになります。

これまで、他の iOS 開発者が制作した Pod に加え、徐々に増えつつある Google 公式 Pod も存在するなか、適切な SDK を探し出すことは難しい状況にありました。今回のアナウンスにより、 Google Cloud MessagingGoogle Maps SDK for iOS などの主要なライブラリは、公の CocoaPods サービス上で見つけることができるようになりました。今後、新しい iOS SDK は Pod としてパッケージ化・ドキュメント化され、cocoapods.org で公開されます。Google Pod の完全なリストとすべてのサポート ドキュメントは developer.google.com/ios/cocoapods でご確認いただけます。

もしまだ CocoaPods を使ったことがなければ、ぜひお試しください。GoogleAnalytics を Podfile に追加すれば、新規ユーザー数をカウントすることができます。pod install で AdMob 広告をアプリに追加することもできます。デモ プロジェクトを簡単に起動できる CocoaPods プラグイン、pod try もぜひお試し下さい。

さまざまな iOS 開発 Tips や、Google の iOS SDK の詳細については、 Todd KerpelmanRoute 85 video series をご覧ください。皆さんが Google の機能を盛り込んだすばらしい iOS アプリを作成してくださることを楽しみにしています。

Posted by Yoshifumi Yamaguchi - Developer Relations Team