新しいGoogle AnalyticsのAPIの「Management API」の序盤を自分向けに訳してみたんです。
が、やはり長い…。
それに、順序通りやってくよりも「Feed Reference」を始めにやったほうが実践的で良かったかもと。…がんばります。
とはいえ、せっかく途中までやっ（ってしまっ）たので、ここに載せとこうと思います。
間違いなどありましたら、アドバイスください。
Manamgement API
グーグルアナリティクスの設定や、アカウントデータへのアクセスをより良くしてくれるのが、このGoogle Analytics Management API。
こんないいこと（ベネフィット）があります：
柔軟性
アカウントリクエストの範囲をカンタンに調整することができます。
(どういうことかというと)例えば、
１回のリクエストで、あなたのアカウント全てのデータやプロファイルにアクセすることができたり、特定のプロファイルのデータだけリクエストする、なんてことができます。
パフォーマンス
全てのアカウント／プロファイルの全部のゴール値をわざわざとってくるのではなく、一つのプロファイルのゴール値だけをとってくるので、フィードのレスポンス時間を減らすことができます。
構造
グーグルアナリティクスのデータ階層構造を横断できます。
The Management APIは、それぞれのフィード毎に親と子を紐づけるので、データオブジェクトに紐づいたプログラムクエリーをアプリケーション内で使うことができます。
（ここの訳はなんかあやしいですね）
いまのところ、Management APIは、以下の５つに限り、リードオンリー（書き込みは不可）でアクセスできます。
- アカウントデータ
- プロファイルッデータ
- ウェブプロパティデータ
- ゴールデータ
- アドバンスセグメント
言語ガイド
google Analytics Managementデータへアクセスし始めるのに、下にあげたガイドページが役に立つかもしれません。
その他使えるライブラリなどは、「Libraries and Examples」ページに詳しい情報があります。
Labsのポリシー
Google Analytics Management APIはまだ実験段階のものです。そのためたびたび変更が加えられていきます。通常、何か機能を削除したり、非推奨にする際は新しいAPIをリリースするおよそ１ヶ月程度前にアナウンスするよう努力します。
専用のメーリングリストに登録して、最新情報を得るようにしておきましょう。エンドユーザーに高いレベルのサービスを提供できない事態や、内部システムに多大な影響を与えるような非常時は、短い期間のアナウンスですぐに変更できる権利が私たちにあります。
通常、APIの使用状況は開発者向けのサービス条件によって統制されています。
Management API – Getting Started
Analytics Management API を使うには、既存のグーグルアナリティクスアカウントへのアクセスが必要となります。
あなたのアプリケーションへアクセスするユーザーも同じようにアクセスすることになります。
グーグルアナリティクスアカウントがないなら、作成してください。グーグルアナリティクスはグーグルアカウントを使うので、もしすでにグーグルアカウントをお持ちであれば、アナリティクスのアカウントとしてそのIDを使い、設定することが出来ます。
IDを設定したら、指示に従って、アナタのサイトへトラッキングコードを埋め込む設定を行ってください。
Feed Retrieval Basics 基本的なフィード取得方法
アカウント内のゴールやプロファイル、ウェブプロパティとグーグルアカウントそのものとの関係性を理解するのが大事です。
アカウントとプロファイルの説明ページを読めば、特定のデータをManagement APIのフィードを使ってどうリクエストすることができるのか、よく分かるはずです。
Management APIを使ってデータを取得する際、あなたのアプリが従うことになるプロセスをまとめたのが、下の基本ステップです。
- 認証
アプリにアクセスするユーザは必ずアナリティクスへログインしなければなりません。通常そのアプリは、アクセスするユーザーからログイン証明をもらうことになります。ユーザはグーグルアカウントのメールアドレスとパスワードでログインします。
認証について詳しくは、認証ガイドページをご覧下さい。 - APIクエリーの管理
ユーザがそのアナリティクスIDへのアクセス権を持っていることをアプリが認証できれば、そのユーザーがアクセスできるアカウント、webプロパティ、プロファイル、ゴールそしてアドバンスセグメントの情報をアプリで使うことができます。それぞれのデータタイプ毎にフィードが分かれているので、そのユーザが利用可能なすべてのエンティティから結果をフィードで返すことができます。
例えば。プロファイルフィードはそのユーザーアカウントに示されているプロファイルのリストを返すことができます。
詳しくは、Feed Referenceページを参照してください。 - IDもしくは、そのユーザーの全データを取得する
The Management APIは、そのユーザが利用可能な全てのデータタイプ（例えば全アカウント情報、全プロファイル情報など）の取得や、特定のデータタイプ（特定のアカウント情報、プロファイル情報）の取得方法を提供しています。- IDで：
特定のIDを使うことで、webプロパティや、プロファイル、ゴールといったフィードをそれぞれのエンティティから取得することが出来ます。例えば、webプロパティIDが、こんな感じ（UA-12345-1)だったとします。このIDを使うことで、アナリティクスの全データから探すよりも、時間を短縮することが出来ます。その結果、アプリのレスポンスタイムも向上するわけです。
IDを使えば、特定の重要な情報（例えば特定のプロファイルにあるゴール名とか）だけ取得するといったことも、カンタンにしてくれます。データクエリーは階層構造になっているので、子のエンティティのIDを特定したいといった場合は、その子エンティティの親のIDも特定する必要があります。 - ~allを使う：
IDを入力する箇所に「~all」と入れれば、そのユーザが利用できる全データを取得することができます。この~all識別子を使う場合は、その要素に続く子の要素でも同じように~all識別子を使わなければなりません。
- IDで：
注意：
~all識別子を使って全てのデータ取得をする場合、遅いです。というのも、グーグルアナリティクスでは、アカウントから始まる全ての階層構造をwebプロパティ、プロファイルといった具合に順に見ていく仕様だからです。
ですので、
たくさんアカウントやプロファイルを設定しているユーザーの場合、レスポンスが返ってくるまでに相当な時間がかかります。
そのためエンドユーザーには特定のIDを入力させるなどして、返答時間を向上させ、結果を絞り込める方法を基本的には用意すべきですね。
Management APIをExport APIと一緒に使う
プロファイルフィードは、そのユーザーがアクセス権を持つ全てのプロファイルデータに、アプリがアクセスできるようにします。
また、プロファイルで使っているData Export APIのデータへアクセスするのに、それぞれのプロファイルエントリーに存在するテーブルIDをアプリで使うことが出来ます。
割当制度(Quota)のポリシー
Google Analytics Management A PIでは、何百万というデータを処理しています。処理できる以上のデータを受けつけてしまうといったことからシステムを守るためにも、またシステムのリソースを均等配分するためにも、割当制度を使うことが必要なんです。
これらポリシーは変わることがありますが、今のところは以下の通りです。
全てのManagement APIフィードについて
それぞれのAPIのリクエストは、１度のレスポンスに対して最大10,000までとなっています。
標準（デフォルト）では１度のレスポンスに対して1,000までとなってますが、max-results queryパラメータを使えば、そのレスポンス量を10,000まで増やすことができます。
全Management APIのクエリにおいて、アプリは１秒間において10リクエスト(10qps)まで可能。
一度割り当てが制限値を超えると、オーバーした分のリクエストについては、特定のアカウントにおいて割当が充分でありませんといったページが表示されると同時に、APIがHTTPステータスコード503を返します。詳しくは、サービス規定をご覧下さい。
