「Google Knowledge Graph Search API」の公開でEntity情報を活用可能に

17日に公開されたGoogle Knowledge Graph Search API
schema.orgのjson-ld形式で返ってくるわけですが、これ英語だけかと思ってたらクエリが日本語でもちゃんと返ってくる!とちょっと驚いたわけですが、日本語だと結構微妙な返り方をする(苦笑

完全な日本語側の対応にも期待です。

今回公開されたナレッジグラフのAPI、即ちGoogleがその事象について知っていることというのは、その情報をウェブサイト側にも利用出来るという意味以上に、その情報以上の情報をウェブサイトで提供することでGoodコンテンツからExcellentコンテンツへの昇華出来る可能性も示唆しています。

まずはサンプルで挙げられているクエリ「Taylor Swift」。

{
  "@context": {
    "@vocab": "http://schema.org/",
    "goog": "http://schema.googleapis.com/",
    "EntitySearchResult": "goog:EntitySearchResult",
    "detailedDescription": "goog:detailedDescription",
    "resultScore": "goog:resultScore",
    "kg": "http://g.co/kg"
  },
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "EntitySearchResult",
      "result": {
        "@id": "kg:/m/0dl567",
        "name": "Taylor Swift",
        "@type": [
          "Thing",
          "Person"
        ],
        "description": "Singer-songwriter",
        "image": {
          "contentUrl": "http://t1.gstatic.com/images?q=tbn:ANd9GcQmVDAhjhWnN2OWys2ZMO3PGAhupp5tN2LwF_BJmiHgi19hf8Ku",
          "url": "https://en.wikipedia.org/wiki/Taylor_Swift",
          "license": "http://creativecommons.org/licenses/by-sa/2.0"
        },
        "detailedDescription": {
          "articleBody": "Taylor Alison Swift is an American singer-songwriter and actress. Raised in Wyomissing, Pennsylvania, she moved to Nashville, Tennessee, at the age of 14 to pursue a career in country music. ",
          "url": "http://en.wikipedia.org/wiki/Taylor_Swift",
          "license": "https://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License"
        },
        "url": "http://taylorswift.com/"
      },
      "resultScore": 883.004883
    }
  ]
}

では次に、日本語でいくつか投げてみます。

■東京
{
  "@context": {
    "@vocab": "http://schema.org/",
    "goog": "http://schema.googleapis.com/",
    "EntitySearchResult": "goog:EntitySearchResult",
    "detailedDescription": "goog:detailedDescription",
    "resultScore": "goog:resultScore",
    "kg": "http://g.co/kg"
  },
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "EntitySearchResult",
      "result": {
        "@id": "kg:/m/07dfk",
        "name": "Tokyo",
        "@type": [
          "AdministrativeArea",
          "Thing",
          "City",
          "Place"
        ],
        "description": "Capital of Japan",
        "image": {
          "contentUrl": "http://t0.gstatic.com/images?q=tbn:ANd9GcSJxjpK7r6C8grUlfZo1m8p4E_Br56BxQOLgnzO3LCA4C-98LrG",
          "url": "https://en.wikipedia.org/wiki/Transport_in_Greater_Tokyo",
          "license": "http://creativecommons.org/licenses/by-sa/3.0"
        },
        "detailedDescription": {
          "articleBody": "Tokyo, officially Tokyo Metropolis, is one of the 47 prefectures of Japan, and is both the capital and largest city of Japan. The Greater Tokyo Area is the most populous metropolitan area in the world. ",
          "url": "http://en.wikipedia.org/wiki/Tokyo",
          "license": "https://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License"
        },
        "url": "http://www.metro.tokyo.jp/ENGLISH/"
      },
      "resultScore": 31.502502
    }
  ]
}

■メガネ・・・うーんビミョー過ぎるww
{
  "@context": {
    "@vocab": "http://schema.org/",
    "goog": "http://schema.googleapis.com/",
    "EntitySearchResult": "goog:EntitySearchResult",
    "detailedDescription": "goog:detailedDescription",
    "resultScore": "goog:resultScore",
    "kg": "http://g.co/kg"
  },
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "EntitySearchResult",
      "result": {
        "@id": "kg:/m/01whc86",
        "name": "ギラギラメガネ団",
        "@type": [
          "Thing"
        ],
        "description": "Musical Artist"
      },
      "resultScore": 6.196605
    }
  ]
}

まだ日本のGoogleで表示されるようなナレッジグラフは返ってきませんが、現状でも利用できる分野は結構ありそう。(分野によりますが)
日本語で分かりますが、クエリが「メガネ」でも返ってくるnameは「ギラギラメガネ団」ということで部分一致で返ってきます。resultScoreで判断すれば良いような気もしますが、部分一致だと微妙に罠がありそう。。。

これは久しぶりに熱くなりました!

Universal Analyticsでアウトバウンドトラッキングにnavigator.sendBeaconを利用するサンプルが追加

Google Analyticsの「アウトバウンド リンクをトラッキングする」ページの英語版にnavigator.sendBeaconを利用する場合のサンプルが追加されました。

var trackOutboundLink = function(url) {
   ga('send', 'event', 'outbound', 'click', url, {
     'transport': 'beacon',
     'hitCallback': function(){document.location = url;}
   });
}

リンクには

<a href="http://www.example.com/" onclick="trackOutboundLink('http://www.example.com'); return false;">Check out example.com</a>

という感じで指定することで、navigator.sendBeaconを利用したアウトバウンドリンクのトラッキングが可能です。
ちゃんとテストをしてみないと何ともですが、非同期でデータを送れるので対応ブラウザに関しては、より精緻にデータの取得が可能になりそうな予感。

今日現在のブラウザ対応状況は以下のとおりです。詳細はこちらを参照してください。





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とカスタムを組み合わせる事はできなそうです。