Google Analyticsを使用したSPAアプリケーションの使用状況の分析

このトピックでは、 単一ページアプリケーションの原理に基づいて構築されたWebアプリケーションにGoogle Analyticsをねじ込むことに関する私の経験を説明したいと思います 。

このタスクの前に、私は、Googleアナリティクスとは何か、それがどんなものであるかを非常にリモートで想像していました。 このため、私はGoogleアナリティクスの理解方法についても話したいと思います。 この絞り込みが、この分析システムに精通し始める人々を助けることを願っています。

タスク自体も少し標準的ではなく、「ハリネズミとヘビを交差させる」ことで得られた経験は、誰かにとって有益な場合があります。

だから

分析の目的

使用が分析されたアプリケーションは、コラボレーションとプロジェクト管理用のSaaSアプリケーションです。 アプリケーションには次の登録スキームがあります。メインサイトからワンクリックでアカウントを作成できます。このアカウントは、URLを入力してログイン情報を入力することで既に登録できます。 このようなスキームは、潜在的な顧客がデータを入力せずにシステムに精通できるように考案されました。 私たちは、クライアントとして怠andで偏執的な人を軽daしません。

このようなワンクリックアカウント（匿名と呼ばれます）には制限があり、その中で最も重要なのは専用URLがないことです（識別はCookieを使用して実行されます）。 その結果、そのようなアカウントで作業できるのは1人のユーザーのみであり、他のユーザーを作成することはできますが、ログインすることはできません。

誰かがシステムをより詳しく知りたい場合は、アカウントを登録するよう招待されます。 登録時には、システムに入るためのパスワード付きのURLと電子メールが表示されます。 また、提案されている料金プランまたは無料のシングルユーザープランを選択することをお勧めします。

タスクは、登録せずに匿名アカウントを離れる人々の理由を見つけることでした。 このデータは、登録の割合を改善するために使用されることになっています。

Google Analyticsを選ぶ理由

すぐに予約する-この問題を解決するときは、「非侵襲的な」診断方法、つまり ログアウトするためのすべてのアンケートは除外されました。

このような問題を解決した経験がなかったため、最初に思いついたのは、ユーザーの作業を修正することです（理想的には、ビデオを録画します）。 このエントリから、ユーザーが何をしているか、なぜ登録していないのかを理解することができます。

GoogleがClicktaleで紹介してくれました。 説明によると、すべてが非常に美しく見えます。特定のJavaScriptコードが挿入され、すべてのユーザーアクション（マウスの動き、クリック、キーボード入力）の記録が開始されます。

このシステムでは、ヒートマップ（ページ上のクリックまたはマウスの動きの強度のマップ-多数のユーザーの平均指標）を作成し、あらゆる種類の統計グラフを作成し、最も重要なこと-特定の訪問のビデオを再生できます！

しかし、よく調べてみると、すべてがそれほどスムーズではないことがわかりました。 システムは次のように動作します-動きとクリックの座標、およびキーボードのキーストロークのイベントが記録されます。 その後、IFRAMEでサイトが開き、記録されたイベントが再生されます。 しかし、同時に、AjAXは一般的な形式では基本的にサポートされていませんが、公平に言えば、これに取り組んでおり、典型的なAJAX実装用のプラグインをリリースしていると言わなければなりません。

言い換えれば、このシステムは静的サイトに適しています。 Webアプリケーション、特にSPAに固定するには、多くの時間とファイルが必要です。

Totango 、 mixpanelの商用分析システムの方向に目を向けましたが、（論理的に）サイト分析に特化したものであることが判明しました-すべてのレートと効率を計算しますが、アプリケーションの使用状況は分析しませんでした。

「何か違うことをしたい」というおかしな考えさえありましたが、 GAVisualユーザーの経路を視覚化し、Googleアナリティクスからデータを抽出するための興味深いオンラインユーティリティを見ました。 これはユーザーの作業のビデオではありませんが、少なくとも一連のアクションと離れる場所ははっきりと見えます。 この場合、数十から数百のセッションを手作業でシャベルしないでください。 その後、Google Analyticsインターフェース自体に「Visitors Flow」という名前で同様の機能が登場しました。

