データ分析備忘録 in Tokyo: 2月 2017

2017年2月26日日曜日

【送別会】永田町パーティー：道中を楽しむ

送別会（永田町パーティー）を開いて頂きました。現職は約９か月という短い期間で退職することになりましたが、大変密度の濃い時間を過ごすことができました。皆様に感謝です。

…誰もが貨幣を創造できる社会の実現を目指し、大学院を飛び出して凡そ３年。少し遠回りをしている気がしますが、焦らず道中を楽しみながら進んできたいと思っています。ハンターハンターのジンも「道草を楽しめ」って言ってますしね。

Thank you very much!

2017年2月23日木曜日

【トレジャーデータ：Ower権限】Ower権限を別のアカウントに移行するには？OwerとAdminの違いは？

Ower権限の移行方法

TDの中の人に聞いたところ、ユーザサイドでは権限移行できないとのこと。そのため、Ower権限の移行は、中の人にお願いする必要がある。直接チャットでお願いすれば数日程度で移行してもらえる。

ちなみにOwerとAdminの違いは？

Owerは、全ユーザのパーミッション（アクセス権限）等の設定ができる。
Adminは、他のAdminとOwnerユーザのパーミッション等の設定ができない。

◇詳しくは下記参照

Access Control（TDのアカウントが無いと見れないかも）

2017年2月22日水曜日

【統計】何人分のアンケートが集まれば統計的に十分と言えるか？

母集団と必要なサンプル数（下記サイト参照）

母集団：100人→必要なサンプル数：80人
母集団：1,000人→必要なサンプル数：278人
母集団：10,000人→必要なサンプル数：370人
母集団：100,000人→必要なサンプル数：383人
母集団：1,000,000人→必要なサンプル数：384人

なるほど、400人くらい確保できれば大体どんなアンケートでも大丈夫そう

参考サイト

適切なサンプリング数とは？アンケートサンプル数の決め方

2017年2月21日火曜日

【トレジャーデータ：Treasure Workflow】今注目のTreasure Workflowとは？その導入手順と活用例（SQL文ループ処理）の紹介

TD Workflowとは？

簡単に言うとTDで実行するクエリをメタなレベルで処理するための機能。例えば、複数のクエリを任意の順序で実行したいときやクエリのループ処理をしたいとき等に使える。

導入手順

コンソールを起動（windowsだとコマンドプロンプト）
自分のTDアカウントにログインする
TDをアップデートする（td update）
TD Workflowをインストール（td workflow）

ループ処理の方法

１．クエリ操作するファイル（dig）とクエリを格納するフォルダを作成（必要に応じて）

td_testというフォルダ下に、クエリを保管するフォルダとdigファイルを作成している

2．クエリを作成

sample.sql

SELECT 
  TD_TIME_FORMAT(time,
    'yyyy-MM-dd',
    'jst') AS time_date,
  AVG(CLOSE) AS daily_avg_close
FROM
  #TDにサンプルで入っているナスダックのデータ
  sample_datasets.nasdaq
WHERE

  #datetime_fromとdatetime_toはdigファイルで定義
  TD_TIME_RANGE(time,
    '${datetime_from}',
    '${datetime_to}',
    'JST')
GROUP BY
  TD_TIME_FORMAT(time,
    'yyyy-MM-dd',
    'jst')

3．digファイルを作成

sample.dig

_export:
  basetime: "2011-03-01 00:00:00"
  loopcount: 5
  td:
    database: workflow_temp

+loop:
  loop>: ${loopcount}
  _do:
    +step:
      _export:
        datetime_from: ${moment(basetime, "YYYY-MM-DD HH:mm:ss").
         add(i, "days").format("YYYY-MM-DD HH:mm:ss")}
        datetime_to: ${moment(basetime, "YYYY-MM-DD HH:mm:ss").
         add(1 + i, "days").format("YYYY-MM-DD HH:mm:ss")}
      td>: queries/sample.sql
      insert_into: roop_test

４．コンソールで実行（事前にdigファイルがあるディレクトリに移動しておく）

td wf run sample
で実行

実行中の画面

５．結果

しっかりデータが入っている

1ループ１日分の処理が5回されるため5日分のデータがテーブルに入る

◇参考サイト（一部、TDのアカウントが無いと見れないかも）

2017年2月19日日曜日

【トレジャーデータ】サービス紹介動画（Treasure DMP）

トレジャーデータの紹介動画
これまで前職でも現職でもTDの導入を推進しTDを中核にしたDMPを構築してきました
そして、次の会社でも導入したいと思っています
なんかTDの伝道師みたいになってます。。

TREASURE DMP from Treasure Data, Inc. on Vimeo.

簡単にプライベートDMPを構築できることがTDの強み
あと、保守運用が楽でチャットで質問するとすぐに返事が返ってくる点も良い
改善してほしいところは、最近、営業担当の返信が遅いことぐらい。。

2017年2月16日木曜日

【トレジャーデータ：Presto】ユーザの継続利用状況を可視化するⅡ（エンゲージメント推移）

◇エンゲージメントの定義

