【ID】imidはSafariが捕捉できず、finger printはユーザの重複が多い

＊あくまで現時点での使用感

imid：インティメートマージャーが発行しているID

サードパーティのcookie情報からユーザを特定しているため、ファーストでないとcookie取得に問題があるブラウザではIDが正しく取得できない。例えば、Mobile Safariだと、ID数=PV数となってしまう。ただ、Safariを除外すると問題なく使える。


finger print：クライアントの端末情報を元に画像を生成してユーザを特定するID

重複が多い。FPでUU数を計測したところ、GAのUU数の1/3になった。個人的には、全く使っていない。


・各IDの参考サイト
Treasure Dataに追加されたExport to Intimate mergerの機能とその使い方
Canvas Fingerprintingとは？

【セミナー報告】TUG (Treasure Data User Group) vol.3 - Biz Dev編

セミナー参加報告

セミナー名
TUG (Treasure Data User Group) vol.3 - Biz Dev編

• 目的

データ分析ビジネス創出のための情報収集及び各企業の担当者と意見交換

• 概要

紹介された事例から分かったことは「箱からプライベートDMPへ」とTDの活用用途が変わりつつあること。その背景には、外部データ・サービスとの連携による次世代のマーケティング基盤の構築、すなわち、リアルおよびインターネット空間のユーザ一人一人のデータを捕捉することでマスから個人への直接アプローチのマーケティングへシフトしたいというクライアントニーズの高まりがある。

実際、本セミナーTUGの会長を務める電通では、将来のユーザーベースマーケティングでも先駆者であり続けるために、TDの外部サービスとして利用者にIDを付与する企業であるインティメートマージャーと資本提携し、TDを基盤にしたプライベートDMPを構築・運用している。このように電通を筆頭に、TDをプライベートDMPとして選択する動きが広まっている理由としては、⑴導入費用工数の低さ、⑵データ連携の容易さ、⑶サポートの充実さが決め手になったと各企業の担当者より聞くことができた。例えば、大規模なプライベートDMPを運用している資生堂では、上記の３点が整っていることで、実質３名という極めて少ない人数で運用することが可能になっているそうだ。

このように、電通、資生堂など大手企業を筆頭にTDを基盤にしたプライベートDMPの構築が広がっている現状、及び、この広がりがさらなるデータ連携の可能性を相乗的に拡大していく構造を鑑みると、今後もTDを軸にしたプライベートDMPの構築が広がっていくと考えられる。幸い、当社はTDを基盤とするプライベートDMPを構築しつつある。そのため、近い将来、拡大すると思われる他社とのデータ連携ビジネスの波に乗る準備は進んでいると言える。本年度中には当社データ基盤の構築が完了する見込みなので、その後はデータ連携先となる企業を開拓することが課題になるだろう。

• セミナー情報

【セミナー情報】TUG (Treasure Data User Group) vol.3 - Biz Dev編

【検討中コード】

---

WITH mysite_with AS(
  SELECT
    MIN(TD_TIME_FORMAT(time,
        'yyyy-MM-dd',
        'JST')) AS date_time,
    imid
  FROM
    log_db.log_mysite
  WHERE
    TD_TIME_RANGE(time,
      '2016-06-01',
      '2016-07-01',
      'JST')
    AND td_browser != 'Mobile Safari'
  GROUP BY
    imid
),
mysite_access_day_with AS(
  SELECT
    TD_TIME_FORMAT(time,
      'yyyy-MM-dd',
      'JST') AS access_day,
    imid
  FROM
    log_db.log_mysite
  WHERE
    TD_TIME_RANGE(time,
      '2016-06-01',
      '2016-10-01',
      'JST')
    AND td_browser != 'Mobile Safari'
  GROUP BY
    TD_TIME_FORMAT(time,
      'yyyy-MM-dd',
      'JST'),
    imid
),
othersite_with AS(
  SELECT
    MIN(TD_TIME_FORMAT(time,
        'yyyy-MM-dd HH:mm:ss',
        'JST')) AS date_time,
    imid
  FROM
    log_db.log_othersite
  WHERE
    TD_TIME_RANGE(time,
      '2016-06-01',
      '2016-10-01',
      'JST')
    AND td_browser != 'Mobile Safari'
    AND brand = 'brand/ie'-- ブランド名を指定
  GROUP BY
    imid
) SELECT
  date_diff(
    'day',
    CAST(
      mysite_with.date_time AS TIMESTAMP
    ),
    CAST(
      next_access.access_day AS TIMESTAMP
    )
  ) AS time_diff,
  COUNT(DISTINCT mysite_with.imid) AS uu
