コンテンツ・メディア第1事業部の荒木です。ピクトリンクというプリントシール画像を使ったアプリのAndroid版を開発しています。最近、AndroidAnnotationsのDependency Injection部分をDagger2に移行したので、そのレポートを書きたいと思います。技術的な話よりも、なぜ移行に踏み切り、どのように進めていったかという過程について詳しく書いていきます。

移行する理由

AndroidAnnotationsとは、コード量を削減して開発効率を上げることを目的としたライブラリです。アノテーションをつけることで、さまざまなコードを自動生成してくれます。ピクトリンクのAndroidアプリでは、View Binding、クリックリスナーの設定、savedInstanceStateの管理、画面間の値渡し、Dependency Injection (以下、DI) にAndroidAnnotationsを利用していました。実際、コード量の削減に大きく貢献しているように思います。

 

では、なぜAndroidAnnotationsから移行するのか。一番の理由は、AndroidAnnotationsの影響範囲がアプリケーション全体に及んでいたからです。一つのライブラリの影響範囲が広いと、もし何らかの理由(人気が低下して更新がなくなる、他のライブラリとの相性が悪いなど)でそのライブラリ使えなくなった場合、アプリケーション全体に影響してしまうので大きな技術的負債となってしまいます。そこで、AndroidAnnotationsの各機能を少しずつ他のライブラリに移して影響範囲を減らしたいと考えました。もともとDI機能の一部にDagger2を導入していたので、今回はAndroidAnnotationsのDI部分を全てDagger2に移行することにしました。

 

また、

  • ビルド時間の増大
  • Hoge_のような Hogeを継承したクラスが自動生成される → 自動生成されたクラスを意識する必要がある

といった点も移行の理由として挙げられます。

移行の流れ

AndroidAnnotationsの@Bean@RootContextによってクラスやContextをインジェクトしている部分をDagger2を利用したコードに置き換えていきたいと思います。

前提

私の所属するチームでは、GitおよびGithubでコードを管理しています。書いたコードは、必ずPull Request(以下、PR)によるレビューを通してからプロジェクトにマージするというルールで開発をしています。今回は、PRを作成するときや、継続的にコミットするために意識したことを書きたいと思います。

方針を示すPRを作成する

完全に移行が完了した状態でPRを投げた場合、

  • 差分が大きくてレビューが大変になる
  • 指摘があった場合、修正箇所が大きくなる

といった問題が出てくると考えたので、まずは一部の画面にだけDagger2を導入したPRを投げることにしました。実際に投げたPRのメッセージは以下です。

Dadder2導入のPR

今後のコードの書き方に大きく影響するので、他のメンバーに受け入れてもらえるように目的や動作について詳しく書きました。

継続的にコミットを進める

PRが無事マージされたので、次は移行作業に入りました。対象クラスが多くて一気に移行するのは難しい状況だったので、毎日少しずつ移行していくことにしました。一度パターンができてしまえば、移行作業は単純作業の繰り返しでつまらないものです。そのため、日々の業務の中でコツコツ進めるのはモチベーションの維持が大変でした。

そこで、1クラスだけ移行した状態でPRをあげて、PRのメッセージに移行すべきクラスのリストを作り、完了したものにチェックをしていくようにしました。こうすることで、いくつ終わったか、いつ終わりそうかが目に見えるようになったので、モチベーションを維持しながら毎日コツコツと移行を進めることができました。

Inject完了リスト

さいごに

この記事では、Androidアプリ開発をする中でAndroidAnnotationsから移行する判断に踏み切ったこと、そして段階的に移行作業を進めたことについてレポートしました。一度に全てを移行することを考えると終わりがないように見えますが、段階的に取り組むことで確実に前に進むことができると思います。千里の道も一歩からという言葉があるようにリファクタリングも一歩ずつ確実に取り組んでいく必要があると感じました。今後は、View Bindingの部分や画面間の値渡しに対して、リファクタリングを進めていきたいです。



こんにちは。コンテンツ・メディア第1事業部の開発課のログチームのラヒルです。

本日は、前回のブログで紹介したデータマイニング用のデータを用いてよく行われているデータマイニング手法を紹介します。

 

前回紹介した準備したデータの5種類は、以下の通りです。

①ユーザーのイベントデータ

②ユーザーのステータスデータ

③ユーザーイベントの定期要約データ

④ユーザーのステータスの時系列変化

⑤システム要約データ

上記の5種類のデータを使って、どのようなデータマイニング手法を用いてユーザー分析をしているかを説明します。

ユーザーイベントデータ

ユーザーイベントをそのまま使える分析手法としては、アソシエーション分析があります。

①アソシエーション分析

ユーザーが同時に、あるいは一定の期間内に行うアクションを抽出するマイニング手法です。Aアクションを行うユーザーはBアクションも行うような関連性のあるアクションを洗い出します。例えば、サービス内では、Bアクションを増やしたいという施策を考えています。その場合、ユーザーが同時にしている他のアクションを分かっていれば、Bアクションの動機が何かを把握できたり、Aアクションを促進することによって、Bアクションを増やしたりすることが可能になります。アソシエーション分析によく出る例としては、スーパーマーケットの買い物で、ビールを買うユーザーは同時に子供用のおむつも購入するという有名な例があります。同時に何を購入する把握することで、スーパーの品物の並べ方を効率的に計画できます。アソシエーション分析は、R言語のarulesパッケージを使って実施できます。

ユーザーイベントはそのままアソシエーション分析以外のデータマイニングに使うのは中々難しいです。データマイニングは、基本的に説明変数を基に色々分析を行う。ユーザーイベントは用いて、ユーザーの特性を定義できるように変数化する必要があります。

ユーザーのステータスデータとユーザーイベントの定期要約データ

ユーザーのステータスデータとユーザーイベントの定期要約データには、大きく以下のような種類の分析手法に使います。

①予測分析

予測分析とは、ユーザーの現在のステータスや直近の行動状況によって、将来どのような行動をするかを予測する分析手法です。ユーザーの現在のステータスや直近の行動状況をは、変数で表します。この変数は、説明変数と呼びます。予測する値は、目的変数と呼びます。目的変数が連続型変数の場合は回帰分析と呼び、不連続型変数の場合は分類と呼びます。予測分析の応用例としては、サービスの利用を離脱しそうなユーザーを把握して離脱対策を計画したり、課金する可能性の高いユーザーを優先的に有料コンテンツへと誘導したりして、動的にオンラインサービスをユーザーの特性に合わせた最適なサービス設計が可能となります。予測分析に利用できるアルゴリズムには、様々なアルゴリズムがあります。例として、線形回帰分析、logistic回帰分析、ニューラルネットワーク、SVMなどがあります。私達のチームでは、オンラインサービスのデータに最も使いやすい「ランダムフォレスト」をよく使って分析を行います。別ブログ記事で、「ランダムフォレスト」を用いた予測分析方法の詳細を記述するので、ここでは詳細を省略します。

 

