Adobe Analytics‎ > ‎

Adobe Analytics実践メモ

Adobe Analytics(旧SiteCatalyst, Discover)に関するニュースやTips、活用テクなど。

Adobe Analyticsの新パスレポート「フロー」の知られざる威力と活用方法

posted Jan 4, 2017, 3:35 AM by Makoto Shimizu   [ updated Jan 4, 2017, 7:13 PM ]

もう何年も進化していなかったパスレポートが2016年10月にようやく刷新され、ワークスペースに「フロー」レポートとして追加されています。モバイルのレポートとして先行リリースされていた新UIがWeb用のレポートとして横展開された形で、旧来のUI(Reports&Analytics)におけるパス系のレポートはフリーズされたまま残っています。

「前より見た目が良くなっただけ」ではありません。改めて何がスゴイのか、どう活用すべきかについて詳しく解説します。

新レポート「フロー」のここがスゴイ!

(1)eVarでも使える!

Googleアナリティクスの行動フローレポートは、ページ(コンテンツグループ)とイベントの経路のみに限定されています。

Adobe Analyticsの従来のパスレポートは、管理者が有効化すれば、ページだけでなく任意のProp(カスタム変数)でも実行できるので、サイト内検索キーワードやコンテンツタイプ、日付、ロイヤルティなどのカスタム変数の変遷を分析することができます。

新しいワークスペースの「フロー」では、順次(sequence)セグメントの機能を使ってデータを処理するので、何とeVarでもパス(フロー)を調べられるようになりました!事前の有効化も不要です。

製品、ドメイン、リファラタイプ、製品などのカスタム変数ではない標準変数にも対応しています。

(2)数の制限がなくなった!

以前のパスレポートでは、表示できる数(縦の項目数、横のステップ数)に制限がありました。

「新しいフロー」レポートでは、クリックして無制限に展開できます。

標準では上位5件の項目が表示されます。一番下の「more」をクリックすると、もっと表示されます。

右端のノードをクリックして、先に進むこともできます。こちらも回数に制限はありません。

(3)訪問(セッション)を超えられる!

従来のパスレポートでは、データが訪問(セッション)内に限定されていました。

ワークスペースの「フロー」では、Ad-Hoc Analysisの「パス」レポートと同じように、設定によってスコープを「訪問」から「訪問者」に延長できます。

設定は初期状態では「訪問者」になっているので、逆に「訪問内の動きに限定することもできる」という方が正確ですね。セッション限定の分析はあまり意味がないので、後方互換のために戻すこともできる、という程度の設定です。

設定画面で「コンテナ」と表記されているのは、内部で「Then」の順次セグメントを利用しているためでしょう

(4)ディメンションを混ぜられる!

最初の設定でディメンションを一つ選択しますが、実は、その後に別のディメンションを混ぜることができるようになりました。以前のように、一つのディメンションに囚われる必要はありません。

方法は簡単。レポートのノード上に別のディメンションをドロップするだけ。

例えば、リファラタイプごとに入口ページを把握し、勝ちパターンを見つけたい場合:

リファラタイプでフローのチャートを作成した後、「ページ」をノードの右にドロップします。

このように、ノードごとに違うディメンションが混ざったフローになります。

(5)選択したパスのセグメントを作れる!

ノードを右クリックして、該当パスを通過した人のセグメントを作成し、詳細分析やターゲティングで利用できるようになりました。

図の例では、「course」系コンテンツからサイトの閲覧を開始し、次に「about」系コンテンツを見た人、つまり「講座情報を検索してサイトにたどり着き、検討を進めるうちに運営者が気になって確認した人」というセグメントが作成されます。このセグメントを使えば、そういった人たちはどこから来たのか?どんなコンテンツを見たのか?申し込みに至った人と至らなかった人の違いは何か?といった詳細分析が可能になります。