サービスの永続にはユーザの愛着心、すなわち、エンゲージメントを高めることが必要とされる。そのため、KPIの一つとして、エンゲージメントの推移を日々確認し、PDCAを回していくことが求められる。しかし、サービスの多様性からエンゲージメントの定義も様々あり、統一的な指標は存在しない。そこで、今回は、メディアの場合のエンゲージメントの指標について考える。結論から言うと、前週アクセス有ユーザの翌週アクセス率（実際のアクセス日数/7）、すなわち、週次ログイン密度の全体（前週アクセス有ユーザ数を母数とする）の平均値をエンゲージメントと定義する。理由は、1. 翌週も引き続き利用している日数が多いほど気に入っている可能性が高い、2. 前週アクセス無ユーザを含めないことで新規流入に伴う影響が排除される、3. ユーザ全体の傾向として週間単位で統一したアクセス行動が見られる（例えば土日にアクセスして平日はしない）ため曜日要因を排除することができるからだ。

◇エンゲージメントの計算方法

計算のイメージ

	翌週アクセス日数ｄ				週次の場合：m=7
前週アクセス有ユーザi	0	1	2	...	m
1		d=1
2	d=0
3					d=m
.
.
.
n			d=2

$Engagement = \displaystyle\frac{1}{n}\sum_{i=1}^{n}\frac{d_i}{m}$

◇エンゲージメントの推移（イメージ）

以前、【トレジャーデータ：Presto】ユーザの継続利用状況を可視化する（アクセス日数遷移）という記事で各ユーザの前週アクセス日数と翌週アクセス日数を集計することで簡易的に継続利用状況を可視化できることを示した。しかし、この前回の方法では、ユーザ全体の継続状況のトレンドを把握し辛い。一方、今回の方法では、エンゲージメントの時系列変化が分かるため、ユーザ全体のトレンドを容易に把握することができる。

◇エンゲージメントのクエリ分析例

--集計日から遡って7日間の内にアクセスした日数を集計
WITH sq_this_week AS(
SELECT
    user_id,
    COUNT(DISTINCT TD_TIME_FORMAT(time,
        'yyyy-MM-dd',
        'jst')) AS this_days
FROM
    access_log
WHERE
    TD_TIME_RANGE(time,
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-7d'),
      TD_SCHEDULED_TIME(),
      'jst')
GROUP BY
    user_id
),
sq_last_week AS(
SELECT
    user_id,
    COUNT(DISTINCT TD_TIME_FORMAT(time,
        'yyyy-MM-dd',
        'jst')) AS last_days
FROM
    access_log
WHERE
    TD_TIME_RANGE(time,
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-14d'),
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-7d'),
      'jst')
GROUP BY
    user_id
),
sq_user_engagement AS(
SELECT
    sq_last_week.user_id AS last_user_id,
    sq_this_week.user_id AS this_user_id,
    -- nullであれば0とする
    COALESCE(
      sq_last_week.last_days,
      0
    ) AS last_days,
    COALESCE(
      sq_this_week.this_days,
      0
    ) AS this_days,
    COALESCE(
      sq_this_week.this_days,
      0
    )/ 7.0 AS engagement_rate
FROM (sq_last_week) LEFT
JOIN (sq_this_week)
    ON (
      sq_last_week.user_id = sq_this_week.user_id
    )
ORDER BY
    engagement_rate DESC
) SELECT
SUM(engagement_rate)/ COUNT(1) AS total_engagement
FROM
sq_user_engagement

【トレジャーデータ】コマンドプロンプトからデータベース(DB)を作成

１．まずはTreasure Dataにログイン

$ td -e https://api.treasuredata.com account -f

でログインする。
Emailとパスワードを入力すればＯＫ。

２．db:createを使って作成

$ td db:create new_db

以上

◇その他役立ちリンク

2017年2月15日水曜日

【トレジャーデータ：Presto】ユーザの継続利用状況を可視化するⅠ（アクセス日数遷移）

◇継続利用可視化の重要性

ゲーム、メディア、ECサイト等を運営する上で重要なデータの一つがユーザの継続利用状況。この継続利用状況を可視化することで見えてくる課題は多い。例えば、継続利用の数値が悪ければ、新規獲得コストが高いこと、競合への乗り換えリスクが高いこと、サービスを長期に支えてくれるヘビーユーザ層が少ないこと、長期安定運営が困難なこと等々の課題がある可能性が高い。

以前、ゲーム買収の評価分析をしていた際、最も重要としていたのがユーザの継続利用のデータ。実際、この数値が悪ければポジティブな評価をすることはなかった。理由は、1．新規を獲得しても直ぐに離脱するためコストに対するリターンが少ない、2．増え続ける競合に乗り換えるユーザも日に日に増えていくため離脱に対する新規獲得が早い段階で追いつかなくなる、3．1と2よりビジネス的にサービスを長期的に継続することが困難であるからだ。そのため、買収評価の際は、利用状況によってユーザの継続率を予想するモデルを構築し、買収後2年先までの売上を維持するために最低限必要な月間の新規獲得UUをシミュレーションによって厳密に推定していた。