②クラスター分析

クラスター分析は、似たような特性、あるいは似たような行動をしているユーザーのグループを把握するための分析手法です。ユーザーのグループを把握することによって、ある特定のグループのユーザーだけをターゲットにして施策を計画することができます。きちんとユーザーの特性に合わせたサービス設計することによって、ユーザー満足度を上げることができます。このクラスター分析は、マーケティングではセグメンテーションとも呼ばれます。クラスター分析にも色々なアルゴリズムが存在します。よく使われるものとしては、kmeans等があります。

 

③相関分析

相関分析は、ユーザーの行動に相関が高いものを抽出します。オンラインサービスを例に挙げると、ソーシャルゲームでよく課金するユーザーは、どのようなプレイしているか、サイト滞在時間でよく見ているコンテンツはどういうものが多いか等が挙げられます。

R言語のcor()関数などを使って、相関分析を行っています。相関分析で気を付けないといけないことは、相関関係は高いけれども、因果関係があるとは限らないということです。因果関係に関しては、サービスの詳細も考えて、判断しないといけないです。

 

ユーザーのステータスの時系列変化

ユーザーのステータスの時系列データを扱う分析は、縦断データ分析と呼びます。ユーザーの行動の変化には、どのような変数が影響しているかが分析可能です。

オンラインサービスを例でいうと、

  • 毎月サービスの滞在時間が伸びているユーザーの特性は何か
  • 継続して使うユーザーと飛び飛びに使うユーザーの違いは何か

この要因を把握することで、ユーザーの満足度を高めるために重要な要因が把握できたりします。

 

システム要約データ

このデータは、各ユーザーごとの特性は表してないため、ユーザーレベルでの詳細分析に使うことはできないです。しかし、サービス全体として予測やトレンドを把握する、施策の効果測定などには非常に重要です。システム要約データは、時系列の一次元のデータとなっています。そのため、その他のデータと違い時系列データの分析手法を用いて分析します。

①時系列データ分析

長期トレンドを把握

時系列データは、長期トレンド、季節要因とその他の部分とを分解することができます。そのために、R言語のdecomposeなどの関数を用いています。時系列データから長期トレンド分をだけを観測することによって、サービスが長期的にどんな変化が起きているかなどが分かります。この長期トレンドは、特に外部要因による変化が多いです。そのため、早めに市場の長期トレンドを把握することによって、サービスの長期的なビジネスチャンスを把握できたり、危機的な状況が見つかったりして、早期対応が可能ともなります。

 

季節要因を把握

時系列データは、季節部分を把握することにより、特にサービスの需要が高くなる時期などを把握し、それに合わせた施策を計画したり、新しいビジネスチャンスを見つけることができます。たとえば、クリスマス時期に需要が高くなるとわかった場合、クリスマスを対象にした特別商品やサービスを計画することが可能となります。

 

施策の効果測定

時系列データから長期トレンドと季節要因部分を除外することにより、その他の要因によるサービスの利用状況の変化が分かりやすくなります。特にサービスの改善や変更施策を実施した場合、それによってどれ位サービスの利用状況の変化があったか等を調べたい時にはかなり有効です。

 

将来予測

サービスの時系列データはかなり複雑で、以前説明した長期トレンド、季節要因とその他の部分によって形成されています。サービスの将来予測をしたい場合は、その部分の要因を参考に計算した方が精度の高い予測が可能です。R言語のHoltwinters関数などを使って、時系列データの予測計算が可能です。

 

終わりに

本日は、データマイニング用に準備したデータを基に、どのような分析をしているかを軽く説明しました。今後、一個一個のデータマイニング手法を、R言語を用いた実施方法に関して詳細に説明する予定です。

 

 

 



 

こんにちは、コンテンツ・メディア第1事業部の開発課のログチームのラヒルです。

本日は、データマイニングを始めるためにはどのようにデータを準備する必要があるかを紹介します。

 

オンラインサービスのデータについて

簡単に分けると、オンラインサービスから蓄積されるデータには大きく2つのタイプがあります。

  1. データベース - サービス運用のために必要なデータが保存される。ユーザーのステータスやユーザーのアクションの結果等が記録されていることが多い
  2. アクセスログ - ユーザーのページアクセスやタップイベント等が記録されている。ウェブサーバーやアプリケーションサーバーに、ログファイルとして保存されている。

データベースのデータは、サービスを維持するために必要なデータが保存されています。しかし、このデータは分析用としてそのまま使うには難しいケースが多いです。アクセスログは、ユーザーがサービスを利用する上で、どのように使ったか(UIの操作履歴)の履歴となっています。ほとんどの場合は、そのまま分析するには複雑すぎることが多いです。では、データベースとアクセスログデータから、データマイニングあるいは分析用にどうデータを変換した方が良いかを説明します。私達のチームでは、この元のデータを加工して、データ分析用のデータベースに(データウェアハウス)保存しています。データ加工とテーブル設計等は、どのようにした方が良いか等を紹介します。

データマイニング用のデータ設計方法

サービスのデータを以下のようなデータ構造に変換してから、データ分析に使っています。

  1. ユーザーのイベントデータ
  2. ユーザーのステータスデータ
  3. ユーザーのイベントの定期要約データ
  4. ユーザーのステータスの時系列変化
  5. システム要約データ

データマイニングは、ほとんどの場合、ユーザーの行動あるいは体験を分析するために行います。そのため、①~④のテーブルは、ユーザーの行動あるいは体験をどう表すかを意識して設計しています。上記のデータの5種類について詳細に見ていきましょう。

①ユーザーイベントデータ

このデータは、ユーザーのアクションと体験を表します。アクションと体験は、サービスのUX設計等をベースに考えると考えやすいと思います。一つのデータレコードは、一つのアクションと体験を表します。しかし、場合によっては、この一レコードは、ユーザーの複数のUIアクセスやタップによって行う操作を、一つのアクションして抽象化しているものもあります。例えば、画像管理と投稿できるようなSNSアプリを参考に考えてみましょう。

主に考えられるユーザーイベント

  • 新規でアプリ登録する
  • チュートリアルを完了する
  • 友達を検索する
  • 友達をフォローする
  • 友達にフォローされる
  • 画像をアップする
  • 画像をアルバムに振り分け保存する
  • 画像を投稿する
  • 友達の画像にコメントする
  • 自分が投稿した画像に「いいね」される