そして、おそらく、決定的な要因は、Google Analyticsがすでにアプリケーションにねじ込まれていることでした。

一般的な分析の基本ガイドライン

ここでは、何もふりをせずに、タスクに関連してGoogleアナリティクスをどのように理解したかについてお話します。 Google Analyticsを使用する最初の範囲は、サイトへのアクセスと「さまざまなマーケティング活動の有効性」に関する統計情報を取得することです（ 引用 ） つまり、Googleアナリティクスを使用する目的としてのサイトでのユーザーの行動の分析は考慮されていませんが、プラットフォームの普遍性の結果にすぎません。 さらに、システムは主にサイト用に強化されており、アプリケーション用ではありません。 以下では、これからどのようなレーキが出たのか、どのようにそれらを踏んだのかについて詳しく説明しますが、これまでのところGoogleアナリティクスシステム自体についてです。

一般的な分析とGoogleアナリティクスの詳細を理解したい人のために、ウェブ分析ブログの冒頭にある優れた記事など、多くの資料があります 。

概念別：

ヒット （名前で障害を見つけないでください）-ロードされたサイト/アプリケーションを使用したクライアントブラウザから統計サーバーへの単一の要求。 （主に）2つのタイプのヒット-PageViewとEventがあります。 1つ目はクライアントが特定のページを開いたことを意味し、2つ目はページのオープンに関連付けられていないイベントが発生したことを意味します。

イベントに関する例では、「ビデオの再生が開始されました」ということがよく使われますが、これは絶対にすべてです-マウスの動き、クリック、キーボード入力、タイマーイベントです。

イベントを呼び出す唯一の方法は、APIを使用してGAに直接アクセスすることです。一方、PageViewを追跡するには、ページ上のGAコードのみが必要です（ページの読み込み後にヒット自体を送信します）。



興味深いことに、GAでは、ヒットはGIFファイルへのGETリクエストによって実行されますが、Webサービスへのリクエストを行うことは論理的に思えるかもしれません。 私の知る限り、これはトラフィックを減らすために行われます。 また、サーバーからのデータが必要ないという事実にも影響します。 ヒットは、訪問者とセッションID、開かれるページのURL、イベント名、画面解像度など、多くの情報を送信します。



訪問者（訪問者） -サイトを訪問したユニークなクライアント。 Cookieを使用して決定されます。



訪問（訪問） -特定のクライアントに対する一連のアクション（ヒット）。 ブラウザが閉じるか、30分間の非アクティブ時間が経過すると終了します。 また、Cookieを使用して追跡されます。 プログラマーとして、これを「セッション」と呼ぶ方が簡単です。



つまり Googleアナリティクスはスクリプトを使用して、ヒットをサーバーに送信することでアクションを収集し、訪問者とセッションごとにアクションをグループ化します。

次に、このデータがGoogle Analyticsインターフェースでどのように表示されるかについて



アカウント -Googleアカウントに関連付けられたヒットストレージ。 1つのGoogleアカウントに複数の分析アカウントを含めることができます。 同じGoogleアカウント内であっても、異なるアカウントは互いに完全に分離されます。 アカウント内では、それにアクセスできるユーザー、データに適用できるフィルター（まだ適用されていないフィルター）、およびその他の設定が示されます。



ウェブプロパティ -Googleアナリティクスでのデータ蓄積の最上位。 各リソースには、クライアントスクリプトに適合する独自のコードがあり、その後、各ヒットとともに送信されます。



プロファイル -単一のリソース内のデータのサブセット。 各リソースには少なくとも1つのプロファイルがあります。 プロファイルでは、データを選択するフィルターを指定できます。 プロファイルは、リソースに従って動的に作成されないことが重要です。 たとえば、新しいプロファイルを作成する場合、プロファイルを作成する前に収集されたデータは表示されません。

プロファイルは主要な「作業単位」です。 すべての統計が計算され、すべてのレポートが1つのプロファイル内に構築されます。





アドバンスセグメント -フィルターによって定義されたプロファイル内のデータのサブセット。 プロファイルとは異なり、セグメントはすべてのプロファイルデータにすぐに構築されます。 また、異なるセグメントのデータを互いに比較することができます（異なるプロファイルのデータ-不可能）。