例えば、「講座を検討した後にabout系コンテンツを確認した人をキャンペーン情報に誘導すれば、背中を押されて申し込みをより強く意識するようになる」といった仮説を導き出した場合は、「course系コンテンツからサイトの閲覧を開始し、次にabout系コンテンツを見たが、まだキャンペーンを閲覧しない状態で2ヶ月以内に再訪問した人」というセグメントを作成し、そのセグメントに属する人が再訪問した時にキャンペーンのバナーをサイドバーに表示する、というターゲティングが可能になります(Adobe Targetとの連携が必要)。

セグメントを作りたくない場合

まだ未確定なので中間的なセグメントは作りたくない、という場合は、右クリックの「Breakdown」が便利です。

実行すると、ワークスペースに以下のようなフリーフォームテーブルが追加されます。

このセグメントは、このテーブルのみで利用可能です。再利用可能なセグメントとして作成されているわけではないので、セグメントのリストには表示されません。ただし編集はできるので、ローカルの一時的な使い捨てセグメントを作成する方法としても応用できます。

アナリティクスのAPIでも、このように、作成済みのセグメントを指定するのではなく、セグメント条件をその場で(インラインで)指定してデータを得ることが実は可能です。パラメータの異なるLP別でユーザー分析を大量に行いたい時などに便利ですね。詳細はこちら:Inline Segmentation

まとめ

以前は「パスなんて細かいデータを見ても役に立たない」と思ってパスレポートはあまり使っていませんでしたが、今回の改善によって、ようやくパス分析が役に立つようになりました。

解析ツールのレポートUIはざっくりと変化や違いを見つけるものであって、詳細分析やターゲティングにつなげることが重要、というプロダクトマネージャーの考えが貫かれているのが心地良いです。極論を言うと、「アナリティクスのゴールはレポート作成ではなくセグメント作成」です。カスタマーアナリティクスの考え方にも合致しているので、ワークスペースは訪問者単位の顧客分析やターゲティング施策の洗い出し、自動化に役立ちます。

順番を指定するセグメントを作る場合は、まず「フロー」で流れとボリューム感を把握し、そのままセグメントを作成してから微修正を加えるようにすれば、ミスが減るのでおすすめです。

DTM併用でAdobe AnalyticsとKaizen Platformを連携させる方法

posted Jun 16, 2016, 11:34 PM by Makoto Shimizu   [ updated Jun 16, 2016, 11:38 PM ]

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が提供するメソッド

try { kzs("activateSiteCatalyst"); } catch(e) {}

を実行した時に「s」オブジェクトが見つからず、eVarやPropのセットに失敗します(try-catchしているので、エラーも発生せず、ひっそりと変数のセットが無視される)。

対策はいくつかありますが、sオブジェクトを自分で作成し、windowのスコープに戻すのが一番簡単。

まず、AppMeasurement.jsをAdobeのDTMサーバー上でホストするのをやめます。

次に、「エディタを開く」をクリックして、ライブラリ(AppMeasurement.js)のコードを編集します。

一番上に次の行を追加するだけ。明示的にグローバルのスコープでsオブジェクトを生成するためです。

window.s = new AppMeasurement();

sオブジェクトにアクセスできることを確認

開発ツールのコンソールで「s」と入力して実行すると、sオブジェクトの存在を検証できます。

「s is not defined.」などではなく、Objectが戻ってくればOK。

これで、Kaizen Platformのメソッド kzs("activateSiteCatalyst"); が機能するようになりました。

指定したPropとeVarにエクスペリエンス情報(Exp_***)がセットされました。

クリック分析の新機能「アクティビティマップ」新登場

posted May 2, 2016, 12:41 AM by Makoto Shimizu   [ updated May 2, 2016, 12:46 AM ]

2016年4月のアップデートで、新機能「アクティビティマップ」がリリースされました。ここ数年間アップデートされることなく放置されてきた類似の機能「ClickMap」が、ようやく刷新されました。根本的に作り直されていて、機能も増えています。