このイベントを見ると、大きく2タイプのものがあることに気が付くと思います。ユーザーが自分の意思で行うアクション、ユーザーが体験することの2つです。一つのイベントが複数のアクションを完了することによって発生することもあります。例えば、画像投稿のイベントは、画像を選ぶ、タイトルを入力する、コメントを入力する、カテゴリー設定、ハッシュタグ設定、公開範囲の設定、等の複数のアクションによって完了されます。もちろん、このアクションを別々にイベントとして保存するということもできます。しかし、分析という意味では、細かいアクションの単位では、なかなか分析が難しくて複雑になりやすいです。そのため、ユーザーの行動は、ある程度に抽象化した形で、ユーザーイベントを定義した方が効果的だと思います。

ユーザーイベントデータの形式:

データは、5W2Hで保存します。誰が(Who)、何を(what)、どこで(Where)、いつ(when)、どの位(How many)、なぜ(Why)、どのように(How)の項目を記録します。イベントによって、5W2Hのすべてが存在しない時もあります。

SNSアプリを例にして、画像を投稿した場合を考えてみると、

Who – ユーザーID

What – 投稿ID

When – 投稿時刻

Where – どこのページで投稿したか

How many – 画像が何枚か

Why – 目的

How – なし

定義が難しいものもあります。特にWhere、WhyやHowの定義はイベントに依存します。

②ユーザーのステータスデータ

ユーザーのステータスデータとは、ユーザーの現在の状態を表すデータを保存するテーブルを意味します。このデータは、毎日のユーザーの行動によって変化するものもあります。そのため、いつも最新状態で保存されています。データを管理する単位は、現在私達のチームでは、データウェアハウスのデータを一日単位で管理しているため、一日一回更新されています。

ユーザーステータスには、二種類のデータがあります。

  • 固定情報:年齢、地域、性別、職業などのユーザーの情報
  • ユーザーの行動から生まれてくるステータス 例:サービス利用期間、友達の人数、保存されている画像枚数の合計等

このデータの特性は、その時刻であるユーザーを説明できるということです。特に、短期間では、著しく変化しない、あるいは、短期間での行動を表すというよりも、長期的な行動状況を表すようなデータを表す変数にした方が良いユーザーの特性に関しては意味があります。

悪い例:最終アクセス時刻

良い例:月間平均滞在時間

データマイニング手法などに使うときは、ユーザーの特性として使えるかという意味で評価します。

 

③ユーザーイベントの定期要約データ

データマイニング手法を用いたデータ分析には、ユーザーは説明変数を用いて表さないといけません。そのためには、ユーザーのイベントデータをそのままデータマイニング手法に使うことはできないことが多いです。その問題を解決するためには、イベントデータを何らかの形で変数化しないといけません。ユーザーの行動イベントは、定期的に要約して変数に変換します。

例:ユーザーのイベントデータから、一ヶ月間でユーザーのある特定のアクション数をカウントして変数として保存します。アプリ起動回数、「いいね」した件数、画像を投稿した件数、新規フォロー作成件数

 

このように変数化することによって、ユーザーの行動イベントの情報量を減らし、説明変数として使えるようになります。私達のチームのデータウェアハウス上では、ユーザーのイベント情報を集約して、ユーザーイベントの定期要約データを作成し保存されるようにしています。現在は、データの集約期間は一ヶ月を期間としています。データ分析を行いたい時には、この定期要約データを使うことが多いです。

④ユーザーのステータスの時系列変化

ユーザーのステータスデータの値は、日々変化していきます。そのため、ユーザーの状態が過去はどうだったか、あるいはどのように変化していたかを後で見るとわからなくなります。そのため、ユーザーのステータスデータを一定期間ごとに、スナップショットとして保存するようにしています。私達のチームのデータウェアハウスでは、スナップショットの保存間隔は一ヶ月間としています。1ユーザー当たり一ヶ月に一回、ユーザーのステータレコードとしてテーブルに挿入されます。このデータを使うと、ユーザーの成長あるいはサービスの利用頻度の変化等はユーザーごとに時系列のデータとして作成できます。

⑤システム要約データ

ユーザーベースのデータだけではなく、サービス全体として集約するデータを作成しています。このデータは、ユーザーの特性や予測には使いませんが、時系列データとして、サービスとしては将来予測に使います。

例:

デイリーアクティブユーザー数、マンスリーアクティブユーザー数、PV数、

新規登録ユーザー数、課金したユーザー数

データによって、一日ごとに集計するものと一ヶ月に一回集計するものがあります。

 

終わりに

本日は、データマイニング用のデータ準備方法に関して説明しました。サービスのデータベースとアクセスログを用いて、ユーザーの行動や体験を表すようなデータの加工方法に関して説明しました。今後は、このデータをどのようなデータマイニング手法に用いて分析しているかを説明します。

 

 

 



こんにちは。コンテンツ・メディア第1事業部の開発課のログチームのラヒルです。

本日は、予測モデルの構築方法として、「ランダムフォレスト」アルゴリズムについて紹介します。

ランダムフォレストのアルゴリズムについて

ランダムフォレストのアルゴリズムは、「決定木モデル」が基になっています。決定木モデルとは、よくプログラムで書くif then elseのような簡単な説明変数の値によって結果を決める手法のことです。ランダムフォレストは、複数の「決定木モデル」を足し合わせる(平均化)するようなアンサンブル学習(Ensemble learning)というアルゴリズムを利用します。そのため、決定木モデルよりも高性能な予測が可能となっています。ランダムフォレストのアルゴリズムは、以下のような特性があるためオンラインサービスのログ分析に適していると言われています。

  • 的変数と説明変数の型に(連続、不連続、バイナリー)何でも対応している

オンラインサービスの場合は、変数はユーザーの年齢(整数)、性別(不連続)、滞在時間(連続)であったりして、混ざったタイプの変数が多いです。そのため、何でも使えるランダムフォレストは便利です。

  • 変数の分布に依存しない

分析手法によって、変数の分布に制約はあります。例:ガウス分布

データの分布の判断は難しいようなケースが多いため、分布の制約は無い方が安心です。

  • 外れ値や欠損値などに強い

オンラインサービスの場合は、データが入っていなかったり、場合によっては、間違ったデータが入っていることがよくあります。例:値の代わりにnullが入っている等ランダムフォレストの予測モデルは、このようなデータによって影響を受けにくいため、データの前準備の手間を減らせます。

  • 説明変数の数が非常に多いケースにも応用できる

サービスユーザーの特性を表す変数の数は、20個も30個もあることはよくあります。そのため、説明変数の数が多くてもきちんと機能する手法が不可欠です。

  • 関係ない説明変数はモデルのパフォーマンスに影響しない。

