Translate

2017/08/26

夏なんで、グロースハック始めました


暑い夏には暑いサービスが必要ということで、グロースハック始めました。

グロースハックとは?

データを分析して、売上の拡大にコミットすること。

ポイント:
・データを分析して、その結果に基いてPDCAを実行する。
・売上(=KGI、目標)とそれに紐づく指標(例えば再訪率、ARPU)にコミットする。売上に寄与しない指標に時間を使わない。

以上、よく「グロースハックってなんですか?」という質問があるが、うまく説明できなかったので自分の言葉で定義しました。どれも当たりの前のことだけど、それを当たり前に継続することが大切。

まず初めに


以下の本を読んで、グロースハックについて大まかに勉強した。

グロースハッカー
 グロースハックとは何か? その心構え。モチベーションがかなり上がった。

いちばんやさしいグロースハックの教本
 具体的に行動するための指針・ステップが説明されていて、非常に参考になった。この本がなかったら、何もできなかったと思う。かなりオススメ。

やったこと

・データ分析
今回はJupyter Notebookを構築し、売上DBをレプリケーションしたものから売上と関連する指標を月次・週次でグラフ化した。
また、Google AnalyticsとMixpanelを使い再訪率や離脱率などの現状も把握。

ARRRAモデルに従って改善
分析結果から、現サービスはARRRAモデルのRetentionの段階と考え、翌週再訪率をKPIと定めた。翌週再訪率を改善するためにお気に入り登録率の向上を目標とする。

経過


方向性が定まり、改善に着手した。まずは、サイト全体で致命的な点を解決するべく以下を実施。

・ランディングページで404エラーのページをリダイレクト設定
 => 離脱率が10%改善
・サイト全体の表示速度の改善
 Google Page Speed Insightsのスコアの改善(ブラウザキャッシュ、コンテンツ圧縮、画像最適化)。閲覧数の多いページの表示ロジックを改善
 => サイト全体のページロード時間が20%改善

結果、翌週再訪率が1.5%改善。

今後


まずは、すぐに改善できることを実施し、改善とモニタリングのサイクルを回し始めることができた。サイト全体の表示速度は、直接KPIに寄与するとともに、今後の改善策の効果を高めることが期待でき、ドッグフーディングにも嬉しい。
これからは、お気に入り登録率を改善するためにUX設計・ユーザーフローの検討をして、本格的にKPIの改善に着手する。

2017/01/12

Yahoo JAPAN の無料コワーキングスペース「LODGE」を体感

今のところ無料で使える話題?!のLOGDEを体感してみました。
https://lodge.yahoo.co.jp

LODGEの個人的なメリット:
・コワーキングスペースの選択肢が増える
・無料
・ランチがヘルシーで安い

行き方や詳細はこちらがとても参考になりました。
http://suppon.innovator.jp.net/entry/yahoo-lodge
http://hrnabi.com/2016/09/28/12131/

平日の11時に到着しましたが、席は8割ほど埋まっていて、あまり余裕はない感じでした。
淡々と作業されている方や、打ち合わせをしている方が半々くらいでした。

Wifiのパスワードは出入り口付近にしかないので、メモをとるか、その場で設定する必要がありました。

食堂は、600円前後の予算で、11時くらい〜14時くらいまで開いているようです。
(公式の情報もなく、見たり聞いたりした雰囲気ですので、参考にとどめてください。)
A/Bランチと量り売りブッフェとあって、量り売りを300g/600円でいただきました。
糖質オフしやすくてかなり良かったです。


また、カフェメニューはエスプレッソが300円弱とかなりお値打ちでした。

赤坂という場所が東京の中央で訪れやすいとのことですが、私は生活圏外のためあまり活用の機会は少なそうです。
赤坂近辺で活動されている方は、利用して損はないかと思いました。

Ruby On Rails で、AWS Elasticsearch のプラクティス

前回のTwitterアプリに引き続き、AWS Elasticsearchについても運用レベルのものを開発したので、開発の要点をまとめておきます。