ClickMapから進化した点

  • 同一ページ内のリンクを自動で判別:以前はリンク先URLだけで識別していたので、同一ページ内でリンク先が同じリンクが複数ある場合は特殊なタグ追加などが必要でした。新しいアクティビティマップでは、リンクテキストやALTなどを組み合わせて個別リンクを識別できます。
  • セグメントを適用可能に:ようやく対応。分析に必須の機能ですね。
  • リアルタイムデータを表示可能に:「Liveモード」に切り替えると、「現在のデータ」とも呼ばれ、リアルタイムレポートでも表示される、トラフィック系の直近データを表示できます。
  • 閲覧中のページに関する詳細データを表示可能に:各種指標やパスレポートを表示できます。パスのレポートは今風に刷新されました。
  • すべての指標を表示可能に:クリック数だけでなくカスタムイベント(コンバージョン)も選択できるようになりました。

アクティビティマップを導入する方法

アクティビティマップは、デフォルトのままでは使えません。導入のために、以下の3つの手順が必要です。

  1. 計測用ライブラリを最新化:AppMeasurementの1.6以降が必要(s_code.jsには非対応)
  2. レポートスイートの設定でアクティビティマップを有効化
  3. ユーザーをグループに所属させる

手順を追って説明します。

1. 計測用ライブラリを最新化:AppMeasurementを1.6以降が必要(s_code.jsには非対応)

DTM(タグマネージャー)を使っていれば楽勝ですね。

ツール設定のドロップダウンメニューで「*(最新)」を選択して保存し承認したら配信するだけ。

これで、クリックした箇所のデータが送信されるようになります。クリックしたときにコールが発生するのではなく、次のページの通常計測データに、前のページでクリックしたリンクに関する各種のデータが追加されるようになります。

※ヘルプに「AppMeasurement.js以外にコードの追加が必要」という記述が残っていますが、AppMeasurement.jsに標準で含まれるようになったので、手でコードを追加する必要はありません。

2. レポートスイートの設定でアクティビティマップを有効化

管理者メニューのレポートスイート設定画面に「アクティビティマップ」という新しい項目が追加されています。

少々おかしな日本語が表示されますが、気にしないで「アクティビティマップレポートを有効にする」をクリック。

このようにサーバー側でも有効化しないと、送信されたデータを受け取って処理してくれません。

3. ユーザーをグループに所属させる

同じ画面の「ユーザーをグループに追加」をクリックすると、自動的に追加された「Activity Map Access」というグループの編集画面が表示されます。

アクティビティマップを使うユーザーを追加しておきます。

アクティビティマップを使ってみよう!

1. インストール

ClickMapと同じように、ブラウザアドオン(プラグイン)のインストールが必要です。

ツール」メニューに追加された「アクティビティマップ」に移動します。

グループに所属するユーザーが開くと、以下のようにダウンロード用のリンクが表示されるので、クリックしてインストール。

ブラウザは自動で識別してくれます。

2. サインイン

インストールが終わったら、サイトにアクセスして、バーに追加されたアイコンをクリックしてAdobe Analyticsにサインインします。

サインイン」すると、Webページの右上にツールバーが表示されるようになります。

3. 日本語に切り替える

まず「Settings」で日本語に切り替えておきましょう。

Other」タブに切り替えてLanguage設定で「日本語」を選択。

4. 詳細データを表示

タイミングによって、データがゼロになることがあるようです。

そこで、まず設定アイコンの左にある目のアイコンをクリックして、詳細データが表示されるか確かめてみましょう。

画面下にリンクの一覧が表示されます。

リンククリック数」がカウントされていれば、正常に動作しています。

  • リンクID:アンカーテキスト(テキストリンクの場合)、ALTやTitle属性やファイル名+リンク先URL(画像の場合)など
  • 地域:日本語訳が変ですが、リンクが配置されたエリアのこと(CSSのクラス名など)
  • 表示:計測されたリンクが画面にまだ表示されている場合は「表示済み」になる

つまり、リンクをクリックした時にAppMeasurement.jsがリンクIDと地域の情報を自動で取得し、ClickMapサーバーへデータを送信、Adobe Analyticsもこれらの2種類の情報を組み合わせて個別のリンクを認識する、ということですね。

5. クリック数を表示する

さて、肝心のクリック回数を表示してみましょう。

デフォルトだと、「バブル」(吹き出し)で指標が表示されます。