線形回帰分析やニューラルネットワーク等は、目的変数と関係のない説明変数をモデル構築に使った場合、予測制度にかなり影響します。そのため、関係性のある目的変数だけを選ぶ等のデータの前準備が必要となります。しかし、ランダムフォレストは、そのような準備をする必要はあまりありません。

  • ビッグデータに対応しやすい

最近、オンラインサービスデータは数百万も数千万件もあることがよくあります。ランダムフォレストは、複数の「決定木」モデルを合わせるような計算手法になっているため、分散計算プラットフォーム(Hadoop, Spark)を使って大量のデータでも扱いやすいです。

 

R言語を用いたランダムフォレストのアルゴリズムの利用

R言語とは、統計解析を得意とする(Libraryが多くある)スクリプト言語です。無料でダウンロードして、Windows, Mac, Linux等どんな環境でも利用できます。CRANからオープンソースのライブラリを無料でダウンロードしインストールすることによって、データマイニングや統計解析手法のほとんどを無料で利用することができます。ランダムフォレストを利用するにはパッケージのインストールが必要です。

 

RandomForestのインストール:

install.packages(“randomForest”, dependencies = TRUE)

library(randomForest)

 

データサンプル:

ランダムフォレストに入力するデータを、CSV形式で以下のように準備する。

一行目がヘッダーとして変数名、二行目から変数の値をCSV形式で記述する。

v1は目的変数、v2~v6は説明変数

data.csv(データサンプル)

v1,v2,v3,v4,v5,v6

n11,n12,n13,n14,n15,n16

n21,n22,n23,n24,n25,n26

CSVデータの読み込み:

datacsv <-read.csv(file=”data.csv”,header = T)

 

モデル構築:

RFmodel <- randomForest(v1 ~ v2+v3+v4+v5+v6, data= datacsv)

N二番目の変数に、説明変数を‘+’で組み合わせて記述する。V1は目的変数、V2~v6は説明変数を表します。

全ての説明変数を予測モデル構築に使う場合は、

RFmodel <- randomForest(v1 ~ ., data= datacsv)

 

モデル評価:

予測モデルの評価方法には色々あります。しかし、Rのprint関数を使うだけで簡単にモデル評価ができます。

例えば、ランダムフォレストを、バイナリーの目的変数を予測に用いた場合は、以下のような結果が表示されます。

Call:

randomForest(formula = v1 ~ ., data = datacsv, ntree = 2000)

Type of random forest: classification

Number of trees: 2000

No. of variables tried at each split: 10

OOB estimate of  error rate: 28.82%

Confusion matrix:

continue redatsu class.error

r1     5573    1092   0.1638410

r2      2026    2128   0.4877227

真ん中のerror rate: 28.82%と出力されているのは、目的変数の予測の精度です。

100件を予測れば、28件の誤りが出る可能性があると出力されています。

モデルを用いた予測:

構築された予測モデルを用いて、結果(目的変数)の分からないユーザーのデータdata2を入力することで、予測値が出力されます。

Results <-  predict(RFmodel ,data2)

 

モデル構築時の注意点:

  1. 目的変数の情報が説明変数に漏れないこと。目的変数と同じ情報が説明変数にも入ってしまった場合は、予測モデルの結果の精度が高くなると評価されますが、実際にデータ予測を行った場合、非常に精度が悪くなる場合があるため、注意して変数を定義しないといけません。
  2. ラベルとして扱わないといけないラベルタイプ(不連続型データ)の変数を、R言語のfactor()を用いて、ラベルとして認識させる必要がある。
  3. パラメータのntree(決定木の数)の値が小さい場合、結果が不安定な時がある。特に、説明変数の数が多い時は、十分に大きな値のntreeを設定する必要がある。

 

終わりに

今回は、ランダムフォレストをR言語で用いた予測モデル構築方法に関して軽く説明しました。今後、ランダムフォレストを「要因分析」へ応用する方法に関して説明していきます。

 

参考資料:

Rのダウンロード

https://www.rstudio.com/

R言語について

http://qiita.com/stkdev/items/6aba2c1db2fa056170ae

RandomForestについて

https://www1.doshisha.ac.jp/~mjin/R/32/32.html



こんにちは。コンテンツ・メディア第1事業部の開発課のログチームのラヒルです。

本日は、データマイニング手法として予測モデルの構築方法について紹介します。

 

予測モデルとは

まず初めに、予測モデルとはどのようなものかを軽く説明します。 予測モデルとは、ユーザーの現在の行動や属性によって、将来どのようなアクションを起こすか予測が立てれるような数学的な手法のことです。

オンラインサービスで例を挙げると、

  • 将来、サービスを使わなくなる可能性のある(離脱する)ユーザーはどんなユーザーかを予測する。
  • 将来、課金する可能性の高いユーザーは誰かを予測する。

などが挙げられる。

予測モデルの結果の形によって、大きく2つのタイプがあります。

予測したい結果は、

  • 連側型変数 - 回帰分析(Regression analysis)
  • 不連続型変数 - 分類 (Classification)

予測モデルの結果を表す変数は、目的変数とも呼びます。予測モデルは、将来を予測するために色々なデータを利用します。そのデータを変数として定義して、予測モデルに入力します。このデータを表す変数は、目的変数と呼びます。目的変数にも、連続型と不連続型変数があります。

オンラインサービスで例を挙げると、

  • ユーザーの年齢、性別(不連続型変数)
  • 一日当たりの滞在時間(連続型)
  • 一ヶ月間での課金総額(連続型)

 

予測モデルの使い方

では、この予測モデルをどのように使うかを説明します。 予測モデルを用いて将来予測を行うためには、予測モデルを学習させないといけません。 そのために、目的変数と説明変数は既に知っているデータを用います。 オンラインサービスで例を挙げると、過去のユーザーのデータを用います。 各ユーザーが、将来どの位サイトで課金するかを予測するケースを考えましょう。 そのためには、過去のサイト利用者のデータを用います。

  • 目的変数:各ユーザーの総合課金額
  • 説明変数:ユーザーの年齢、性別、一日当たりの滞在時間等

既に結果を知っているデータを使い学習させることを、予測モデル構築と言います。 過去の結果を既に知っているユーザーのデータを使って学習させたモデルに、今後、結果(目的変数)を知らないユーザーのデータ(目的変数)を入力して、結果の予測(Predict)を行います。それによって、将来サービスでどのようなことが起きるかという予測を立てられます。この予測を使い、サービスの改善や将来の計画がしやすくなります。

 

予測モデルのアルゴリズムについて

