Adobe Analytics（旧SiteCatalyst, Discover）に関するニュースやTips、活用テクなど。 |
Adobe Analytics >
Adobe Analytics実践メモ
Adobe Analyticsの新パスレポート「フロー」の知られざる威力と活用方法
もう何年も進化していなかったパスレポートが2016年10月にようやく刷新され、ワークスペースに「フロー」レポートとして追加されています。モバイルのレポートとして先行リリースされていた新UIがWeb用のレポートとして横展開された形で、旧来のUI（Reports&Analytics）におけるパス系のレポートはフリーズされたまま残っています。 「前より見た目が良くなっただけ」ではありません。改めて何がスゴイのか、どう活用すべきかについて詳しく解説します。  新レポート「フロー」のここがスゴイ！（１）eVarでも使える！Googleアナリティクスの行動フローレポートは、ページ（コンテンツグループ）とイベントの経路のみに限定されています。 Adobe Analyticsの従来のパスレポートは、管理者が有効化すれば、ページだけでなく任意のProp（カスタム変数）でも実行できるので、サイト内検索キーワードやコンテンツタイプ、日付、ロイヤルティなどのカスタム変数の変遷を分析することができます。 新しいワークスペースの「フロー」では、順次(sequence)セグメントの機能を使ってデータを処理するので、何とeVarでもパス（フロー）を調べられるようになりました！事前の有効化も不要です。  製品、ドメイン、リファラタイプ、製品などのカスタム変数ではない標準変数にも対応しています。 （２）数の制限がなくなった！以前のパスレポートでは、表示できる数（縦の項目数、横のステップ数）に制限がありました。 「新しいフロー」レポートでは、クリックして無制限に展開できます。 標準では上位5件の項目が表示されます。一番下の「more」をクリックすると、もっと表示されます。  右端のノードをクリックして、先に進むこともできます。こちらも回数に制限はありません。  （３）訪問（セッション）を超えられる！従来のパスレポートでは、データが訪問（セッション）内に限定されていました。 ワークスペースの「フロー」では、Ad-Hoc Analysisの「パス」レポートと同じように、設定によってスコープを「訪問」から「訪問者」に延長できます。  設定は初期状態では「訪問者」になっているので、逆に「訪問内の動きに限定することもできる」という方が正確ですね。セッション限定の分析はあまり意味がないので、後方互換のために戻すこともできる、という程度の設定です。 設定画面で「コンテナ」と表記されているのは、内部で「Then」の順次セグメントを利用しているためでしょう。 （４）ディメンションを混ぜられる！最初の設定でディメンションを一つ選択しますが、実は、その後に別のディメンションを混ぜることができるようになりました。以前のように、一つのディメンションに囚われる必要はありません。 方法は簡単。レポートのノード上に別のディメンションをドロップするだけ。 例えば、リファラタイプごとに入口ページを把握し、勝ちパターンを見つけたい場合： リファラタイプでフローのチャートを作成した後、「ページ」をノードの右にドロップします。  このように、ノードごとに違うディメンションが混ざったフローになります。  （５）選択したパスのセグメントを作れる！ノードを右クリックして、該当パスを通過した人のセグメントを作成し、詳細分析やターゲティングで利用できるようになりました。  図の例では、「course」系コンテンツからサイトの閲覧を開始し、次に「about」系コンテンツを見た人、つまり「講座情報を検索してサイトにたどり着き、検討を進めるうちに運営者が気になって確認した人」というセグメントが作成されます。このセグメントを使えば、そういった人たちはどこから来たのか？どんなコンテンツを見たのか？申し込みに至った人と至らなかった人の違いは何か？といった詳細分析が可能になります。 例えば、「講座を検討した後にabout系コンテンツを確認した人をキャンペーン情報に誘導すれば、背中を押されて申し込みをより強く意識するようになる」といった仮説を導き出した場合は、「course系コンテンツからサイトの閲覧を開始し、次にabout系コンテンツを見たが、まだキャンペーンを閲覧しない状態で2ヶ月以内に再訪問した人」というセグメントを作成し、そのセグメントに属する人が再訪問した時にキャンペーンのバナーをサイドバーに表示する、というターゲティングが可能になります（Adobe Targetとの連携が必要）。 セグメントを作りたくない場合まだ未確定なので中間的なセグメントは作りたくない、という場合は、右クリックの「Breakdown」が便利です。  実行すると、ワークスペースに以下のようなフリーフォームテーブルが追加されます。  このセグメントは、このテーブルのみで利用可能です。再利用可能なセグメントとして作成されているわけではないので、セグメントのリストには表示されません。ただし編集はできるので、ローカルの一時的な使い捨てセグメントを作成する方法としても応用できます。 アナリティクスのAPIでも、このように、作成済みのセグメントを指定するのではなく、セグメント条件をその場で（インラインで）指定してデータを得ることが実は可能です。パラメータの異なるLP別でユーザー分析を大量に行いたい時などに便利ですね。詳細はこちら：Inline Segmentation まとめ以前は「パスなんて細かいデータを見ても役に立たない」と思ってパスレポートはあまり使っていませんでしたが、今回の改善によって、ようやくパス分析が役に立つようになりました。 解析ツールのレポートUIはざっくりと変化や違いを見つけるものであって、詳細分析やターゲティングにつなげることが重要、というプロダクトマネージャーの考えが貫かれているのが心地良いです。極論を言うと、「アナリティクスのゴールはレポート作成ではなくセグメント作成」です。カスタマーアナリティクスの考え方にも合致しているので、ワークスペースは訪問者単位の顧客分析やターゲティング施策の洗い出し、自動化に役立ちます。 順番を指定するセグメントを作る場合は、まず「フロー」で流れとボリューム感を把握し、そのままセグメントを作成してから微修正を加えるようにすれば、ミスが減るのでおすすめです。 |
DTM併用でAdobe AnalyticsとKaizen Platformを連携させる方法
A/Bテストのツールを導入する場合、単にどのパターン（エクスペリエンス）のコンバージョン率が高かったのかをA/Bテストツール側で判定するだけでなく、長期で間接的な効果を調べたり、エクスペリエンスを見た後のサイト上の行動の違いを詳しく調べるようにすると、短期的で小さな最適化に振り回されず、顧客をより深く理解でき、長期的な視点で成果につながる最適化を回せるようになります。 そのためには、AやBやCなど、振り分けられたエクスペリエンス情報をアナリティクスで計測する必要があります。 Kaizen PlatformとAdobe Analyticsを連携させる方法どのエクスペリエンスが表示されたかをeVarにセットする方法について、公式マニュアルでは情報が足りないので、補足しておきます。 DTM（Adobeのタグマネージャー）を使わない場合この場合は、Kaizen Platformの公式ヘルプ通りでOK。s_code.jsでもAppMeasurement.jsでも機能します。
DTMを使ってAAを導入している場合DTMでAdobe Analyticsをツールとして導入すると、sオブジェクトが見えなくなる（オブジェクトの名前空間が変更される）ので、 Kaizen Platformが提供するメソッド
を実行した時に「s」オブジェクトが見つからず、eVarやPropのセットに失敗します（try-catchしているので、エラーも発生せず、ひっそりと変数のセットが無視される）。 対策はいくつかありますが、sオブジェクトを自分で作成し、windowのスコープに戻すのが一番簡単。 まず、AppMeasurement.jsをAdobeのDTMサーバー上でホストするのをやめます。 次に、「エディタを開く」をクリックして、ライブラリ（AppMeasurement.js）のコードを編集します。 一番上に次の行を追加するだけ。明示的にグローバルのスコープでsオブジェクトを生成するためです。
sオブジェクトにアクセスできることを確認開発ツールのコンソールで「s」と入力して実行すると、sオブジェクトの存在を検証できます。 「s is not defined.」などではなく、Objectが戻ってくればOK。 これで、Kaizen Platformのメソッド kzs("activateSiteCatalyst"); が機能するようになりました。 指定したPropとeVarにエクスペリエンス情報（Exp_***）がセットされました。 |
クリック分析の新機能「アクティビティマップ」新登場
Excel版autoSDRのメリットと使い方
Adobe Analyticsのレポートスイート設定を自動でExcelに取り込めるautoSDR、もう試しましたかー？このスゴさが分からない人のために、メリットと具体的な使い方を紹介しましょう！ ここがスゴイ！autoSDRのメリット
具体的な使い方では、さっそく使ってみましょう！
1. まずダウンロードまずはインテリジェンスビジネスソリューションズ(IBS)のサイトからExcelドキュメントをダウンロード。 2. サインイン（認証）エクセルで開いたら、まず「KAISEKI-Assist」リボンを開いて「SDR取得」ボタンをクリック。  続いて認証情報を入力します。  共有暗号鍵には、通常のパスワードではなく、Webサービス（API）の権限を持つユーザーに付与される認証情報を入力します。 Adminコンソールのユーザー編集画面で確認できます。  注意：この認証情報は隠しシートに保存されて残るので、Excelドキュメントを閉じてまた開いたり、他の人が開いても、サインインした状態が継続されます。認証情報をクリアしたい場合は、「KAISEKI-Assist」リボンの「Sign Out」ボタンをクリックしましょう。 3. レポートスイートを選択設定情報を取得するRSを一つ選択します。複数選択はできません。  eVarやイベントの最大個数を変更することもできます。契約の種類によって、使える変数の数は異なります。 抽出ボタンをクリックしてしばらく待つと、設定情報がSDRシートに反映されます。 4. 設定情報を閲覧・編集セルに反映された設定内容は、普通に編集できます。  カスタムトラフィック変数 (Prop)変数の名前、有効状態（メニューでの表示）、リストProp扱いにするかどうか、その場合の区切り文字、パーティシペーションとパスの有効化、が可能です。 有効と無効の切り替えは選択式なので、入力不要です。  Adminコンソールとの唯一の違いは、このautoSDRでは説明文を変更できない、という点のみです。 カスタムコンバージョン変数 (eVar)Adminコンソールの「説明文」以外は同等の設定が可能です。 成功イベントAdminコンソールの「説明文」と「視認性」以外は同等の設定が可能です。 リスト変数こちらも「説明文」以外はAdminコンソールと同等の設定が可能です。
編集できない項目表示のみで、変更ができない項目もあります。SDRには含まれないことも多いので、設定内容を確認できて便利！
5. 編集内容を送信「データを送信」ボタンをクリックすると、変更した内容をサーバーへ送信する前に、どの設定をどう変更したのかの確認画面が表示されます。  この時点で、確認のためサーバーとの通信が発生します。終わるまで、しばらく待ちましょう。 サーバーから新たに取得された最新データとExcel上の更新内容との差分が検出され、画面に表示されます。 この時点では、まだ変更内容は送信（アップロード）されていません。  ソースコードのDIFFみたいなものですね。変更された項目のみ、BeforeとAfterが表示されます。チェックを入れた項目が、実際の送信対象になります。 サーバーの状態との比較なので、Excel上では変更していなくても差分が検出されることがあります。たとえば、autoSDRで設定をダウンロードした後に、誰かが通常のAdminコンソールを使ってRS設定を変更すると、相違が発生します。その場合、オリジナル（Before）の方が新しい設定になります。 どのツールを使っても同じですが、チームでRS設定を管理する場合はコミュニケーションが重要ですね。 6. 元に戻したい時はいろいろ編集した挙句「やっぱり元に戻したい！」という場合は以下の2種類の方法でExcel上のデータをクリアできます。 1. UNDOシートの上の方にあるUNDOボタンをクリックすると、シート全体がクリアされ、最後にサーバーから抽出した状態に戻ります。 最後にサーバーと通信した状態に戻すだけであって、最新のデータをサーバーからもう一度取得するわけではない点にご注意。 2. シートを再作成シートを一度削除して、サーバーから新しくデータを再取得します。このためのボタンは用意されていないので、ダウンロードしたばかりの状態の空のautoSDRを使って新規作成と同じ手順でシートを新規作成します。シートを手で削除することもできますが、裏に隠しシートが残ってしまうので、新たに再作成した方がドキュメントのサイズが無駄に増えません。 実際のところは、こちらの方がUNDOよりも利用頻度が高いはず。いつかの時点で、UNDOボタンをこちらの挙動に変更するようアップデートしたいと思っています。 7. 複数のレポートスイートに対応する方法2016年3月時点のautoSDRは、一つのレポートスイートにしか対応していません。 複数のSDRを作成したい場合は、レポートスイートごとにExcelドキュメントを分ける必要があります。 活用の例
以前にGoogleスプレッドシートで同じものを作成したことがありますが、今回のはExcelなので使い勝手がよく、機能も増えています。 上手に活用してみてください！ |
Adobe Analyticsの設計書「SDR」を自動更新できるツール「KAISEKI-Assist: autoSDR」を公開しました
2015年のクリスマスプレゼントとして、Adobe Analytics (SiteCatalyst)のレポートスイート設定をExcelのセルに自動反映する「autoSDR」を公開しました！  多くの管理者が望んでいたSDRの自動更新を、私が戦略顧問を勤めるインテリジェンス ビジネスソリューションズとのコラボにより実現しました。 エクセルを開いて、Report Builderのような感覚でログインし、RSを選択すれば、サーバーと完全同期したSDRが完成！ ダウンロードはこちらから： 「KAISEKI-Assist」- Adobe Analytics支援ツール集  今回は第一弾です。１月に第二弾を公開します！ |
オフラインデータを取り込んで分析やターゲティングができる「顧客属性」の使い方
2015年の春にリリースされた「顧客属性」(Customer Attributes)を実際に使ってみました。 会員IDで外部データをインポートできるAdobe Analyticsにデータを送信する時点で会員IDをセットしておき、そのIDに紐づく属性情報を後でアップロードすると、分析やセグメント作成でその属性情報を利用できるようになる、という機能です。 早速使ってみましょう！ インポート方法1. IDをセットするログインが成功した状態でデータをAdobe Analyticsへ送信する際に、会員IDをセットします。 eVarやPropのようなカスタム変数ではなく、Marketing Cloud ID Serviceを使ってIDをセットします。 タグマネージャ(DTM)のデータ要素を使って値をセットすると楽です。  2. CSVファイルを作るビジネス要件に合わせて、送信したIDをキーとしたCSVファイルを作成します。  1行目はインポート時に項目名として識別されるので、半角英数字にしておくと良いでしょう。半角スペースは問題ありません。 注意：Analyticsレポート上で日本語が表示されないというバグがあるので（2015年11月9日現在）、例では値を半角英数字に変換したカラムを追加してあります。 どのカラムを使うかはインポート後に選べるので、不要なカラムが残っていても問題ありません。 ただし、ファイルが100MBを超える場合は、Webからはファイルをアップロードできず、FTPサーバーに転送する必要があります。 3. 顧客属性ソース（箱）を作る（Analyticsではなく）Adobe Marketing Cloudにサインインし、「オーディエンス」メニューの中にある「顧客属性」という画面に移動し、新規作成ボタンをクリックします。  「属性ソース」とは、属性データを入れる箱のようなもので、複数定義することができます。 まず、名前と説明文を入力します。 これらは、管理画面上に表示され、管理者が理解するための情報なので、見る人にとってわかりやすいことが重要です。  エイリアスIDは、内部的な識別子になり、Audience Manager内でそのまま記録されるので、半角英数（アルファベットは小文字）とアンダースコアのみで命名します。 4. CSVをアップロードWebブラウザ上でのCSVアップロードが終わると、自動的にスキーマ検証画面に進みます。  5. スキーマを検証（カラム定義）インポートしたCSVに含まれるカラムのデータ型や名前を定義します。 タイプ：デフォルトの「string」（文字列）だと、属性がディメンションになります。「integer」「number」（数値）にすると、カスタムイベントや計算指標のように、指標として使えるようになります。 表示名：レポート名になり、メニューなどに出現します。 説明：属性についての説明文を適宜。 6. ツールに紐付ける顧客属性のデータをAnalyticsなどのツールで利用できるようにするため、マッピングが必要です（初回のみ）。  スキーマで定義した項目のうち、連携させたいものにチェックを入れます。  ツール内で選択できる属性の数は契約によって変わります。Adobe Analytics Standardの場合は3つまでです（2015年11月現在）。 ツールは後から追加することも可能です。顧客属性のデータはAnalyticsのデータとは独立したデータベース（Audience Manager）上に保管されるので、後から紐付けた場合でも、取り込み済みのデータをすぐにツール側で利用できます。 7. 有効化最後に「アクティブ」をクリックして有効化すれば準備完了！  初回だけ初期設定に少し時間がかかるので、しばらく待ちましょう。 Analyticsでのレポートでの見え方初期設定が終わると、新しいメニューが出現します。カスタマイズしていない標準状態では、「訪問者プロファイル」の下の「顧客属性」の下に、属性ごとの項目が追加されます。  顧客属性をアップロードすることによって、以下のような興味深い分析ができるようになりました！  セグメントでも使えるという点が重要です。Marketing Cloud経由でセグメントを共有すれば、顧客属性を使ってAdobe TargetでA/Bテストやターゲティングも可能です。  Web上の行動に加えて、デモグラ情報やオフラインでの購買情報、ロイヤルティ、セールス系情報なども合わせた分析やターゲティングが可能になるのです。これはスゴイ！ SAINTとどう違う？今までは、同様のことを実現するためにSAINTで分類する必要がありました。 今回の顧客属性がAnalyticsの分類（SAINT）とどう違うのかをまとめておきます。
参考：公式ヘルプ |
Adobe AnalyticsをYahoo!検索SSL化に対応させる方法
GoogleとBing、米Yahooに続いて日本のYahooもようやく2015年8月から段階的にSSL化を進めていくという決断をしました。マーケターにとっては利用できるデータが減って不便ですが、数年前にNSAやFBIがISPやFacebook、Googleなどの通信データを傍受していたことが問題になって以来、ユーザーとの通信内容を暗号化するという大きな流れは、一部のマーケターが反対したところで変わることはありません。未練を捨てて諦め、LP単位など別の分析手法を確立する方が建設的ですね。 とはいえ、検索エンジンとしてすら認識されないのは困ります。Adobe Analytics (SiteCatalyst) での現状と対策についてまとめました。 追記：2015/9/18のメンテナンスリリースでサーバー側のデータベースが更新され、SSL版のYahoo検索が正しく「検索エンジン」「キーワードを使用できません」として認識されるようになりました。以下の対策はもう不要です。 Googleアナリティクスの現状と対策については「Yahooの検索結果がSSL化したことによるGoogleアナリティクスの現状とこれから」（アユダンテ）をどうぞ。 「その他のウェブサイト」として認識されるGoogleと同様に今回のYahoo!検索も、ドメインだけはリファラに残る仕組みをわざわざ提供してくれています。 ただし、クエリが削除されたドメインだけのリファラを検索エンジン経由と認識するには、Analyticsツール側で対応が必要になります。リファラのドメインだけでなく、検索クエリを表すパラメータの有無も判断基準に含まれるためです。 2015年8月27日現在、この対応がまだ実施されていないため、Adobe AnalyticsはSSLのYahoo!検索を正しく認識できません。
判定ロジック更新には時間がかかりそうAdobe Analyticsの場合は、データ受信後にサーバー側でリファラの判定が行われます。このロジックの更新は、過去のパターンから推測すると、毎月の第三金曜日に実施されるメンテナンスリリースと同じタイミングになるので、順調なら次のメンテナンスリリースが行われるであろう9月18日か25日になると思われます。優先度が低いなどの理由で、もっと遅くなるかもしれません。 それまで待てない場合は、自力で対策する必要があります。一つの方法を以下で紹介します。 リファラを改変して正しく認識させる方法実は簡単。リファラは通常は編集できませんが、Adobe Analyticsの場合、s.referrerという変数にURLをセットすると、HTTPヘッダのリファラよりもその値を優先するという仕組みが提供されているためです（元々はリダイレクト対策用）。 この仕組みを使って、
というようなコードをdoPlugins内に追加すると、強制的にリファラにpパラメータを付与できます。 「?p=」とパラメータ名だけでは不十分で、何かの値が入っている必要があります。「none」などと適当な文字列を入れても良いですが、過去データとの整合性を保つため、例では「::empty::」をセットしています。「キーワードを使用できません」(Keyword Unavailable) は、実は内部では固定文字列「::empty::」として保存され、そのデータがレポート画面に表示される時に「キーワードを使用できません」という文字列に変換されます。実験したところ、標準で計測される「::empty::」と、今回のように明示的にセットする「::empty::」は、同じ扱いになるようです。 なお、DTMでAppMeasurement.jsをロードしている場合は、doPluginsではなくAdobe Analyticsツール設定のカスタムコードに上記のコードを入れると良いでしょう。 実験結果以下のような結果になりました。  下の行：SSLのYahoo!検索からはリファラが「http://search.yahoo.co.jp」になり、検索エンジンではなく「その他のウェブサイト」として認識されています。 上の行：前述のコードを導入することでリファラに「/search?p=::empty::」を付与したデータです。「Yahoo! - Japan」の「検索エンジン」として正しく認識されるようになりました。 リファラレポートを検索キーワードでクロスすると：  「::empty::」が「キーワードを使用できません」に正しく変換されています。 SSL化されたYahoo!検索からのトラフィックを、検索エンジン、Yahoo! - Japan、キーワードは不明、として正しく認識できるようになりました。 ※カスタマイズのテストは慎重に。 9/4追記：Firefoxの場合はdocument.referrerは「http://search.yahoo.co.jp」ですが、ChromeやIEの場合は「http://search.yahoo.co.jp/」と最後にスラッシュが入るので、コードを修正しました。正規表現を使ったり、hostnameはyahooだけれどもsearch (Query String) にp=*が存在しない、と分解して判定する方法もありますね。コードの分かりやすさ、テキストの短さ、パフォーマンス、自社のコーディング規則などを考慮し、適宜決めてみてください。 追記：2015/9/18のメンテナンスリリースでサーバー側のデータベースが更新され、SSL版のYahoo検索が正しく「検索エンジン」「キーワードを使用できません」として認識されるようになりました。以下の対策はもう不要です。 |
DTMで設定すべき５つの設定
実は複雑なAdobe Marketing CloudのクロスドメインID管理
前回は同一ドメイン内のページを遷移する場合のVisitor ID Serviceの挙動について紹介しました。 今回は、別ドメインへの遷移、既存レガシーサイトにおけるMMP (Visitor ID Service) 導入、も考慮して解説します。 （3rd-party Cookieが無効の場合とCNAMEを利用している場合は別途） 前提条件：
訪問者ID発行と保管の流れVisitor ID Service (VisitorAPI.js) 導入前のs_viクッキーが残っている状態でドメインの異なる2ページを閲覧した場合の流れについて図解します。 
まとめ
|
直帰率とバウンス率の違いは？
 サイトを訪問し、すぐに去る「直帰」という概念はWeb解析で一般的ですが、Adobe Analytics（SiteCatalyst）の場合は歴史的な経緯のため複雑怪奇、多次元的に紛らわしいので、調査・整理しました。 ※ 2015-10-19追記：2015年4月のリリースで仕様変更があったので、以下の記述は現状と合致していません まず、具体例から。 シンプルな直帰 ページAで訪問を開始し、そのままサイトを去りました。一番シンプルな「直帰」ですね。 実験結果：ページAに「Bounces」「Single Access」の両方がカウントされました。 リロードするとどうなる？ ページAを閲覧した後にリロードしました。 実験結果：Reports&Analytics (SiteCatalyst) では、BounceにもSingle Accessにもなりませんでした。Ad Hoc Analysis (Discover) では、設定の「繰り返しインスタンスをカウントする」をOFFにした場合のみ、ページAに「Bounces」「Single Access」の両方がカウントされました。 リンク計測が続くとどうなる？ ページAをロードした後に、外部サイトへの離脱リンクをクリックし、リンクのイメージリクエストを送信させました。GAでは、リンクトラッキングを直帰率に反映させるかどうかをリンク単位で切り替えられます。 実験結果：Bounceにはならず、Single Accessにはなりました。Ad Hoc Analysis (Discover) では、設定の「繰り返しインスタンスをカウントする」をOFFにすると、「Bounces」にもなります。 明らかに直帰ではない 実験結果：予想通り、BounceにもSingle Accessにもなりません。 実際のレポート結果これら4つの訪問を発生させた結果のレポートがこちら。  英語モードのヘッダを上に重ねています。 Ad Hoc Analysisの場合はこちら。Single Page Visitsという指標も追加してあります。  指標ごとの解説Bounces（バウンス）厳密な直帰。イメージリクエスト（Hit）が1度しか送信されなかった訪問回数。ページのリロードやリンク計測が発生した場合はBounceにならない。 要注意：
Bounce Rate（直帰率／バウンス率）上記のBounceを訪問回数で割った比率。 要注意：
Single Access（直帰数／単一アクセス）パスをONにすると使えるようになる指標。 v14までの定義：変数（ページ名やProp）に対してユニークな値が１種類しか送信されなかった訪問回数 v15以降の定義：リンク計測を除外したゆるい直帰。リンク計測（離脱・ダウンロード・カスタム）のリクエストが発生しても直帰扱いになる点がBounceと異なる。 要注意：
Single Page Visits（直帰数）Reports&AnalyticsではパスをONにするとパスレポートの一部として使えるようになるが、指標として普通のレポートに追加することはできない。 要注意：
まとめ（オススメ）
参考：Adobe公式ヘルプ（ただし古いので注意） |
1-10 of 92