バブルは水平方向にズレて表示するバグがあり、それが直ったとしてもどのリンクを指しているのかがわかりにくいので、「グラデーション」がおススメ。

グラデーション」ならリンクのクリック可能な領域が囲まれて表示されるので、わかりやすいです。

表示される数字は、設定画面で変更できます。

  • ラベルなし:数字を表示しないという謎のオプション
  • :クリック回数や訪問回数、注文回数など、設定で選択した指標の実数を表示
  • 割合:リンクごとの値を全リンクの合計値で割ったパーセント
  • ランク:上位からの連番

分析の目的や指標の種類、トラフィックの量によって選択。数値が1桁、2桁と小さい場合は「」が無難。リンクごとの違いをわかりやすくするのが大事。

6. 新しいパスレポートが使える

ページ下部のパネルを開いて左上の「ページの詳細」に切り替えると、開いているページに関する各種指標とパスレポートが表示されます。

このパスレポートでは、モバイルアプリ用のレポートで実装された新しいデザインが採用されています。

末端をクリックしても前後移動できないので、モバイル画面のパスレポートには及びません。早く分析ワークスペースに実装して!!

7. Reports&Analyticsの画面でもチェック可能

通常のレポート画面にも「Activity Map」というメニューが追加されていて、同じデータを確認することができます。

が、このレポートは義務的に追加されただけで、使う機会はほとんど無いと思います。

Data WarehouseやReport Builderでデータを取得できることの方が重要ですね。

清水の感想

  • コンテンツやUIの分析に使える
  • 実際にクリックされたリンクのみが対象になり、クリックの位置は記録されないので、ヒートマップ系のツールではないことを理解すべし
  • パスレポートの代替えとしても価値がある
  • 日本語訳の質が低いので、英語で使ったほうが良い

Excel版autoSDRのメリットと使い方

posted Apr 6, 2016, 11:12 AM by Makoto Shimizu   [ updated Apr 6, 2016, 1:34 PM ]

Adobe Analyticsのレポートスイート設定を自動でExcelに取り込めるautoSDR、もう試しましたかー?このスゴさが分からない人のために、メリットと具体的な使い方を紹介しましょう!

ここがスゴイ!autoSDRのメリット

  • 1つのExcelシート上で全設定を閲覧・編集できる
    • 従来の管理画面は変数ごと別画面で、しかも100個などの単位でページをめくる必要がありました(面倒!)
    • autoSDRなら、250個のeVar、100個のProp、1,000個のevent、3つのリスト変数を一つのExcelシート上で確認・編集できます。
      さらにマーケティングチャネルや個別訪問者変数、内部URLフィルタ、有料検索検知の設定も(参照のみ)
  • 設定を一気にコピペできる
    • 従来の管理画面では自由記述の項目のみ一つずつクリックしてからテキストを貼り付ける必要がありました(面倒!)
    • autoSDRなら、すべての設定はExcelのセルに格納されるので、999個のeventを一気に有効化したり、関数を使って動的に加工した名前を一気に250個のeVarに反映させる、ということが可能です。
  • 変更履歴の確認やロールバックができる
    • 従来の管理画面ではログにデータがテキストで表示されるだけで、ダウンロードできません(見にくい!)
    • autoSDRなら、変更内容のみを自動検知し、変更前後の比較ができます。任意のタイミングの状態をスナップショットとしてExcelドキュメントのまま残しておけば、一気にその状態に戻すことも可能です。
  • SDRと実際の設定内容の相違がなくなる
    • 従来はSDRを手で管理するので、更新が漏れがちでした(面倒!)
    • autoSDRなら、サーバーから設定内容をダウンロードしてExcel形式のSDRを自動生成してくれるので、初期の作成だけでなく最新化もカンタン

具体的な使い方

では、さっそく使ってみましょう!

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には含まれないことも多いので、設定内容を確認できて便利!

  • 個別訪問者変数
  • 内部URLフィルタ
  • 有料検索検知
  • マーケティングチャネル

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ドキュメントを分ける必要があります。