参考:
https://www.elastic.co/guide/index.html
http://ruby-rails.hatenadiary.com/entry/20151018/1445142266#rails-elasticsearch-1-freetext-keyword
http://qiita.com/kyouryu_/items/061b3bc47c1d64b37818
http://easyramble.com/elasticsearch-queries-and-filters.html

やったこと

  • AES(Amazon Elasticsearch Service)を使ったElasticsearch
  • Railsのモデルを、Elasticsearchとして使う
  • RakeタスクでElasticsearchにデータをインポートする

要点

以降詳細を列挙していきますが、特に重要だと思ったポイント:

  • 本家サイトが大事。
    Qiitaとかまとめ記事いろいろあるけど、用語の意味や使い方が曖昧・まちまちなので、混乱しやすい。本家できちんと基礎から数時間かけて理解した方が最終的には速い。
  • いきなりRails使わずにCURLとかでElasticsearchってどういう感じなのかを掴んておくといいと思う。
    自分みたいに、いきなりRailsでmodel 使うGemを使うと、自分のやっていることがわけわからず、とりあえず動いているっていう状況になり、応用きかず設計変更やトラブルで大変になる。


AES(Amazon Elasticsearch Service)を使ったElasticsearch

ドメインの取得、オレゴン
Kibana使いづらい
AWS認証

Railsのモデルを、Elasticsearchとして使う

Gem model
検索
 Index、キーワード、AND、OR、Page、Page size、Aggs、Sort

RakeタスクでElasticsearchにデータをインポートする

Gem client

ソースコード



2016/09/30

流行りのビッグデータをやってみた。

最近、Twitterからツイートを分析するような作業が多かったので、これはデータ分析の入り口として良さそうだったので、勉強・実践してみた。

データ分析とは

この定義もかなりあいまいなようでピンとくる記事が見つからなくて困った。
一番わかりやすかったのはこちらのデータサイエンティストの説明。

以下自分なりにまとめた、作業・ツール。

収集 =>  整形  =>  蓄積 =>  分析・可視化
説明 アクセスログや可視化したい統計データなどをDBなどに保存する。 収集した時に実行する場合と、DB保存後にバッチ処理する場合がある。 データを保存しておく場所。DataWareHouseというらしい。 Visualization。これもリアルタイムでデータを更新していくものと、バッチ的に分析するものがある。
ツール
fluentd
logstach
Apache Spark
Hadoop
自作スクリプト
Apache Spark
Hadoop
自作スクリプト
Elasticsearch
Apache Solr
各DB
AWS S3
Google Drive
ローカル
Kibana
Banana
Jupyter
Rstudio
Data sientist workbench
スプレッドシート 

整形・分析などをサービスとして使えるBIツールというものがあるが、今回は調査できなかった。

今回やってみたこと

やり方はいろいろありすぎて、どれがいいのか分からず。流行りのデータ解析らしく、
Spark + Elasticsearch + Kibana
という割りと情報がありそうなものをやってみた。

参考記事とやった結果:
https://github.com/Samemura/twitter-spark

無事、SparkでデータをElasticsearchに蓄積し、Kibanaで表示できるようにできた。

感想

データ分析の流れを構築できたものの、効果的に分析できる方法は構築できなかった。
このあたりはKibanaでは限界がありそうなので、Jupyterなどで分析する方法を検討したい。
またデータ収集部分は、普段から使っているスクリプトなどでもあまり困らなそうだと感じた。大量のデータをリアルタイムで分析する、まさにビッグデータでなければメリットがなさそう。

アルゴリズムの検討などには、
1.自作スクリプトでデータ収集
2.Jupterなどで詳細分析・可視化
を次のステップとしたい。

2016/06/17

Webサイトの決済に、Amazon Paymentsを実装した。 そうRuby On Railsで。

仕事でAmazon Paymentsを使って決済機能を開発したので、そのまとめ。

まとめ