すべてのフィールドをセグメントでフィルタリングできるわけではないのは残念です。 そこで、統計を台無しにして、オフィスからのテストトラフィックを開始したかったのです。 プロファイルを介してこれを行う必要があり、その結果、以前に収集されたデータは「クリア」されませんでした。



収集されたデータに基づいて、さまざまな指標が計算されます-1日あたりの訪問者数/月/...、1日あたりの訪問数/月/ ...、新規訪問者と再訪問者の比率、ページがサイトで閲覧/滞在された平均時間、特定のセッション完了の割合ページおよびその他多数。

この形式では、統計はあまり役に立ちません。なぜなら、 彼女は私たちの目標について何も知りません。 Googleアナリティクスの目標は、サイトに滞在する最小時間、訪問あたりの開いているページ数、または固定イベントとして、到達したいページとして示すことができます。 アクションのシーケンスを追跡できる「チャネルのグループ」もありますが、これは曲技飛行です。

私がした主な結論は、あなたがそれから何を望んでいるかを正確に知っている場合、この分析は良いということです:)私たちはそのような理解を持っていなかったので、「訪問者フロー」レポートを使用して、アプリケーションで訪問者が何をしているかを見ることにしました。 さて、基本的な統計を参照してください。突然解釈する方法を理解した場合。

どうだった

最初に遭遇した問題は次のとおりです。 Googleアナリティクスの分析の主要な「ユニット」は、サイトページです。 当然のことながら、このアプリケーションにはそのようなページはありません。

幸いなことに、アプリケーションは単にページの類似物を選択することができました。 これを通常の定義にする方法はわかりませんが、ほとんどの場合、特定の形式の特定のタイプのオブジェクトのリスト、または特定のオブジェクトに関する詳細情報を含む画面でした。 このようなものはどのアプリケーションでも強調表示できると思います。

さらに幸いなことに、ページはアプリケーションのクライアントアーキテクチャに明確な一致を見つけました。 ページの開始を追跡することは技術的な問題でした-適切なコード（適切な場所（1つだけ！）でGA APIにアクセスできます）で、これで完了です。 これは昔々行われました。

余談があるはずです。 当初、統計は「万が一に備えて」具体的な目標なしにめちゃくちゃにされました。 そして私たちが踏み込んだ最初のレーキは、システムのメニューとサイドバーがページと同じオブジェクトに基づいて構築されたことです。 つまり、システムが起動すると、分析コードは正直に3つのヒットを送信しました-メインページに加えて、メニューとサイドバーも開かれました。 彼らはレースにグーグルに到達しました-あなたはビジターフローでそれがどのように見えたか想像できます：





訪問開始時のおに加えて、障害の割合はほぼゼロでした。 失敗はセッション内の1ページのみを訪問していると見なされ、3ページで一度に「開きました」。

コードから偽の呼び出しを削除することは難しくありませんでしたが、以前に収集された統計の月を返しませんでした。



その後、アプリケーションがユーザーのほぼすべてのクリックでヒットを送信したことが判明しました。 そして、これらのヒットはイベントのようなものでした。 論理的には、送信するPageViewではありません。 イベントは多かれ少なかれ構造化されているという事実（階層には、カテゴリ、アクション、ラベルの3つのレベルがあります）にもかかわらず、すべてのイベントが混在しており、意味のある結論を導き出すことができませんでした。

最大の問題は、イベントが訪問者フローにキャプチャされないことです。 イベントのシーケンスは復元できません。

イベントはアプリケーションから慎重に削除され、登録の統計を維持するために最低限必要なものだけが残されました。



第三に、コンポートの代わりに、彼らは最大の問題を得ました-訪問者はセグメント化されませんでした。 目標に戻る-匿名アカウントを作成したばかりの新人の行動を追跡する必要があります。 もちろん、Google Analyticsはヒットのソースについて何も知らず、1つのヒープに初心者、経験者、およびすでに購入した人の両方を捨てました。 このヒープには意味がありませんでした。