活用の例

  • 新規導入時に、レポートスイートの設定を一気に行う
  • 既存のSDRを捨ててautoSDR版に移行し、定期的にリフレッシュしていく
  • 既存のSDRはそのまま管理を続け、設定の変更検出とバージョン管理としてautoSDRを活用する
  • 既存レポートスイートの設定内容を別のレポートスイートへコピーする
  • クライアントからアカウントをもらったが管理者権限が無いので、APIの権限だけもらってサクッと設定内容を把握する

以前にGoogleスプレッドシートで同じものを作成したことがありますが、今回のはExcelなので使い勝手がよく、機能も増えています。

上手に活用してみてください!

Adobe Analyticsの設計書「SDR」を自動更新できるツール「KAISEKI-Assist: autoSDR」を公開しました

posted Dec 24, 2015, 1:37 AM by Makoto Shimizu   [ updated Jan 23, 2016, 8:25 PM ]

2015年のクリスマスプレゼントとして、Adobe Analytics (SiteCatalyst)のレポートスイート設定をExcelのセルに自動反映する「autoSDR」を公開しました!

多くの管理者が望んでいたSDRの自動更新を、私が戦略顧問を勤めるインテリジェンス ビジネスソリューションズとのコラボにより実現しました。

エクセルを開いて、Report Builderのような感覚でログインし、RSを選択すれば、サーバーと完全同期したSDRが完成!

ダウンロードはこちらから: 「KAISEKI-Assist」- Adobe Analytics支援ツール集

http://www.ibs.inte.co.jp/kaiseki/

今回は第一弾です。1月に第二弾を公開します!

オフラインデータを取り込んで分析やターゲティングができる「顧客属性」の使い方

posted Nov 9, 2015, 1:11 AM by Makoto Shimizu   [ updated Nov 9, 2015, 1:22 AM ]

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)とどう違うのかをまとめておきます。

  • ユニーク値の月間最大件数の制限がない
  • Analytics以外のツール(TargetやAudience Manager)でも使える
  • ディメンションだけでなく、指標としても使える
  • アップロードできる属性の数が多い
    • Adobe Analytics Standardは3個
    • Adobe Analytics Premiumは200個

参考:公式ヘルプ

Adobe AnalyticsをYahoo!検索SSL化に対応させる方法

posted Aug 27, 2015, 3:02 AM by Makoto Shimizu   [ updated Sep 23, 2015, 7:21 PM ]

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!検索を正しく認識できません。

  対策前の現状 (8/27時点)
対策後(希望)
リファラータイプ その他のウェブサイト (Other Web Sites) 検索エンジン
検索エンジン (何も記録されない) Yahoo! - Japan
検索キーワード (何も記録されない) キーワードを使用できません(Keyword Unavailable)

判定ロジック更新には時間がかかりそう

Adobe Analyticsの場合は、データ受信後にサーバー側でリファラの判定が行われます。このロジックの更新は、過去のパターンから推測すると、毎月の第三金曜日に実施されるメンテナンスリリースと同じタイミングになるので、順調なら次のメンテナンスリリースが行われるであろう9月18日か25日になると思われます。優先度が低いなどの理由で、もっと遅くなるかもしれません。

それまで待てない場合は、自力で対策する必要があります。一つの方法を以下で紹介します。

リファラを改変して正しく認識させる方法

実は簡単。リファラは通常は編集できませんが、Adobe Analyticsの場合、s.referrerという変数にURLをセットすると、HTTPヘッダのリファラよりもその値を優先するという仕組みが提供されているためです(元々はリダイレクト対策用)。

この仕組みを使って、

if (document.referrer == 'http://search.yahoo.co.jp' || document.referrer == 'http://search.yahoo.co.jp/') {

   s.referrer = document.referrer + '/search?p=::empty::';

}

というようなコードを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で設定すべき5つの設定

posted May 25, 2015, 9:35 PM by Makoto Shimizu   [ updated May 25, 2015, 9:37 PM ]

