ラベル core reporting api の投稿を表示しています。 すべての投稿を表示
ラベル core reporting api の投稿を表示しています。 すべての投稿を表示

Google Analytics API V4をいじる

Google Analytics APIがV4が出て数ヶ月が経ちました。少しずつ各種ツールもV3がV4に切り替わりつつあるような気がしています。今まで別々にデータを出力してからローカルでデータを集計したり、それを補うように以前は1ユーザあたりセッション数などを出力できるAPIが用意されて、直ぐに廃止されたりと色々な動きがありました。

またコホートなどV4でしか利用出来ないmetricやdimensionが出始めましたが、かなり柔軟で有用な代わりに多機能でV4用に覚えなおさないといけないという印象です。サポートツールも出始めているので、自分で細かく指定しなくても良くなりそうですが。

ちなみにReporting API V4は別APIとして管理されているようです。


  1. 2期間でのデータ比較
  2. metricsの計算結果を返す
  3. pivotを利用してヒストグラムを生成する
  4. コホート分析をする
※以下、VIEW_IDはみたいGAのビューIDを入れている前提となります。
※JSONフォーマットの改行が無い状態で読みにくくなっている点ご了承ください。

1. 2期間でのデータ比較

Reporting API V4では期間を複数指定出来ます。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"},{"startDate":"2015-07-01","endDate":"2015-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  'metrics': [{'expression': 'ga:sessions'}]
}]

出力サンプル
dateRangega:browserga:sessions
Date range (1)Android Browser5
Date range (1)Chrome631
Date range (1)Edge0
Date range (1)Firefox185



Google Analyticsのブラウザ(GUI)上では普通に出来ますが、2期間を指定して比較が可能です。
上記の例はdataRangesを2期間指定して前年比を取得しています。

この場合返ってくるデータはdimensionの昇順で返ってきてしまい、あまり結果としてはイマイチな感じが出てきます。

そこでデータのソートをかけます。セッション数の変化量降順に並び替える時はorderBysを利用します。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"},{"startDate":"2015-07-01","endDate":"2015-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  "orderBys": [{
    "fieldName": "ga:sessions",
    "orderType": "DELTA",
    "sortOrder": "DESCENDING",
  }],
  'metrics': [{'expression': 'ga:sessions'}]
}]

出力サンプル
dateRangega:browserga:sessions
Date range (0)Safari90
Date range (1)Safari74
Date range (0)Safari90
Date range (1)Safari74

サンプルでは2期間を連続して出力しています。

2. metricsの計算結果を返す

metricsは単純にリストで指定するだけでなく所謂「計算指標」を自由に作成することができるようになっています。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"}],
  "dimensions":[{"name":"ga:browser"}],
  "metrics" : {
    'expression': 'ga:sessions/ga:users',
    'formattingType': 'FLOAT',
    'alias': 'Formula1'
  }
}]

出力サンプル
dateRangega:browserFormula1
Date range (0)Android Browser1
Date range (0)Chrome1.146167558
Date range (0)Edge1.6
Date range (0)Firefox1.206521739


この場合はmetricsのexpressionでユーザあたりセッション数をブラウザごとに表示します。計算指標化したときのheader名はaliasで指定して、formattingTypeで整数だったりパーセントだったり日付だったりと指定できます。

3. pivotを利用してヒストグラムを生成する

V4ではorderBysのorderTypeでHISTOGRAM_BUCKETを利用して自由にカスタマイズしたヒストグラムを生成することが出来ます。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dateRanges":[{"startDate":"2016-07-01","endDate":"2016-07-23"}],
  "dimensions":[{"name":"ga:sessionCount" , "histogramBuckets":["1","5","10","15","20"]}],
  "orderBys":[{"fieldName":"ga:sessionCount","orderType":"HISTOGRAM_BUCKET"}],
  "metrics" : [{"expression":"ga:users"}]
}]

出力サンプル
dateRangega:sessionCountga:users
Date range (0)1-4939
Date range (0)5-911
Date range (0)10-141
Date range (0)20+1


上の例の場合はdimension(セッション数)に対して1,5,10,15,20という階級を与えています。
返ってくる範囲は

1 -> 1-4
5 -> 5-9

