一人十郷 - Takumi Nasuno Photography
ビジネス
2020/04/26

GASでGoogle Analyticsのアクセスログ(ユーザーエクスプローラ情報)を自動取得してみた【User Activity API】

みんな大好きGoogle Analytics、通称GA(ジーエー)。

JavaScriptのタグを入れるだけでウェブサイトのアクセス状況が自動で分析されてダッシュボードとして表示されるという簡便さから、GAは個人利用だけでなく法人利用でも圧倒的なシェアを誇っています。

ただし、GAで基本的に分析できるのは、要約されたマクロな集計値です。一人一人がどういう行動をとったかという個票レベルでのアクセスログは、分析どころかアクセスすることすらパッと見できそうではありません。

2016年3月に提供開始されたユーザーエクスプローラ(User Explorer)機能によって個別のユーザー行動を追えるようになっていますが、UIにはかなり癖があり、データ分析に適したものではありません。というのも、アクセスログはユーザーごとに別格納されていて、データとしてエクスポートしようにもユーザーごとに手作業をしなければならないからです。手作業、やってらんないですよね。。

なんならAPIで自動取得すればいいじゃんということでGAのAPIについて仕様を調べてみたら、思った以上に日本語情報がないどころか英語の公式情報すら調べづらい状態にあったので、ここで簡単にまとめることにしました。

(API取得ニーズはないんだろうか?いやきっとそれなりにあると思うのだけれど、ユーザーエクスプローラ自体がマイナーな機能だし、そもそもGAでそういうことをやろうという発想に至る人は少ないのかもしれません。)

 

APIの全体像

GoogleアナリティクスのモダンAPIは、2020年4月現在で6つあるようです。

  1. 基本的なレポートにアクセスする『Reporting API V4』
  2. ユーザーごとの全アクティビティを取得する『User Activity API』
  3. 現在発生しているリアルタイムなユーザーアクティビティを取得する『Realtime API V3』
  4. コンバージョン経由データを取得する『Multi-Channel Funnels API V3』
  5. クライアントサイド(JavaScript)から呼び出す『Embed API』
  6. レポートの完全なデータを取得できる『Metadata API』

 

GAのAPIは基本的には以下の一覧に載っているのですが、

・・・なぜかUser Activity APIはここに載っていません。User Activity APIのURLは『/reporting/core/v4/user-reporting』なので、階層的にはReporting API V4に含まれる模様ですが、Reporting API V4とは全然毛色が違いますし、後述するライブラリの呼び出し方法も大上段から分岐します。なにより肝心のReporting API V4ページから辿れる導線が見当たりません。

不思議。。

 

さて本題に戻ります。アクセスログ自体を取得できるのは User Activity API ですが、このAPIはGA上でユーザーごとに定義されるクライアントIDをパラメータに渡さないと取得できません。そのため、バッチ処理でReporting API V4 を呼んで直近訪問者のクライアントIDを控えつつ、そのクライアントIDを使って User Activity API を呼んでアクセスログを取得する、というのが基本的な実装形式となりそうです。

なお、有料サービスである Google Analytics 360(GA 360)ではGoogle BigQueryへのエクスポートができるようなので、上記のような回りくどい実装は不要です。色々考えるのはめんどくさい、と言う人はGA360に移行するのがよいのかもしれません。

 

実際のAPIの使い方

まずはReporting API V4を使ってクライアントIDを取得できる実装を考えます。今回は最速で実装したいので、Google Apps Script(GAS)で書いてみたいと思います。

通常だと、

  1. アプリ登録
    (Google APIコンソールからアプリを登録する。)
  2. 認証
    (OAuth 2.0 にてアクセストークンを取得する。)

