Gunosyデータ分析ブログ

Gunosyで働くデータエンジニアが知見を共有するブログです。

テキストアナリティクスシンポジウムにて招待講演/研究発表を行いました

データ分析部研究開発チームの関です。 最近は10月のエビ中とBishの対バンイベントに向けて双方の楽曲の予習を行っています。

この度データ分析部では9月7日, 8日に成蹊大学で行われた第11回テキストアナリティクスシンポジウムに参加し, 7日は招待講演とパネルディスカッション、8日には2件の研究発表を行いました。

テキストアナリティクスシンポジウムとは

テキストアナリティクスシンポジウムは電子情報通信学会の言語理解とコミュニケーション研究会(NLC研)が主催するシンポジウムで、 自然言語処理の結果をどのように分析・解釈・活用するかという点に着目した研究会です。 第10回まではテキストマイニングシンポジウムと呼ばれていましたが、業界全体のトレンドを考慮し、今回からテキストアナリティクスシンポジウムと改称されました。 参加者も学生や研究者だけでなく、企業の実務担当者が多かった印象です。 また自然言語処理を専門にする研究者だけでなく、自然言語処理を活用する他分野の研究者の発表も多くありました。

第11回テキストアナリティクス・シンポジウム:参加募集 - 言語理解とコミュニケーション研究会

参加/発表の目的

データ分析部の人数も増え、中期的なビジョンに沿った研究開発を行うことにリソースを使えるようになってきました。 そんななか発足したGunosyのデータ分析部研究開発チームでは研究成果の外部発表に力を入れており、 将来的にトップカンファレンスへacceptされるような研究を行うことを目標にしています。 そのなかでまず業務の中での外部発表を増やしていくために、国内研究会への定期的な発表参加を行っています。

普段業務の中で様々な問題に取り組んでいるものの、研究発表を行うことを目的とした実験やその結果の整理、原稿の執筆を業務の延長線上で行うことはなかなかに難しいのが現状です。 そこで国内研究会での発表を定期的なマイルストーンにして原稿の執筆を行うことで、定期的に実験や結果の整理を行い、 そこでの議論と結果の蓄積をもって、査読付きジャーナルへの投稿や、国際会議のワークショップへの投稿をまずは目指していくという方針を立てています。

テキストアナリティクスシンポジウムは、特に自然言語処理技術の応用にフォーカスしており、 実務での応用を目指した研究開発を行っている当社の試みとも親和性が高いと判断し、 今回以下2件の発表申込をするに至りました。

  • 関 喜史, 潮 旭, 米田 武, 松尾 豊, クリックベイトの特定に向けたユーザ行動分析
  • 米田 武, 久保 光証, 関 喜史, ニュース配信システムにおけるパーソナライズの設計と導入

招待講演

また発表参加とは別に招待講演の依頼を頂き、発表をさせていただきました。

今回の招待講演のテーマはウェブ企業におけるテキストアナリティクスの活用ということで、 当社以外にInsightTechさん、SanSanさん、メルカリさんの発表がありました。

当社からは「Gunosyにおけるデータドリブンなサービス開発とテキストアナリティクスの活用」と題して発表させていただきました。

f:id:Y_sekky:20170915131648j:plain:w300
招待講演の様子

事例よりもデータドリブンな開発体制の話を中心に話しました。 テキストアナリティクスをサービスに活かすという点においては、 テキストアナリティクスがどのような結果をもたらすかという点ももちろん大事ですが、 その結果を活かせるような会社の意思決定の仕組みが非常に大事だと考えています。

データ活用における組織の重要性については中山ところてんさんの資料でも述べられています。

今回は当社が試行錯誤しながら作り上げてきた組織の仕組みについて発表させていただきました。

参加者の方々からは「徹底的なデータドリブンな開発体制は非常に勉強になった」という声を多くいただきましたが、一方で「もう少し具体的な事例を聞きたかった」という意見もいただきました。 今後の発表に活かして行きたいと思います。

また招待講演終了後、他の招待講演者ともにパネルディスカッションが行われました。 各社の持っているデータや、活用方法はそれぞれ多種多様でしたが、「ゴールの設計をしっかりやること」という点がみなさん一致していたのが興味深かったです。

研究発表

2日目には当社から「クリックベイトなニュース記事の特定に向けたユーザ行動分析」と「ニュース配信システムにおけるパーソナライズの設計と導入」の2件の研究発表を行いました。 まだ研究開発段階のためウェブ上での資料の公開は差し控えますが、活発な議論を行うことができました。