予測モデルを構築できる手法は世の中には、たくさんあります。例をあげると、線形回帰、logistic回帰分析、ニューラルネットワーク、決定木、サポートベクターマシーンなどがあります。アルゴリズムは、すべてが万能ではありません。手法によって、目的変数と説明変数の形(連続、不連続)が限られたり、変数の値のデータ分布の制約があったり、データのノイズや欠陥への対応が苦手だったりします。そのため、予測モデルのアルゴリズムの選び方は、きちんとデータの中身を理解してそれにあった手法を選ばないといけません。データマイニングでよく言われるのは、「ごみを入れるとごみが出てくる」(Gabage-in,garbage-out)ので、注意して応用しないといけません。この記事では、分析手法の詳細は説明しませんが、今後別の記事でR言語を用いて予測モデルの構築する方法を説明する予定です。

 

終わりに

今回は、予測モデル構築とはどういうものか、変数の定義方法等についてオンラインサービスをケースとして軽く説明しました。今後、具体的に各予測モデル構築手法に関する手法に関して説明していきます。


Posted bymaeda


こんにちは、コンテンツ・メディア第一事業部 前田です。

業務でSpring Bootを使って新しくプロジェクトを作成する機会がありましたので、新規プロジェクト作成、実行、設定ファイルの分け方についてまとめていきます。

Spring Bootとは

簡単にSpringプロジェクトを作成することができるフレームワークです。

Spring だと最初に様々な設定をする必要がありますが、Spring Bootには必要ありません。xml設定ファイルがそもそもありません。また、プロジェクトを起動するのにTomcatも必要ありません。jarファイルを使って、javaコマンドでアプリケーションを実行することが可能です。

Spring Bootで新規プロジェクトを作成する

環境

 IDE IntelliJ IDEA
JDKバージョン JDK 8
Mavenバージョン 3.3.9

作成までの流れ

File→New→Project…からMavenを選択し、新規Project作成を選択します。

無題

プロジェクトを作成できたら、pom.xmlにSpring Bootを追加します。

spring-boot-starter-parent  Spring Bootの標準設定
spring-boot-starter-web Spring MVCの機能が入っている

これでSpring Bootの機能が使えるようになりました。

jarコマンドでプロジェクトを実行

Spring Bootではjarファイルを指定し、jarコマンドでプロジェクトを実行することができます。

まずはjarファイルを作成します。

これでtarget配下にjarが作成されます。

注意点として、mavenのバージョンが3以上でないと以下のようなエラーとなります。

mavenのバージョンは3以上で実行しましょう。

jarを作成したらjarコマンドを実行します。

で実行できます。

起動できれば以下の様なログが流れます。

起動時に適用する設定ファイルを指定したい

Spring Bootの設定ファイルはproperties形式とYAML形式があります。

ここではYAML形式で設定ファイルを作成することとします。

ymlファイルの名前を変更し、それを起動時に指定することで設定ファイルをわけることができます。

application-test.yml

の設定で起動したい場合、先程のjarコマンドで起動する際

のように書きます。

つまり、

application-指定する名前.yml

で設定ファイルを分けることができます。

感想

新規プロジェクト作成では設定でつまりがちで中々Hello Worldが出せない私ですが、Spring Bootではスムーズにプロジェクトを起動することができました。

参考

http://maplesystems.co.jp/blog/programming/18474.html

http://projects.spring.io/spring-boot/

http://www.techscore.com/blog/2014/05/01/spring-boot-introduction/


Posted byKayo


みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。今回は、OpenStackの続きで、7つのコンポーネントとノードの役割、構築手順についてお話しします。

7つのコンポーネントとノードの役割

前々回の記事でも少し触れましたが、OpenStackは7つの機能から構成されます。
注意:OpenStackのバージョンアップに伴い、コンポーネントの数も更新されます。実際には、16のコンポーネントが存在しますが、今回は、構築で重要となる7つについてお話ししたいと思います。

コンポーネント 役割
Nova 仮想マシンの提供と管理を行う
Keystone ユーザー認証・管理を行う
Horizon Webブラウザ経由で管理・操作できるGUIコンソールを提供する
Glance 仮想イメージの管理を行う
Cinder 仮想マシンが使用するストレージ管理を行う
Neutron 仮想ネットワークの管理を行う
Swift クラウドストレージを提供する

役割ノードの紹介

ノードタイプ 役割
controllernode OpenStack 環境が機能するために必要な管理ソフトウェアサービスを実行
computenode OpenStack 内の仮想マシンインスタンスを実行
storagenode OpenStack環境に必要な全データを保管
networknode Openstack環境に必要なすべての仮想ネットワーキングを実行

各コンポーネントとノードの紐づけ

各コンポーネントごとのノードの役割を下記の図で表しています。

Nova controllernode computenode
Keystone controllernode
Horizon controllernode
Glance controllernode
Cinder controllernode storagenode
Neutron controllernode computenode networknode

構築にあたって

7つのコンポーネントをどのサーバノードで稼働、同居させるかは、負荷分散や冗長化の観点から、とても大切な設計です。みなさんもご自身の環境、サーバスペックにあった構成を組んでいただければと思いますが、フリューでは、サーバ8台構成でOpenStackを構築しました。また、今まではCentOSを使うことが多かったのですが、OpenStackでは、Ubuntu14.04LTSをホストOSとして採用しました。

理由

  1. Ubuntuは標準パッケージでOpenStack環境が用意されている。
  2. Ubuntu/debianの基本方針として、ディストリビューションのバージョンが変更されない限り、パッケージのバージョンは更新しない方針なので、不意にOpenStack環境がバージョンアップされない。 ※Firefoxなど例外あり
  3. LTSを使用すれば、2年または4年毎くらいでディストリビューションのバージョンアップが可能。 ※サポート期間は5年

read more


Posted bymorioka


みなさんこんにちは、コンテンツ・メディア第1事業部の盛岡です。久々の投稿です。

今回のエントリは、関西モバイルアプリ研究会#15 で発表した内容を整理して掲載します。

今回は少し見難い画像もあるかもしれませんが、研究会で利用したものをそのまま利用してライブ感を持ってお届けします!

 

Firebase Dynamic Linksとは

公式ドキュメント

https://firebase.google.com/docs/dynamic-links/

 

概要

Firebase Dynamic Links(以下 FDL)とは、Android / iOSに対応したディープリンクを行うURLを生成するサービスです。

ディープリンクとは主にスマートフォン端末において、ネイティブアプリの特定のコンテンツへ直接リンクするようなものを指します。

さらにFDLの便利な機能として、「リンク時にアプリがインストールされてない場合、アプリインストール後に指定したリンク先へ戻すことが可能」という機能があります。強力な機能であり、是非活用したいですね。

 