報告書は最初に結論が大事。ということで、早速まとめ。
  • Amazonが提供しているDocumentやサンプルが豊富でとても助かった。
  • サーバーサイドとフロントエンド(JavaScript)の両方で実装する必要があったので、他の決済と比べると理解に時間がかかった。
  • 仕様はオープンだが、ネットでの実装事例はなくて、完成イメージを持てずに苦労することもあった。
    →この記事がその助けになったら嬉しい。
  • サイトのUXはすごく向上したと思う。個人的にAmazonをよく使っていることもあり、Amazonログイン→支払いはとにかく簡単。
  • Amazon Paymentsのアカウント開設前に、すぐに使えるテスト環境はないため、事前の技術検証がほぼできなかった。Ruby SDKをAPI通信をスタブして、コードはかろうじて動かせた。これが改善されたら、もっと導入するところが増えると思う。他の決済サービスは準備されていることが多いらしい。
    (もちろん、サンドボックス環境はある)
  • 決済サービスってどれを選べばいいの?って決めるまでは全然決められなかった。考えれば考える程、どれでも同じなような。でもとにかくAmazonログインのUXを優先して決めてよかったと思う。Paypal, WebPayとかは導入はいいと思う(事例やドキュメントが多い)けど、UXの向上は見込みないので。

決済機能とは?

有名なのはPaypal、その他にも最近はいろいろあって、結構群雄割拠。

去年くらいまではPaypalっぽい専門の決済サービスが多かったようだが、大手ECサイト(Amazon / 楽天 / Line ?)が参画して、今後はこっちに流れていくような気がする。

理由は、既にアカウント持っている人が多ければ、その人はすぐに支払いができるから。
ユーザーには、決済のUIはあんまり重要じゃないと思う。
また、使っているサービスで支払いできた方が安心感もある。Amazonはそれを謳ってもいる。

Amazon Paymentsって?

って動画を見ても、あんまり理解できないと思う。
要は、Amazonでログインボタン、Amazonでお支払いボタンを自サイトに埋め込んで、Amazonアカウントで支払いができるということ。

決めた理由:
  • UXの向上
    →Amazonでログインは効果があるはず
  • 支払い手数料
    →競合と比較して大体同じ
  • 運営者の使い勝手
    →Amazon Seller Centralという、Amazonマーケットプレイスと同じプラットフォームで、安定
  • 定期支払い
    →会員年会費の支払いに使いたかったので、必須

サービス名がところどころ、Amazon ログイン&ペイメント とかってなっていてよくわからなくなるけど、多分世界的に共通な名称がAmazon Paymentsで、日本のサービス名がAmazon ログイン&ペイメントってことのよう。

大差ないが、APIはログインとペイメントで分かれているので、一応気にしておく必要はある。Ruby SDKは同じような名前のメソッドだけど。

Documentが豊富

amazon.co.jpでは問い合わせしないとDocumentがもらえない(なのでここで公開することは適切でないと思う)
しかし、amazon.comでは普通に公開されているので、こちらを参照するといい。
Forumもあって、質問すれば、1日くらいで回答きた。

実装

動線がすごくわかりにくいけど、こんな素晴らしいモックが用意されていて、これにかなりお世話になった。
使ったRuby SDK(gem)はこちら。

詳細はインテグレーションガイドを参照してもらうとして、概要はこんな感じ。
  1. JS(JavaScript)でログインボタンと支払いボタンを実装。
  2. ボタンを押すと、AmazonのJSがアカウントを認証し、指定したコールバックURLにリダイレクト、クエリパラメータでアクセストークンがついてくる。
  3. アクセストークンを使って、ユーザー情報を取得したり、支払い処理を実行する。
今回は、調べながらで2週間くらいで基本的な実装はできた。
Ruby SDKを使ったモックを自分でも作ったので、参考にしてもらえるとうれしい。
HerokuでPreviewも提供していて(Readme参照)、実際にはログインできないが、Amazonのログインウィンドウが出てくるところまでは見ることができる。

おまけ

Ruby SDKを使わせてもらったけど、日本のサンドボックス環境のEnd pointが間違っていたので、Forkして修正した。よかったら、こちらをどうぞ。

あと、細かいハマりポイントなども、質問されればなるべく回答しますので、お気軽にコメントどうぞ〜