f:id:Y_sekky:20170915133504j:plain:w300
関による研究発表の様子

f:id:Y_sekky:20170908140511j:plain:w300
米田による研究発表の様子

おわりに

これまでスポンサーとしての参加は積極的に行ってきましたが、 今回ははじめてのまとまった研究発表を行う研究会の参加でした。 今後もスポンサーとしての学術コミュニティへの貢献は継続しつつ、 発表者としても参加し、研究者の皆様との議論を深めていきたいと考えています。

【Slack×Re:dash×SpreadSheet】らくらくリアルタイムKPI通知

こんにちは、データ分析部のクボタです。最近はアイドルではsora tob sakanaの『ribbon』とアイドルネッサンスの『前髪』と東京女子流の『鼓動の秘密』を良く聴いています。来年のTIFと@jamが楽しみですね。 www.youtube.com www.youtube.com www.youtube.com

現在Gunosyでは様々なプロダクトを運営・開発していますが、施策等における意思決定においてデータを非常に重要な指標として扱っています。そのため、日常より分析部以外のメンバーも含めたダッシュボードやSlackのリアルタイム通知によるプロダクトの現状把握の場を大事にしています。

GunosyがKDDI株式会社と共同で提供しているアプリのニュースパスでは現在ダッシュボードはRe:dashを用いて作成しています。Re:dashは細かいSQLクエリの更新スケジュール設定や、Slack通知などの便利な機能からデータの可視化ツールとして重宝しています。詳細なRe:dashの特徴やSlackとの連携については、本ブログの以下の記事で紹介されています。 data.gunosy.io

上記の記事に即してニュースパスにおいても同様にslack連携によるリアルタイム通知を行おうとしたのですが、何故かうまくいきません。Re:dashでは右下のチャットツールから開発者のArikさんに英語で質問などを送ることができます。そこで何度かやりとりしたところどうやら1つのRe:dashアカウントには一つのSlackアカウントしか連携できないため現在の環境ではニュースパスのRe:dashアカウントとは連携できないとのことでした。

また、今後の開発のためとのことで複数アカウントに関する以下のような質問をされたので、それに答えて代替策としてSpreadSheetによるSlack通知を行ってきました。 f:id:khirohisa:20170825141104p:plain

すると、最近以下のようなメールが届いたらしく・・・ f:id:khirohisa:20170825141629p:plain 質問への回答が功を奏したのか分かりませんが、複数アカウントで/redashコマンドで投稿できるようになったそうです。

Slack×Re:dash×SpreadSheet

ここからは代替策として行っていたSpreadSheatを経由したSlack通知について説明したいと思います。 Re:dashとSlack連携による投稿に比べて事前準備が必要ですが、SpreadSheet経由のSlack通知は沢山コードを書くこと無く様々なカスタマイズが可能です。ここでは簡単にRe:dashの図を投稿する方法を説明しますが、これを応用して様々なKPI通知等が可能になると思います。 まず、SpreadSheetとSlackの連携のためにincoming Webhooksの設定をする必要があるため以下にアクセスします。 https://my.slack.com/services/new/incoming-webhook/my.slack.com Post to Channelで通知したいSlackのchannelを選んでAdd integrationします。

f:id:khirohisa:20170822165401p:plain

選んだSlackのchannelで以下のような投稿がされていれば準備完了です。 f:id:khirohisa:20170822165718p:plain 次に、SpreadSheetの設定に移ります。 まず、分かりやすいslack通知などの名前で以下のようにSpreadSheetを作ります。その際にシートの名前はchannelごとに通知を分けるためにSlackのchannel名などにすると便利だと思います。複数シートを作れば複数のchannelに通知を打ち分けることも出来ます。

f:id:khirohisa:20170825132234p:plain

次に、このSpreadSheetの各列について説明していきます。A列はどのKPIを通知するかを記載します(なくても良いが整理のため)。B列はre:dashのchartの左下にあるEmbedから得られるurl情報を記載します。かつてはこの情報をSlackに投稿すると図が展開されていたのですが、現在はそのままでは展開されないので少し修正が必要です。Embedには以下のようなurlがあると思います。

https://app.redash.io/アカウント名/embed/query/数値1/visualization/数値2?api_key=文字列

これを以下のように変形してB列に入れます。

https://snap.redash.io/p/アカウント名/数値1/数値2/文字列.png

