目次


シングルページ・アプリケーションのエクスペリエンスを最適化する

顧客のための IBM Tealeaf DOM Capture and Replay ソリューション

IBM Tealeaf によるオンラインでのカスタマー・エクスペリエンスの改善

IBM Tealeaf は、オンラインでのカスタマー・エクスペリエンスを改善するために、サイト訪問者のオンラインでの操作をキャプチャーしてアナリティクスを提供します。これにより、顧客のオンラインでのエクスペリエンスを詳細に視覚化することや、顧客の行動に関する洞察を得ること、さらには顧客のリクエストに対するサイトの応答を把握することができます。IBM Tealeaf ソリューションは、各操作の詳細を高い精度で大量に、独自の方法でキャプチャーします。

e-コマース、マーケティング、生産サポート、顧客に対するサービスおよび法令遵守の管理などをはじめとする一連の機能をサポートするために、組織全体で Tealeaf を利用することができます。Tealeaf を利用すれば、組織はサイトを改善および革新する機会を探り、要件への対応を推進できるとともに、より優れたオンラインのソリューションやサービスを顧客に提供する優先順位を設定することができます。

背景: SPA への移行

Web テクノロジーの進化と、Web に精通していて能力を持ったコンシューマーの数が増えると予想されることが、円滑なユーザー・エクスペリエンスを提供する今どきの Web アプリケーションを作成するよう企業を駆り立てる大きな要因となっています。シングルページ・アプリケーション (SPA) は、そのような今どきのアプリケーションの一例です。

SPA とは、スクロール可能な単一の Web ページに収められた Web アプリケーションまたは Web サイトであり、ユーザーのアクションに応じて適切なコンテンツが動的にロードされます。SPA では、単一ページ上の複数のコンポーネントでのリッチな操作をサポートすることができます。

マルチページの Web アプリケーションと SPA との違い

従来の Web アプリケーションは一般に、静的コンテンツで構成されています。従って、ユーザーがあるページから別のページにナビゲートする際には、ページ全体のロードと、クライアントとサーバーとの間でのデータ送信が必要になります。

1 つのページとしてブラウザーに提供される SPA では、顧客がアプリケーションのある部分から別の部分に移動するとしても、ページのリロードは必要ありません。

SPA では、データのプレゼンテーションからデータを切り離すことから、UI のどの部分を再描画する場合でも、サーバーとやりとりして HTML を取得する必要がありません。そのため、SPA でのユーザー・エクスペリエンスはより円滑なものとなり、ナビゲーションの時間も短縮され、ネットワーク転送もより効率化されます。

IT の観点では、SPA は従来のマルチページのアプリケーションに比べ、クライアント・サイドがよりリソース・インテンシブとなっています。

SPA のメリット

SPA がマルチページのアプリケーションより優れている点は、以下のとおりです。

  • ロード時間: SPA は、HTML、CSS、JS のそれぞれが 1 ファイルあれば構成できるため、マルチページのアプリケーションより、ロード時間が短くなります。
  • データ転送量の軽減: SPA では、XHR 呼び出しで送信するデータはロー・データのみであり、HTML マークアップは送信しないため、データ転送量が軽減されます。
  • 負荷分散: SPA は負荷をクライアントに分散することにより、サーバー上の負荷を軽くします。また、キャッシングが単純化されて、より効果的になります。
  • サーバー・サイドの API から動的にデータをロードする場合、RESTful Web サービスが使われます。
  • SPA では、ページの状態遷移がより滑らかになり、UI コンポーネント間でよりリッチな操作を行えるようになります。
  • アプリケーションに必要なマークアップ、CSS、および JS は、初期リクエストで送信されます。
  • ページの変更は、JavaScript によってテンプレートを使用したり、DOM を操作したりすることで行われます。
  • 状態を追跡するために使用する URL フラグメントには、ブックマークを付けることができます。

移行における課題

SPA に移行する企業が増える中、キャプチャー & リプレイ・ソリューションのプロバイダーは、リソース・インテンシブなクライアント・サイドのプロセスによって生じる技術的な課題と、このパラダイム・シフトの影響 (つまり、ユーザーによるすべての操作が単一ページで行われることによる影響) を理解する必要に迫られています。