ただ、日々の継続利用を把握するために毎日モデルを構築してシミュレーションすることは現実的ではない。そこで、一度のクエリ構築で自動で現状把握できる分析が求められる。この分析の一つが、アクセス日数遷移。これは、各ユーザの当週（集計日から遡って7日間）と前週（当週に対する前週）のアクセス日数の変化を見ることで、ユーザの継続利用状況を可視化できる。また、前週と前々週の結果も合わせて比較することで、施策実施前後の数値から施策の効果を確認することもできる。

◇アクセス日数遷移の集計イメージ（上部が比率、下部がUU）

*数値は仮想のもの

最新		↓当週
前週→	last_week	離脱率	this_1	this_2	this_3	this_4	this_5	this_6	this_7
	1	93%	3%	3%	1%	0%	0%	0%	0%
	2	88%	9%	2%	1%	0%	0%	0%	0%
	3	63%	23%	10%	2%	0%	1%	0%	0%
	4	31%	32%	20%	9%	7%	1%	1%	0%
	5	14%	28%	26%	2%	15%	11%	3%	2%
	6	0%	22%	24%	10%	10%	14%	19%	2%
	7	14%	8%	5%	33%	16%	8%	13%	4%
	当週新規	0%	72%	25%	2%	0%	0%	0%	0%

UU										前週合計
	last_week	this_no_access	this_1	this_2	this_3	this_4	this_5	this_6	this_7	918
	1	700	22	22	7	1	0	0	0	752
	2	130	14	3	1	0	0	0	0	148
	3	6	2	1	0	0	0	0	0	10
	4	2	2	1	1	0	0	0	0	7
	5	0	0	0	0	0	0	0	0	1
	6	0	0	0	0	0	0	0	0	1
	7	0	0	0	0	0	0	0	0	0
	当週新規	0	250	88	8	1	0	0	0	347
	当週合計	838	291	115	17	3	1	0	0	427

◇クエリ例（上の集計イメージ下部のUUを集計する部分。比率は別途計算）

--アクセス日数遷移
--集計日から遡って7日間の内にアクセスした日数を集計
WITH sq_this_week AS(
SELECT
    user_id,
    COUNT(DISTINCT TD_TIME_FORMAT(TIMESTAMP,
        'yyyy-MM-dd',
        'jst')) AS this_days
FROM
    access_log
WHERE
    TD_TIME_RANGE(TIMESTAMP,
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-7d'),
      TD_SCHEDULED_TIME(),
      'jst')
GROUP BY
    user_id
),
sq_last_week AS(
SELECT
    user_id,
    COUNT(DISTINCT TD_TIME_FORMAT(TIMESTAMP,
        'yyyy-MM-dd',
        'jst')) AS last_days
FROM
    access_log
WHERE
    TD_TIME_RANGE(TIMESTAMP,
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-14d'),
      TD_TIME_ADD(TD_SCHEDULED_TIME(),
        '-7d'),
      'jst')
GROUP BY
    user_id
),
sq_days AS(
SELECT
    sq_last_week.user_id AS last_user_id,
    sq_this_week.user_id AS this_user_id,
    -- nullであれば0とする
    COALESCE(
      sq_last_week.last_days,
      0
    ) AS last_days,
    COALESCE(
      sq_this_week.this_days,
      0
    ) AS this_days
FROM (sq_last_week) FULL
JOIN (sq_this_week)
    ON (
      sq_last_week.user_id = sq_this_week.user_id
    )
),
sq_uu AS(
SELECT
    last_days,
    this_days,
    COUNT(DISTINCT CASE WHEN last_days > 0 THEN last_user_id WHEN this_days > 0 THEN this_user_id END) AS uu
FROM
    sq_days
GROUP BY
    last_days,
    this_days
) SELECT
last_days,
COALESCE(
    SUM(CASE
        WHEN this_days = 0 THEN uu END),
    0
) AS "0",
COALESCE(
    SUM(CASE
        WHEN this_days = 1 THEN uu END),
    0
) AS "1",
COALESCE(
    SUM(CASE
        WHEN this_days = 2 THEN uu END),
    0
) AS "2",
COALESCE(
    SUM(CASE
        WHEN this_days = 3 THEN uu END),
    0
) AS "3",
COALESCE(
    SUM(CASE
        WHEN this_days = 4 THEN uu END),
    0
) AS "4",
COALESCE(
    SUM(CASE
        WHEN this_days = 5 THEN uu END),
    0
) AS "5",
COALESCE(
    SUM(CASE
        WHEN this_days = 6 THEN uu END),
    0
) AS "6",
COALESCE(
    SUM(CASE
        WHEN this_days = 7 THEN uu END),
    0
) AS "7"
FROM
sq_uu
GROUP BY
last_days
ORDER BY
last_days

◇ネクストステップ

【トレジャーデータ：Presto】ユーザの継続利用状況を可視化するⅡ（エンゲージメント推移）

登録: 投稿 ( Atom )

注目の投稿