次に、Slack投稿用のスクリプトを準備します。 スクリプトも好きなように書けば良いのですが例えば以下のようにすると、選んだチャンネルに複数の図を投稿することができます。

function postSlack() {
  var sheet    = SpreadsheetApp.openById('SpredSheetの/d/と/edit#の間の文字列を代入');
  
  for (var i=2; i<投稿する図の数; i++ ) {
  
    var sentence = sheet.getSheetByName('sheet名').getRange(i,2).getValue();
   
    var payload  = {
      'text'      : sentence,
    };
 
    var options = {
      'method'      : 'post'                 ,
      'contentType' : 'application/json'     ,
      'payload'     : JSON.stringify(payload),
    };
 
    var url = 'incoming Webhooksの設定で得られるWebhookURLを代入';
    UrlFetchApp.fetch(url, options);
  } 
}

最後に自動投稿の時間指定についてです。時間指定は編集>現在のプロジェクトトリガーを選択すると 以下のような画面で毎分時日週月で自動投稿を設定することができます。 f:id:khirohisa:20170825135228p:plain 例えば、毎日9時~10時などに定時投稿すると朝の数値チェック等に便利そうです。

簡単な説明になりましたが、SpreadSheetによるSlack投稿の利点は簡単なスクリプト程度で様々なカスタマイズができることだと思うので慣れてきたらやっていくと良さそうです。 参考になるページを貼ります。 www.minemura-coffee.com

箱根でデータ分析部開発合宿をしました(小田原・箱根おすすめグルメ情報付き)

こんにちは、データ分析部の久保です。 データ分析部では四半期に一度ぐらい開発合宿を行っています。 参加は任意でもちろん業務としてカウントされます。

合宿編

今回の合宿場所は以前も使用したAirbnbのこちらの部屋を使いました。

www.airbnb.jp

ホストのErikoさんも丁寧に対応してくれるし、部屋はとてもきれいで8~10人の宿泊にはかなり快適です。 ただ1点備え付けのwifiにつながりにくいという欠点があったので、今回は予めwifiレンタルをしていくことにしました。

【国内用】当日発送で高速WiFiをレンタル | WiFi東京RENTALSHOP

初日のチェックイン時刻までは途中小田原に立ち寄って、小田原の商工会議所の会議室を借りて各自作業しました。 f:id:beatinaniwa:20170722144653j:plain

今回各自が取り組んだテーマはいくつか例をあげると下のようなものでした

- 「テキストアナリティクスシンポジウムでの発表に向けた実験データの整理と再実験」
- 「ログデータの異常値検出」
- 「広告CTR予測モデルの作成」

合宿中には異常検知の手法についてディスカッションしていたときに確率分布の話題になり、こんな名言(?)も出ていました。

夜には箱根湯寮で温泉を楽しみ、晩御飯を食べながらメンバーの親交を深めました。

www.hakoneyuryo.jp

グルメ編

さて開発合宿の楽しみといえば現地でのおいしい食事があります。 初日のお昼は小田原の海鮮料理を食べました。

サカナキュイジーヌ・リョウ (SAKANA CUISINE RYO)

海鮮ちらし、とくに生しらすは絶品でした。 f:id:beatinaniwa:20170724155734j:plainf:id:beatinaniwa:20170724155755j:plain

また2日目は箱根から小田原に向かう途中に風祭で途中下車し、うなぎを食べに行きました。

うなぎ亭 友栄

友栄は食べログのうなぎランキング全国3位(7/24現在)にもなっていて、行く前から相当期待が高まっていましたがその期待をまったく裏切ることない味で最高でした。箱根近辺に行った際にはぜひ立ち寄ることをおすすめします。 今まで食べたうなぎの中でも個人的には相当上位でした。

(時間帯によるかもしれませんが30~1時間ぐらいは待つ覚悟をしていったほうが良い気がします)

f:id:beatinaniwa:20170724155811j:plain

開発合宿は日頃なかなか手を付けられない中長期的なタスクに取り掛かるのにはとても良い方法だと思います。 次の開発合宿をどこでやるか、今から楽しみにしています。

Gunosy における AWS 上での自然言語処理・機械学習の活用事例: AWS Summit dev day 2017

はじめに

こんにちは。Gunosyデータ分析部の大曽根(@dr_paradi) です。最近はJOHN TROPEA BAND featuring STEVE GADD etcのライブを観に行きました。 業務では主にニュースパスのユーザ行動分析、記事配信アルゴリズム開発全般を担当しています。