企業とソリューション・プロバイダーの双方が、クライアント・サイド・テクノロジー (Ajax、jQuery、JavaScript、フレームワーク、DOM など) の進化を考慮して、これらの進化が SPA での顧客の操作をキャプチャーする上でのストラテジーに与える影響を理解しなければなりません。

SPA における Classic Capture and Replay の限界

従来のリプレイ方法である Classic Replay では、キャプチャー済みの HTTP ネットワーク・データおよびユーザー操作を使用することで、アプリケーションのステートフルなレンダリングを再度行います。

マルチページ・アプリケーションの場合、Classic Replay ではブラウザーのサンドボックス内で各ページをレンダリングします。サンドボックスは、元のアプリケーション・インスタンスの状態を複製します。キャプチャー済みのユーザー操作 (例えば、チェック・ボックスを選択する、ボタンをクリックするなどの操作) はプログラムによってトリガーされて、アプリケーションでのユーザー操作が視覚化され、それをリプレイすることができます。

Classic Replay でアプリケーションのステートフルなレンダリングを行うには、以下の条件が必要です。

  • 初期ページをレンダリングするためのサンドボックスを再作成できること。
  • 記録済みのユーザー操作を適用しつつ、正しいアプリケーションの状態を維持できること。

マルチページのアプリケーションでは、レンダリングの状態が実質的にリセットされる変わり目となるのが、それぞれのページです。アプリケーションの一部のページをリプレイできない場合でも、レンダリングの状態をリセットすることによって Classic Replay を正常な状態に戻してビジネス価値を提供することが可能になります。

SPA の Classic Replay は、成功するか失敗するかのどちらかになります。アプリケーションを正しい状態に初期化できなければ、失敗した状態から正常な状態に戻ることは不可能です。

Classic Replay は、ユーザー操作のほぼすべてが単一ページで行われるアプリケーションで有効に機能するようには設計されていません。SPA の場合、単一ページに関連付けられたユーザー操作の数は、マルチページのアプリケーションの場合の何倍にもなります。リプレイ時にアプリケーションの状態を維持するために必要となるプログラミングの複雑さは、ページごとに記録されるユーザー操作の数と正比例して増大します。アプリケーションの状態を維持できなければ、それ以降のユーザー操作をリプレイすることはできません。

SPA のための DOM Capture and Replay ソリューション

シングルページのアプリケーションをリプレイする際の技術的課題に対処するために、DOM によるキャプチャー & リプレイ・ソリューションである Tealeaf DOM Capture and Replay では、1 つ以上のスナップショットをキャプチャーするという方法を採用しています。レンダリングされたアプリケーションの状態を HTML 形式で示すスナップショットは、アプリケーションのシリアライズされた DOM を表します。Classic Replay では、ステートフルなレンダリングを再度、続けて行おうとしますが、それとは異なり、DOM Capture and Replay でキャプチャーしたスナップショットは、それぞれ単独でレンダリングすることができます。

キャプチャーするデータの量は、アプリケーションのコンテンツによって異なりますが、DOM Capture and Replay を使用してキャプチャーされるデータのサイズは、ほぼ必ずと言ってよいほど、Classic Capture and Replay でキャプチャーされるデータのサイズを上回ります。

追加で必要となる保管領域は、かなり大規模になる可能性があります。データ・サイズの増加によって起こり得るリプレイ・パフォーマンスの問題を埋め合わせるには、戦略的に DOM Capture and Replay を構成することで、キャプチャーのトリガーを最適な形で行い、最大限のビジネス価値を実現できるようにする必要があります。

Tealeaf DOM Capture and Replay ソリューションは、DOM とその変更内容を収集するクライアント・サイドの革新的なキャプチャー・プロトコルとリスナーを実装することで、今どきのオンプレミス、クラウド、そしてモバイル・ハイブリッドの SPA に対して高い忠実度の視覚化を実現 (さらには、それらの視覚化を分析する機能を提供) します。しかも、プライバシー、セキュリティー、イベント、レポートなどの重要な機能は中断することなく機能し続けるようになっています。

慎重に計画された Tealeaf DOM Capture and Replay の実装は、以下のメリットをもたらします。

  • 業界で従来使われているキャプチャー & リプレイ・ソリューションに比べ、IBM Tealeaf DOM Capture and Replay を有効にするために必要な構成は少ないことから、タイム・ツー・バリューがより短くなると同時に堅牢性も強化されます。
  • リプレイ・ルールの数が少ないため、リプレイがより単純化されます。
  • レンダリング・エンジンを迂回するため、リプレイのパフォーマンスに優れています。
  • キャプチャー時点でのユーザー・エクスペリエンスを高い忠実度でリプレイして視覚化します。

