Core Reporting APIのV3を利用している人でV4になかなか踏み出せないという方も多いのではないかと思います。V4がリリースされて1年ちょっと。V3からV4への移行によるメリットは以下目的に集約されるのではないでしょうかということで、少しまとめてみようと思います。
従来2期間、例えば前年比や前週比、その他特定期間同士を比較する場合V3では2期間それぞれでAPIを叩き、その結果を自分たちで比較する必要がありましたが期間を配列で2つ渡すことが可能となったことによって1リクエストで完結することができるようになりました。
個人的にはこの機能が一番分析スピード、Google Analytics APIへのリクエスト数削減となりました。
例えばdimensionの値によってこのようなグラフを作成したい場合、今まではfilterで個別の条件、この場合は6条件指定してデータを抽出してから一つにデータを並べて描画する必要がありました。
(6リクエスト)
しかしながら今回historical bucketが発生したのでこのデータ抽出は1リクエストで完結します。(6 -> 1リクエスト)
これはかなりデータ抽出時間の削減になります。
historical bucketでは指定した値は範囲の上の値となります。例えば ['1', '3', '4', '7'] という配列が指定された場合、1未満、3未満、4未満、7未満、7以上というデータが返却されます。
V4のみサポートされる機能の利用
■pivot
これが地味に嬉しい機能ですね。GAのpivot…、あまり利用されている方をお目にかかることはない機能ではあります。pivotを利用することで抽出できるデータの幅が広がりますし、2期間比較のところで述べた内容と同じではありますが複数回リクエストしてからSpreadsheetなどでデータを整形するとなると抽出されたデータが100%データであれば問題ありませんが、filterやデータサイズによって返却されたデータの中でしか分析ができないのです。
Google Analyticsの画面側での領域を以下のように3つに分解すると
APIでは以下のような位置づけになります
① : dimensions
② : pivot.dimensions
③ : pivot.metrics
この辺はあまりヘルプでも詳しく説明されてはいないように思います。
■cohort
コホートも時々見る程度で利用しているという人はあまりお目にかからないような気はしますが、個人的にはスマートフォンだとAndroidとiOSで定着に差がありそうだとか、いくつかsegment別定着数、定着率ウォッチ用に使っていたりします。
OSや何か条件によって定着って結構ぶれますし、普段からなんとなくデータを見ておかないと特にリリース後の異常値に気づかないということもありますので。
例えばAndroidにセグメントをかけつつcohortデータを出す場合は
{
viewId = , cohortGroup = {
cohorts = {
dateRange = {
endDate = 2017 - 12 - 21,
startDate = 2017 - 12 - 21
}
}
}, samplingLevel = LARGE, metrics = {
expression = ga: cohortActiveUsers
}, dimensions = [{
name = ga: cohort
}, {
name = ga: cohortNthDay
}, {
name = ga: segment
}], segments = {
dynamicSegment = {
name = os,
sessionSegment = {
segmentFilters = {
simpleSegment = {
orFiltersForSegment = {
segmentFilterClauses = {
dimensionFilter = {
expressions = Android,
dimensionName = ga: operatingSystem,
operator = EXACT
}
}
}
}
}
}
}
}
}
こんな感じになります。(viewIdは抜いています)
※注意点 : 期間指定の仕方
ga:cohortNthDay : startとendが同一日
ga:cohortNthWeek : startが日曜日、endが土曜日
ga:cohortNthMonth : startが1日、endが月末最終日
個人的にはこの期間指定、使いにくいなーって思っています…。
■LTV
今唯一このLTV機能だけは利用していないので若干間違っている部分があるかもしれないのですがAPIでのLTVはcohortの拡張でCohortGroupの中にlifetimeValueが存在しています。
lifetimeValueはtrue,falseの指定をする形になりますのでcohortの期間に関する注意点は同様となります。
{
viewId = , cohortGroup = {
lifetimeValue = true,
cohorts = {
dateRange = {
endDate = 終了日入れる,
startDate = 開始日入れる
}
}
}, samplingLevel = LARGE, metrics = {
expression = ga: cohortActiveUsers
}, dimensions = [{
name = ga: cohort
}, {
name = ga: cohortNthDay
}]
}
こんな感じになるのかなと思います。(viewIDや期間は未指定)
その他注意点など
■session dateが存在しなそう…
session date…これはstack overflowとかを見てもcohortで書けよ的なものも見受けられますし、Googleのヘルプもcohortに紐づくものか？と思われる書き方がされているし、ちゃんとした仕様を把握している人、Googleにも実はいないんじゃ…と思わなくもなく。むしろ開発側の認識と企画側の認識の差が生み出した機能！？
まずはsession dateとはなんぞや？という事ですがsegmentにある「セッション日」です。
これは特定の期間にセッションが存在しているということしか意味していないような動きをしています。その証拠にとあるアカウントでデータを抽出してみたものを見てみます。
分かりやすいようにコホートページで且つセグメントとしてセッション日が特定の日であるという条件にします。
そうするとリテンション割合データはこの通り表示されます。
即ち100%と表示されているのがセグメントで指定した日ですね。
この「セッション日(session date)」には指定した日にセッションが存在したという条件しかかかっていない事が分かると思います。
V3ではこのsession dateには `dateOfSession` というパラメータが存在しましたが、V4では存在しません。この `dateOfSession` = session dateなのか？という点については
過去に別のpostをしましたが。
V4で日付を指定するには分析期間としてのdateRangeとコホートのdateRangeがありますが、segmentでは存在しません。date使えばいいじゃん…というツッコミもあると思いますがdateはsegmentでは利用出来ません。この `Allowed In Segments` の部分。
その他date関連はすべてセグメント指定には利用出来ない事になっています。
一方でcohort内で指定される日付については指定しなくても指定しても最初のアクセス日としか処理されません。
なので現状は存在しないと思われます。
基本V3で動いていたScriptをV4に移行しているのですが、session dateまわりのものだけは移行出来ませんでした。
すみません…このsession dateまわりに悩みつつ利用しつつはや4年くらい…以前Googleの人に直接聞いたものの個別案件には回答出来ないと言われたままｗ (聞き方が悪かった説が濃厚
■V3であったfilterは存在するけど機能分裂
APIのV3ではデータに対して何らか条件で抽出する場合、segmentとfilterの2種類存在していました。これはGoogle Analyticsの画面上でも同様で意識的な使い方としては…
- segment : 解析するデータの母集団に対するフィルタリング
- filter : 返却されたデータに対するフィルタリング
だと思っています。(あまり意識していなくてもGoogleがうまく抽出しているように見えるような事もある)
segmentは例えば検索経由で流入した人とか、新規ユーザといった分析対象となるユーザやセッション、セッション中のヒットなど母集団を絞り込む機能です。そのためこのsegmentの設定を間違えるとそもそも対象となる母集団にゴミがまじったりといった副作用があります。一方でfilterは返却値に対するフィルタで例えば返却されたURLの中から `hogehoge` という文字列が含まれるものを絞り込むといった用途になります。
例) 検索経由で流入したユーザがランディングしたページがサイトTOPページとなっているセッション数は？
この場合…
segment : 検索経由で流入したユーザ (ユーザレベル , 検索経由)
metric : セッション数
dimension : ランディングしたページURL(ga:landingPagePath)
filter : ランディングしたページURLがサイトTOP (ga:landingPagePath == '/' )
といった感じになります。
即ちdimensionとそれに対するfilterです。
今回V4になってfilterはいくつかに分解されました。
- サーバ側filter
- dimensionFilterClauses : dimensionsに対するフィルタ
- metricFilterClauses : metricsに対するフィルタ
- 返却データに対するfilter
- filtersExpression : V3のfilterと同義
まず大きく分けてデータ抽出に対するフィルタと返却されたデータ群に対するフィルタの2種類が発生しました。
今までのV3のフィルタはmetricsに対するフィルタもdimensionsに対するフィルタも書けた訳ですが、抽出後データへのフィルタ一本化されていたように思っています。今回V4化でデータ抽出時にsegmentをした母集団に対して更にdimensions、metricsに対しフィルタをした状態でデータを返却可能となりました。そしてもしそれで足りなかった場合は返却されたデータの中から更にfilterをかけるという構造です。
ただし個人的には従来のフィルタは基本的にClause側へ完全に寄せ、filtersExpressionはV3との互換性確保のために一応用意されているものではないかと感じています。(次のバージョンでは消える…とか)
filtersExpressionではV3のfilterと全く同じ文法で書くことができるようになっています。
■欲しい機能