Adobeのタグマネージャ「Dynamic Tag Management」(略してDTM)。Adobe Marketing Cloudの中では「Activation」(=導入支援)という名称のコアサービスとして位置づけるようです。Tealiumほどの機能は無いものの、Adobe系ソリューションとの親和性は当然のことながら世界一。Google系タグの管理はGTM、Yahoo系のタグはSignal(旧Bright Tag)、とタグマネージャーを使い分けるのも良いでしょう。そんなDTMのおすすめ設定を紹介します。

Webプロパティの詳細設定

「複数ルールの同時承認を可能にする」をONに

これをONにすると、一部の変更のみにチェックを入れて承認することが可能になります。

チームでDTM設定を管理している場合は、自分の変更のみを発行できるので便利です。

「一部のみの発行を可能にする」をONに

これをONにする最大のメリットは、承認されたけれどもまだ発行されていない変更の数が「キューを発行」ボタンの上に(2)などと表示される点です。

この表示が無いと、未発行のキューが残っていることが分からないので、変更を発行するのを忘れてデータが欠損したり、勘違いでデバグ時間を無駄にする、といった単純ミスにつながるので要注意。

キューを発行」ボタンをクリックすると、内訳が表示されます。

あまりにも便利なため、2015年4月のアップデートで、この設定はデフォルトONの標準機能に昇格しました。

ただし、以前に作成したWebプロパティではOFFのままなので、手動でONに切り替えると良いでしょう。

「未定義のデータ要素に対して空の文字列を返す」をONに

2015年4月に追加された新しい設定です。デフォルトではOFFになっているので、手動でONにするのがオススメ。データ要素がreturnする値がnull(空)だった場合に、今までは「%PageName%」などとデータ要素名が入ってしまい、ゴミデータがレポートに混ざるのを回避できるようになります。

Adobe Analyticsツール設定

「自動設定を有効にする」

これによって、RSIDの入力が補完されるようになったり、Adobe Analytics契約の種類を自動判別してeVarやeventの枠が増えたりします。

ライブラリ管理を「アドビが管理」に

AppMeasurement.jsのコアライブラリをカスタマイズしないようにすれば、自動配信できるようになり、アップデートが確実&楽になります。

カスタマイズされたコード部分でネックになるのは、従来のプラグインとdo_Pluginのコードですね。これらはDTMのデータ要素とルールを使ってDTMのUI上で再構築するのが本質的な対策ですが、楽して移行するために残したい場合は、ツール設定の「ページコードをカスタマイズ」へそのまま移動させるという方法もあります。少なくとも基本ライブラリ部分とカスタムコードを分離させれば、管理が楽になり、かつコピペミスも減らすことができるでしょう。

実は複雑なAdobe Marketing CloudのクロスドメインID管理

posted May 3, 2015, 9:30 AM by Makoto Shimizu   [ updated May 8, 2015, 5:36 AM ]

前回は同一ドメイン内のページを遷移する場合のVisitor ID Serviceの挙動について紹介しました。

今回は、別ドメインへの遷移、既存レガシーサイトにおけるMMP (Visitor ID Service) 導入、も考慮して解説します。

(3rd-party Cookieが無効の場合とCNAMEを利用している場合は別途)

前提条件:

  • VisitorAPI.js 1.3.2
  • AppMeasurement.js 1.4.1
  • Data Collection Serverは地域固定の2o7.netではなくRDC (*.omtrdc.net)で、自社ドメインのCNAME設定なし
  • ブラウザは3rd-party Cookieを受け付ける
  • 従来のs_vi Cookieは残っているが、Visitor ID Service導入後は初めてアクセスする

訪問者ID発行と保管の流れ