FROM (mysite_with)
JOIN
  (othersite_with)
  ON (
    --他社サイトのブランドサイト訪問
    mysite_with.imid = othersite_with.imid
  )
JOIN
  (
    -- アクセス初日後、最初のアクセス日を抽出
    SELECT
      MIN(TD_TIME_FORMAT(TD_TIME_PARSE(mysite_access_day_with.access_day),
          'yyyy-MM-dd',
          'jst')) AS access_day,
      mysite_access_day_with.imid
    FROM (mysite_access_day_with)
    JOIN
      (mysite_with)
      ON (
        mysite_access_day_with.access_day != mysite_with.date_time
--修正
　　AND
        mysite_access_day_with.imid = mysite_with.imid
      )
    GROUP BY
      mysite_access_day_with.imid
  )next_access
  ON (
    mysite_with.imid = next_access.imid
  )
GROUP BY
  date_diff(
    'day',
    CAST(
      mysite_with.date_time AS TIMESTAMP
    ),
    CAST(
      next_access.access_day AS TIMESTAMP
    )
  )
ORDER BY
  time_diff

---

【セミナー情報】TUG (Treasure Data User Group) vol.3 - Biz Dev編

タイトル：TUG (Treasure Data User Group) vol.3 - Biz Dev編
日時：　2016/10/05（水） 16:00～19:30
会場：　EBiS303
住所：　東京都渋谷区恵比寿1-20-8 エビススバルビル 5F
詳細：　http://eventdots.jp/event/600439

【定　員】100名
【参加費】無料
【持ち物】名刺2枚

アジェンダは下記の通り

15:30	開場
16:00	スタート
16:00〜16:10	ご挨拶 トレジャーデータユーザー会 会長 電通 データ・テクノロジーセンター テクニカルディレクター 山崎 茂樹さま
16:10〜16:35	事例紹介 1 資生堂ワタシプラス　One to Oneマーケティングへの取り組み 資生堂ジャパン ダイレクトマーケティング部 Web推進室 吉本 健二さま
16:35〜17:00	事例紹介 2 CNET Japanが考えるこれからの時代のWebメディア 朝日インタラクティブ 技術・制作部 ディレクター兼シニアマネージャー 石澤 知広さま
17:00〜17:10	休憩 10分
17:10〜17:20	ライトニングトーク1 事例紹介：オイシックスのデータ分析基盤 オイシックス システム本部 副本部長 普川 泰如さま
17:20〜17:30	ライトニングトーク2 電通 データ・テクノロジーセンター テクニカルディレクター 山崎 茂樹さま インティメートマージャー 代表取締役社長 簗島 亮次さま
17:30〜17:50	トレジャーデータからのお知らせ トレジャーデータ マーケティング担当ディレクター 堀内 健后
17:50〜18:00	アンケート
18:00	懇親会
19:30	終了

• セミナー参加報告

【セミナー報告】TUG (Treasure Data User Group) vol.3 - Biz Dev編

【晩御飯】ホットケーキでPDCA

今日の晩御飯はホットケーキ

泡が出てきた

ひっくり返すの失敗

美味しくいただきました。（ちょっと焼けてなかった気も。。）

• まとめ