DOM Capture and Replay ソリューションは、SPA に特有の技術的課題の多くに対処してはいるものの、このソリューション固有の課題がないわけではありません。DOM Capture and Replay とClassic Capture and Replay の全般的な比較については、IBM Knowledge Center の資料「標準のキャプチャーおよび再生と DOM キャプチャーおよび再生の間での選択」を参照してください。

事例研究: IBM Customer Experience Analytics によって顧客のことを理解している ARC

背景

ARC (Airlines Reporting Corporation) は、10 年以上にわたる Tealeaf の顧客です。ARC は顧客のエクスペリエンスを正確かつ完全に表現するために、Tealeaf を使用して自社の Web ページをモニターし、それぞれの顧客が各ページで表示した内容、行った操作をキャプチャーして記録しています。レベル 1 のカスタマー・ケア担当者からエンタープライズ生産サポート・チームに至るまで、Tealeaf はカスタマー・エクスペリエンスの問題を識別、診断、解決する上でなくてはならない役割を果たしています。

新しい Web テクノロジーの課題

ARC のアプリケーションは長い年月をかけて、緑色の画面の文字ベースのアプリケーションから基本的な HTML Web アプリケーションへ、そして Adobe Flex ベースのアプリケーションへと進化し、最近では Angular/HTML5 ベースのアプリケーションにまで進化しました。

ARC が緑色の画面の文字ベースのアプリケーションから HTML Web アプリケーションへ移行した時点で、Tealeaf は正確かつ完全なキャプチャー & リプレイ・ソリューションを提供することができました。カスタマー・エクスペリエンス・マネジメント (CEM) 分野で業界をリードする Tealeaf は、Web ページがサーバー上でレンダリングされてからクライアントのブラウザーに送信される標準的な Web ベースのアプリケーションのキャプチャー & リプレイにおいて抜きん出ていたのです。

一時期、ARC は Web アプリケーションに Adobe Flex 開発プラットフォームを使用していましたが、Adobe Flex で作成されたアプリケーションはキャプチャーしてリプレイするのが困難でした。そのため、ARC が基本的な HTML アプリケーションに備えていた高品質のリプレイ・エクスペリエンスは、Adobe Flex ベースのアプリケーションには欠けていました。その当時、業界は Angular/HTML5 アプリケーションへと移行しつつありました。ARC の管理チームは、Adobe Flex ベースのアプリケーションに存在する技術的課題のいくつかは、Angular/HTML5 開発プラットフォームに移行することで解決できることに気付きました。その一方で、この移行によってAngular/HTML5 開発プラットフォームに固有の技術的課題も出てきました。

その 1 つは、Angular/HTML5 を使用して開発された Web ページは、サーバー上ではレンダリングされず、クライアント・ブラウザー上で動的にレンダリングされることです。さらに、Angular/HTML5 テクノロジーは業界で使われている最新のブラウザーでないとサポートされないため、ARC の顧客が古いブラウザーを使用しているとしたら、新しい Angular/HTML5 アプリケーションを操作することができません。実際、Tealeaf Analytics により、現 ARC ユーザー・ベースの 25% を超えるユーザーがブラウザーを更新しなければ、ARC の新しい Angular/HTML5 アプリケーションを操作できないことが明らかになりました。

Tealeaf を使用し始めて以来、ARC はカスタマー・エクスペリエンスをキャプチャーしてリプレイするためにアプリケーションに変更を加えなければならなかったことは一度もありません。しかしながら、Web 開発手法が移り変わり、ブラウザー・テクノロジーが変化する中、ARC は Tealeaf のキャプチャー & リプレイによるメリットを引き出し続けるには、アプリケーションを変更しなければならないことを認識しました。

ソリューション

ARC は、サーバー上ではなくクライアント上でレンダリングされるアプリケーションに有効なキャプチャー & リプレイ・ソリューションを見つけ出すために、Tealeaf に連絡しました。

ARC が使用できる Tealeaf のリソースは限られていたことから、通常はアプリケーションごとにカスタマイズしなければならない Tealeaf クライアント・サイドのソフトウェア開発キット (SDK) を使用するのは現実的なソリューションではありませんでした。