Visitor ID Service (VisitorAPI.js) 導入前のs_viクッキーが残っている状態でドメインの異なる2ページを閲覧した場合の流れについて図解します。

  1. ユーザーがサイトに初めてアクセスする
  2. 1st-partyドメインのAMCV Cookieが存在しないので、Audience Manager (dpm.demdex.net) のID管理サービスにOrganization IDを渡し、Marketing Cloud IDを問い合わせる
  3. demdex.netドメインのCookieが存在しないのでMarketing Cloud IDを新規発行し、Cookieをセットする(demdex idが存在する場合はorgidとのコンビネーションで発行済みMarketing Cloud IDを調べて返す)
  4. Marketing Cloud IDをJSONで返す
  5. 収集サーバー (DC) のID管理サービスにOrganization IDとMarketing Cloud IDを渡す
  6. 従来のs_vi CookieからAnalytics IDを入手
  7. 従来のAnalytics Visitor ID (s_vi CookieのVisitor ID) をJSONで返す
  8. Marketing Cloud IDとAnalytics Visitor IDを結びつけるため、Audience Managerにデータを送信
  9. 1st-partyドメインで各種情報 (Organization ID, Marketing Cloud ID, Analytics ID) を格納するAMCV Cookieをセットする
  10. IDが確定したので、AppMeasurementがそのIDを使って各種のデータをDCへ送信する
  11. ユーザーが次のページに移動する
  12. (2と同じ)
  13. (3に近い)demdex idが存在するので3と同じMarketing Cloud IDをサーバーから取り出す
  14. (4と同じ)
  15. (5と同じ)
  16. (6と同じ)
  17. (7と同じ)
  18. (8と同じ)
  19. (9と同じ)
  20. (10と同じ)

まとめ

  • 3rd-partyクッキーが有効でdemdexのクッキーが残っていれば、ドメインを超えてもIDが同じになり、訪問がつながります。
  • 従来のs_viクッキーが残っていると、AnalyticsのVisitor IDが引き継がれるので、Visitor ID Serviceを入れてもデータはリセットされません。

直帰率とバウンス率の違いは?

posted May 2, 2015, 9:40 PM by Makoto Shimizu   [ updated Oct 19, 2015, 12:07 AM ]

サイトを訪問し、すぐに去る「直帰」という概念は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にならない。

要注意

  • Ad Hoc Analysis(旧Discover)では、設定画面の「繰り返しインスタンスをカウント」をONにしないとリロードやリンク計測が無視され、値がReports&Analyticsと一致しなくなる
  • Single Accessを先に「直帰」と訳していた経緯のため、日本語モードでは「バウンス」と表記される。

Bounce Rate(直帰率/バウンス率)

上記のBounceを訪問回数で割った比率。

要注意

  • Bounceは「バウンス」なのにBounce Rateは「直帰率」と訳されている(要改善)
  • Ad Hoc Analysisでは「バウンス率」と訳される

Single Access(直帰数/単一アクセス)

パスをONにすると使えるようになる指標。

v14までの定義:変数(ページ名やProp)に対してユニークな値が1種類しか送信されなかった訪問回数

v15以降の定義:リンク計測を除外したゆるい直帰。リンク計測(離脱・ダウンロード・カスタム)のリクエストが発生しても直帰扱いになる点がBounceと異なる。

要注意

  • v15になって定義が変わった
  • 公式ヘルプの説明と実際の挙動が一致しない
  • Reports&Analyticsでは「直帰数」と訳されている(要改善)
  • Ad Hoc Analysisの日本語モードでは別名「単一アクセス」になる(こちらが妥当)

Single Page Visits(直帰数)

Reports&AnalyticsではパスをONにするとパスレポートの一部として使えるようになるが、指標として普通のレポートに追加することはできない。

要注意

  • Single Accessに近い数値になるが、詳細不明
  • 「直帰数」と訳されている

まとめ(オススメ)

  • 直帰関連の指標を日本語で正しく判別するのは不可能なので英語モードで使う
  • 厳密な直帰を知りたい場合は「Bounces」を、リンク計測を無視したい場合は「Single Access」を使う
  • Single Page Visitsは特殊な指標(汎用性がない)なので使わない
  • v14時代のように変数の値が変化しないという意味の単一アクセスを知りたい場合はAd Hoc Analysisを使うしかない(設定変更が必要)
  • 通常は指標の定義をAd Hoc AnalysisとReports&Analytics間で統一しておいた方が良いので、設定の「繰り返しインスタンスをカウント」はONにしておく

参考:Adobe公式ヘルプ(ただし古いので注意)

1-10 of 92