スクリーンショット 2016-07-15 21.21.33

FDLの利用は無料であり、生成したURLを短くするいわゆる”短縮URL”としての機能もあります。

 

FDLの想定される用途

ドキュメントにも記載されてますが、用途としてはEメール/SNSなど検索エンジン外からのネイティブアプリへの誘導利用を想定されてます。
Firebaseではその他、検索エンジンからの誘導に「App Indexes」、ユーザー間での招待には「Invites」が用意されてます。

 

スクリーンショット 2016-07-11 13.39.38

 

各プラットフォームのディープリンク基礎知識

アプリケーションにFDLを対応させるために、以下のような技術について知識が必要です。

  • Android : App Links
  • iOS : URLScheme & Universal Links

 

以下で簡単に説明しますが、公式ドキュメントの一読をおすすめします。

 

App Links

公式ドキュメント

Handling App Links 

 

Androidにて、URLスキームに対応するのアプリケーションを起動するための仕組みです。

“AndroidManifest.xml”にURLとマッピングするActivityを指定します。

また、アプリケーションの証明書フィンガープリントを利用することで、起動スキームとアプリケーションを1対1で紐付けることも可能です。

 

Universal Links

公式ドキュメント

Support Universal Links

 

iOS9以降のiOSアプリケーションにて、http/https URLとアプリケーションをマッピングし、該当アプリケーションを起動するための仕組みです。

アプリケーション実装時に、”Associated Domains”を登録することで動作させます。(XCodeにて設定)

 

スクリーンショット 2016-07-15 21.26.01

 

また、マッピング対象のWebサイトルートに、”apple-app-site-association”ファイルを設置することでアプリケーションを起動するための認証を取ります。