先日開催されました、AWS Dev Day Tokyo 2017において、「Gunosy における AWS 上での自然言語処理・機械学習の活用事例」というタイトルで発表してきましたので、その内容について簡単ですが書きたいと思います。

発表内容

私が発表した内容は下記のスライドにまとまっています。弊社が提供するサービスのニュースドメインのもの(グノシー、ニュースパス)における処理の流れを大まかに話しました。

発表内容では以下の3点を中心に話しました

  • 記事分類
  • 属性推定 + スコアリング
  • 効果測定 (ABテスト)

各項目に関して過去の発表資料を含め簡単に解説します。

記事分類

文書分類に関しては多くの手法がありますが、基本的には文書を(いろいろな方法で) ベクトル化し*1、教師あり多クラス分類問題として解きます。 ナイーブベイズを用いた例に関しては下記の資料にまとまっております。

qiita.com

教師あり分類問題においては、教師データの作成、収集が重要になります。 教師データおよびモデルの管理に関しては以前の勉強会で私が簡単に話しました。

発表資料にある通り、作成したモデルはアプリケーションのdeploy時にS3から取得します。 deployの際に下記のようなスクリプトを実行しています。

# get models
execute "aws s3 cp --region #{s3_region} s3://#{s3_bucket}/#{s3_prefix} #{application_data_dir}/ --recursive"

属性推定 + スコアリング

属性推定

属性推定の手法に関してはWebDB Forum 2016の技術報告で発表済みで、下記のエントリにまとまっています。 属性推定でも、記事分類と同様にユーザのクリック履歴をベクトル化し、教師あり多クラス分類問題として解いています。

data.gunosy.io

スコアリング

今回紹介しているニュースのドメインにおいては、記事に鮮度がある*2ので、リアルタイムでのコンテンツ評価が重要になります。 集計および可視化の具体的な方法に関しては下記のエントリが詳しいです。

data.gunosy.io

また、GunosyでのKinesis Analyticsの利用し始めた経緯、詳細については下記のイベントで発表予定です。 AWS Solution Days 2017 ~AWS DB Day~(2017 年 7 月 5 日開催) | AWS

効果測定 (ABテスト)

Gunosyではデータに基づいた意思決定を非常に重要視していますが、ニュースアプリのであるため、時流や季節要因などの影響を受けやく、データに予期しないノイズが乗り、計測が困難になることが多くあります。 そのため、ABテストを用いてできるだけ施策の効果を正確に継続することを重要視しています。

ABテスト実施および測定の際に参考にしたブログは下記のエントリにまとまっています。 data.gunosy.io

マイクロサービスにおけるABテスト実装時のTipsなどは下記の資料にまとまっています。 ABテスト対象であるかどうかのパラメタをログに含めることで、解析を容易にすることができます。

ABテストの重要性に関しては下記の論文発表が詳しいです。

おわりに

AWS Dev Day Tokyo 2017での発表について簡単にまとめました。

機械学習ライブラリの充実により、ある程度の精度のもの(分類器などは)を作成するコストは下がっているように思えますので、今後は実際のサービスで動かすことがより重要になってくるかと思います。 今回の発表が、実サービスで機械学習を応用する際の参考に少しでもなれれば幸いです。

*1:文書のベクトル化についてはそのうち当ブログにて公開される予定です

*2:既知のニュース記事は読まれにくい

プロダクト改善のためにウォッチしておくべき7つの指標

データ分析部でグノシーというニュースアプリのプロダクト改善を担当している @ij_spitz です。

今回はプロダクト改善のためにウォッチしておくべき7つの指標をSQLで算出してみます。 Gunosyではこれらの指標を、プロダクトに異常があった時に検知するため、また施策の効果検証といった主に2つの目的で使用しています。

簡潔にするため、ユーザーとログインの2つのテーブルを使った算出できる指標のみを対象としています。 また、これらの指標をどうやってプロダクト改善に役立てているのかということも少しではありますが、合わせて書いていきたいと思います。

  • DAU
  • WAU(MAU)
  • HAU
  • 積み上げHAU
  • 1ユーザーあたりのログイン回数
  • 登録N日後継続率
  • 登録日別N日後継続率

前提

今回のブログで紹介するSQLはAmazon Redshift上で動くSQLなので、MySQLやGoogle BigQueryでは動かない可能性があります(というか動きません)。 またテーブル定義は以下のようになっています。

logins