Tealeaf が ARC に提示したのは、DOM Capture/SDK ソリューションです。DOM Capture ソリューションであれば、ARC はアプリケーションに必要最小限の変更を加えるだけで、クライアントでのカスタマー・エクスペリエンスをキャプチャーすることができます。

現実のシナリオ

ARC は、PCI および ISO 27001 の認定を受けています。2015年の監査で、ARC ではまだ SSLV3 暗号をサポートしていることが明らかになりました。PCI および ISO 27001 認定を維持するためには、SSLV3 暗号を無効にする必要があります。

当初のソリューションは、単に SSLV3 暗号をオフに切り替えて、顧客が直面する可能性のある接続問題に対処するというものでしたが、Tealeaf Analytics により、SSLV3 暗号をオフに切り替えると、ARC の顧客の 25% 以上が極めて重要な ARC システムにアクセスできなくなることが判明しました。

そこで、ARC はプログラムによるソリューションを使用することにしました。そのソリューションは、古いクライアント・ブラウザーを検出するとポップアップ・メッセージを表示し、顧客をサポート・ページにリダイレクトするというものです。サポート・ページは、ユーザーの環境を検査して、現在使用しているブラウザーとオペレーティング・システムのバージョンを示す、シングルページ・アプリケーション (SPA) になっています。ユーザーが使用している環境は、サーバー・サイドではなくクライアント・サイドで判別されます。

残念ながら、このソリューションは ARC のサポート・チームにとって問題になりました。ARC の顧客がヘルプ・デスクに支援を求めてくると、ヘルプ・デスクはその顧客のセッションをリプレイしますが、そのために使用する Tealeaf の Classic Capture and Replay は、新しい SPA に対応していなかったからです。こうした状況は許容されるものではなく、すぐに是正する必要があり、そのためのソリューションを短期間で開発して本番環境にデプロイしなければなりませんでした。

Tealeaf は、新しい DOM/SDK ソリューションがこの問題を解決する仕組みを実証することができました。ARC のブラウザー確認用 SPA に数少ないマイナーな変更を加え、Tealeaf システム内部で DOM Capture and Replay をアクティブにすることにより、ARC サポート・チームはページのリプレイ時に顧客の正確なエクスペリエンスを確認できるようになりました。

  • 顧客のシステム環境が最小要件を満たしていない場合、顧客には ARC の製品およびサービスにセキュアにアクセスできるよう、要件を満たしていないブラウザーとオペレーティング・システムを更新するためのリンクを通じて、是正措置を取るべく指示が出されます。
  • 一方、顧客のシステム環境が最小要件を満たしている場合は、その環境が要件を満たしていて ARC の製品とサービスにセキュアにアクセスできることを通知するメッセージが表示されます。

その後の展開

DOM/SDK 統合の経験を基に、ARC では現在、この機能を自社の新しい Angular/HTML5 ベースのアプリケーションのすべてに統合する方法を評価しています。

Tealeaf DOM Capture and Replay を実装する際のベスト・プラクティス

以下のリストにベスト・プラクティスを明記し、IBM Tealeaf DOM Capture and Replay ソリューションの実装に関連して参考となる情報を記載します。