という2つの事前作業が必要で、特に認証まわりはリファレンス情報自体が少ないうえに日本語は皆無、実装上は環境依存も多くて意外なところで壁にぶつかることこの上ないのですが、GASであれば同じGoogleサービス内ということでAPIを呼ばずとも『AnalyticsReporting』ライブラリ経由で直接使えるため、アプリ登録と認証という面倒な作業が不要になるという特大特典があります。「OAuth 2.0 何それ美味しいの?」という感じの方は、とりあえずGASぐらいの気持ちでGASを選定する方が絶対に楽です。

(細かいことを言うと、認証不要の恩恵を受けるには対象となるGAを保有しているGoogleアカウントのGASからのアクセスが必要です。別のGoogleアカウントが保有するGASからアクセスする場合は『AnalyticsReporting』で参照できないため、外部アプリとしてOAuth 2.0による認証が必要になります。)

 

なお、実際に作業に入る前に、参考になるページを以下に並べておきます。自分でもっと読みたい、調べたい、という方は是非ご覧ください。

 

それでは作業に入ります。

まずはGAS画面を立ち上げてライブラリの有効化をします。細かいGASアプリの立ち上げについて分からない人は、1年くらい前の記事を参照するかググってください。GAS画面にたどり着いたら、GAS画面の上タブの『リソース』から『Googleの拡張サービス』を選び、『Analytics Reporting API』を『V4』で有効化して『OK』ボタンを押します。ただし、初めての時は

Advanced Google Services

To enable Advanced Services for your Apps Script-managed Cloud Platform project, please accept the Cloud Console Terms of Service. If the terms were recently accepted, please wait a bit and try again.

などと表示されて、Google Cloud Platformの利用規約を承諾するよう促されるので、リンクをクリックして承諾します。すると、もう一度『Googleの拡張サービス』をクリックすると10数個の拡張サービス(ライブラリ)が並ぶので、『Analytics Reporting API』を『V4』で有効化して『OK』ボタンを押します。

 

ライブラリの有効化ができたら、あとはコードを書くだけです。

以下のコードサンプルは、対象としたいビューについてGAの管理画面でビューID(たぶん8桁の数字)を調べてグローバル変数『VIEW_ID』にて『ga:』の後に続くように入力するだけで使えるサンプルです。

ざっくり説明すると、『saveRecentAnalyticsActivityList』という関数を実行すると、昨日のアクティビティを取得して、【クライアントID、セッションID、日時、パス】に絞って整形してリスト化し、JSON形式でGoogle Driveに保存するような機能です。

 

留意点をいくつか挙げると、

  1. 本実装の鍵となるクライアントIDを取得するために必要なディメンション名『ga:clientId』は残念ながらリファレンス上に記述がない。言われればそうだと思えるディメンション名だが、リファレンス上にないので気付かない人は永遠にクライアントIDが取得できないと思われる。
  2. AnalyticsReportingでの対象期間は日付(startDate, endDate)指定だが、返ってくるアクティビティデータがGMT基準だった。つまり例えば昨日と指定すると、昨日の朝9:00~今日の朝8:59という風に9時間後ろ倒れした日本時刻(JST)にて取得されるように見える。GAのビュー設定ではタイムゾーンをJST指定しているため、タイムゾーンの如何は関係ないのかもしれない。なお、複数のアカウントで試してみたら後ろ倒れしないケースも見られたため、何か別のキーがあると思われる。根本的な原因は不明。
  3. AnalyticsReportingではクロスデバイスで一意なIDを設定できるuserIdが仕様として取得できないため、AnalyticsReportingでuserIdなるものを取得したい場合はカスタムディメンションに設定しておく必要がある。
  4. ユーザーリスト取得に絡めてカスタムディメンションを追加取得する場合、AnalyticsReporting.Reports.batchGetのdimensionsに放り込めばとりあえず取得はできるが、取得するレコードは指定したディメンションの総掛け合わせであるため、カスタムディメンションの設定前/設定後の期間がある場合は同一クライアントIDにおいてカスタムディメンションのパターンに応じた複数レコードが返ってきてしまう。その場合、User Activity APIに繋ぐためにはクライアントIDのユニーク化処理が必要となる。
  5. ユーザ一覧の取得は10万件の取得が上限であるため、10万人/1日以上の訪問がありうるウェブサイトではページングを実装する必要がある。(このサンプルコードでは割愛した。)
  6. User Activity APIのリクエストがユーザー1人ずつしかできない。userIdフィールドにクライアントIDを配列で放り込んでも配列拒否エラーが出るし、文法の癖を読んでuserIdsフィールドとして配列を放り込んでもフィールド名から受け付けないため、本当に1人ずつしかできない模様。つまり、実質的にユーザー数とリクエスト数がほぼ比例するため、大規模サイトの場合は次項のリソース制限に苦しむことになる。
  7. AnalyticsReportingにはAPIリクエストの制限と割り当てが存在する。2020年4月現在、①プロジェクトごとに50,000リクエスト/1日の制限、②IPアドレスごとに10クエリ/1秒の制限、③ユーザーごとに100リクエスト/100秒の割り当て制限(1,000リクエストに変更可)、④ユーザーごとに10リクエスト/1秒の割り当て制限、という4つの制約が存在するため、大規模なサイトではユーザごとにアクティビティを取得する処理(つまりAnalyticsReporting.UserActivity.search)を敢えて分割バッチ処理にするなどしてスローダウンする必要が出てくる。