Column Type 備考
user_id integer
created_at timestamp without time zone ログイン日時

users

Column Type 備考
user_id integer
created_at timestamp without time zone ユーザーの作成日時

DAU

SELECT
    created_at::date AS date,
    COUNT(DISTINCT user_id) AS dau
FROM
    logins
WHERE
    created_at >= '2017-06-01 00:00:00'
    AND created_at < '2017-07-01 00:00:00'
GROUP BY
    date
ORDER BY
    date

みなさんおなじみだとは思いますが、1日にサービスを利用したユーザーのユニーク数を表すDAUです。 ニュースアプリは毎日使ってもらうのが大事なので、毎日どれくらいのユーザがアプリを起動したかどうかを重要視しています。

DAU = Σ 新規ユーザー数 * 継続率

と分解できるので、DAUを増やすためには新規ユーザー数を増やすことおよび、継続率を上げる(下がった時に異常に早く気付く)ことが重要になってきます。

WAU(MAU)

SELECT
    date_series.date,
    COUNT(DISTINCT user_logins.user_id) AS wau
FROM (
    SELECT
        DISTINCT created_at::date AS date
    FROM
        logins
    WHERE
        created_at >= '2017-06-01 00:00:00'
        AND created_at < '2017-07-01 00:00:00'
) AS date_series
JOIN (
    SELECT
        DISTINCT
            created_at::date AS date,
            user_id
    FROM
        logins
    WHERE
        created_at >= DATEADD(day, -7, '2017-06-01 00:00:00')
        AND created_at < '2017-07-01 00:00:00'
) AS user_logins
ON
    user_logins.date <= date_series.date
    AND user_logins.date > DATEADD(day, -7, date_series.date)
GROUP BY
    date_series.date
ORDER BY
    date_series.date

DAUを最大化しようとすると、短期的な最適化に陥ってしまう可能性があります(非常に極端な例ですが1日に10回プッシュを打ってみるなど)。

そういった状況を避け、長期的に見てユーザー数が最大化するためには、DAU以外にWAUやMAUといった指標も確認しておく必要があります。

HAU

SELECT
    EXTRACT(HOUR FROM created_at) AS hour,
    COUNT(DISTINCT user_id) AS hau
FROM
    logins
WHERE
    created_at >= '2017-06-01 00:00:00'
    AND created_at < '2017-06-02 00:00:00'
GROUP BY
    hour
ORDER BY
    hour

HAUもよく使われる指標の1つです。

グノシーでは1日に4回プッシュ通知を打っているので、そのプッシュ通知の効果がどうだったかというのを見るためにHAUも確認しています。

プッシュの開封率も確認していますが、アプリのアイコンを直接タップして起動するユーザーもいるためHAUと両方の数値を見ています。

積み上げHAU

SELECT
    hour_series.hour,
    COUNT(DISTINCT logins.user_id) AS hau
FROM (
    SELECT
        DISTINCT EXTRACT(HOUR FROM created_at) AS hour
    FROM
        logins
    WHERE
        created_at >= '2017-06-01 00:00:00'
        AND created_at < '2017-06-02 00:00:00'
) AS hour_series
JOIN
    logins
ON
    hour_series.hour >= EXTRACT(HOUR FROM created_at)
WHERE
    created_at >= '2017-06-01 00:00:00'
    AND created_at < '2017-06-02 00:00:00'
GROUP BY
    hour_series.hour
ORDER BY
    hour_series.hour

DAUを最大化するという目的に立ち返った時に、HAUばかりを見ていると同じユーザーばかり起動していて最終的にDAUはそれほど伸びていなかったというケースもあり得ます。

その日に初めての起動を促すプッシュの方がDAUへの寄与は高くなるため、積み上げHAUも同時に見ています。

1ユーザーあたりのログイン回数

SELECT
    created_at::date AS date,
    1.0 * COUNT(1) / COUNT(DISTINCT user_id) AS login_num
FROM
    logins
WHERE
    created_at >= '2017-06-01 00:00:00'
    AND created_at < '2017-07-01 00:00:00'
GROUP BY
    created_at::date
ORDER BY
    created_at::date

1ユーザーあたりの◯◯という指標もよく使います。 グノシーの場合だと1ユーザーあたりの読んだ記事数や閲覧したタブの数なども見ています。

登録N日後継続率

SELECT
    rr.num_elapsed,
    100.0 * rr.user_num / inflows.user_num AS retention_rate