などです。別に等間隔でなくてもデータが返ってきますので自由にカスタムして欲しいデータの範囲を設定して投げられます。ただし該当の階級に値が存在しない場合はその階級のデータは返ってこないようです。

4.コホート分析をする

V4でしか利用出来ないけど使いたいニーズの高いコホート分析。
この場合は全体のdateRange指定は無しでコホートの部分でdateRange指定をする。

'reportRequests': [
{
  'viewId': VIEW_ID,
  "dimensions":[{"name": "ga:cohort"},{"name": "ga:cohortNthDay"}],
  "metrics":[{"expression": "ga:cohortActiveUsers"},{"expression": "ga:cohortTotalUsers"}],
  "cohortGroup":{"cohorts":[{"name": "cohort 1","type": "FIRST_VISIT_DATE","dateRange":{"startDate": "2016-06-01","endDate": "2016-06-01"}},
  {"name": "cohort 2","type": "FIRST_VISIT_DATE","dateRange":{"startDate": "2016-07-01","endDate": "2016-07-01"}}]}
}]

ga:cohortNthDayの場合はdateRangeは1日のみ指定。
ga:cohortNthWeekの場合はstartDateは必ず日曜日、endDateは必ず土曜日。
 ga:cohortNthMonthの場合はstartDateは必ず1日、endDateは必ず月末といった感じでの縛りもあるので、自分で何回か書いてみて覚えないといけなそう。


以上ざっくりとしたV4追加機能の部分ですが、もちろんフィルタやセグメントも普通にかけられますし、V3ってこんなに複雑だったっけ?と思う部分もあったりしますが、Googleのドキュメントを見ながら必要なものを揃えれば良いと思います。