注: 通常のベスト・プラクティスの場合と同じく、これらのベスト・プラクティスは、製品の進化と、Tealeaf で分析を行う作業者が経験を積むことで革新的な使用事例とストラテジーの開発および実装に長けてくるのに伴い、変わってくる場合があります。

  1. 費用対効果の分析: 費用対効果の分析によって、SPA に最適なキャプチャー & リプレイ・ソリューションを決定してください。どのキャプチャー & リプレイ・ソリューションが SPA に最適であるかを見極めるには、費用対効果の分析を行う必要があります。

    Tealeaf Classic Capture and Replay では、必要となるネットワーク・リソースが少なく済みますが、このソリューションを SPA に適用するのは、複雑かつ時間もかかる可能性があります。

    逆に、SPA 用の DOM Capture and Replay は簡単に実装できるとは言え、このソリューションではほぼ必ず、処理とネットワーク伝送のコストが増えることになります。

    以下の側面を検討してください。

    • アプリケーションや Web サイトを実行するすべてのものが、顧客のリクエストに対するレスポンスの中に含まれている、顧客が Web サイトと対話する従来のシナリオでは、Classic Capture and Replay は効果を発揮します。
    • Classic Capture and Replay (SasS など) では現在サポートされていないシナリオ、または Classic Replay を構成するのが複雑であるため Classic Capture and Replay を使用できないシナリオでは、DOM Capture and Replay を使用することを検討してください。例えば、複雑な JavaScript がシングルページ・アプリケーションで実行される場合には、DOM Capture and Replay の使用を検討してください。

    Classic Capture and Replay と DOM Capture and Replay の違いについては、IBM Knowledge Center の資料「DOM キャプチャーおよび再生」を参照してください。

  2. 混合モード・ソリューション: 非 SPA の場合、Classic Capture and Replay の要素と DOM Capture and Replay の要素を慎重に使用した、混合モード・ソリューションを検討してください。

    このような混合モードのモデルには、マイグレーションは不要です。

    キャプチャー & リプレイ・ソリューションに DOM Capture を効果的に統合するには、最適な UIC 構成にすることが鍵となります。既存の Tealeaf の顧客は引き続き、従来の Tealeaf のキャプチャー、リプレイ、イベント、技術投資を利用および拡張することができます。

    IBM Tealeaf DOM Capture and Replay を、Classic Capture and Replay に代わるソリューションとして捉えないでください (ただし、代替ソリューションにするための最適化の機能強化が進められているところです)。さらなる可視性を必要とする、関心のある特定のページ、画面ビュー、または要素に対して、DOM Capture and Replay を使用することを検討してください。

    注: SPA には、Classic Capture and Replay または DOM Capture and Replay のどちらかを使用する必要があります。混合モードによる SPA のキャプチャー手法はありません。

    DOM Capture and Replay を実装するには、以下の手順に従う必要があります。

    • 「Configuration (構成)」ウィザードを使用して DOM Capture を有効にする前に、Classic Capture が機能することを確認します。このステップには、イベントとプライバシーの構成およびターゲット・ページのデプロイメントのすべてが、Tealeaf の Classic Capture に対して有効に機能することを確認する作業も含まれます。
    • 初期セットアップとテストのみを行います。

      「Configuration (構成)」ウィザードの DOM Capture ページで DOM Capture を有効にします。ロード、クリック、変更、およびアンロードのすべてのイベントに対して DOM Capture をトリガーし、DOM スナップショットがキャプチャーされることを確認します。

      これらのトリガーを追加するには、「Configuration (構成)」ウィザードを使用します。トリガー追加後の UIC SDK リプレイ・モジュールは、以下の例のような内容になります。

      リスト 1. DOM Capture の初期構成
         replay: {
          // DOM Capture configuration
          domCapture: {
              /**
               * NOTE: Enabling DOM Capture has significant implications
               * on data transmission and infrastructure. Hence this
               * feature should be enabled judiciously. If enabled, it 
               * requires further configuration to only perform the DOM
               * Capture based on specific events and elements. Please
               * refer to the documentation for more details.
               */
               enabled: true,
              /**
               * The rules for triggering DOM Snapshots are similar to 
               * the Privacy configuration. It accepts a mandatory 
               * "event" followed by one or more optional targets as 
               * well as an optional delay after which to take the DOM 
               * snapshot. The default configuration below will capture 
               * a full DOM snapshot for each and every click, change 
               * action as well as for all screenview load and unloads. 
               * Please refer to the documentation for details on fine 
               * tuning this configuration to specific elements and 
               * screenviews.
               */
              triggers: [
                {
                   event: "click"
                },
                {
                   event: "change"
                },
                {
                   event: "load"
                },
                {
                   event: "unload"
                }
              ]
            }
         }
  3. ステージング環境および本番環境に合わせてトリガーを微調整する: Tealeaf の DOM Capture が機能することを確認した後は、アプリケーションに不可欠の (ページまたは要素レベルの) データをキャプチャーするように、DOM Capture のトリガーを微調整する必要があります。それと同時に、パフォーマンス、ペイロード送信、およびストレージの要件を満たすことも確実にしなければなりません。

    SPA の場合、顧客のエクスペリエンスを有効にリプレイするには、戦略的かつ最適な UIC 構成にすることが鍵となります。それぞれのアプリケーションによって異なりますが、ユーザー・エクスペリエンスを正確に描写する視覚化を実現するだけでも、複数の主要なスナップショットが必要になります。

    SPA では、クリック、変更、ロード、アンロードのすべてをキャプチャーすると、大量のデータが送信および保管されることになります (その結果、コストが増え、パフォーマンスが劣化します)。従って、以下の作業が不可欠となります。

    • アプリケーションのワークフローをビジネスの観点で検討し、重要なステージ (トリガー) を識別します。
    • リプレイの粒度とパフォーマンスを比較検討し、ストレージとペイロード送信のトレードオフを検討します。
    • UISDK (tealeaf.js) に、必要なトリガーに悪影響を及ぼしかねない過剰な DOM Capture のトリガー・サンプルがないことを確認します。

      例えば、アプリケーションで tempTestButton 要素を使用していないのに、SDK に含まれるクリック・イベントが tempTestButton 要素に対してだけ DOM Capture をトリガーするように設定されているとしたら、tempTestButton を SDK から削除する必要があります。これを削除しなければ、DOM Capture ソリューションに悪影響が及ぶだけでなく、問題のトラブルシューティングに無駄な時間を費やすことにもなりかねません。

      DOM Capture に対する UISDK イベント・トリガーを検討および検証し、環境でキャプチャーする必要があるデータそのものを正確に反映していることを確認するようお勧めします。

    • リプレイの有効性とアプリケーション・ワークフローの正確さを損なうことなく、必要最小数のスナップショットを取得するようにトリガーを構成します。
    • 必要に応じ、適切な遅延を設定してトリガーを微調整します。
    • オプション: gzip エンコーダーを Tealeaf ソリューションに統合することに同意した Tealeaf クライアントは、ステージングおよび本番環境に合わせたトリガーを微調整するための最終ステップとして、gzip エンコーディングを構成して有効にする必要があります。
  4. 最大メッセージ・サイズのしきい値を設定する: DOM Capture メッセージの最大サイズのしきい値を設定します。デフォルトのターゲット・ページは 20 KB です。

    DOM Capture のサイズ制限は、圧縮前のサイズに基づきます。従って、キャプチャーされた DOM のサイズが圧縮前のデータのサイズ制限に達していなければ、キャプチャーは JSON Type 12 メッセージにシリアライズされます (さらに、gzip がオンになっている場合は圧縮されます)。一方、キャプチャーされた DOM のサイズが、構成されたサイズ制限を超えている場合、キャプチャーは破棄され、エラー・メッセージがログに記録されます。

    しきい値サイズの詳細については、2014年 12 月 4日にリリースされた、IBM Tealeaf CX UI Capture j2 バージョン 4 リリース 0 を参照してください。

  5. DOM Capture POST リクエストの gzip 圧縮を設定する: 組織の中で gzip エンコーディングを使用できる場合は、DOM Capture POST リクエストの gzip 圧縮を設定してください。

    DOM Capture のサイズ制限は、圧縮前のサイズに基づきます。UIC (4.0.0) では、リクエスト・データの gzip 圧縮をサポートしています。gzip は、MS IE 10 以降でサポートされています。

    圧縮を有効にする手順は以下のとおりです。

    1. pako JS (オープンソースの圧縮エンコーディング・ライブラリー) を組み込むことに同意する必要があります。このライブラリーは、以下の Web サイトからダウンロードして圧縮することができます。
      • プロジェクト・ページ: https://github.com/nodeca/pako
      • ダウンロード・ディレクトリー: https://github.com/nodeca/pako/tree/master/dist
    2. ページ上で UIC の前に pako JS が読み込まれることを確認します。
    3. UIC 内で、キュー・サービスの構成に encoder: “gzip” プロパティーが以下のように設定されていることを確認します。
      リスト 2. gzip 圧縮の有効化
      queue: {
         /**
          * WARNING: Enabling asynchronous request on unload may
          * result in incomplete or missing data
          */
         asyncReqOnUnload: false,
         queues: [
           {
              qid: "DEFAULT",
              endpoint: "/TealeafTarget.php",
              maxEvents: 50,
              timerInterval: 300000,
              encoder: "gzip"
           }
         ]
      }
  6. DOM Capture を有効にする: Tealeaf Management System (TMS) を使用して、「Replay Server (リプレイ・サーバー)」構成で「Enable DOM Capture (DOM Capture を有効にする)」を 1 に設定します。
  7. DOMCaptureVHit を有効にする: Tealeaf Management System (TMS) を使用して、「Transporter Server (トランスポート・サーバー)」ノードの DOMCaptureVHit セッション・エージェントを有効にします。

    必ず、パイプラインのインフレートとプライバシーの間に DOM Capture Virtual Session Agent (仮想セッション・エージェント) を挿入してください。

    注: 検索用インデックスを作成し、プライバシー・ルールと DOM のイベント生成を適用するには、仮想ヒットが必要です。仮想ヒットは、BBR ナビゲーション・リストには表示されませんが、セッションの TLA で確認することができます。

  8. ブラウザー・ベースのリプレイ: Tealeaf Browser Based Replay (BBR) 9.0.1 からは、ページ・レベルで混合モードのリプレイがサポートされるようになっています。

    EnableDOMCapture グローバル・オプションはデフォルトで有効にされるため、リプレイはトランスペアレントに行われます。

    • ページで DOM が検出されると、リプレイにはそのキャプチャーされた DOM が使われます。
    • ページで DOM が検出されなければ、リプレイはデフォルトで従来のリプレイに設定されます。
    • リプレイが DOM Capture であるか、Classic Capture であるかを判別するには、以下のようにします。

      ポート 38000 にアクセスし、対象のセッションを選択してから「Nav List XML (ナビゲーション・リスト XML)」をクリックしてナビゲーション・リスト XML を表示します。

      プロパティーに isDomCapture = true という設定がある場合、この UI イベントは DOM を使用してリプレイされることがわかります。

      現在、UI イベントには Tealeaf の DOM サポートが有効であるため、プロパティー UIEvent = false に設定されているページでは、isDOMCapture プロパティーを false に設定する必要があります。

    • キャプチャーされた DOM が含まれるページは、Tealeaf Browser Based Replay の中で識別されます。
  9. キャニスター・イベント・メトリックを再確認する: キャニスター・イベント・メトリックを再確認して、修正が必要かどうかを判断してください。

    DOM Capture のシナリオによっては、Canister Safety Limits (キャニスター安全限度) [BB] イベントを変更する必要があるかもしれません。

    Canister Safety Limits (キャニスター安全限度) [BB] イベントは、セッションが長すぎる場合や、大きすぎる場合、あるいはヒット数が多すぎる場合には、セッションを終了します。DOM Capture ソリューションは、追加の処理およびネットワーク伝送コストをもたらす可能性があるため、その追加コストに対処すると同時に、セッションがあまりにも早く分割されることがないように、Canister Safety Limits (キャニスター安全限度) [BB] イベントの Bytes セクションに指定されたバイト・サイズを増やす必要があります。

    詳細については、IBM Knowledge Center の資料「キャニスター安全限度 [BB] イベント」を参照してください。

  10. 既存の Tealeaf イベントには、Tealeaf の DOM を使用することができます。

