はじめに
ログとユーザデータを綺麗にするだけでDMPは簡単にできる。
ただし、条件はいろいろとあり、
* ログは全てのカラムを保存すること
* マスターデータのKEYはユーザID !!
* 属性はできるだけあったほうが後々良い
* ログデータ期間は長くても微妙
とここまで書いたが、要するに切り口を広げれば広げる程、
施策やリーチの条件にはなるが、ある適度は決まってきている
ので、まずはこのデータを毎日のルーチンで流れを作ることが先決である。
最終的にユーザデータベースをリッチに作ることに尽きるかと思います。
このデータをもって、広告やメール配信などのマーケティング
オートメーションに利用するのが目的かと思います。
何をポイントにしてDMPとするか?
(1)コンバージョンの頻度や回数
(2)その場所に何度も訪れる
(3)ページを何回も見る
(4)何回も購入する
(5)経路(検索、広告etc)
1つ1つ簡単に説明していくと
(1) コンバージョンした人はどんな人か?というのがわかると
他の人(似たようなユーザ)に流用ができる。
→ リーチの対象となるユーザを絞りやすい
(2) 似たような場所にいる人をターゲティングしやすくなる
→(1)と似ているが、場所という観点だけで似たような施策が打てる
(3) 何度も見てる人は、気になっている証拠
(4) (3)と似ているが、購入して気に入った人はリピートして買う
(5) これは難しいシナリオですが、ページ作成や流入経路はコンバージョン心理の対象と言える。
これらを網羅し、サイトやアプリなどWEBトラッキングされる構造のものは
ある程度、定量化して施策が打てると判断できる世の中になってきている。
今までPVやUUなどの見えない回数からもう少しリアルに近い回数が
数えられるのが普通となっている。
個人情報により近くなってくると今後のログ分析はどこに行くのだろうと考えてしまう。
さて、具体的手法として、TreasuraDataを利用し、
簡単なインプット、集計、アウトプットの手順を以下に書いてみる。
(1)ログデータを用意
* データアップロード(トレジャーデータの機能より)
* ユーザーkeyとしてデータを作成
- id,gender,age,home,site,conv,segment,search,buy,occupation
- その他のIDとシンクする
→ 携帯,タブレット,PCが繋がる
* webやアプリログを投入
上記はuser_masterとaccess_logを作成した例である。
(2)結果分析(条件指定でKPIを設定)
- kpiを定義し、業務にあった分析を行う。
(2-1)サマリ(基本的な値):ダッシュボード等に利用する。
- PV,UU,ユニークブラウザ数,ip数,page数,host数
SELECT
COUNT(1) AS pv,
COUNT(DISTINCT uid) AS uu,
COUNT(DISTINCT ua) AS uniq_browser_count,
COUNT(DISTINCT ip) AS uniq_ip_count,
COUNT(DISTINCT parse_url(url,'HOST')) AS host_count,
COUNT(DISTINCT parse_url(url,'PATH')) AS path_count
FROM
access_log
- urlの中身を確認
SELECT
parse_url(url,'HOST') AS host
,parse_url(url,'PATH') AS path
,parse_url(url,'QUERY','p') AS query -- ここでユーザIDが取得できる
FROM
access_log
(2-2)トラフィック(daily/hourly/monthly/weeklyなどのカウント)
この辺りはおそらく何処かに書いてあるだろう…(省略)
(2-3)ユーザマスターを作成し、アトリビュートデータとjoinしたweb解析
- 年齢ごとのPV及びUU
select
b.age as age
,count(1) as pv
,count(distinct a.uid) as uu
from
access_log a
join
user_master b
ON
a.uid=b.uid
group by
b.age
- 国ごとのPV及びUU
SELECT
b.country AS country,
COUNT(a.uid) AS pv,
COUNT(DISTINCT a.uid) AS uu
FROM
access_log a
JOIN
user_master b
ON a.uid = b.uid
GROUP BY
b.country
- デバイスごとのPV及びUU
SELECT
b.device AS device,
COUNT(a.uid) AS pv,
COUNT(DISTINCT a.uid) AS uu
FROM
access_log a
JOIN
user_master b
ON a.uid = b.uid
GROUP BY
b.device
- セグメントごとのPV及びUU
- 職業別ごとのPV及びUU
SELECT
b.occupation AS occupation,
COUNT(a.uid) AS pv,
COUNT(DISTINCT a.uid) AS uu
FROM
access_log a
JOIN
user_master b
ON a.uid = b.uid
GROUP BY
b.occupation
ユーザデータがリッチになればなるほど細かい分析が可能となる。
ただし,これはユーザデータなどでリッチにしたログ分析であり、
本題はDMPなので以下の作業が続く。
(2-4)ユーザマスタへのログからの追加
ユーザマスタをさらにログから属性などを追加していく。
かなり情報が詰まっているので、さらに追加する項目を探すとすると
TD_PARSE_USER_AGENTを利用して、細かいデバイス情報を取得し、
user_masterに追加していく。
SELECT
uid
,TD_PARSE_USER_AGENT(ua,'os_family') as os
,count(1) as cnt
FROM
access_log
GROUP BY
uid
,TD_PARSE_USER_AGENT(ua,'os_family')
(3) 連携先にユーザデータをフィードバック
- 何のために?
-
(WEB+モバイル+その他の混在ログ)✖︎(アトリビューション)の分析
-
サービス連携
-
- メルマガ配信
- 位置や店舗プッシュ通知
- ABテスト
- 広告配信(DSPなど)
##(4) トレジャーデータで出来るDMPとは
- ユーザベースのデータベース作成:それを利用した上記のDataPush機能
- アトリビュート分析
(注) トレジャーデータは決してベンダーと連携しているわけではなく、
バックエンドとして利用されているだけである。