高度なフィーチャーのタグ付け

最終更新日: 2023年08月25日 13:16

この記事では、フィーチャーのタグ付け機能を説明します。自動選択の品質を判断するのを支援し、カスタムセレクターのテスト方法に関する情報を提供します。

注：この記事は、読者にある程度技術的な知識があることを前提としており、すべてのユーザーに推奨される手法ではないことをご了承ください。この記事の内容についてご質問がある場合や、以降の進め方がわからない場合は、PendoカスタマーサクセスマネージャーまたはPendoテクニカルサクセスチームにお問い合わせください。

前提条件：CSSセレクターとChrome DevTools

Pendoにおけるフィーチャー選択は、アプリケーションのコンポーネントを識別する方法としてCSSセレクターのサブセットを使用します。ここでの作業を開始する前に、一般的なCSSセレクターと、当社が特に許可しているフィーチャーの両方を熟知しておくことをお勧めします。以下は開始のためのリソースです。

CSS：

Chrome DevTools：

フィーチャー選択の仕組み

フィーチャータグは、CSSセレクターを使ってユーザーのアクティビティデータを選択することで機能します。これは、ウェブページから要素を直接選択する場合と同様です。これらのイベントは、イベントが記録される各ページ要素の階層表現として取得されます。アクティビティの収集と保存の方法によって、使用できるセレクターが制限されます。これらの各セレクターは「フィーチャールール」と呼ばれています。

フィーチャールールの仕組み

それぞれのフィーチャールールは、受信した総データに対して処理され、ルールが適用される各イベントを表示します。

一般的なセレクター（任意の「送信（Submit）」ボタンなど）は、特殊なセレクター（正確なモーダルの「送信（Submit）」ボタンなど）よりも多くの結果を返すことになります。

Pendoは、ページ要素の階層表現の形式でデータを収集します。つまり、フィーチャールールの特異性のレベルは、Pendoアプリケーションで表示される合計数に影響を与える可能性があります。これについては、以下のフィーチャールールの品質を決定するのセクションで詳しく説明しています。

また、複数のルールを利用して選択を組み合わせることもできます。複数のフィーチャールールを使用しても、結果が重複して表示されることはありません。各ルールはそれぞれのフィーチャーのコンテキスト内で処理されるため、総カウント数には別のルールにすでに含まれているイベントは含まれません。特定のフィーチャーに対してアクティビティを正確に取得するために必要なルールの数は、アプリケーションの実装やタグ付けするフィーチャーの目的に依存します。

フィーチャールールの品質を決定する

アプリケーションの実装や、タグ付け時にユーザーがフィーチャーを選択する方法によっては、データを意図したとおりに取得しない自動フィーチャールールが選択される場合があります。簡単で一般的な例として、buttonタグまたはanchorタグに含まれるspanがあります：

上記の例では、アンカー要素（<a...で示される）があり、その子要素は「Generic Page」というテキストを含むスパン（<span\>で示される）であることがわかります。画像のハイライト部分は、フィーチャーのクリック数がどのように最低レベルで追跡されるかを示しています。青いスペースのクリックはspanに対して追跡され、緑のスペースのクリックはanchorに対して追跡されます。この要素にアプリ内でタグ付けすると、クリックした場所に応じて、次の2つのセレクターのいずれかが表示されます。

アンカー、ルールA：

[href="/assets/pages/generic.html"]

スパン、ルールB：

span:contains('Generic Page')

どのセレクターが適しているかを判断するには、クリックした要素より上の、最も明確なものから追跡されることに注意してください。ここでは、両者の主要な違いを簡単な図で説明します。

ルールA（アンカーに対するもの）を見ると、クリック1とクリック2の、2つのクリックイベントが確認できます。このルールでは、これらのクリックイベントの両方がルールによって取得されます。これは、スパンに対してクリックすると、この要素から上が追跡されるためです。アンカータグを対象とするすべてのルールは、その中のすべてのクリックを取得する必要があります。

