2017年2月26日日曜日

【動画】Style ’20 コンセプトムービー







音楽めっちゃいい!




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


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

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


  
  



 Thank you very much!

2017年2月23日木曜日

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

Ower権限の移行方法

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

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

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

◇詳しくは下記参照

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文ループ処理)の紹介


 Treasure Workflowとは?

Treasure Workflowは最近導入されたばかりのTreasure Data(TD)の最新サービス。このサービスを活用することで、TDだけでなく、GoogleのBigQueryやG Suite、Amazon Redshift、Microsoft Azureなど複数クラウドやWebサービス上のデータを統合して管理することができるとされる。TDはこのサービスを軸にして、LDM(Live Data Management)というDMP(Data Management Platform)を超えた概念、すなわち、ベンダーを超えたデータの相互アクセスを可能にする世界観を目指しているとのこと(確かに、今様々な企業で構築・運用されているDMPをそのまま統合・管理できればすごい便利そう)。


取り急ぎ、Treasure Workflowを試してみる

Treasure Workflowでは、クエリをメタなレベルで処理することができる。例えば、複数のクエリを任意の順序で実行したいときやクエリのループ処理をしたいとき等に使える。特に、ループ処理は通常のSQLでは記述できないため、Treasure Workflowが大いに活躍すること間違いなし。そこで今回は、Treasure Workflowを使ったクエリのループ処理について試してみる(ちなみに、ループ処理のためのdigファイルの書き方は、TDの中の人から頂いたサンプルを参考にしました)。


導入手順

  1. コンソールを起動(windowsだとコマンドプロンプト)
  2. 自分のTDアカウントにログインする
  3. TDをアップデートする(td update)
  4. Treasure Workflowをインストール(td workflow)

ループ処理方法


1.クエリ操作するファイル(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

4.コンソールで実行(事前にdigファイルがあるディレクトリに移動しておく)

 td wf run sample
で実行


実行中の画面

5.結果

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


1ループ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. ユーザ全体の傾向として週間単位で統一したアクセス行動が見られる(例えば土日にアクセスして平日はしない)ため曜日要因を排除することができるからだ。


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


計算のイメージ
翌週アクセス日数d週次の場合:m=7
前週アクセス有ユーザi012...m
1d=1
2d=0
3d=m
.
.
.
nd=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)を作成

 1.まずはTreasure Dataにログイン

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

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

2.db:createを使って作成

$ td db:create new_db

以上

◇その他役立ちリンク


2017年2月15日水曜日

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

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


ゲーム、メディア、ECサイト等を運営する上で重要なデータの一つがユーザの継続利用状況。この継続利用状況を可視化することで見えてくる課題は多い。例えば、継続利用の数値が悪ければ、新規獲得コストが高いこと、競合への乗り換えリスクが高いこと、サービスを長期に支えてくれるヘビーユーザ層が少ないこと長期安定運営が困難なこと等々の課題がある可能性が高い。
 
以前、ゲーム買収の評価分析をしていた際、最も重要としていたのがユーザの継続利用のデータ。実際、この数値が悪ければポジティブな評価をすることはなかった。理由は、1.新規を獲得しても直ぐに離脱するためコストに対するリターンが少ない、2.増え続ける競合に乗り換えるユーザも日に日に増えていくため離脱に対する新規獲得が早い段階で追いつかなくなる、3.1と2よりビジネス的にサービスを長期的に継続することが困難であるからだ。そのため、買収評価の際は、利用状況によってユーザの継続率を予想するモデルを構築し、買収後2年先までの売上を維持するために最低限必要な月間の新規獲得UUをシミュレーションによって厳密に推定していた。
 
ただ、日々の継続利用を把握するために毎日モデルを構築してシミュレーションすることは現実的ではない。そこで、一度のクエリ構築で自動で現状把握できる分析が求められる。この分析の一つが、アクセス日数遷移。これは、各ユーザの当週(集計日から遡って7日間)と前週(当週に対する前週)のアクセス日数の変化を見ることで、ユーザの継続利用状況を可視化できる。また、前週と前々週の結果も合わせて比較することで、施策実施前後の数値から施策の効果を確認することもできる。


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


*数値は仮想のもの
最新↓当週
前週→last_week離脱率this_1this_2this_3this_4this_5this_6this_7
193%3%3%1%0%0%0%0%
288%9%2%1%0%0%0%0%
363%23%10%2%0%1%0%0%
431%32%20%9%7%1%1%0%
514%28%26%2%15%11%3%2%
60%22%24%10%10%14%19%2%
714%8%5%33%16%8%13%4%
当週新規0%72%25%2%0%0%0%0%
UU前週合計
last_weekthis_no_accessthis_1this_2this_3this_4this_5this_6this_7918
1700222271000752
213014310000148
36210000010
4221100007
5000000001
6000000001
7000000000
当週新規02508881000347
当週合計838291115173100427


◇クエリ例(上の集計イメージ下部の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


◇ネクストステップ