(例:https://pictlink.comとアプリを連携させる場合、https://pictlink.com/apple-app-site-association を設置する)

 

iOS9ではアプリケーションがインストールされてない場合にAppStoreへの遷移を促す場合には、Universal Linksを利用するくらいしか手がないためにFDLでも利用しています。

 

Firebase Dynamic Linksコンソールにおけるドメインの払い出し

ここからは、Firebase側での処理を確認して行きます。

FDLを利用し始めるとドメインが払い出されます。

ここでは黒塗りしますが、  abcde.app.goo.gl  のような(abcdeはサンプル)ドメインが各Firebaseプロジェクト毎に出来上がります。

 

スクリーンショット 2016-07-11 11.11.34

 

上記の払い出された “app.goo.gl”は何に利用されるのでしょうか?

これは、FDLのリンクのドメイン部分として記述され、リダイレクタとして利用するイメージです。

 

また、Universal Linksの設定において、登録するドメインにもなります。

(app.goo.glとサービス側のドメインの2つをAssociated Domainsに登録する必要があります)

 

では、Universal Linksで利用するapple-app-site-associationは、”app.goo.gl”ではどうしているのでしょうか?

実際にiOSアプリケーションをFirebaseに登録後、app.goo.glを掘ってみました。

 

スクリーンショット 2016-07-11 11.18.26

app.goo.glにて動的に生成されてますね。

動的に生成されるapple-app-site-associationには、Firebaseプロジェクトに複数のiOSアプリケーションがあっても、全て含めてくれます。

 

アプリケーションへの組み込みについての補足

仕組みの解説は一旦終わり、実際の組み込みについてです。

Firebase自体の利用方法から、アプリケーションの登録、自社アプリへの組み込みまで公式ドキュメントの実装どおりに行えば問題無いと思います。

ただし、何点か補足があるので説明します。

 

補足1:Firebaseに登録したアプリケーションの項目設定

Firebaseに登録しているネイティブアプリケーションの設定項目を埋めるという作業がありますので忘れずにやっておきましょう。

以下の項目が、オプショナル扱いのものです。

アプリ種別 設定項目
Android 証明書フィンガープリント(SHA-1)
iOS App Store ID
iOS  チームID

 

App LinksやUniversal Linksにちゃんと対応するために必要です。

 

補足2:Universal Linksのデバッグ

iOS9対応のためにネイティブアプリケーション側でUniversal Linksの設定も必須となりますが、Universal Linksの設定はデバッグが難しいため注意が必要です。

そのため、私は以下のようなツールを活用していました。

 

App Search API Validation Tool – Apple Developer

34 iOS 9 Apps That Support Universal Links (updated 11-19) — Jack’s Place

 

あとは、Webサーバのアクセスログを確認などして地道に動作確認を実施していきました。

 

補足3:Androidの実装

Androidにおいて、アプリケーションインストール後のリンクを再取得する処理で注意が必要です。

以下にアプリケーション内で記述するサンプルソースを示します。DeepLinkを取得した後、処理をresultCallBack内に記載(下記9行目)しないとダメであり、ブロック外には制御は戻ってきません。

 

 

動作確認

実際のリンクサンプルと、動作確認を行った結果を示していきます。

 

パラメータ内容 値(サンプル)
FDL配布ドメイン abcde.app.goo.gl
コンテンツURL https://pictlink.com/myPage
Androidパッケージ名 jp.furyu.pictlink.android
iOSバンドルID jp.furyu.pictlink.ios
アプリScheme pictlink
AppStore ID 000000001

 

リンク

https://abcde.app.goo.gl/?link=https://pictlink.com/myPage&apn=jp.furyu.pictlink.android

&ibi=jp.furyu.pictlink.ios&ius=pictlink&isi=00000001

 

利用するパラメータを元に、公式ドキュメントに従ってリンクを組み立てましょう。

このようなリンク一つで、Android / iOSのアプリケーションの起動を制御出来るはずです。

(さらに、コンテンツURLに対応するWebサイトがれば、PCブラウザからはWebサイトへ遷移させることも可能です!)

 

動作確認結果

上記のパラメータを用いて動作確認を行った結果、以下の機能が対象OSにて動作しました。

 

 動作 Android iOS8 iOS9
アプリインストール時:リンククリック後アプリ起動
アプリ未インストール時:リンククリック後、アプリストアへ遷移
アプリインストール後:初回起動時にリンクアドレス再取得

 

まとめ

Firebase Dynamic Linksを利用することで、サービス運営者からネイティブアプリケーションへの誘導がうまく出来るようになります。

これまではリダイレクタを自作したり、複雑なjsを用意したり、”あまり触れたくない”ノウハウの塊のような箇所をFirebase側でソリューションとして提供してもらっているイメージです。

 

利用にあたり、アプリケーションの入り口となるコンテンツやページの設計には注意が必要です。アプリケーションとマッピングするサイトURLを丁寧に設計すれば「サイト→ネイティブアプリ」のシームレスな連携が可能になるでしょう。

 

また、導入方法自体はそれほど困難ではないのですが、FDLの動作とアプリケーションの動作を理解していないと、想定した動きにならないことが多いので時間が取られることもあるかもしれません。

個人的には、ディープリンクと言えばFirebase Dynamic Linksの利用が第一候補になっていくのでは、と考えます。本当に便利なものなので、みなさんも是非ご活用下さい。


Posted bymaeda


こんにちは、コンテンツ・メディア第1事業部の前田です。

業務で自動更新購読型のAppStore課金を取り入れたのですが、AppStoreから返却される自動更新購読レシートの中身がよく分からず行き詰まることがありました。今回は自動更新購読レシートを調べた中で分かった仕様や消耗型・非消耗型レシートとの違い、ユーザの課金状態によってレシートの内容はどう変化するかについて書いていきます。

AppStore自動更新購読のざっくりとした流れ

MjPZWUULH3UMZYQP-24407

上図が購入から完了までの流れになります。今回はレシートの内容についてなので詳細には触れません。

この図中にあるAppStoreAPIから返却された検証結果レシートの内容について詳しく見ていきます。

レシート仕様

AppStoreから返却されるレシート例を以下に示します。

レシートパラメータの各値は伏せ字にしておきます。見難いかと思いますがご了承下さい。

※レシートデータの内容はiOSのバージョン毎に異なりますので注意して下さい。

各パラメータ内容

重要なパラメータのみ説明します。

プロパティ 子プロパティ 内容
status レシートが正しければ0、異常であれば対応したエラーコードとなる。なお購読の有効期限が切れても0が返る。
receipt in_app latest_receiptの詳細となる。下記「in_app~消耗型・非消耗型プロダクトとの違い~」で詳しく説明。
latest_receipt_info 今まで購入した自動更新のレシートがすべて入る。下記「latest_receiptについて」で詳しく説明。
product_id なんの商品(たとえば1ヶ月購読と半年購読があったりした場合)を判別できるもの。
transaction_id 購入または更新に対するID。latest_receipt_infoの配列毎に値は異なる。
original_transaction_id product_idを購読購入したということに対するID。購読購入→一度やめる→また1年後に購入とした場合でも値は同じとなる。下記「original_transaction_idの検証で詳しく説明」
purchase_date transaction_idに対応した購読開始日時。
original_purchase_date transaction_idに対応した購読購入した日、または更新した日時。更新というのはApple側が更新をかけた日時であって、購読更新日(この日からまた購読)という日時ではない。
expires_date transaction_idに対応した購読期限。
cancellation_date Appleを通してキャンセルされた場合に入る。設定から自動更新オフした場合とかではない。ここに値が入っている場合は有効期限内であっても購入はキャンセルされているので注意。
latest_receipt 自動更新購読型にのみ存在する。アプリから渡され、レシートデータとしてAppStoreAPIへ渡す。ある購読情報をBase64エンコードしたもの。

in_appについて~消耗型・非消耗型プロダクトとの違い~

自動更新購読のレシート構造は消耗型・非消耗型プロダクト(ゲームなどによくあるアイテム課金等)のレシート構造といくつか違いがあります。非消耗型プロダクトのレシートは、in_appの中に課金したアイテムの情報が入ってきます。ですのでそのとき購入した情報はin_appを見れば分かるのですが、自動更新購読レシートはそうとは限りません。自動更新購読のin_appにはlatest_receiptに紐付く購入情報が入ってきます。latest_receiptが一番最新の購入情報であればin_appには最新の購入情報が入りますが、古いlatest_receiptであればin_appには古い購入情報が入ってきます。

具体的には下図のようになります。下図では自動更新購読の内容を「一ヶ月の定期購読課金」としています。

MjPZWUULH3UMZYQP-F3A95

 

 latest_receipt_infoについて

latest_receipt_infoは一見すると最新のレシートのみが入ってくるようにみえるのですが、ここにはアプリ内で購入した自動更新のレシート情報が全て入ってきます。一度更新をやめてしばらく経ってから再度購読を開始した場合でも、以前の購読レシートは一緒になって返ってきます。また、アプリ内にプロダクトが複数あり(300円コース、1000円コース等)、かつ両方で課金したことがある場合には両方の情報が入ってきます(下図参照)。

MjPZWUULH3UMZYQP-BA574 (1)

original_transaction_idの検証

以下図にある3つの状態でレシートを取得した際、original_transaction_idの内容について検証した結果をまとめます。

ここでは、自動更新購読の内容を「一ヶ月の定期購読課金」としています。

 

①1月1日に購読を開始し、2月、3月も購読を更新している場合

MjPZWUULH3UMZYQP-AB86F

latest_receipt_infoには3ヶ月分の購読情報が入ってくる。また、この3つのoriginal_transaction_idは全て同じものである。

 

②1月1日に購読を開始。1月5日に自動更新を解除したが、1月10日に更新解除をやめ、2月、3月と購読した場合

MjPZWUULH3UMZYQP-6EE2D

latest_receipt_infoには3ヶ月分の購読情報が入ってくる。また、この3つのoriginal_transaction_idは全て同じものである。

 

③1月1日に購読を開始し、1月5日に自動更新を解除。3月1日に購読を開始した場合。

MjPZWUULH3UMZYQP-7E69C

latest_receipt_infoには1月、3月の購読情報が入ってくる。また、この2つのoriginal_transaction_idは全て同じものである。

 

つまり、あるアプリ内で自動購読を開始すると、途中で更新解除→再度課金してもoriginal_transaction_idは全て同じとなります。じゃあどこで月々の購読情報を見分けるの?と言うと、transaction_idで見分けることができます。パラメータ内容にも書きましたが、transaction_idには購読が更新される毎に違う値が入ってくるからです。

感想

初めはレシートの中身がややこしすぎて全く分からない…と焦っていたのですが、実際に取得したSandboxのレシートを見てみることによって仕組みを理解することができました。今後自動更新購読を実装する際に参考になればと思います。

参考

In-App Purchaseプログラミングガイド

レシート検証プログラミングガイド

自動購読課金について【iOS編】- サイバーエージェント 公式エンジニアブログ

商標について

AppStore、In-App Purchaseは、Apple Inc.の商標です。



コンテンツ・メディア第1事業部の荒木です。ピクトリンクというアプリのAndroid版を開発しています。今回は、Google I/O 2016 で新しく生まれ変わったFirebaseを使ったABテストと、従来の方法であるGoogle Tag Manager (GTM)とGoogle Analytics (GA)を連携させて行うABテストの違いを見ることで、新しいFirebaseの強みと弱みを考えてみたいと思います。

ちなみに、この記事はumeda.apk #1でLT発表した内容をもとに書かれております。発表スライドは以下です。また、記事の最後にumeda.apkの様子についても書かせていただきます。

ABテストの流れ

GTM&GAでもFirebaseでもABテストの流れは、以下の三つのステップに分けられます。

  1. ABを出し分けるためのWebコンソールでの設定
  2. ABを受け取るためのアプリの実装
  3. テスト結果の解析

今回は、上記の三つのステップについてGTM&GAとFirebase Remote Configを比較したいと思います。

1. Webコンソールでの設定

GTM&GA

GTMのWebコンソールで「Google アナリティクスのウェブテスト」という変数を設定することで、ABの出し分けをすることができます(詳しく知りたい方は、 Google Tag Manager でAndroidアプリのABテスト -ABの出し分け- をご覧ください)。変数の設定画面は以下のようになっています。

GTM設定画面1

まだまだあります。

GTM設定画面2

結構長いですね。具体的には、GAとの連携部分やテストの詳細設定が項目数を増やしています。

Firebase Remote Config

FirebaseでABの出し分けをする際は、Remote Configを利用します。Remote Configとは、特定のキーに対する値をWeb上で自由に設定して、アプリに渡すことができるサービスです。アプリのアップデートをせずにWeb上で値を変えるだけで、ユーザーに見せる文言を変更したり、ゲームの難易度を調整したりできます。また、Remote Configには、ユーザーごとに違う値を渡す機能があります。ABテストではこの機能を利用してABの出し分けを行います。Remote Configの設定画面は以下のようになっています。

5. 条件の値を入力

先ほどと比べると、非常にシンプルな印象を受けるのではないでしょうか。Webコンソールで設定する項目を説明します。

パラメータ

パラメータとは、キーと値のペアのことです。たとえば、キーに”hoge”を指定したら値として”fuga”がもらえるという設定ができます。今回は、キー値”pattern”でデフォルト値”A”がもらえる設定を行います。

条件

条件とはパラメータにつけることができるもので、特定の条件を満たしたときだけ”hoge”キーで値として”piyo”がもらえるという設定ができます。たとえば、キー値”pattern”でデフォルトでは値として”A”を渡すが、半分のユーザーには”B”を渡したい場合、以下のように条件を追加してパラメータに追加し、条件達成時の値を”B”としてやれば、ABの出し分けができます。

2. 条件の追加

2. AB受け取りの実装

各手法の初期化とABの値の受け取りをJavaで実装します。

GTM&GA

初期化の流れは、

  • TagManagerインスタンスの生成
  • コンテナID(GTMのWebコンソールで取得)とデフォルト値(リモートからの値取得失敗時の値)の設定
  • リモートからの値取得完了時のコールバック設定

となっています。また、ABの値の取得にはContainer#getString(String key)が利用されています。

Firebase Remote Config

初期化の流れはGTM&GAとかなり似ています。

  • FirebaseRemoteConfigインスタンスの生成
  • デフォルト値(リモートからの値取得失敗時の値)の設定
  • リモートからの値取得完了時のコールバック設定

違う点は、GTMにおけるコンテナIDの設定に相当する部分がないことです。

また、ABの値の取得はFirebaseRemoteConfig#getString(String key)で行っています。この点もGTM&GAに似ていますが、GTMではリモートからの値取得完了時にContainerHolderのインスタンスを自作のシングルトンクラス(ContainerHolderSingleton)に保存しておく手間があるので、若干Firebaseの方がシンプルになっています。

3. テスト結果の解析

GTM&GA

GTMとGAを連携させた場合は、イベント送信時に自動的にそのイベントのセッションがどのパターンであるか(AであるかBであるか)の情報を付与してくれます。また、コンバージョン率やBのコンバージョンがAを上回る確率も計算して、GAのコンソールに表示してくれます。以下は、GAの「ウェブテスト」から見られる画面の例です。

GAテスト結果表示

Firebase Remote Config

Firebase Remote ConfigはAかBかの値をアプリに渡すだけなので、あるユーザーがAを受け取ったのかBを受け取ったのかの情報はイベント送信時に送る必要があります。Firebase Analyticsで送信する場合は、以下のようにカスタムパラメータを付与してイベント送信する必要があると思われます。

また、コンバージョン率の計算や統計的な解析なども自力で行う必要があります。私なら、Firebase AnalyticsとBigQueryを連携させて解析する方法をとると思います。

比較のまとめ

ここまで、ABテストの流れに沿ってGTM&GAとFirebase Remote Configを比較してきました。比較の結果をまとめると、

  1. Webコンソールの設定:Firebaseの方がシンプルである
  2. AB受け取りの実装:FirebaseはGTM&GAと似ている(Firebaseの方が若干シンプルである)
  3. テスト結果の解析:Firebaseは自前でやる必要がある

となりました。Firebaseの強みは、とにかくシンプルであることだと感じました。逆に、シンプルであるがゆえ、高度なことをするときは自分たちで考える必要がある点は抑えておきたいと考えました。

おまけ umeda.apk #1 について

突然ですが、京都はとても住みやすいところです。自転車でどこにでもいけるし、よいお店がたくさんあるし、観光地なので見るところもたくさんあります。そんな京都で私は働いているのですが、一つ困っていることがあります。それは、Android開発者の集まる勉強会が少ないことです。これは京都に限らず関西全体の話です。関西モバイルアプリ研究会という素晴らしい勉強会が京都を中心に開かれていていますが、こちらはiOSとAndroidの両方を対象にしているので、純粋にAndroidアプリ開発者の集まりとなるとなかなか見つかりません。そんな状況の中、umeda.apkという勉強会が6月17日にサイバーエージェントさんの大阪支社で開催されました。

 

この勉強会は、shibuya.apkという渋谷で開催されているAndroidアプリ開発者の勉強会を関西でもやろうということで開催されたそうです。第一回なので、どのような勉強会になるか分かりませんでしたが、日本有数のAndroidアプリ開発者の方が登壇されると知り、すぐに参加を決めました。#1のメインテーマは Google I/O 2016 の報告で、Building for Billions、Firebase、Android in Car、Awareness API、Project Tango、Google I/O セッションまとめ、設計の話(Bento vs Burrito)などの発表がありました。

 

発表を聞いた印象として、どの発表も非常に分かりやすかったです。参加前には、自分が理解できない高度な発表かもしれないと不安を抱いていましたが、Android開発をやっていて最新情報にも多少興味をもっている人なら十分ついていける内容でした。次回は8月に開催予定らしいので、また参加したいと思います。関西でAndroidアプリ開発をされている方は、是非参加してみてください。