あたりは気にしておいた方が良いかもしれません。

 

まとめ

ということで、サンプルコードが半分くらいを占める投稿になってしまいましたが、AnalyticsReportingを使ったとしても意外とハマりやすいユーザーエクスプローラ情報の取得について書いてみました。

大規模なサイトでは上述の留意点をクリアする実装をするか、思い切って有料版であるGA360に切り替える必要がありますが、その点を考慮したとしても、GAさえ使っていれば案外簡単にアクセスログを引っこ抜くことができるのだなというのが今回の発見でした。

こうやって必要なデータだけに整形してアクセスログを取得してJSON形式で保管できれば、あとは煮るなり焼くなり好き勝手にできます。今回はAPIを使って自動取得に成功しているので、以降のデータ分析やアクションへの落とし込みまでを自動化すれば、かなり自由度の高いウェブマーケティングが実現できると思われます。

以上、作業メモでした。

同じカテゴリの投稿もどうぞ!

ビジネス組織における多様性と持続性について、徒然に考察してみた
ビジネス
2020/08/02
ビジネス組織における多様性と持続性について、徒然に考察してみた
Firebaseで2個目のWebアプリ開発、Cloud Firestoreベースで本格的に開発挑戦するときの勘所について
ビジネス
2020/05/27
Firebaseで2個目のWebアプリ開発、Cloud Firestoreベースで本格的に開発挑戦するときの勘所について
IT&マーケティング界隈で働くうえで自分が大切だと痛感している基本的なビジネススキルと志向性を言語化してみた【2019年12月版】
ビジネス
2019/12/26
IT&マーケティング界隈で働くうえで自分が大切だと痛感している基本的なビジネススキルと志向性を言語化してみた【2019年12月版】
【Webアプリ作成】Firebaseを使ってリアルタイムでデータを可視化する要点【最短ルート】
ビジネス
2019/11/20
【Webアプリ作成】Firebaseを使ってリアルタイムでデータを可視化する要点【最短ルート】
【GASデータ活用】Google Apps Scriptによる快適なデータ操作を考えてみた
ビジネス
2019/11/12
【GASデータ活用】Google Apps Scriptによる快適なデータ操作を考えてみた

≫ もっと読む

ブログ著者について

那須野 拓実(なすの たくみ)。たなぐら応援大使(福島県棚倉町)。トリプレッソを勝手に応援する人。ネイチャーフォト中心の多言語ブログを書いてます。本業はナレッジマネジメントとかデータ分析とかの何でも屋ですが、今は半年間の育児休業中。
ブログカテゴリ