Redashへのリプレイスから活用方法までの話
はじめに
最近ウチはAuroraに切り替えをしました。🎉🎉🎉
当然良かった点はいくつもありますが、一つにリーダーエンドポイントが気軽に増やせることがあります
なので一つAurora Readerを作成してAnalytics用途として活用しています。このコトを契機に分析用の仕組みを色々と改善できるなーと感じていて
Aurora切り替えが無事に完了してRedash導入後、1ヶ月経過したので少しまとめて見ようと思います
Redashに移行する前の分析
- バッチで必要なデータを取得・加工してElasticSearchに入れる
- Kibanaからグラフ化してダッシュボード化して見ていた
ここでの課題感
- 分析するデータが増えた場合、バッチ修正して、既存Indexも作り直してってとても面倒だった😰
- 定期バッチで取り込んでいたので多少なりともタイムラグが存在していた😰
- キャンセルなどで過去のデータ=過去のIndexに修正が入った場合に修正するのがとても手間だった😰
- Elasticsearchの運用も日に日にかさんでいった…😰
- Google Analyticsのデータは別で分析してた。一元管理できなかった😰
そこでRedashに乗り換えたわけですが
最終的な構成イメージ
利用者はまず社内の認証システム(Single Sign-On)で認証してからRedashの閲覧できます
Redashのデータ・ソースとしては下記を設定
- AuroraのAnalytics用途のReader
- Google Analytics
- Google Spreadsheet
- Python
Redashを選んだ理由
簡単に書くと下記の点でうちにはマッチすると思った
- 元々データ分析のソースとしてはDBのデータ、Google Analyticsを使っていてこの２つを一元的に扱いたいなーと思ってた
- Redash1系からGoogle Analyticsのデータを直接参照できるようになった
- 元々Google Spreadsheetをフル活用してて、それらの資産を取り込めてダッシュボード化できた点
- Shell Script経由でDBからデータを抽出してSpreadsheetに反映させたりと色々動いていた
- Google App Scriptを活用してSpreadsheetに反映させてたりと色々動いていた
- Elasticsearch+kibanaの時の課題感も当然解消できると思った
他のツールとの比較した
Amazon QuickSight
- Google Analyticsのデータをデータソースとして活用できない… キビシイ😅
- あくまでもAWS内のマネージメントサービス内にあるデータを効率的に分析できるツールのようです
Google Data Studio
- データソースには当然Google Analyticsを扱えた
- Aurora Readerの設定もできそうだったけどセキュリティ的な部分で少々不安を覚えた😅
- 表示している期間と前の期間との比較させて見せるグラフとか気に入ってたりしたんだけど…
- 検討していた当時は無料枠では5つしか作ることが出来ず、また有料枠も明確な価格設定を出してなくて、んーとなった😅
Tableau
ビジネスインテリジェンスとデータ分析 | Tableau Software
- 一番評判の良いツールなので当然、セキュアにDBにつながるし、Google Anayticsにも繋げられる
- ただ、価格がうちにとっては高かった…😅
- ツールの位置づけもバリバリのデータサイエンティストがフル活用してやっとペイするような話を他部署で聞いたし…
そしてRedashをどのように業務に活用しているか
ダッシュボードを複数に分けて使っている
色々一つのダッシュボードにまとめたくなるけど、表示重くなるし、目移りしちゃうので一つにまとめることはやめた。
それぞれの立場の人によって一番みたいデータが異なる。なので見る人が誰で何のデータを一番見たいかを基準にまとめてる
- ビジネスサイド人向けのダッシュボード
- 開発者向けの〇〇機能のチーム向けのダッシュボード といった感じ
あとは期間としては30日間を目安に集計したデータを表示している
- 時と場合によるけど目先追いかけるデータとしては直近30日間が妥当だと思っている
他のツールの計測数値をiframeでRedashのダッシュボードに表示している
うちで言うとNewrelic、SpeedCurveのデータは関連するKPIと一緒に見たいときがある。大体のサービスはiframeでの表示機能を提供しているのでそのURLをコピペしてダッシュボードに一緒に表示している
最近の新たな活用方法
- メルマガ用のアドレス抽出に活用してたり、経理の締め作業に活用してたりしている様子
- そのうちSQLを覚える人が増える事を期待している🙂
こうできると良いなと思う点
まとめ
今のところうまく運用できていると思っている😀
朝会の時に昨日のデータをRedashのダッシュボードから見てから朝会しても良いなーとか思ってたりする💪🏽
`Inspired: 顧客の心を捉える製品の創り方` を読んだ
読んだ本
- 作者: マーティケイガン
- 出版社/メーカー: 株式会社 マーレアッズーロ
- 発売日: 2015/02/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
気になった部分をピックアップ
第6章:プロダクトマネージャの条件
技術の進歩は急速なので、プロダクトマネージャーは、新しい技術を短期間で身につけることや、新しい分野で問題の解決に取り組むことが得意でなければならない。私がプロダクトマネージャーの候補者をインタビューするときは、すでに身につけているものは何かを見るのではなく、今までやってきた製品開発で、何を学ばなければならなかったか、学ぶのにどのぐらいの時間がかかったか、そして、身につけた知識をどのように活用したかを見るようにしている。
Engineer出身であると必然的にクリアしなければならない課題なのでEngineer的思考が十分に生かせるなーと感じた
第7章:プロダクトマネージャを管理する
ネットプロモータースコア(NPS)
普段ネットサービスを使っててよく出てくるアレである。この指標がプロダクトマネージャの評価基準になりえるのは初めて知った。コレ系はSaasとして取り入れたいなぁーと感じた。でもあまり世の中に無い気がする。
すべてのユーザが直感的に回答できるし、回答内容も全社的に共有して問題無いし、やるべきだなーと思った次第。
第11章:製品の市場性評価
顧客を理解するという点からは、財務部門が持っている情報はものすごく役に立つのだ。 財務部門の人間というのは、だいたいはかなりもの静かであり、プロダクトマネージャーのデスクまでやって来て製品機会について説いたりするようなタイプではない。だいたいは、プロダクトマネージャーのほうが、彼らのところに出向かなければならない。
この本を読まなければ気づかなかった視点でした。財務部門で扱うデータは提供しているWEBサービスでは出てこないが、とても情報の信頼度が高いものが集まっている(支払状況・今までの取引の記録・信用度等々)。顧客を理解する上ではとても有効な情報だなーと思った。
何に活かすという明確な形にはなりづらいけど、頭に入れておくという意味で良いと思った。
また、人のタイプ的にプロダクトマネージャーからアクションすべしという所も納得感あった。
第13章:製品理念
プロダクトマネージャーは、意思決定のプロセスと理由付けをみんなに完全に見えるようにしておくことだと思う。プロダクトマネージャーは、直感だけに頼っているとチームのみんなから思われるようではダメだ。プロダクトマネージャーの設定した目標と目的、それらの優先順位、プロダクトマネージャーがそれぞれの選択肢をどう評価したか、といったことについては、チームのメンバー全員にわかるようにしておかなければならない。
議論が紛争している時こそ、決断しなければいけなし、決断したら100％その決断にコミットをみんながしなければいけないし、でもそこにはある程度の納得感が必要。その一役に見える化しておく事。
普段からわかりきった事でもなるべく丁寧にプルリクに説明やら背景やらを書くことにしてレビューしてもらっているが、同じことだなぁーと感じた。
第15章:ユーザモニター制度
プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、と私は思っている。
当たり前だけど専任でやる前提での話。ユーザに直接ヒアリングできる機会ほど有効な時間はなし、関連するMTGに参加して洞察力を磨く事も重要だなと思った。結局参加するMTGに意味があったが無かったなどは臨む心構えで変わったりする時ある。
第18章:製品仕様はどうあるべきかを考える
製品仕様の大半は、ハイファイプロトタイプとするべきだ。
Sprintを区切ってやるべきだし、何度も作り直し前提だし、デザイナーを含めた実際に手を動かせる開発者をいかに早く巻き込めるかが重要かもしれない。
早く巻き込む事で生じる人件費等のコストは必要経費だし、そうしないと良い製品開発はできないという事なんだと思った。最近だとハイファイプロトタイプを支援するツール類も充実してきているし、前よりも低コストで実現可能だと思うのでやるべきですね。
第21章:製品仕様の検証
フィージビリティ(実現可能性)の検証
ユーザビリティ(使いやすいかどうか)の検証
価値(買いたいと思ってもらえるかどうか)の検証
特に目新しい内容では無いけど、やっぱり基本的な部分なので改めて大切だなと思いながら読んだ
第29章:大きい会社でもイノベーションは不可能ではない
私が知る限りでイノベーションを起こすいちばん手っ取り早い方法の1つは、実際のユーザーが自社の製品やライバルの製品を使ってみようとするところを、じっくり観察する(そしてユーザーの話に耳を傾ける)ことである。こういう観察を何回かやれば、ユーザーの不満や期待のパターンが見えてくるだろう。
自分たちのプロダクトではなく競合他社のプロダクトを使ってるところを観察するの事の重要性はこの本で初めて知ったし、低コストで実現できるなーと思った。
ひたすら自分たちのプロダクトについて色々と考えていたけど、競合他社のプロダクトをうまく使うことは考えつかなかったなぁ
第32章:特別仕様には要注意
特別仕様の何が悪いのだろうか？製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。
この言葉の理由には下記3つ簡単に記されていた
- 顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい
- 顧客はどんな技術が可能であるかを知らない
- 顧客は共通のテーマを確認するために顧客同士が交流することはめったにない
特別仕様を飲み込めば大口の契約という目の前のメリットに惑わされることなく、常に本質を求めて行かなけれいけないなぁーと感じたけど、実際の経営者の立場からすると会社の経済状況が思わしくないと色々と考えが存在するだろうなと感じた。
CEOレベルの明確な意思表示が必要とも書いてあったけど、会社としての意思決定レベルの話ですね。
個人向けインターネットサービス製品で大切なこと
でも、顧客サポートの費用を抑えることが大事なのではなく、サービスを利用する顧客にすばらしい体験をしてもらうことが目的なのだ。
最近はカスタマーサービスに力を入れる企業も当たり前に増えて来たし、また改めてZappos.comの本を読みたくなった。日本の企業でも従業員の7割がカスタマーサポートの企業もあるし、サポートエンジニアの重要性も高まってきていると個人的に感じているし、そーいう流れなんだろうなと。
最後に
読みやすい本でした。いろいろな人が読める本だと思った。
勉強会:GCPUG Shonan vol.13 続・移行話 にたまたま参加させて貰った
はじめに
- いつも藤沢で利用しているコワーキングスペースで今日も作業しようかなと思ったら本当に偶然にGCPUGが行われていた
- なんか良さげな話をしていて、主催者のお気遣いを頂き参加させて貰った😃
勉強会概要
発表
Parse.comからGCPへ移行した話 ~完結編~ @tache_jp さん
- 一年がかりの移行プロジェクトかぁ
- オープンソース化されたParseサーバを動かしながら移行していった話
- 多くのバグを踏みながら対応していった話
- GCPのauto scalerの話は良かったなぁー。CPU基準で主にscaleすると言っていたけどメモリバウンドのサーバ群の場合とかどうするんだろうってちょっと気になった
- ロックオン上等とか…3ヶ月以内に収益化しなきゃいけないとかツライっすね…
- 元ネタはこのへんかな
GKEの話 @sinmetal さん
- kubernetes,GCP,Firebaseを使ったアプリケーションの構成の話
- Remoteでちょっと聞きにくく…資料をもとに見直したいなぁ🙏🏼
最後感想とか
社内勉強会でHTML Cacheの構成の話をした
その時の資料
備考
- 最近であればRoute53からドメインのAレコードをAWS Cloudfrontに向けて、originサーバにLB経由でアプリケーションサーバみたいな構成がありうる
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
- globalにあるエッジロケーションのキャッシュデータをクリアするのに20minぐらいはかかるとのことらしい
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
参考
勉強会:pixiv Night #02 - 画像処理技術 に参加した時のメモ
勉強会概要
発表
Blenderを使ってCUIベースで3D画像処理する by haya (15min)
- 下記のピクシブfactoryで使われている画像処理にBlenderを使ってる話
実はブログに詳しく書いてあるとのこと。このあたりかな
平面的なもの（Tシャツ）にディスプレイスメントマッピングと質感、パースで全然違和感なかった
- 画像処理する前に一度元画像からリサイズしてから、変換や合成をしている
- 元画像は容量的に重すぎて処理に時間がかかりすぎてしまう為
pixivFACTORYの画像処理周りについて何か話す by redcap97 (10min)
ピクシブfactoryで使われている画像処理の話
画像を変換するのに各フォーマット毎に別の処理をしている
- png … ImageMagickを使ってる
- pdf … rubyのprawnを使ってpdfを生成
- svg … potraceを利用して変換
小説の画像から空白を取り除く画像処理 by 496 (10min)
- 下記のサービスで活用されている様子
小説から本文を抜き出したい…
主なポイントは
- 行間隔
- 段組み
- 文字間隔
どれも自己相関、周波数解析で抽出している様子
JPEGのブロックノイズとはなにか？ by harukasan (10min)
- cgo内での処理が多いらしい
- ImageFluxの中身がだいたい知れて良かった
- ストリーム処理でバッファ分をメモリ確保するだけなので効率的
go-thumber に ImageMagick をつなげた話 by yoya (5min)
- go-thumberをスマニューでそのまま活用しようとしたけどforkしてカスタマイズしたのがyoya-thumber
- ImageMagickは処理の前に一度メモリに載せる(=遅いし、マシーンスペックは必要)
- proxyを通してhttp経由で画像変換を提供
- nginxのproxy_cache経由で返却
- 1パツ目のアクセスはキャッシュが無いので負荷がデカイ
- オンデマンドでサムネイル画像を返却する仕組みのツラさも良く分かる…
ImageMagickの中身をすごく詳しくてびっくりした
halide-langについて by saturday06 (5min)
これから使っていきたいライブラリ
C++の画像処理ライブラリだけど言語と言っている by 公式
- Halide
a language for image processing and computational photography
- Halide
- ffmpeg(libswscale)からhalideへ乗り変えを検討
まとめ
- 画像処理深い…😅
- 少し軽いノリで参加させてもらったけど、話がdeep過ぎてあまりついて行けなかった😨
- 画像変換は今自分たちも課題があるけど、自前のコア技術として持つまでのフェーズではないから、OSSやこのあたりのSaaSをうまく活用していきたいなと思った
- ImageMagickってすごく昔からあるけど、取って代わるプロダクトってまだ出てきてないんだなぁーと感じた
- 画像処理系をメインに仕事をしている人はもちろんだけど、傍らでやってるエンジニアにとっても少しでも中身を知るキッカケになって良かった。
- 色々理解出来なかった部分をググって少しでも知ることができて良かった😄
- Streamingで画像処理をする話とか、へーそうやって軽くして多くの処理をしようとしているのかーと思った
勉強会:データ分析基盤Night #1に参加してきた
概要
発表
「リブセンスのデータ分析基盤の全貌」yusaku omasa(taise)
- ビーコンの活用か
- 無いとビジネス上困るからスタートしているので（あきらかなニーズがあるので）当然使われるシステムなったと言うのは良いな
- Cookieを最大限活用しているのがポイント
- 実装側がJavaScriptのコードを一行読み込めば良いと言う気軽さは良いな
「Rettyのデータ分析基盤について(仮)jp_taku2
- AthenaとBigQueryを主に活用して構築している
- 機械学習の基盤まで整っているので感じでより奥深いなーと思った
「Gunosyのデータ分析/ログ基盤の全容」atsushi morimoto
- 攻めの為のデータ基盤、守りの為のデータ基盤と言うような分類があった
- 守りの為のデータ基盤、タスクはなるべく自動化を図って人の手を介さないようにしている
- いかに多くの時間を攻めの為に使えるように回すかがポイント!!
- 完璧なログ設計は難しくて、どこかで差異が出てしまってそれをどこで(API？コンバーター？で)カバーするか？みたいな話はよく分かる…
- カバーすればするほど複雑性が出てしまい、後からjoinしたエンジニアに申し訳なくなるパターン
- デロリアンというオフラインテストはへーそこまでやるんだーと思った
- 過去ログからアルゴリズムを変更してAパターンだったらどのようなデータ抽出なるか、Bパターンだったらどのようなデータ抽出になるか等々
- これをもっと気軽にできるとproductの精度増しそう🤔
まとめ的なもの
- やっぱりみな頑張ってBigQueryに移行している感じだった
- 発表を聞かせてもらってもUIの為のデータ分析と言うのはABテストというものでひと括りになってしまってて、どちらかと言うとみなCVを上げるためのデータ分析基盤と言う印象が残った
- UIやUX改善に焦点を当てたデータ分析基盤、分析方法というのに興味を持ったし、色々考えていきたいなと思った💪🏽
- 事業インパクトがそれなりに大きいので、それぞれ専属チームで担当していた
- 1人とか2人とかでやれる業務範囲ではないなーと思った
- 逆に1人 or 2人でも出来るデータ分析基盤構築と分析といった感じのライトにできる事始め的な内容なら紹介出来るかもと思った😅
- お疲れ様でした👏🏽
Googleデータスタジオを使って見てBIツールについて考えた
はじめに
下記の記事でちょっと触れてて現状の業務に少し導入してみた。
tsuyoshi-nakamura.hatenablog.com
数日後、下記のニュースが出てヨッシャー無料で使いまくれるじゃないかと思ってもっと業務に取り入れてやってみた analytics-ja.googleblog.com
ほとんど数値は隠してますが、下記のような感じで使ってました
example
1
2
3
このあたりのBIツールに関して思うこと
世の中にはBIツール系はたくさんありますが、今の業務と照らし合わせて考えてみる。
現在PCとスマホのブラウザ版でのサービスを提供している状況で考えるとwebのアクセスログが一番重要だったりする。
UIを改善してみたり、Designを変えてみたり、メルマガのセグメントを変えて見たりという日々の改善の効果測定はGoogle Analyticsから取るデータが一番指標になる。
そのアクセスログ系のデータとDBなどにストアしているデータをかけ合わせて数値を追える事が一番重要だなと感じてる
そういった視点で考えると繋ぎこむ事ができるデータソースにGoogle Analyticsがある事が重要だなーと思っている。
以上を踏まえて最近のBIツールを見てみる
Re:dash
- 直接Google Analyticsには繋ぎこむ事は出来ない
- Google AnalyticsのデータAPIで取得して一度Spreadsheetに落としてから活用する感じになる
- OSSでの提供なので自身が管理するネットワーク内のサーバにインストールして内部のDBに対してSQL投げてデータが取れる
Amazon QuickSight
- 直接Google Analyticsには繋ぎこむ事は出来ない
- 主にAWS内にあるデータに対して簡単に分析が出来るのが特徴
- RDS,RedShift,S3,Kinesis,EMRとかこの辺に色々データが溜まってると非常に便利だと思う
Tableau
- 直接Google Analyticsに接続出来る様子
- もちろんMYSQLなどのデータにもつなげてSQLを投げれる
Google Data Studio
- 直接Google Analyticsに接続出来る
- ただDBへの接続が出来るけど、セキュリティ周りの設定項目があまり出てこなかったのでちょっと心配
まとめ
Tableauは周りでの評価も高いし、一番良いんだろうなと感じてる。セキュリティ周りも少し調べた感じだとしっかり考慮されてる感あったし、安心して使えそう- ただ当然有料
Google Data Studioは無料で使えてGoogle Analyticsのデータも自由に使えるので👍だと思ってる- いきなりお金のかかるツールの導入って決済者目線で言うとちょっとok出しづらいと思ってる
- 使ってみたいと思う人も本当に活用しきれるか不安でもあるし、失敗した時の事考えるとちょっと止めとこうっと思ったりする
- 無料のもので出来る事はたくさんあって、まづはそこで活用してみて、もっとこういう情報を分析する必要があって、その分析が進むとこういった施策が打てて….といった所まで使い込んで見るとよいと思う
- そうすると本当に自分たちのチームにとって必要なツールで必要な投資かどうか自信を持って言えると思う
- 有料の額にもよる部分もあるけど、こういった思考、実際にやってみた後の評価・判断が出来る事が自体が良い経験だったりするし😁
