Local blog for Japanese speaking developers
さらなる収益最適化のヒント - データのパターンを分析してビジネス拡大の機会を見い出す
2019年4月3日水曜日
この記事は Adam Carpenter (Head, Developer Business Growth, Google Play) による Medium Blog の記事 "
Signs and signals of sub-optimal monetization
" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリ内購入（IAP: In-app purchase）は、アプリやゲームを収益化するための一般的な方法の 1 つです。IAP は数年前から広く利用されていますが、期待しているほどの成果が上がらないケースもあるようです。
この投稿では、IAP の収益化戦略をさらに最適化する余地があるときに、アプリ内指標がどのような兆候を示すかについて解説し、どうしたらそれらをビジネスの拡大につなげられるかについて説明します。
まずは、日次売上 (Daily Revenue) の構造をあらためて確認し、収益を構成する指標がお互いにどう関係しているかを見てみましょう。下の図は、Google Play で「収益ツリー」または「売上ファネル」と呼んでいるものです。
収益ツリー
収益ツリーは、日次売上を上から下へとツリー状に分解し、売上がどのような指標で構成されているかを明らかにしたものです。ツリー内の各指標は、その下につながっている 2 つの指標を乗算すると算出できます。ただし、左下の点線で囲まれた指標は例外で、この 2 つは加算することでその上の指標を算出できます。
赤色の四角が中心的な収益化指標で、「1 日の購入者の割合（Buyer %）」と「有料ユーザーごとの平均売上（ARPPU）」の 2 つのグループに分かれています。
個人的には、「1 日の購入者の割合」が最も重要な指標だと思っています。なぜなら、たくさん購入してくれる一部のプレーヤーだけに頼るよりも、購入してくれるプレーヤーの割合を高めるほうが売上の幅が広がって安全だからです。
一方、「有料ユーザーごとの平均売上（ARPPU）」と、それを構成する「平均取引額（ATV）」および「購入者ごとの取引数（TX / Buyer）」は二次的な収益化指標です。 これらも重要な指標なのですが、すでに購入することを決めているユーザーからどれだけの売上を上げられるかを測定したものなので、これらを無理に高めようとすると弊害が生じるおそれがあります。たとえば、有料ユーザーの購入を促進すれば平均売上は簡単に上がるかもしれませんが、その影響で購入者のコンバージョン率が下がるおそれがあります。
ここでは、売上をバランス良く成長させることができるよう、この売上ツリーを使って売上の構造について見ていきます。まず、売上をモニタリングするための方法をいくつか紹介し、ゲームの収益力を把握できるようにします。次に、購入者の構成について検討し、頻繁に購入してくれるリピーターを増やす方法を考えます。最後に、二次的な指標について議論し、ゲームを改善して収益力を高めるためのヒントを紹介します。
売上をどう伸ばすか
売上を成長させるための代表的な方法の1つが LiveOps です。LiveOps は、売上を促進する効果的な方法の 1 つであり、ゲームビジネスを拡大し、需要を喚起するうえで不可欠なものとなっています。しかし、LiveOps は一面的な施策ではありません。供給側のセールと需要側のイベントという 2 つの面を持ち、それらの間のバランスも重要になります。
供給側のセールとは、ゲーム内のアセットを割引価格で提供し、ユーザーが同じ購入額でより多くの価値を手に入れられるようにする方法です。需要側のイベントとは、トーナメントや週末チャレンジといった競争的なイベントを開催し、ユーザーが手持ちのアセットを消費するよう促す方法です。ゲーム内経済を健全に保ちながら収益力を高めるには、この 2 つのバランスをとることが重要です。
このバランスをどうとるべきかを解説するため、以下に LiveOps の 2 つの実施例を示します。
日次売上の変動例（出典：Google Play 内部データ）
左のグラフは、1 か月に 1 回程度のペースで大きなセールを実施するデベロッパーの例です。セールの期間中はかなりの売上を上げることができています。月に 1 回で少なければ毎週 LiveOps を実施することもできますが、次のセールまでの間にどうしても売上が下がってしまいます。右のグラフは、ほぼ毎日 LiveOps を実施しているデベロッパーの例です。
供給側と需要側をバランス良く実施したことで、売上が大きい日がかなり頻繁に発生しています。LiveOps の興味深いところは、デベロッパーが毎日を魅力的にしようとすると、毎日利用しているユーザーがその価値に気付いて財布の紐を緩めてくれる点です。
では、最適な戦略はどれでしょうか。実を言うと、すべての状況に対応できる最適解はありません。最適な戦略は、開発チームとそのスキル、ゲーム、ユーザーなどによって変わってきます。LiveOps をどれくらいの頻度で作成、実施できるでしょうか？セールやイベントによって、ユーザーの購買行動をさらに促進することは可能でしょうか？
「売上心拍」で売上をモニタリングする
LiveOps をモニタリングするツールとして最適なのが、「売上心拍」と呼ばれるグラフです。売上心拍を視覚化するには、各月の日次収益の最大値と最小値を特定し、その月の日次収益の平均値を計算します。これらを月別にプロットすると次のグラフのようになります。
売上心拍（各月の最小売上、最大売上、平均日次売上）のグラフ
（出典: Google Play 内部データ）
理想的なのは、平均売上を表す折れ線の上下に、最大売上と最小売上の帯が安定して描かれている状態です。つまり、平均売上が順調に拡大しつつ、最大売上と最小売上の差（つまり帯の幅）が一定している状態です。そのようなグラフになっていれば、日々の需要を適切に喚起できていて、プレーヤーたちも継続的に夢中になってくれているということです。
上のグラフと違い、下に示す売上心拍のグラフには理想的とは言えないパターンが見られます。
売上心拍のパターンが理想的ではないグラフ
ポイント A と C で大規模なセールを実施したことで最大売上は急上昇していますが、その後の反動により、月ごとの平均売上が下降するほど収益力が落ちてしまっています。セールを実施するときは、その後の反動の期間と大きさを最小限に抑えることが重要です。少なくとも、セール後の売上がセール前より小さくなる事態は避けなければなりません。
一方、ポイント B ではデベロッパーがゲーム内経済を引き締め、セールをあまり実施せずに需要を喚起しました。ユーザーにアセットの消費を促し、手持ちのアセットを減らして購入意欲を高めるというのは非常に効果的な方法です。
売上心拍を使用して収益の推移をモニタリングすることで、ゲームの収益力やセールの効果を把握し、セールの頻度が適切かどうかを判断できます。
その他の売上指標
さらに高度な方法で売上を分析することもできます。特に効果的なのは、1 か月間の日次売上の変動係数を使用する方法です。日次売上の変動係数は 1 か月間の売上のばらつきや変動性を表す指標で、LiveOps のパフォーマンスを定量化するのに便利です。1 か月間の日次売上の標準偏差を計算し、これを平均で除算することで求められます。
Google Play に公開されているゲームについてこの変動係数を計算したところ、売上成長率と強い相関関係にあることがわかりました。つまりこの変動係数を見ることで、ゲームの収益が成長するかどうか、その潜在性を推定できるということです。また、皆さんに追求することをおすすめする最適化や価値のヒントにもなります。
上位のゲームにおける日次売上の変動係数の分布（出典: Google Play 内部データ）
2017 年 1 月～2018 年 1 月の期間で Google Play のトップ 250 の IAP ゲームを調べたところ、その大部分で変動係数が 39% を下回りました（多少のばらつきはありますが極端なものはありませんでした）。このデータを、前月比で売上が伸びているゲームに絞り込んだところ、興味深い事実が明らかになりました。
上位のゲームにおける月次売上成長率と変動係数（出典: Google Play 内部データ）
上のグラフを見ると、変動係数が 0～39% のゲームの 55% 以上で月次売上が伸びており、変動係数が低いゲームほど売上が成長する可能性が高いことがわかります。一方、変動係数が高いゲームのうち、月次売上が伸びているのは半数未満です。
この分析から、ゲームの売上の変動係数が適正レベルかどうかを検討することが重要であるとわかります。変動係数が適正レベルでない場合は、LiveOps の頻度を最適化して需要と供給のバランスをとり、売上の変動を抑える必要があるということです。
週ごと、月ごとのセールを定期的に実施していると、ユーザーもそのパターンを予測できるようになります。すると、セールのときにアセットを買いだめし、セール以外で買わないようになるかもしれません。アセットが少なくなってきても、次のセールがすぐあるとわかっていたら買い控えるかもしれません。定期的なセールに伴う買いだめや買い控えは、売上機会の損失につながります。
その解決策となるのが、私が「
予測可能な予測不能性
」と呼んでいるものです。プレーヤーが、「何かいいことがある」ことは予測できても、それが何かまでは予測できないようにするのです。「何かいいこと」が何かまでは予測できないため、それが起きる前にプレーヤーが行動を変えることがない点が重要です。これまでのセールやイベントが予測可能だったかどうか、プレーヤーに予測されていたかどうかを検証してみましょう。もし予測可能だったなら、予測不能にするにはどうしたらよいか検討することをおすすめします。
リピーターを増やす
有名な「80 対 20 の法則」はゲームの売上にも当てはまります。つまり、多くの IAP ゲームは売上の 80% を購入者の上位 20% から得ているということです。ただし、これは IAP ゲームのエコシステム全体を見た場合です。この法則を収益戦略に当てはめるのは危険であり、おそらくそれでは長期的に売上を維持することはできません。さらに興味深いことに、高い売上を上げているゲームの多くはそのような戦略をとっていません。
トップ 25 のゲームが上位 20% の購入者から得た売上の割合 - 2018 年 4 月
（出典: Google Play 内部データ）
Google Play に公開されているトップ 25 の IAP ゲームのデータを見ると、購入者の上位 20% から得ている売上が 80% を超えているゲームはわずかに 6 つです。大部分は 70% 台で、60% 台が 3 つ、50% 台が 2 つとなっています。つまり、上位のゲームのほとんどが、もっと幅広い購入者から売上をあげているのです。
トップ 100 のゲームのうち 80 対 20 の法則を満たすゲームの割合 - 2018 年 4 月
（出典: Google Play 内部データ）
対象をトップ 100 のゲームに広げてみると、順位が低いゲームほど上位 20% の購入者からの売上に頼っていることがわかります。
では、売上の大部分を一部の高額購入者だけに頼ってしまっている場合、どうしたら購入者の幅を広げることができるのでしょうか。
まずは、どこから売上をあげているかをしっかりと把握する必要があります。そこで、月次 ARPPU とユーザーが 1 か月間に購入した日数を調べ、それぞれを十分位数に分割します（上位 10% をグループ 1、次の 10% をグループ 2 のように分けます）。
ここでは例として、典型的なアクション RPG ゲームのデータを示します。このジャンルで高い売上をあげているゲームによく見られるパターンです。
購入者を十分位数に分割した例（出典: Google Play 内部データ）
この例を見ると、第 1 十分位数（最上位のグループ）の購入額が月平均 579 ドルと最も多く、それに続く第 2 十分位数の購入額は月平均 120 ドルとなっています。つまり 80 対 20 の法則に従っています。それ以降は購入額が下がり続け、購入者の下位 50% は 1 人 10 ドル以下しか購入していません。
これを、売上を成長させる機会と見るべきでしょうか。それとも、上位の購入者がたくさん購入してくれていることに満足すべきでしょうか。さらなる成長をするためには、この状況を絶好の機会と捉えるのが良いでしょう。
この機会をどうやって収益化するかを説明する前に、もう 1 つの要因である「購入者が購入した日数」を見てみましょう。
購入者が購入した日数（出典: Google Play 内部データ）
上のグラフを見ると、購入者の半数は 1 か月に 1 日しか購入していません。これは Google Play 全体に見られる傾向で、ほとんどの IAP ゲームでは、購入者の 40～60% が 1 か月に 1 日しか購入しません。これらの人々に、月にあと 1 日購入してもらうのは難しいでしょうか？何か魅力的なセールを実施すれば、もう 1 日くらい財布の紐を緩めてもらうのはそれほど難しくないように思われます。
では質問です。ここに売上成長の機会はあるでしょうか。あるとすれば、何に焦点を絞るべきでしょうか。最も大きな価値を生んでくれそうなユーザー層はどこでしょうか。答えは、1 か月に 1 日しか購入していないユーザー層です。
1 か月に 1 日しか購入していないユーザーの月次 ARPPU（出典: Google Play 内部データ）
上のグラフで 1 か月に 1 日しか購入していないユーザーの ARPPU を見ると、その 80% は購入額が 10 ドル未満であることがわかります。購入者の 50% が 1 か月に 1 日しか購入しておらず、そのうち 80% が 10 ドル未満しか購入していないとしたら、これは売上を上げる大きな機会ではないでしょうか。
彼らの半数が、あと 5 ドルずつ購入してくれるようになったとしたらどうでしょう。かなりの収益増ですし、しかもそれは継続的に見込める売上です。どうしたらこの機会をものにすることができるでしょうか。
選択肢はいくつかあります。たとえば、ターゲットを絞って特典を提示したり、セールを実施したり、これらのユーザーにとって特に魅力的な価値提案を行ったりできます。
ゲームの収益力を高めたいなら、どのように価値提案すべきかじっくり考えることが重要です。以下の点を考えてみましょう。
お買い得だということをユーザーにどう伝えますか？
その「価値」はどれくらい魅力的ですか？
ユーザーは何が手に入るかを簡単に理解できますか？
また、セールのセグメント化と特典の提示方法も検討する必要があります。ユーザーの立場で考えてみましょう。たとえば 1 か月に 1 回 5 ドルしか購入しない人が、100 ドルの SKU が 5 ドル割引セールになっているのを見たらどう思うでしょうか。高額購入者限定で、魅力的な価値提案が行われていると知ったらどう感じるでしょう。たった 5 ドル分のアセットでは、一気に 100 ドル購入する人に勝てるはずがないとあきらめてしまうかもしれません。
つまり、ユーザーをどうセグメント化し、特典をどう提示するかを考える必要があるということです。プレーヤーの購入パターンに合った特典を、彼らが魅力的と感じるように提示するようにしましょう。
もう 1 つの効果的な戦術が、Google Play でもよく見かけるようになった
日替わりセール
です。上位のゲームは、日替わりセールをうまく活用してアセットの価値や希少性を伝え、それを購入することで得られる満足感を高めるようにしています。
最後に、
リピート購入ボーナス
という戦術についても簡単に触れておきます。たとえば、ユーザーがその月に初めて購入したとき、7 日以内にもう一度購入すれば 10% のボーナスをプレゼントする、といった提案です。これをきっかけに、毎週購入することが習慣になるかもしれません。
二次的な指標を最適化する
収益上位のゲームの二次的な指標 - 2018 年 1 月～6 月（出典: Google Play 内部データ）
Google Play のトップ 250 の IAP ゲームについてデータを見ると、「購入者ごとの取引数（TX / Buyer）」は1.5～1.9 回、「平均取引額（ATV）」は 8.50～25 ドルとなっています。これらから算出した「有料ユーザーごとの平均売上（ARPPU）」は、ゲームによって幅はありますが、13.70～44.50 ドルの間に収まっています。
数字だけ見ると高収益な感じがしますが、多くの場合ごく一部のユーザーが平均を引き上げています。これらの指標間の関係から、売上改善の機会を見い出せるかどうか検討してみましょう。
「有料ユーザーごとの平均売上」と「平均取引額」の相関
（出典: Google Play 内部データ）
この図を見ると、「有料ユーザーごとの平均売上（ARPPU）」と「平均取引額（ATV）」の間には正の相関があることがわかります。ユーザーごとの購入額を増やすことができれば、効果的に売上を伸ばすことができそうです。しかも、1 日あたりの「購入者ごとの取引数（TX / Buyer）」は1.5～1.9 回しかありません。「有料ユーザーごとの平均売上（ARPPU）」を高めるうえで鍵を握るのは、どうやら「平均取引額（ATV）」のようです。
「有料ユーザーごとの平均売上」と「購入者ごとの取引数」の相関
（出典: Google Play 内部データ）
一方、「有料ユーザーごとの平均売上（ARPPU）」と「購入者ごとの取引数（TX / Buyer）」のプロットはノイズだらけです。クラスタ分析や曲線当てはめなどの相似解析も試しましたが、信頼度の高いパターンは見つかりませんでした。おそらくこの指標はゲームの設計（またはゲーム内経済）と関係しており、それらを考慮に入れることで相関関係を見い出せるかもしれません。
もしあなたのゲームが 25 パーセンタイル以下に入るなら、次の点を検証する必要があります。
ゲーム内で販売しているアセットの数はいくつですか？
販売しているアセットタイプは 1 つのみですか？（ジェム、コイン、クレジットなど）
どれくらいの価格で販売していますか？
購入者ごとの取引数が少なく、IAP の販売価格が非常に高い場合、通貨の流通速度はどれくらいですか？
ボーナスなどによりユーザーがなるべく大きなアセットセットを購入するよう動機付けし、長い時間をかけてそれらのアセットを使い切ることを想定していますか？それとも、アセットはいつか使い切るので、急いで何度も購入してもらう必要はないと考えていますか？
一方、あなたのゲームが 75 パーセンタイル以上に入るなら、次の点を検証する必要があります。
販売しているアセットの数はいくつですか？
2 つ以上のアセットタイプを販売しているなら非常に健全な状態です。1 種類のアセットしか販売していない場合、衝動買いを誘発するために、ゲームにどのような仕組みを取り入れていますか？
ユーザーが非常に小さい取引を、毎日何度も行うよう動機付けすることを想定していますか？
最後の質問に対する答えが「はい」なら、売上をあげる機会を逃しているおそれがあります。ユーザーが購入するかどうかを何度も決断する必要がある場合、購入しないという決断をする可能性が生じるからです。これを避けるには、ユーザーがより高価なものを選択する機会を提供することです。X ジェムを 2 ドルで販売するだけでなく、2 ドルと 5 ドルのジェムを提示して、ユーザーがより高いものに興味を示すかどうかを確認するのです。
ここにも最適化や改善の機会はありますが、どの方法が適切かはゲームによって異なります。最適な方法を見つけるには、開発段階で次の点を検証してみてください。
通貨の流通速度はどれくらいですか？
プレーヤーによる衝動買いは 1 日に何回ありますか？
ゲームの仕組みで、プレーヤーがアセットをため込む動機付けになっているものはありませんか？
ゲーム内経済をどのように設計していますか？
資本支出経済（ユーザーが主にジェムなどのアセットを購入し、それを使用して永続的なアップグレードを手に入れる仕組み）になっていますか？
それとも、消費可能なアセットを中心とした経済（プレーヤーがコインやクレジットなどの消費可能なアセットを購入し、日々のプレイにおいて消費する仕組み）になっていますか？
終わりに
売上成長を効果的に加速させるには、最適化の余地があることを示す兆候を見つけることが重要です。
Google Play で上位にランクするゲームは日々の売上変動が少なく、そういうゲームほど売上が成長しやすい傾向にあります。売上の変動性を評価し、LiveOps の供給側と需要側のバランスをとって変動を最小限に抑えるようにしましょう。
Google Play のトップ 25 のゲームの特徴は、下位のゲームに比べ高額購入者への依存度が低いことです。ゲームの収益構造が 80 対 20 の法則に当てはまっていないか、購入者の層を広げて多様化する機会はないか検討してください。1 か月に 1 回しか購入しないユーザーに、もう 1 回余分に購入してもらうにはどうしたらよいかを考えてみましょう。
「平均取引額」と「有料ユーザーごとの平均売上」には強い正の相関がありますが、「購入者ごとの取引数」と「有料ユーザーごとの平均売上」には相関はありません。これを最適化にどう結びつけるかはゲームによって異なり、創造力が試される部分です。
ここに挙げた 3 つの領域に取り組むことで、ゲームの成長戦略を最適化し、目に見える成果を上げることができるはずです。
Reviewed by Toru Shimazaki - Google Play, Partner Development Manager
ラベル
.app
1
.dev
1
#DevFest16
1
#DevFest17
1
#DevFest18
1
#hack4jp
3
A/B Testing
1
A4A
4
Actions on Google
14
Activation Atlas
1
Addy Osmani
1
ADK
2
AdMob
31
Ads
28
Ads API
21
AdWords API
9
Agency
1
AI
3
AIY
3
AIY Vision Kit
2
ALPN
1
AMP
71
AMP Cache
5
AMP for Email
1
AMP Story
2
amp-bind
1
AMPHTML Ads
1
Analytics
9
Andorid
12
Android
312
Android Auto
1
Android Design Support Library
1
Android Developer Story
4
Android Developers
4
Android Go
1
Android Jetpack
2
Android N
18
Android O
13
Android P
7
Android Pay
1
Android Q
2
Android Security Year in Review
1
Android Studio
32
Android Support Library
5
Android Things
15
Android TV
10
Android Vitals
3
Android Wear
29
androidmarket
3
AndroidX
2
Angular
2
Angular 2
2
AngularJS
2
API
25
APIExpert
45
apk
2
app
3
App Action
1
app engine
23
App Indexing
7
App Invites
6
App Maker
2
AppCompat
2
Apps Script
11
aprilfool
4
AR
2
Architecture Components
6
ARCore
1
ArtTech
1
Associate Android Developer Certificate
1
Audio
6
Auth Code
1
Authentication
8
AuthSub
2
Autotrack
2
Awareness API
1
Beacons
6
Better Ads Standards
1
BigQuery
9
Billing
1
BLE
4
Blink
1
Blockly
1
blogger
1
BodyPix
1
Brillo
1
Brotli
2
Budou
1
Calendar
3
Cardboard
4
Career
1
Case Study
1
Certificate
2
chrome
106
Chrome Custom Tab
2
Chrome Dev Summit
2
chrome extension
6
Chrome for Android
2
Chrome for iOS
2
Chrome OS
2
Chrome Tech Talk Night
3
Chromebook
3
Chromecast
7
chromewebstore
6
Chromium
5
CLI
1
ClientLogin
3
Closure Compiler
1
Cloud
20
Cloud Firestore
3
Cloud Functions
9
Cloud IoT Device SDK
1
Cloud Next
6
Cloud OnBoard
3
Cloud PubSub
1
Cloud Storage
1
Cloud Study Jams
2
Cloud Test Lab
2
Coalition for Better Ads
1
CocoaPods
1
codejam
5
codelab
4
Colaboratory
1
Community
1
compute engine
3
Context
1
Coral
2
Crash Reporting
2
Crashlytics
1
Dart
2
DataCenter
1
Daydream
4
Deep Learning
3
Demo Party
1
Design Sprint
3
DesignBytes
1
DevArt
3
DevBytes
6
Developer
14
Developer Console
4
Developer Preview
6
Developer Relations
2
DevFest
7
DevFestX
3
DevOps
1
devtools
4
Dialogflow
1
DirectShare
1
Domain
1
Doodle
1
DoubleClick
4
Doze モード
1
drive
2
Dynamic Links
3
EarlGrey
1
Easter Egg
1
ECMAScript 2015
1
Eddystone
4
egypt
1
Encryption
1
English
2
ES2015
1
ES2016
1
ES6
2
ES7
1
Featured
2
Firebase
107
Firebase Admin SDK
6
Firebase Analytics
10
Firebase Auth
4
Firebase Cloud Messaging
10
Firebase Crashlytics
2
Firebase Database
5
Firebase Libraries
1
Firebase Notifications
1
Firebase Performance
3
Firebase Remote Config
5
Flash
1
Flutter
4
font
3
fraud
1
G Suite
18
game
27
Game Developers Conference 2018
1
Gboard
1
GCP
6
GCPUG
1
GDD11JP
56
GDD2010JP
23
GDE
2
GDG
15
GDG Cloud
1
Geo
50
Gingerbread
1
GLIDE
5
Gmail
4
Gmail API
2
Go
1
golang
5
goo.gl
1
Google
5
Google Analytics
3
Google API
1
Google Apps
14
Google Apps Script
4
Google Assistant
7
Google Assistant SDK
1
Google Cast
8
Google Cloud
20
Google Cloud INSIDE Games & Apps
6
Google Cloud Messaging
11
Google Cloud Platform
11
Google Code-in
1
Google Developer Experts
2
Google Developers Academy
1
Google Developers live
5
Google Developers Summit
2
Google Drive
6
Google Fit
2
Google for Mobile
2
Google for Work
1
Google I/O
10
Google Impact Challenge
1
Google Maps
55
Google Maps Platform
3
Google Pay
1
Google Play
88
Google Play Console
6
Google Play Game Services
9
Google Play Instant
1
Google Play Services
22
Google Plus
14
Google Search
7
Google Sheets API
3
Google Sign-In
12
Google Slides API
5
Google Summer of Code
1
Google Tag Manager
1
Google Trust Services
1
Google マップ
3
Google+
2
Googleapps
10
GoogleGames
1
GoogleI/O
28
GoogleLabs
1
GooglePlay
1
GoogleTV
1
Gradle
1
gRPC
2
GTUG
5
GWT
2
hack4jp
2
hackathon
7
Hangouts Chat
2
Hosting
3
HTML5
17
HTML5Rocks
1
HTTP/2
5
HTTPS
11
ID Token
1
Identity
14
Identity Toolkit
1
Ignite
4
IME
11
Indie Games Festival 2018
2
Indie Games Festival 2019
4
Inevitable ja Night
18
Instant Apps
5
intern
2
Invites
1
iOS
20
IoT
6
IPv6
1
Issue Tracker
2
Japanese Input
1
JavaScript
7
Jetpack
1
K-12
1
Key Transparency
1
Knowledge Graph
1
Kotlin
5
l10n
8
LaunchPad
1
Lighthouse
1
LINE
1
Local AI
1
Lollipop
10
Machine Learning
18
Marshmallow
10
Material
1
Material Design
27
MDL
1
MDN
1
MIDI
2
ML Kit
5
Mobile
12
Mobile Bootcamp
4
Mobile Sites certification
1
Mobile Vision
4
mod_pagespeed
1
monetize
3
Mozc
15
Music
1
NativeDriver
2
NativeScript
1
NBU
1
ndk
3
Nearby
5
Next Extended
1
Next Tokyo
1
Nexus
2
Nexus S
1
NFC
1
Node.js
3
Noto CJK
1
NPAPI
2
NPN
1
oauth
11
OpenAI
1
OpenGL
4
OpenID
3
OpenID Connect
4
OpenSocial
1
opensource
17
Optimization
1
Payment
4
PEM
30
People API
2
Performance
12
Performance budget
1
PersonFinder
1
Physical Web
3
Pi
1
Place Picker
1
Play Billing Library
1
Player Analytics
4
Playtime 2017
1
Policy
4
Polymer
7
Progressive Web Apps
13
project hosting
1
Promise
1
Promo code
1
Protocol Buffers
1
PRPL
1
publicdata
1
Push API
1
Push Notification
3
PWA
2
Python
2
QUIC
1
QWIKLABS
2
RAIL
1
React
1
React Native
2
Realtime Database
9
reCaptcha
1
Redux
1
Remote Config
3
Remote Display API
1
Resonance Audio
1
Rewarded Video Ads
2
Runtime Permission
1
Safe Browsing
1
Sample Code
2
Santa Tracker
1
schema.org
1
secur
1
security
44
Service Worker
4
SHA-1
1
sketchup
1
SmartLock for Passwords
4
social
4
Social Good
1
SPDY
3
speak2tweet
1
Spreadsheet
3
startup
5
Storage
2
story
1
streetview
3
Study Jams
5
Swift
2
SwiftShader
1
Symantec
1
Task
4
Team Drive
1
techtalk
12
TensorFlow
23
TensorFlow Federated
1
TensorFlow Lite
3
TensorFlow Object Detection API
1
TensorFlow Probability
2
TensorFlow.js
1
test
4
Test Lab
6
ToS
1
Transliteration
1
Twitter
1
Udacity
20
Unity
3
UX
4
V8
2
VP9
1
VR
11
Vulkan
2
Watch Face
2
wave
2
Wear OS
2
Weave
1
Web
17
Web Animations
1
Web Components
6
Web Manifest
1
Web Packaging
2
WebAssembly
3
WebGL
1
WebMusic
5
WebView
1
WTM
4
Xcode
1
YouTube
16
YouTube API
1
インタビュー
1
コードサンプル
1
プライバシー
1
言論の自由
1
節電
3
東日本大震災
9
日本語入力
41
ブログ アーカイブ
2019
4
3
2
1
2018
12
11
10
9
8
7
6
5
4
3
2
1
2017
12
11
10
9
8
7
6
5
4
3
2
1
2016
12
11
10
9
8
7
6
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
2014
12
11
10
9
8
7
6
5
4
3
2
1
2013
12
11
10
9
8
7
6
5
4
3
2
1
2012
12
11
10
9
8
7
6
5
4
3
2
1
2011
12
11
10
9
8
7
6
5
4
3
2
1
2010
12
11
Feed
Google
on
Follow @googledevjp
"プロダクトに関するご意見は
プロダクトフォーラム
にお願いします"