FROM (
    SELECT
        DATE_DIFF('DAY', users.created_at::date, actives.date) AS num_elapsed,
        COUNT(DISTINCT actives.user_id) AS user_num
    FROM
        users
    JOIN active_users AS actives
    ON
        users.user_id = actives.user_id
    WHERE
        users.created_at >= '2017-06-01 00:00:00'
        AND users.created_at < '2017-06-08 00:00:00'
        AND actives.date >= '2017-06-01'
   GROUP BY DATE_DIFF('DAY', users.created_at::date, actives.date)
) AS rr
JOIN (
    SELECT
        COUNT(DISTINCT users.user_id) AS user_num
    FROM
        users
    WHERE
        users.created_at >= '2017-06-01 00:00:00'
        AND users.created_at < '2017-06-08 00:00:00'
) AS inflows
ON
    1 = 1
WHERE
    /* 対象登録日の最終日に十分な経過日数がある日だけに絞る */
    rr.num_elapsed  < DATE_DIFF('DAY', '2017-06-08', CURRENT_DATE)
ORDER BY num_elapsed

ユーザーが新規登録してからN日後にログインしている率を継続率と呼びます。

ABテストを行ったときは2つのグループ間でこの継続率を比較して、その施策がどれだけ継続率をリフトアップさせているか(もしくはダウンさせているのか)を確認しています。

DAU = Σ 新規ユーザー数 * 継続率

前述した上記の式からもわかるように、継続率が高いほどDAUの積み上がりも良くなるので、基本的には継続率が良くなる施策 = 良い施策となります(もちろん例外はありますが)。

登録日別N日後継続率

SELECT
    rr.created_date AS created_date,
    100.0 * rr.user_num / inflows.user_num AS retention_rate
FROM (
SELECT
    users.created_at::date AS created_date,
    DATE_DIFF('DAY', users.created_at::date, logins.created_at::date) AS num_elapsed,
    COUNT(DISTINCT logins.user_id) AS user_num
FROM
    users
JOIN
    logins
ON
    logins.user_id = users.user_id
WHERE
    users.created_at >= '2017-06-01 00:00:00'
    AND users.created_at < '2017-07-01 00:00:00'
    AND logins.created_at >= '2017-06-01 00:00:00'
GROUP BY
    created_date,
    logins.created_at::date
) AS rr
JOIN (
    SELECT
        created_at::date AS date,
        COUNT(DISTINCT users.user_id) AS user_num
    FROM
        users
    WHERE
        created_at >= '2017-06-01 00:00:00'
        AND created_at < '2017-07-01 00:00:00'
    GROUP BY
        date
) AS inflows
ON
    rr.created_date = inflows.date
WHERE
    rr.num_elapsed = 1
ORDER BY
    created_date

上のクエリはN = 1となっています。 これも継続率の1種ですが、先ほどの登録N日後継続率とは少し用途が異なります。

登録N日後継続率では主に異なる2つのグループ間での継続率の差を見るときに使用しているのですが、こちらの登録日別N日後継続率だと時系列で継続率の推移が確認できるので、異常検知に使用したり(例えば特定の広告で獲得したユーザーの継続率が低かったとか)中長期的に見て継続率がどんな傾向をしているのかを見るために使用しています。

弊社でBIツールとして主に用いているRedashでの可視化のアウトプットを見ると両者の違いがわかりやすいと思います(細かい数値は載せられないので軸が見えていない点はご了承ください)。

  • 登録N日後継続率(縦軸が継続率、横軸が登録後経過日数) f:id:ishitsukajun:20170703205354p:plain

  • 登録日別N日後継続率(縦軸が継続率、横軸が登録日) f:id:ishitsukajun:20170703205138p:plain

Redashについての記事はこちらをご覧ください。

data.gunosy.io

data.gunosy.io

おわりに

以上で終わりになります。 少し複雑なSQLもありましたが、2つのテーブルとSQLだけでこれだけの有用な指標を算出することができます。 SQLを叩く環境がもし社内に整っているなら、エンジニアでなくても、ぜひSQLをマスターして色々なデータを眺めてみることをおすすめします。 今後、アプリやWebサービスの業界では社内にSQLを叩ける環境があるということがスタンダードになってくるはずなので、覚えておいて損はないスキルだと思います(弊社ではエンジニア以外の社員もSQLを叩いて自分の見たい数値を見ています)。

Gunosyでは数値に基づいたプロダクト改善を日々行っているということを少しでも実感していただければ幸いです。