あるべき姿：美味しいホットケーキを作る
問題：概ね美味しかったがちょっと生っぽいところが美味しくなかった
原因：ひっくり返すのを失敗して一部分の厚みが増しよく焼けていないところできた
仮説：小さなホットケーキを作っていればひっくり返すのを失敗することなく均等に熱が行き渡り一部が生っぽいホットケーキになることなく美味しくいただける
検証：また次回

【トレジャーデータ】自社サイトから他社サイトへ遷移する日数の分布集計（日数差分はdate_diffを用いる）

前置き。。

• 遷移日数の分布を見ればユーザの行動変容を読み取れる

自社サイトから他社サイトへ遷移するまでの期間を知ることは、自社サイトを通じたユーザの行動変容を知る上で大変有用。例えば、他社サイト→自社サイト、自社サイト→他社サイトとの遷移期間の分布がそれぞれ同様の構造を持っていれば、自社サイトを通じた行動変容は起こっていないと言える。一方、自社サイト→他社サイトの遷移で遷移期間に対するUUの減衰の変化、例えば、通常、遷移期間が長くなるほど右肩下がりに減衰するはずのUUがある特定の期間で増加するような現象が見られる場合、その特定に期間においてユーザの行動変容が起きているという仮説を立てることができる。この仮説を設定することで、ユーザの行動変容が起きるタイミングで広告配信をおこなう等の施策が設定可能となる。ただ、効果の高い施策を実施することのみを目的とする場合、基本的には、自社サイト→他社サイトへの遷移は24時間以内に起きるのが圧倒的に多いため、自社サイト訪問直後にアプローチするのが最も高い効果が期待される。

下記は、他社サイト→自社サイト、自社サイト→他社サイトへの遷移期間を集計するSQL。

 ---start---
WITH mysite_with AS(
  SELECT
    MIN(TD_TIME_FORMAT(time,
        'yyyy-MM-dd HH:mm:ss',
        'JST')) AS date_time,
    user_id
  FROM
    log_db.log_mysite
  WHERE
    TD_TIME_RANGE(time,
      '2016-06-01',
      '2016-10-01',
      'JST')ｃ
  GROUP BY
    user_id
),
othersite_with AS(
  SELECT
    MIN(TD_TIME_FORMAT(time,
        'yyyy-MM-dd HH:mm:ss',
        'JST')) AS date_time,
    user_id
  FROM
    log_db.log_othersite
  WHERE
    TD_TIME_RANGE(time,
      '2016-06-01',
      '2016-10-01',
      'JST')
    AND brand = 'brand_name'-- ブランド名を指定
  GROUP BY
    user_id
) SELECT
  date_diff(
    'day', -- 他にも minute, hour, week, monthなども指定できる
    CAST(
      mysite_with.date_time AS TIMESTAMP
    ),
    CAST(
      othersite_with.date_time AS TIMESTAMP
    )
  ) AS time_diff,
  COUNT(DISTINCT mysite_with.user_id) AS uu
FROM (mysite_with)
JOIN
  (othersite_with)
  ON (
    mysite_with.user_id = othersite_with.user_id
  )
GROUP BY
  date_diff(
    'day',
    CAST(
      mysite_with.date_time AS TIMESTAMP
    ),
    CAST(
      othersite_with.date_time AS TIMESTAMP
    )
  )
ORDER BY
  time_diff
 ---end---


Prestoでの期間計算（date_diff）の詳細は下記参照

• Hadoop利用者ならきっと知ってる、Hive/Prestoクエリ関数の挙動の違い
• 6.10. Date and Time Functions and Operators

【統計】ABテストの結果を電卓で計算できるぐらい簡単に統計的に判断する方法（二項分布、正規分布近似）

• まず、ABテストとは？

例えば、WEBページに設置するバナーのクリック数を上げたい時、左側に設置するのが良いのか右側に設置するのが良いのか悩むことがあります。この悩みを解決するために、どっちのバナーが良いのかを検証することをABテストと呼びます。詳しくは、「A/Bテスト（英: A/B testing）とは、主にインターネットマーケティングで行われる、施策判断のための試験の総称である。」をご参照。

