記事一覧
分析用SQLを書くときの思考回路について
本稿では、分析用のSQLを書くときに則っている思考回路について述べて行こうと思います。
この言語化はあまりきちんとされている印象が無いので、自分がそこそこ初めての言語化だと思って頑張ってやってみようと思います。
言い換えれば、私はこういう思考回路でSQLを書きますが、みなさんどうですか、という話でもあります。
あとは、前提として、現代的な分析用の分散エンジンにSQLを投げるときを考えています。それ
データをいじりだす前に、分析の設計をして問題を構造化しよう
「分析してたら、迷路に迷い込んでしまった…結局何を分析すればいいんだ？」
「せっかく細かく分析した結果がほとんど使われなかった…」
みたいなことってありませんか？
少し極端かもしれませんが、私の経験上、分析における失敗パターンでよくあるのが下記です。
【1】分析しないといけないことが見つかった or 依頼が来た時に、すぐにデータをいじりだしてしまう。しかし、すぐに答えが見つからず、迷宮にはまり、
Redash×slackで、KPIが閾値を超えたらアラートが来るようにする
複数のプロダクトや施策を追っていると、見るべきKPIが多くなって「毎日見ないといけないダッシュボードだけで数十個ある…」みたいな状況になったことはありませんか？
KPIを可視化して定点観測することはとても重要なことですが、数が増えすぎるとその監視コストもバカになりませんよね。
KPIの中には、日々見ないといけないものとは別に、見るべきタイミングが限定されるものも多いです。例えば、
「獲得広告のCP
Redash×Slackで可視化したKPIを関係者に自動通知する
Redashとは、様々なデータソース（MySQLやBigQueryなど）に対応したダッシュボードツールです。自由にデータ抽出や加工、チャート化ができるのでKPI管理やデータ分析に重宝します。エンジニアでなくとも、SQLさえ書ければ使いこなすのも難しくありません。個人的に大好きなツールの一つです。
この記事では、RedashとSlackを連携させ、可視化したKPIを関係者に自動通知する方法を解説しま