まとめ

効果的にカスタマー・エクスペリエンスを管理することは、あらゆる業界でビジネスが成功する鍵となっています。Web に精通していて能力がある最近のコンシューマーは、SPA などの今どきの Web アプリケーションを使用してオンラインでビジネスを行うことを期待しています。IBM Tealeaf バージョン 9.0.1 以降で使用可能な DOM テクノロジーは、高い忠実度のキャプチャー & リプレイを効果的に提供するだけでなく、SPA 対応の Tealeaf 分析によって実用的な洞察を提供します。さらに、企業が積極的に顧客のエクスペリエンスを改善するために使用できる最新のテクノロジーと手法によって、タイム・ツー・バリューを短縮します。Tealeaf の DOM テクノロジーを採用してその恩恵を受けている ARC などの顧客は、将来的にこのテクノロジーの実装をさらに増やそうと尽力しています。顧客のエクスペリエンスを管理、改善するために IBM Tealeaf の DOM テクノロジーを利用する方法についてのお問い合わせを歓迎します。IBM Tealeaf の DOM テクノロジー・シリーズの今後のホワイト・ペーパーにご注目ください!


ダウンロード可能なリソース


関連トピック

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=ビジネス・アナリティクス
ArticleID=1025843
ArticleTitle=シングルページ・アプリケーションのエクスペリエンスを最適化する
publish-date=01282016