中には数字が入る部分も文字列で渡さないといけないとか、以前からのGoogle仕様はV4でも変わらず健在です!(苦笑

現状コホート以外はjavascriptでも提供されていました。
pivotとコホートはAPI側から触れるのは嬉しいですね。あとセグメントで通常の「条件(condition)」指定はシンプルと言うんですね。

ツールや使い方だけでなく、自分が取りたいデータを自由に取得できるようになりましょう!

Core Reporting APIのdateOfSessionの怪

この投稿は Google Analytics Advent Calendar 2015 の 10日目の記事です。分析視点ですみません。

前回セグメント書きまくろうぜーヒャッハーという記事をアップしたものの、やはりヘルプ紛らわしいでしょという部分があるし、検証って必要だよねということで最近1番納得のいっていない「 dateOfSession 」について書きます。
※なお本記事で検証に利用しているアカウントは大規模サイトすぎてセグメントをかけるとサンプリングデータとなるため各自要検証です。

まずはGoogle先生のヘルプを見てみましょう。
セグメントでは、dateOfSession 構文を使用する分析手法がサポートされます。BETWEEN <> 演算子と組み合わせることにより、特定の期間内にセッションを開始したユーザーのグループにセグメントを制限できます。dateOfSession の最長期間は 31 日です。
これだけ読むとdateOfSessionはウェブ側の「最初のセッションの日付」と同じ条件のように見えます。ちなみに英語版でも全く同じ事が書かれています。



ウェブ側の「最初のセッションの日付」は「初回訪問日」と書かれている通り、初回訪問者が絞りこまれます。

同じ感覚でAPIを使ってみます。

まずは基準データとして以下データセットを取得します

start date : yesterday
end date : yesterday
metrics : ga:users,ga:newUsers

昨日一日のユーザー数と新規ユーザー数です。
では早速比較データを作成していきましょう。start dateとend dateは特に言及がない場合yesterdayを利用します。

単純にdateOfSessionをsegmentに当てて見ます。

segment : users::condition::dateOfSession<>2015-12-05_2015-12-05
※ yesterday = 2015-12-05 とする

そこで返ってきた値はyesterdayの users と一緒となるようです。
即ちdateOfSessions単体では初回訪問を意味しませんので、初回訪問を取得する場合にはsessionCountの指定が必ず必要となります。

では、次にこんなセグメントをかけてみましょう。

segment : users::condition::ga:sessionCount==1;dateOfSession<>2015-12-05_2015-12-05
※ yesterday = 2015-12-05 とする

この値はyesterdayのnewUsersと一緒の値となります。
同様に以下のsegmentをかけて検証してみます。

segment : users::condition::ga:sessionCount>1;dateOfSession<>2015-12-05_2015-12-05

この値はusers - newUsers(即ち既存ユーザ)の値が出力されるようです。
さて、ではこんな風にデータを取得してみると何が取得出来るのでしょうか?

start date : 2daysAgo
end date : yesterday
segment : users::condition::ga:sessionCount==1;dateOfSession<>2015-12-05_2015-12-05
※ yesterday = 2015-12-05 とする

このデータはyesterdayのnewUsersとイコールになるようです。逆に

start date : 2daysAgo
end date : yesterday
segment : users::condition::ga:sessionCount==1;dateOfSession<>2015-12-04_2015-12-04
※ 2daysAgo = 2015-12-04 とする

このデータは2daysAgoのnewUsersとイコールになるようです。
ということで、いったんの結論としては「 dateOfSession 」自体はその名前の通りセッションを絞り込む役割しか果たしません。
「初回訪問者」を特定するためには ga:sessionCount==1 と一緒に組み合わせて利用する必要があります。

もう少しデータ検証をしてみましょう。こんなデータの取得の仕方だとどうでしょうか?

start date : 2daysAgo
end date : yesterday
segment : users::condition::dateOfSession<>2015-12-05_2015-12-05
※ yesterday = 2015-12-05 とする

どうやらyesterdayのusersと同じ数値になるようです。
この理解が正しいと仮定すると、前回の設問には出しませんでしたがこういうものも可能になります。

設問

2015/4/1~2015年4/7にウェブページ www.foo.com/campaign/ にアクセスし、且つ2015/4/8~2015/4/14に再度同一ページへアクセスした人を絞り込むセグメントを書いてください。

解答例
users::sequence::ga:pagePath==www.foo.com/campaign/;dateOfSession<>2015-04-01_2015-04-07;->>ga:pagePath==www.foo.com/campaign/;dateOfSession<>2015-04-08_2015-04-14

実際にそれっぽいデータが返ってきたりしますが、その辺の利用はお任せしますw 厳密な値を取得したいわけではなかったりするので私自身はこれはこれで一つの指標として利用したりしていますが。

APIは基本的には「ga:」のprefixを意識しているので「 dateOfSession 」は後ろから形容詞的な役割で私個人理解していますが、ネット上でsegmentを組んでいる人を見ている感じ、 users::sequence::dateOfSession~ という書き方もアリっぽいですね。気持ち悪いので使いませんがw

さて、前回の設問7「2015/4/1~2015年4/7に初めてアクセスし、サイト滞在時間が600秒を超えるユーザを抽出」という問題に対して、回答が

users::sequence::^ga:sessionCount==1;dateOfSession<>2015-04-01_2015-04-07;->>ga:sessionDurationBucket>600

となる理由は何となく見えてきましたか?何度も考えつつ結局何となくしか理解できていませんが、とはいえ毎度こういう書き方を見ると「シーケンス」ってなんだっけ?とか凄く疑問を持ちます…
ではでは、こんなデータの取得は可能なのでしょうか?

start date : yesterday
end date : yesterday
segment : users::condition::ga:sessionCount==1;dateOfSession<>2015-12-04_2015-12-04
※2015-12-04は2daysAgo

ちなみにこれは可能で、start dateとend dateはあくまでデータの取得日なだけでsegmentのセッション期間は影響を受けないようです。
色々segmentを書いているうちに間違って指定したところからこれは見つけましたが、これも結構活用方法ありますよね。

実は前回と今回で1番感じてもらいたかった内容は…
GAというDBにデータが入っていれば何でも取得できる!
というメッセージだったりします(笑
もちろん色んなセグメントを書いてスポットで取得していると限界を感じることもありますが。

Google AnalyticsのCore Reporting APIにおけるsegmentは沢山書いて覚えよう

この投稿は Google Analytics Advent Calendar 2015 の 8日目の記事です。分析視点ですみません。

見えないデータを可視化する

Google Analytics(GA)で既にビジュアル化されているものを、Excel等で再度ビジュアル化する意味はあまりありません。
インターフェースが嫌いで自分なりに作り直すか、社内ポータルなどで皆が見れるようにビジュアル化する事はあるかもしれませんが、ウェブを運営している人は見えないデータを見える化する努力をしなければなりません。

そこで必要な能力は今回書く セグメントを自分で書く / 作る技術 です。

セグメントを書きまくる

セグメントはセグメントでも今回取り上げるのはCore Reporting API側のセグメントですが、基本的にはウェブで言う「アドバンスセグメント」の「カスタム」についてです。(Built-inで最初から予約されているセグメントに関しては最後に補足)
セグメントはサイトによって書き方が全く異なりますので、あまりウェブで具体的に語られることはありません。またCore Reporting APIのセグメントは非常に難しいものですので活用している人を殆ど知りません。Googleヘルプが優秀というのもあると思います。

セグメントを書き始める OR Core Reporting APIをいじる上で参考とするページがこの2ページ。
本記事に関して「そんなのタブロー使ったらいいじゃん」とか、「このツールのほうが簡単だよ」とかは色々あると思いますが、今年中 OR 来年にはGoogleヘルプページにあるセグメント例を見ても全く動じぬ心を身につけましょう!

はじめにWEBとAPIのセグメントに関する簡単な対比説明

こんな条件ありえませんが、仮に以下のような条件をAPI化したいとします。


左側のメニューが「条件」となっているので condition:: を使います。(乱暴
フィルタが2つ(2枠)ありますので、ユーザーに関する条件は users::condition:: で書き始めます。セッションに関する条件は sessions::condition:: で書き始めます。

では、WEBキャプチャの条件を一気に書いてしまいます。

users::condition::ga:landingPagePath=@0;ga:landingPagePath=@1;sessions::condition::ga:landingPagePath=@2,ga:landingPagePath=@3

「=@」 は 「含む」、「;」がAND条件、「,」がOR条件。上から順にザッと書いていく感じです。仮に2つ目のセッション条件が「含める」ではなく「除外する」条件だとするなら

users::condition::ga:landingPagePath=@0;ga:landingPagePath=@1;sessions::condition::!ga:landingPagePath=@2,ga:landingPagePath=@3

こういう対比が何となくわかっていれば、ウェブで普段取得しているものをAPI化するのも楽でしょう。逆に日次で何か条件内の数字をインクリメントしていたりするものは、API化してしまうと楽ちんです。

ではここから先はお題を提示します。基本ソラで回答を書いていますので回答例が間違っていたら指摘してくれたら嬉しいです。オフィシャルのヘルプで間違っていると思われる点もありますが…


設問スタート(8題しか無い)

前提
・ドメイン情報もGAのページに表示している状況を元に記載しています。
・設問が悪いというクレームは受け付けておりません。何卒ご了承ください m(_ _)m

設問1

キャンペーンページ www.foo.com/campaign/a/ を踏み、続けてその詳細ページ www.foo.com/campaign/a/1/ へ遷移したセッションを絞り込むセグメントを書いてください。

解答例
sessions::sequence::ga:pagePath==www.foo.com/campaign/a/;->ga:pagePath==www.foo.com/campaign/a/1/

1問目から「条件」ではなく「シーケンス」を使っていますあが、シーケンスの場合は condition:: ではなく sequence:: を使います。

設問2

特定の1日においてユーザが何回特定のページ www.foo.com/page1/ を閲覧したか、以下のようなカラースケールを用いたマトリックスで俯瞰したいと思います。まずは0時台に特定ページを閲覧した人が次に何時にアクセスしてくるかのデータを抽出するセグメントを書いてみてください。



解答例
users::condition::ga:hour==00;ga:pagePath==www.foo.com/page1/

※start date , end dateを特定日に限定してしまえば良いかな
※metricsはga:users , dimensionsは ga:hour , sortはga:hourを指定する
※この取得の仕方の場合はグラフを描画するタイミングや連続的に一気にデータを取得する必要はあります
※この設問、結構批判されるかもw 色んな意味で。

設問3

キャンペーンページ www.foo.com/campaign/a/ を踏み、続けてその詳細ページ www.foo.com/campaign/a/1/ へ遷移したセッションと、キャンペーンページ www.foo.com/campaign/b/ を踏み、続けてその詳細ページ www.foo.com/campaign/b/1/ へ遷移したセッションの2つのセッションを含むセグメントを書いてください。

解答例
sessions::sequence::ga:pagePath==www.foo.com/campaign/a/;->ga:pagePath==www.foo.com/campaign/a/1/;sessions::sequence::ga:pagePath==www.foo.com/campaign/b/;->ga:pagePath==www.foo.com/campaign/b/1/

設問1を2つくっつけただけですが、usersレベルで書いても良いですね。
条件同士はANDでしかくっつきませんので2条件を「;」でつなげます。

設問4

キャンペーンページ www.foo.com/campaign/a/ を少なくとも1度は踏んでおり、1セッションあたりの滞在時間が1分以上5分未満のセッションが含まれるユーザ数を抽出するセグメントを書いてください。

解答例
users::condition::ga:pagePath==www.foo.com/campaign/a/;perSession::ga:sessionDuration<>60_299

無理やり作った設問ではありますがperSessionなどのスコープも忘れないようにしようという戒めのお題ですw
perSessionなどのスコープを使用しない場合、意図せぬスコープが適用される可能性があります。Googleヘルプの例を利用するならば

・ライフタイムバリューが1000円以上のユーザ抽出
users::condition::perUser::ga:revenue>=1000
users::condition::ga:revenue>=1000

・1セッションで1000円以上のユーザ抽出
users::condition::perSession::ga:revenue>=1000

設問5

セッション回数が10回以上20回未満のユーザで、かつキャンペーンページ www.foo.com/campaign/a/ を少なくとも1度は踏んでいるユーザを抽出するセグメントを書いてください。

解答例
users::condition::ga:sessionCount<>10_19;sessions::condition::ga:pagePath==www.foo.com/campaign/a/

前の問題とは反対にperSessionが使えないという問題。この辺のスコープまわりはヘルプも不親切な気もしています。ちなみにga:pagePathはスコープ指定出来ません。こういう出来ない事からくる制約を感じる事があります。
ヘルプ側だとそもそもアドバンスセグメントとして指定できないものもスコープのテーブルに多数入っていますが、たぶんスコープ指定してもダメな気がします。とくにaverage系とか。(ちゃんと検証していません)

単純に上の設問だと sessions::condition:: 自体特に不要ですね。同じ結果が返ってくると思います。

設問6

PCのChromeブラウザでランディングページがキャンペーンページ www.foo.com/campaign/a/ 、ページ滞在時間が10秒以上のユーザで、かつ収益が1000を超えるユーザを抽出するセグメントを書いてください。

解答例
users::condition::ga:deviceCategory==Desktop;ga:browser==Chrome;ga:landingPagePath==www.foo.com/campaign/a/;perHit::ga:timeOnPage>=10;ga:revenue>1000

この問題はperHitとかperSessionなどのスコープが及ぼす影響範囲を捉えるのには良い問題かなと思い作りました。
perUser、perSession、perHitは、その直後に指定されたAPI名だけに適用されます。ということで最後のga:revenueはユーザレベルで適用されています。

Googleヘルプだとこんな例が載っています。perSession::を2回書いていますね。
users::condition::ga:sessions>100;ga:daysSinceLastSession>=7;perSession::ga:transactions>2;perSession::ga:sessionDuration>100

具体的に「セッションあたり」と思い描いているのであれば、perSessionを付けてもよいかもしれません。

設問7(Googleヘルプからのパクリ問題)

2015/4/1~2015年4/7に初めてアクセスし、サイト滞在時間が600秒を超えるユーザを抽出するセグメントを書いてください。

解答例
users::sequence::^ga:sessionCount==1;dateOfSession<>2015-04-01_2015-04-07;->>ga:sessionDurationBucket>600

※個人的にはいきなり書けと言われたら下のように書いてしまいます…が、間違いです。
users::condition::ga:sessionCount==1;dateOfSession<>2015-04-01_2015-04-07;ga:sessionDurationBucket>600

実はこの辺が非常に理解しづらい。Advent Calendarの10日目でも少しだけ補足しますが、自分も完璧に理解出来てはいません。
APIを書いて不安が少しでもあったら、一旦ウェブで作ってみる事そしてAPI側とデータの付け合せすることをオススメします。

設問8

2015年に発売されたスマートフォン端末の中でSOV32、SOV31からアクセスされており、Chromeを利用しているセッション数を絞るセグメントを書いてください。

解答例
sessions::condition::ga:mobileDeviceModel[]SOV32|SOV31;ga:browser==Chrome
sessions::condition::ga:mobileDeviceModel=~.*(SOV32|SOV31).*;ga:browser==Chrome

一応 [] というリスト演算子がパッと出てくるかどうかのために用意した問題ですが、私自身実際に利用したことはありません。たぶんリスト演算子を利用したほうが処理は速いと思いますが。
というのはたぶんリスト演算子は完全一致じゃないか?と思っていたりします。(誰か試してみて!)
そうなると一つ目の解答例だと引っかからない可能性が大きいのです…

※最近気づいたのは、GAのmobileDeviceModel名が同じ機種なのに変わる事があるということ。「Xperia」などの冠の有り・無しで同一機種のデータが存在している事を見て気づいたのですが、もしかしたらキャリアによって違うとかあるのかも?


最後に…

セグメントが重要だということは分かっていても、なかなか視点が思いつかないとか色んな悩みがあると思います。
最近はデザイン思考だったり、エンジニア・デザイナ・マーケター・プランナー・責任者なども巻き込みながらサービスを作るという会社が増えている気がします。その過程でペルソナをエスノグラフィ的手法で作成するだけでなく、アクセス解析の結果だったり、潜在ニーズを探るためのSEO的な視点などを利用して皆で作るとなった場合には、「このサービスを利用するユーザはどういう人だろう?」という視点が発生します。

セグメントはそのゴールとなる全体像へのアプローチの過程で発生する問いを、GAのsegmentとして全て書き起こせばイイのです!(乱暴
こういう問いは都度発生するもので、片っ端から毎日のようにsegmentを書いてみる。そんな事をしてみると良いかもしれませんよ?

本当は1000本ノックばりに設問作りたかったなぁ(ぉぃ
皆でセグメントに関するお題を出しあうと面白いかも!
8問だけなのに長過ぎるよ…このエントリ。

(参考)予約されているsegment

予約されているアドバンスセグメント(Built-in系)指定です。予約されているsegmentは自分でsegmentを書く必要がありません。

gaid::-1All Sessions
gaid::-2New Users
gaid::-3Returning Users
gaid::-4Paid Search Traffic
gaid::-5Non-Paid Search Traffic
gaid::-6Search Traffic
gaid::-7Direct Traffic
gaid::-8Referral Traffic
gaid::-9Sessions with Conversions
gaid::-10Sessions with Transactions
gaid::-11Mobile and Tablet Traffic
gaid::-12Non-bounce Sessions
gaid::-26Tablet Traffic
gaid::-2Bounced Sessions
gaid::-28Mobile Traffic
gaid::-29Tablet and Desktop Traffic
gaid::-100Single Session Users
gaid::-101Multi Session Users
gaid::-102Converters
gaid::-103Non-Converters
gaid::-104Made a Purchase
gaid::-105Performed Site Search

※Built-inとカスタムを組み合わせる事はできなそうです。

Google AnalyticsのCore Reporting APIにユーザーレベルの指標がいくつか追加

Google AnalyticsのCore Reporting APIを利用されている方であれば、よく参照するであろう「Dimensions & Metrics Reference」。最近AnalyticsではUniversal Analyticsで、かつユーザー単位でデータを取得していることが前提、またはユーザー単位でデータを取得していなければ指標としてのメリットがフルに生かせないと思われる「コホート分析」なども出てきていますが、Core Reporting API側にも少しずつリリースがかかっているようです。

■ECommerce(Metrics)
  • ga:transactionsPerUser
  • ga:revenuePerUser
ユーザー単位の注文数だったり受注金額という指標ですね。

■USER(Metrics)
  • ga:sessionsPerUser
ユーザー単位のセッション数という指標です。

その他、Geo Networkも大幅に追加がかかっています。

Geo Network(Dimension)
  •  ga:cityId
  • ga:countryIsoCode
  • ga:regionId
  • ga:regionIsoCode
  • ga:subContinentCode
このGeographical IDというのが、実際にどう活用できるのかがイマイチ分かっていませんが、例えば北ヨーロッパは「UN M.49」というIDだとかサンプルが出ていますので、国別ではなくグローバル企業における北欧マーケット全体のマーケティングプランを考えたりとか、そういったビジネス的視点から導入された指標なのかもしれません。


何はともあれ、ユーザー単位トラッキングについては積極的に導入していく必要がありますね。