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先生を利用してノンビリジオコーディングしていたものが一旦終了しました。
というか、こんなデータ全く必要なかったんですけどねw

郵政サイトの住所そのままは使えないので「()」みたいな記号が含まれていたりするものはざっくり除外してユニーク処理した後のものをジオコーディングしていますが、それでも欠損データがポツポツ有ります。その辺はもう一回裏側で取得し直そうかと思いつつも、すぐに利用する用もないので暫く放置予定です。


データはこちら

データ検証はしていませんが、まぁ、それぞれのデータの最大値・最小値はこんな感じなので大丈夫でしょう。

緯度
MAX : 45.5162367
MIN : 24.061406

経度
MAX : 145.8121033
MIN : 123.0018701

不安であれば欠損値は含めず現在の緯度経度情報を地図にプロットしてみてどうかな?という感じで調査をしてみれば良いですかね。

[GTM]DOM ElementのCSS SelectorでElement Selectorを複数指定する

直近、GTMがリリースされた時から要望が多かったタグ自体のシーケンス機能が入るなど進化が続いています。dataLayer.setとかが入り始めて、まだちゃんと動作テストをしていないのですが(苦笑

今回はCSS Selectorで複数Elementを指定する場合を調べてみました。


ちょっと複雑に、ルックアップテーブルなどを使っても良いような気がしなくもありませんが、マクロをひたすら組み合わせると全体が一気に把握しにくくなったりします。GTM側での指定はCSS Selectorですが、今回はSemanticのマイクロフォーマットを以下のように指定してみました。

h1[itemprop="headline"],h1[itemprop="name"]

これで綺麗にマイクロフォーマットのコンテンツを取得できました。
例えば、Universal Analyticsのフィールド「title」に吐き出して、metaのtitleではなく、特定の「ヘッドライン」名などをタイトルとしてGAに入れてみるということも良いですね。

もしくは、authorを取得してGA側で分析したり、その辺りはカスタムディメンションへデータを入れたりも自由自在。
この辺りは結構活用されている方々がいらっしゃるでしょうね。

GoogleのスマートフォンbotのUA更新

小さな話ですが、GoogleのスマートフォンbotのUAが今月更新されています。

(旧)
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

(新)
Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

基本的な部分に変更は無いので、特に影響はないとは思いますが、iPhoneのOSだったり細かい部分が少し変更となっています。
ガラケー側のUAも変更されているのですが、まぁそちらは良いでしょう。。。

Google検索結果ページからコンテンツ側へのPLA展開

Googleの商品広告、所謂PLAは恐らく今まで国内では検索結果ページのみで展開をしていたと思われますが、海外で去年10月頃に発表されたAdsense for Shoppingという、Adsense枠にも商品広告が表示される商品が少しずつ展開されてきているようです。


これはKDDIが提供するauone.jpのスマートフォンサイト、ショッピング検索ページ。
海外でこのプロダクトがリリースされた後、その後のパフォーマンスなどの情報は一切出てこず、自分のブラウザ設定に起因するかは分かりませんが、リリース直後にこの商品広告が表示されることがあるとされるウェブサイトを閲覧していたけれども、全然見ることが出来なかったような気がしています。

少し広告表示について調べてみると、どうやらGoogle検索でPLAが表示されるパターンではAdsense for Shoppingも表示されるようですが、Google検索結果にPLAが表示されない検索クエリの場合は、Adsense for Shoppingも表示されないように見えます。

「デジタルカメラ」で検索した場合のauone.jp。


Google検索をしたみた時。


コンテンツについては、Google検索で表示されるPLAの1位の商品がよく表示されるように見えますが、必ずしもそうだと断言出来るものではないようです。また、全く同一ページでもリロードすると別の商品が表示されたりするので、Google側もCTR等で表示する商品を最適化しているのかもしれません。

Googleショッピング側のカテゴリ名で検索しても、必ずしもPLAが表示されるわけではない事を考えると、恐らくPLAを表示するロジックはGoogle検索結果でコマースサイトがクリックされているとか、何かの指標を色々組み合わせて商品を表示すべきとGoogle側が判断した場合に限って表示しているのでしょう。

Adsenseのコードは通常のものと異なり、Adsense for Shoppingの専用コードとなっていますが、現状のAdsense for Shoppingで提供されるフォーマット「Multiple」側では「Query」が必要となっている事と、「Single」フォーマットでは「GTIN」が必要となっている事を考えると、コンテンツマッチという形ではないため、展開出来るウェブサイトはそれほど多くなく、また導入企業が爆発的に増えるようなものではないように思ったりしますが、ゆくゆくはAdsense枠として一つのコードに統一されてくるのかもしれませんね。

auone.jpからリンクされているパラメータを見てみると

  • ai
  • sig
  • adurl
  • ctype
  • clui
  • nb
  • res_url
  • rurl
を持っているようです。
外部のサイトで色々調べてもパラメータの意味を完全に解説できているサイトはなさそうなので、なんとも言えませんが、Adsense for Shoppingではリンク元サイトのURLの他に、リンク元サイトに来る一つ手前だと思いますがrurlに参照元が入っているように見えたりします。

この辺の値は常に固定っぽい?

ctype=5
clui=1
nb=9
cluiは以前cdとなっていた表示ランキングというか、表示順序の値っぽいですね。
今後は日本でも採用する企業が増えていくのでしょうか。

ウェブサイトがクロール出来る状態であるにも関わらずアクセスが殆ど無いページをScreaming Frog SEOで抽出

今月はじめにScreaming Frog SEOもVer.4.0となりまして、更にイケてるUpdateが数多くされております。
本家でも大きな機能改修としてうたわれている機能の中の1つ、Google Analytics APIとの連携機能。こちらがまた素晴らしい。

Google Analytics APIと連携すると、ある特定ページに対して"全然アクセスが来ない・・・"という受け身から、nofollow等でブロックされていないか?階層は深くないか?などクロール視点からページを分析出来るようになります。検索エンジン側に表示された場合のタイトルや説明文、その他細かい分析を同時に出来るようになります。

設定方法

1.Google Analytics APIとの連携をする(起動後毎回行う必要があります。)


2.初回は「Connect to New Account」をクリックします。2回め以降は「Existing Accounts」という欄に自分のメールアドレスが表示されているので、そこを選択して「Connect」ボタンを押します。


3.ブラウザが起動し、認証画面が表示されるので認証画面で「Accept」を押します。
その後「Received verification code. You may now close this window...」というメッセージが表示されたら、ブラウザ側は閉じてアプリ側に戻ります。


4.Screaming Frog SEO側で連携するプロパティや、最初からセグメントされたデータだけを分析したい場合は、Google Analyticsに最初から用意されているアドバンスセグメントデータを選択出来ますので、そちらで設定を行います。


5.実際にどのmetricsを表示したいか、どのdimensionを選択したいかは各タブで選択可能です。「Date Range」タブは集計期間です。


6.設定が完了すると、「Analytics」というタブが発生し、ウェブサイトをクロール後、Analyticsのデータはそこから確認出来るようになります。



クロール後にAnalyticsのタブを見てみると設定したmetricsデータが表示されています。

画像 : screamingfrog.co.uk

【参考】
Screaming Frog SEO Spiderとその使い方・活用法に関する記事はこちら

Google Analyticsで計測されるWindows10とMicrosoft Edge

海外の報告を見ている限り、Google Analyticsで計測されるWindows 10は、GAのOSにはNTとして表示されているようです。

画像 : geekwire.com

また、今回Windows 10に搭載されているEdgeブラウザですが、Microsoftの公式ページによるとユーザエージェントは

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240

のような形式。
このユーザエージェントは私のPCのものですが、オフィシャルの情報はこちらにあります。

で、このユーザエージェントはGoogle Anallytics上、どうやらChromeとして計測されている模様です。

画像 : geekwire.com

OS情報に関しては、今日明日中には修正されると思いますがブラウザ情報は少し厄介そうな気もします。

via geekwire.com

(追記)Edgeの正式名称がMicrosoft Edgeだったので、タイトルを修正しました。