ユーザー変数が助けになりました。 プリミティブに言えば、最大5つの名前と値のペアをヒットに割り当てることができ、それによってデータがアドバンスセグメントでフィルターされます。 変数の値をアカウントのタイプ（匿名、トライアル、または購入済み）に設定する行が分析コードに追加され、アドバンスセグメントが構成されます。 トライアルおよび購入したアカウントに加えて、「帰国者」も破棄されました。



これからは、すべてが統計を収集する準備が整いました。 しかし、UXスペシャリストは別の要件を提示しました。登録ページでのユーザーの行動を詳細に監視する必要があります。 マウスの動きを追跡することを拒否したことを神に感謝します（分析のセッションはラバーではありません-最大500ヒット）、フィールドのフォーカス、ボタンのクリック、キーボード入力を追跡する必要がありました。

イベントはこれに適していない-アクションのシーケンスを復元する必要がありました。 イベントの代わりにPageViewを使用することにしました（Google Analyticsの作成者はご容赦ください）。 つまり、電子メール入力フィールドのフォーカスは、ページを開く/登録/ emailfocus、パスワードフィールドのキーボード入力がページ/登録/ passwordkeypressなどのようになります。

技術的には、実装が簡単であることが判明しました。クライアントAPIでは、ページURLを指定することでページの開始をシミュレートできます。 さらに、分析では同一の発見が連続してグループ化され、1つの発見としてカウントされることが判明しました。 これは、キーボード入力の追跡に役立つことが実証されています。

最後の要件は、失敗した登録の理由を修正することでした（空白フィールド、ビジーURLなど）。 ここでは、非常に簡単に実行しました。登録に失敗すると、「開いた」仮想ページのURLに検証概要テキストが追加されました。 form register / submitinvalid / aliasistakenのページの「openings」を取得しました。

コードを実行して最初の統計を取得した後、私たちは失望しました。 失われた時間とは別に失望-アナリティクスのデータは数時間遅れて表示されるため、通常、変更の結果は翌日のみ表示されます。

実際、失望は、登録ページへのパスとページ自体がさまざまな訪問として記録されたことでした。 この理由は、登録ページの実装でした-IFRAMEに表示される別のアプリケーションにありました（この理由は技術的ではなく組織的です-作業を分割する方が簡単でした）。 IFRAMEは別のサブドメインのURLを表示し、分析Cookieはそれぞれサブドメインにクロールしませんでした。

Googleはすでにこの状況に対応する既製のソリューションを用意しています。 メインドメインとサブドメイン間でCookieを偽造する必要はなく、サブドメイン間のみで_setAllowHashが実行されなかったことにのみ注意してください。

デバッグの時間を節約するために、まだベータ段階のリアルタイム機能を使用しました。 それにもかかわらず、それは動作します:)デバッグのために、アカウントに別のリソースを作成し、変更の結果がすぐに見えるようになりました：





ささいなことは別として、それだけです。



まだ克服されていない問題が1つ残っています。 訪問者のフローは頑固にルートページへの訪問をキャプチャしますが、空のURLでPageViewがヒットすることはありません。 ほとんどの場合、これはアカウントを登録する場合です。 イベントは特定のページも参照します。SPAがあるため、すべてのイベントは自動的にルートページを参照します。 クライアントAPIを介してイベントにページを強制的に登録する方法は見つかりませんでした。

さらに奇妙なのは、このルートページからのユーザーの離脱です。 アカウント登録イベントが到着したが、開始ページのPageViewが到着していないかのように。 確かに、ユーザーが適切なタイミングでブラウザーをすばやく閉じると想定できますが、そのような終了の割合は非常に大きくなります。 多くのユーザーがこのような良い反応と直感を持っているとは思いません（瞬間を推測する必要があります）。 私たちはまだ詳細に問題を調査していません-それは人生にあまり干渉しません。

もう1つのコメントは、訪問者フローレポートのデータが他のレポートよりも少し遅れるため、このレポートの訪問数は他のレポートよりもわずかに少ないことです。

また、このレポートの注釈はページの不思議なグループ化である場合があります。ある反復ステップで、たとえば8ページのグループが1つある場合があります。 これらのページが個別に表示されない理由（画面上に場所があります）-Googleだけが知っています。

その結果、次のようなものが得られました。



これの解釈は別の記事のトピックであり、1つの記事ではない場合があります。