Adobe Analytics（旧SiteCatalyst, Discover）に関するニュースやTips、活用テクなど。 |
Adobe Analytics >
Adobe Analytics実践メモ
Adobe AnalyticsのiTP 2.1対策はサーバーCookie
こんにちは、清水 誠です。Safari 12.1以降ではCookieの有効期間が7日に制限されるようになり、Adobe AnalyticsやGoogle Analyticsのデータに影響が出るようになりました。Adobeからは見解や対策予定がブログ記事（英語）で公開され、3月末のAdobe Summitでも説明がありました。そして「4月か5月には」という予定通り、日本時間の5月14日にiTP 2.1対策の新機能がリリースされたので、その内容と検証結果をここでレポートします。  サーバーからCookieを発行するようになった対策としてはシンプル。AdobeのサーバーからCookieを発行するようになりました。 実際にSafariで検証してみましょう。以下は、5/21にセットされたCookieの一覧です。  AMCV_****という名前のCookieが、訪問者単位で発行されるCookieです。有効期限が、セットされた5/21からちょうど1週間後の5/28に短縮されていることがわかります。JavaScriptから発行されるCookieは、7日を過ぎたらCookieが消されるのではなく、7日を超える有効期限を指定しても有効期限が7日間に短縮されてCookieがセットされます。 その下の「s_ecid」が、今回のiTP対策としてAdobeのデータ収集サーバーからセットされるようになった新しいCookieです。2年間という7日よりも長い有効期限（正確には2年後の1日前）のCookieがセットされました。 iTP対策のために必要なことこのiTP対策の機能を有効にするには以下の条件を満たす必要があります。 (1) CNAMEを登録するこれがもっとも敷居が高いですね。自社のDNSにCNAMEレコードを追加し、「xxx.omtrdc.net」というAdobeのデータ収集サーバーに「adobe.example.co.jp」のような自社のサブドメインを割り当てます。DNSを管理している部門と、収集サーバーを管理しているAdobeの両方への依頼が必要になります。 (2) IDサービス 4.3.0以降を導入する発行された新しい「s_ecid」Cookieの値を読み取り、IDとして採用してデータ計測サーバーへ改めてデータを送信する機能を持つIDサービスを導入する必要があります。 以前のs_code.js時代とは異なり、訪問者に固有のIDを発行する仕組みが「IDサービス」という機能としてAdobe Analyticsから切り出されています。「Visitor API」「Marketing Cloud ID Service」「Experience Cloud ID Service」「ECIDライブラリ」などと時代や文脈によって表記はいろいろなのでご注意。 DTM（第二世代のタグマネージャ）でAdobe Analyticsを導入している場合は、ツール「Experience Cloud ID Service」を最新化します。Launch（第三世代のタグマネージャ）でAdobe Analyticsを導入している場合は、エクステンション「Experience Cloud ID Service」を最新化します。 (3) 計測サーバーをRDCに移行するAdobeのデータ収集サーバーは、昔はドメインが「2o7.net」であり、地域がサンノゼやダラスなどに固定されていました。RDCとはRegional Data Collectionの略で、世界各地に分散された複数のサーバーを自動で切り替える機能を持ったデータ収集サーバーのことです。RDCのドメインは「omtrdc.net」になります。最近導入していれば、既にRDCになっているはず。 その他
|
2018年1月のAdobe Analytics変更点まとめ
Adobe Analyticsは12月を除く毎月中旬〜下旬の金曜日にメンテナンスリリース（MR）が実施され、バグ修正や機能追加、仕様変更が行われます。春にはSpring Release、秋にはFall Releaseと呼ばれる大きな変更がリリースされますが、それ以外の月は小さな変更のみで、大きなアナウンスはありません。 とはいえ、隠れ便利機能や重要な仕様変更が含まれることもあり、リリースノートをよく見ておくと得することがあります。 例えば2018年1月19日のリリースでは... ワークスペースのテーブルに表示できるデータの最大行数が200から400に拡大 ディメンションを「日」にした場合に1年分のデータを表示・ダウンロードできるように、という趣旨だとか。 フリーフォームテーブルのフィルタの条件がきめ細かく選択肢が増えました。 
ビジュアライゼーション（テーブル）の別プロジェクト・パネルへのコピー＆ペースト以前は、ビジュアライゼーションまたはパネルの単位で複製することしかできなかったので、テーブルなどを別のパネルへ移動するのが面倒でした。 テーブルやグラフの上の方で右クリックしてコピーすると  別のパネルやプロジェクトへ貼り付けられるようになりました。  この貼り付け（挿入）は、右クリックのメニューの中にあるので、既存のテーブルやグラフの上の方を右クリックしないと実行できません。「上書きされるかも？」と心配になりますが、既存のものは残る形で追加されるのでご安心を。 eVar、Prop、event番号による検索時の表示改善ディメンションや指標の名前だけでなく、「eVar7」「Prop5」「event123」などと種類と番号で検索することは前からできましたが（でも知らない人が多い）、画面左のレーンに表示されたりされなかったりと一貫性がない、常に表示されると邪魔、というUIの問題を解決するための改善がリリースされました。 番号は通常は表示されませんが、  検索ボックスに「ev」「Pr」などとタイプすると、ディメンションや指標の名前の後ろにカッコで番号が表示されるようになりました。 必要な時だけ目立たない形で表示されるのが良いですね。 「なし」の扱い変更eVarなどのディメンションに時々表示される「なし」「未指定」といった表記を統一するための修正を行ったようです。  「なし」や「未指定」は分析では邪魔なことが多いので、今までは「::」を含まない、というフィルタで除外していたのですが、今回の変更で画面の言語に依存した見た目の表記でしかフィルタできなくなったので、既存のダッシュボードが色々壊れて大変...。この仕様だと「unspecified 未指定」のいずれの語句も含まない、という条件が良いですが、他の言語に対応していなく、長くて設定しにくい、スペルミスのリスクがあるという点でスマートではありません。フィルタに関しては仕様変更で派生したバグとも言えるので、いずれ改善されるかも？ リリースノートは要チェック！以上、2018年1月はメジャーではなくマイナーなメンテナンスリリースだったにも関わらず、日常の業務に影響する変更や改善が多かったので、紹介しました。特にワークスペースは一番力が入っているので、バグ修正だけでなく機能追加も頻繁に行われています（2018年1月現在）。 リリースノートは毎月チェックしておくと役立ったりトラブルを避けられるので、オススメ。リリース前にメールで通知を受けることもできます（ただし英語のみ） |
データ量が少ないと割合がブレる問題への対応方法まとめ
直帰率やコンバージョン率といった割算の指標が、データ量が少ないと高すぎたり低すぎたりと極端な値になってしまい、分析の邪魔になる問題に対処する方法についてのまとめ。 アプローチ１：加重する1-A. 加重した結果で並び替えするGoogle Analyticsの場合、割合の指標を並び替える際に、加重の計算を行うオプションを利用できます。  加重後の値は並び替えの基準として内部的に使われるだけで画面には表示されませんが、恣意的に改変された値は分析の用途としては意味をなさないので、良いUIだと思います。 ただし、アルゴリズムがわかりにくく、変更できない、というデメリットがあります。 特徴
1-B. 加重した結果を別の指標とするAdobe Analyticsの場合、昔は、列の合計値を使って計算指標を作るのが主流でした。
 計算式を確認・変更できるのは良いですが、このように単純な計算式だと全体的に値が変わってしまうので、分析の際は注意が必要です。  無意味な「100%」はゼロになりましたが、2行目の「88.66%」も「6.9%」になってしまいました。これは直帰率とは言えないので、取扱注意です。 特徴
アプローチ２：足切りする問題なのは値がブレた一部のデータだけなので、全体的に加重するのではなく、無意味な値を消し込んで無効にする、というアプローチです。 2-A. 絶対値で足切りする「訪問が10以下」など、特定の指標が一定の値に満たない場合の値をゼロに変更します。 特徴
2-B. 割合で足切りするAdobe Analyticsの計算指標で使える関数が増えたので、パーセンタイルで相対的に下限を設定できるようになりました。値の分布が時期によって変動する場合に便利です。多くの場合は、この方法がベストでしょう。  計算指標の作り方
特徴
参考：http://analyticsdemystified.com/adobe-analytics/creating-weighted-metrics-using-percentile-function/ 計算指標の関数は他にも色々あります。ヘルプがわかりにくいので、試しながら挙動を理解すると良いでしょう。 |
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検索が正しく「検索エンジン」「キーワードを使用できません」として認識されるようになりました。以下の対策はもう不要です。 |
1-10 of 95