Exploreデータセットの概要

Zendeskのデータは複数のデータセットに分割されます。各データセットには、レポートの作成に使用できるメトリックと属性が含まれています。Zendesk Exploreでデータを照会する前に、特定のデータセットを選択する必要があります。

データセットの選択と管理については、「データセットの操作」を参照してください。

レポートの作成については、「レポートの作成」を参照してください。

ヒント：成功を測定し、賢明なビジネス上の意思決定を行うために必要なメトリックと属性を見つけるための支援が必要ですか？その場合は、「重要なカスタマーサービスメトリック」ガイドを参照してください。

この記事を使用して、レポートに適したデータセットを選択したり、データセットによる会社情報の保存に関する詳細情報を参照したりできます。この記事では、次のトピックについて説明します。

• 適切なデータセットを選択する
• データセット構造について

適切なデータセットを選択する

データセットは次の製品で使用できます。製品を選択して各データセットの詳細を確認し、使用できるメトリックと属性を見つけます。

• Supportのデータセット
  • Tickets：チケットの量、チケットのアクティビティ、チケットの種類など、チケットの主要なメトリック。
  • Updates history：チケットの有効期間中に行われたすべての更新。
  • Backlog history：任意の日について、その日の終わりの時点での未解決のチケットに関する情報。
  • SLAs：サービスレベルアグリーメント（SLA）の順守状況に関する情報。なお、このデータセットは、SLAポリシーが適用されたチケットがある場合にのみ、表示されます。「SLAポリシーの定義と使用」を参照してください。
• Talkのデータセット：
  • Calls：コールセンターとエージェントのアクティビティに関する情報。
• Live chatおよびmessagingデータセット：
  • Engagement：Chatを使用したカスタマーとのやりとりについての情報。
  • Chat Concurrency：エージェントの同時チャットエンゲージメントについての情報。
  • Messaging tickets：Webメッセージング、モバイルメッセージング、ソーシャルメッセージングチャネルを含む、すべてのメッセージングチャネルに関連する情報。この情報には、チケットの数、解決時間、満足度などが含まれます。
• Guideのデータセット
  • Knowledge Capture：サポートチケットを削減するための記事の選択の効率性を理解するのに役立つ情報。
  • Team Publishing：（Guide Enterpriseのみ）記事の作成日、公開日、更新日など、チームの活動を理解するのに役立つ情報。
  • Knowledge Base：ヘルプセンターの記事がどのくらいの頻度で閲覧されているか、どの記事に投票が多いかまたは少ないかなどを理解するのに役立つ情報。
  • Search：ユーザーが実行した検索と、ユーザーがナレッジベースで検索した用語の情報。
  • Community：投稿やコメントの数、賛成投票数と反対投票数、コミュニティメンバーなど、コミュニティフォーラムでのアクティビティに関する情報が表示されます。
• Sellのデータセット
  • Sell：Zendesk Sellのセールスパイプラインに関する情報。
  • Calls：Zendesk Sellのセールスコールに関する情報（着信、発信、コール時間など）。
  • Products：今までにいくつ売れたか、どの商品が最も売れたかなど、製品の売上に関する情報。
  • Activities：送信メール数、発信コール数、完了したタスクの数、実施された商談予約の数、訪問数など、Sellのアクティビティと営業チームの貢献度に関する情報。

• Answer Botのデータセット
  • Article Recommendations：カスタマーに対して自動的に推奨されるヘルプセンターの記事の効果に関する情報。
  • Flow Builder：Zendeskのすべてのチャネルにおけるボットの効果に関する情報。

データセット構造について

Exploreのデータセットには、製品または製品の機能について利用可能なすべての情報が含まれています。データを効率的に照会し、重複したデータや矛盾したデータを回避するために、Exploreはデータを複数のデータテーブルにグループ化します。データテーブルは、データが格納される一種の「箱」と考えることができます。各データテーブルは分離されておらず、テーブル内のデータの各行の一意の識別子として機能する接続ポイントの特別な属性によって互いに結合されています。

次の図の例では、チケットデータはTicketデータテーブルに格納され、Usersデータは別のユーザーデータテーブルに格納されています。これらのデータテーブルは、接続ポイントの特殊な属性を使用してデータセット内で結合されます。

たとえば、Ticket IDはTicketデータテーブルの接続ポイントですが、Requester IDはUsersテーブルの接続ポイントです。

ユーザーがレポートを実行すると、Exploreは必要なメトリックと属性を含むテーブルを特定し、テーブルを結合する必要があるかどうかを判別します。必要なメトリックと属性が同じテーブルにある場合、接続（または結合）は行われません。この例は、チケットIDをステータス別にカウントするレポートです。

ただし、必要なメトリックと属性が複数のデータテーブルに分かれている場合は、テーブルが結合されます。この例は、チケット更新を担当者名別にカウントするレポートです。この場合、Ticket updates、Tickets、およびUsersテーブルが結合され、結果が生成されます。

Exploreデータテーブルは、LEFT JOINメソッドを使用して接続します。つまり、テーブルが結合されると、右側のテーブルから一致する行がない場合でも、レポートは左側のテーブルからすべての行を返します。上記の例では、担当者名ごとにチケットIDをカウントしようとすると、担当者の有無にかかわらずすべてのチケットが返されます。

場合によっては、大量のデータや高速なレポート実行が必要となるため、技術的に複数のデータテーブルにデータを格納できないことがあります。この例として、Backlogデータセットがあります。このデータセットは、データの格納に1つのテーブルのみを使用します。