ルールB （スパンに対するもの）を見ると、別の2つのクリックイベントであるクリック3とクリック4が確認できます。このルールではクリック4のみが取得されます。これは、アンカーに対するクリックではアンカーとその上にあるものしか収集されないのに対し、当社のルールでは、アンカーの下にある要素を非常に明確に指し示しているからです。

この要素に対する最適なタグ付けの選択は、アンカーに対するルールAとなります。

フィーチャールールをテストする

注：Pendoには、ウェブページから要素を読み込んで選択するためのSizzleライブラリが実装されています。Sizzleはテストに適していますが、フィーチャーに許可されたものよりも多くのセレクターに対応しています。iFrameレベルでコンソールを照会しない限り、SizzleはiFrame内の要素を検出できません。詳細については、サポートされているフィーチャーのCSSセレクターについての記事「フィーチャーのタグ付けでサポートされているCSSセレクターは何ですか？」をご覧ください。

ルールをテストするには、フィーチャーが存在するページ（デザイナーの外）に直接移動し、Chrome DevToolsを開きます。以下のようにコンソールに入力します：

pendo.Sizzle('FEATURE_RULE_HERE')

コマンドを実行すると、セレクターの結果がドロップダウンで表示されます。

これらの結果にマウスを合わせると、アプリケーション内の項目がハイライト表示されます。

また、結果をダブルクリックすると、「要素（Elements）」ペインにその要素が表示されます。この情報とハイライト表示部分を組み合わせると、ルールの効果がわかります。

動的にレンダリングされたフレームワーク

クラスやIDなどの動的に生成される属性は、React.js、EXT.js、またはEmberなどのフレームワークでは一般的です。Pendoではいくつかの自動除外が作成され、Suggested Matchはこれらの除外を回避しようとします。ただし、すべてのデータを取得したり毎回ツールチップを表示したりするためには、カスタマイズが必要になる場合があります。

以下に、動的に生成される属性の例をいくつか示します。

.nav_bar__2RnO8

#ember123

#btn-1050-el

この数字は、ページが読み込まれるたびにランダムに生成されるため、別のものを選択するか、一致をワイルドカードで表すようにしてください。ワイルドカードを使用して取得されるものより具体的なものをクエリ文字列で取得したい場合は、通常Containsを使用します。詳細については、フィーチャーのタグ付けでサポートされているCSSセレクターは何ですか？を参照してください。

アプリ内のデザイナーでフィーチャーのタグ付けを行った後、［フィーチャー要素の一致（Feature Element Matching）］で［カスタムCSS（Custom CSS）］を選択します。

Screen_Shot_2020-02-13_at_10.57.19_AM.png

例を挙げて説明しましょう。Suggested Matchが「.nav_bar__2RnO8」だったとします。Pendoでは「^」がサポートされており、これはReact.jsクラスをタグ付けする際の便利なオプションである「～で始まる属性」を意味しています。「.nav_bar__2RnO8」のフォーマットは次のようになります。

[class^=“nav_bar__”]

ヒント：正しい構文で適切な要素を選択したことを示すために、要素の周りに赤いボックスが表示されます。

上の例の「class」は「.」のための属性ですが、これと同じ構文は、id（「#」で表される）や「href」などの他の属性にも有効です。

Pendoがサポートするルール

[attribute^=“what it begins with”]

[attribute$=“what it ends with”]

[attribute*=“what it contains”]

注：より適したカスタム属性が使われているかどうかを開発者に確認してください。Pendoはデフォルトではカスタム属性を取得しませんが、設定で追加できます。これにより、Suggested Matchがより正確になり、カスタマイズの必要性も少なくなります。詳細については、カスタム属性の記事をご覧ください。

その他のリソース

CSSセレクターの詳細については、米国ドメインの方は、Pendo Academyで以下の動画をご視聴ください。

EUドメインの方は、以下のリンクからご視聴ください。