• 優劣を正しく判断するために統計を使う必要がある

左側に設置するAバナー、右側に設置するBバナーがあるとき、それぞれのクリック数の平均値で比較することもできます。ただ、単純な平均値の比較だと、どちらも本当の効果は同じにも関わらず、偶然的に生じた平均値の違いで優劣を判断してしまう場合があります。そこで、統計をうまく使い、優劣を正しく判断することが求められます。

• 二項分布を仮定すると期待値、分散、標準偏差を簡単に計算できる

統計的に優劣を判断するには、一般的に期待値や分散、標準偏差を求める必要がありますが通常手計算では求めることが難しいです。ただ、二項分布を仮定すると、簡単に分散等を計算することが可能です。ちなみに、二項分布は、結果が成功か失敗のいずれかである n 回の独立な試行を行ったときの成功数で表される離散確率分布です。そして、二項分布の期待値と分散は定義により容易に求めることができます。例えば、nを試行回数、pを成功確率とするとき、期待値はnp、分散はnp(1-p)、標準偏差は√np(1-p)となります。

• 実際に二項分布を仮定して期待値、分散、標準偏差を計算

実際に計算してみます。AバナーとBバナーがあるとします。何れもN=100,000です。クリック率は、Aバナー：Pa=0.001、Bバナー：Pb=0.0011です。ここで、A{N, Pa}とB{N, Pb}は何れも二項分布に従うと仮定します。期待値は、Aバナー：Ea=NPa=100、Bバナー：Eb=NPb=110です。分散は、Aバナー：Va=NPa(1-Pa))=99.9、Bバナー：Vb=NPb(1-Pb))≈109.9,です。標準偏差は、Aバナー：Sa=√NPa(1-Pa)≈10.0、Bバナー：Sb=√NPb(1-Pb)≈10.5です。

• 仮説検定をおこなう

上記で計算したところ、Ea>Ebとなり、Aバナーの期待値が大きいことが分かりました。しかし、これは偶然の結果であり、AバナーとBバナーの間には本質的な違いはないかもしれません。そこで、仮説検定をおこないます。今回は、AバナーとBバナーは同等であるという帰無仮説を設定します。ここで、Bバナーがクリックされた回数、すなわち期待値Ebが二項分布（と仮定する）A{N, Pa}に従うとするとき、ラプラスの定理により(Eb-Ea)/(Sa)は近似的に標準正規分布に従うことを導けます。これを用いて計算すると、(Eb-Ea)/(Sa))≈1.0になります。標準正規分布の95%信頼区間は、-1.96~1.96なので1.0はその範囲内に入ります。そのため、帰無仮説を棄却できない、すなわち、本質的に違いがないことを否定できません。つまり、期待値で見ればEa>Ebですが、統計的な差はないと言えます。

• 統計的に差がないことが分かったら

残念。と落胆する必要はありません。今回の結果、バナーを左側に設置するか右側に設置するかでは、何れも効果が同じであるという事実が分かりました。そのため、この事実を活かした施策が提案可能になります。また、設置場所によって効果の差がでないことが分かったので、今後、左右のバナーでクリック率等の違いが出た際は、他の要因、例えば、バナーのクリエイティブで差が出たと推定することが可能です。

• 組み合わせの問題

今回は、組み合わせによる問題は考慮していません。つまり、本来は左側の方がクリック率が高いにも関わらず、右側でクリック率が高まるクリエイティブを選んでしまい実験した結果、それが丁度良い具合に補正されて、偶然にも左右同等の結果になってしまった可能性があるということです。このような問題を回避するには、単一のクリエイティブの影響を小さくするために複数のクリエイティブで実験する等の対策をおこなう必要があると考えられます。


参考サイト

• 【統計】2項分布を使ってABテストを簡単に