Zendeskのデータは複数のデータセットに分割されます。各データセットには、Exploreレポートの作成に使用できるメトリックと属性が含まれています。レポートを作成する前に、特定のデータセットを選択する必要があります。
この記事を使用して、レポートに適したデータセットを選択したり、データセットによる会社情報の保存に関する詳細情報を参照したりできます。
この記事では、次のトピックについて説明します。
関連記事
利用可能なデフォルトのデータセットの概要
以下の表に、各製品で利用可能なデータセットを説明します。
Zendesk製品 | データセット名 | 内容 |
---|---|---|
Support | Tickets | チケットIDや担当者など、チケットの詳細情報。チケットの更新イベントは含みません。 |
Updates history | チケットの有効期間中に行われたすべての更新。 | |
Backlog history | 任意の日について、その日の終わりの時点での未解決のチケットに関する情報。 | |
SLAs | サービスレベルアグリーメント(SLA)の遵守状況に関する情報。 SLAポリシーが適用されたチケットがある場合にのみ、利用できます。詳しくは「SLAポリシーの定義と使用」を参照してください。 |
|
Group SLAs | グループのサービスレベルアグリーメント(SLA)の遵守状況に関する情報。 SLAポリシーが適用されたチケットがある場合にのみ、利用できます。詳しくは「社内チームのためのグループSLAポリシーの定義」を参照してください。 |
|
Guide | Knowledge Capture | サポートチケットを削減するための記事の選択の効率性を理解するのに役立つ情報。 |
Team Publishing | 記事の作成日、公開日、更新日など、チームのアクティビティを理解するのに役立つ情報。 Professionalプラン以上のプランでのみ利用できます。 |
|
Knowledge Base | ヘルプセンターの記事がどのくらいの頻度で閲覧されているか、どの記事に投票が多いかまたは少ないかなどを理解するのに役立つ情報。 | |
Search | ユーザーが実行した検索と、ユーザーがナレッジベースで検索した用語の情報。 | |
Community | 投稿やコメントの数、賛成投票数と反対投票数、コミュニティメンバーなど、コミュニティフォーラムでのアクティビティに関する情報が表示されます。 | |
メッセージングとオンラインチャット | Messaging tickets | Webメッセージング、モバイルメッセージング、ソーシャルメッセージングチャネルを含む、すべてのメッセージングチャネルに関連する情報。チケットの数、解決時間、満足度などが含まれます。 |
Engagement | Chatを使用したカスタマーとのやりとりについての情報。 | |
Chat Concurrency | エージェントの同時チャットエンゲージメントについての情報。 | |
Answer Bot | Article Recommendations | カスタマーに対して自動的に推奨されるヘルプセンターの記事の効果に関する情報。 |
Flow Builder | Zendeskのすべてのチャネルにおけるボットの効果に関する情報。 | |
Talk | Calls | コールセンターとエージェントのアクティビティに関する情報。 |
Sell | Sell | セールスパイプラインに関する情報。 |
Calls | セールスコールに関する情報(着信、発信、コール時間など)。 | |
Products | 今までにいくつ売れたか、どの商品が最も売れたかなど、製品の売上に関する情報。 | |
Activities | 送信メール数、発信コール数、完了したタスクの数、実施された商談予約の数、訪問数など、セールスアクティビティと営業チームの貢献度に関する情報。 |
データセット構造について
Exploreのデータセットには、製品で利用可能なすべての情報が含まれています。データを効率的に照会し、重複したデータや矛盾したデータを回避するために、Exploreはデータを複数のデータテーブルにグループ化します。データテーブルは、データが格納される一種の「箱」と考えることができます。各データテーブルは孤立しているのではなく、代わりにテーブル内のデータの各行の一意の識別子として機能する接続ポイントの特別な属性によって互いに結合されています。
次の図の例では、チケットデータはTicketデータテーブルに格納され、Usersデータは別のユーザーデータテーブルに格納されています。これらのデータテーブルは、接続ポイントの特殊な属性を使用してデータセット内で結合されます。
たとえば、Ticket IDはTicketデータテーブルの接続ポイントですが、Requester IDはUsersテーブルの接続ポイントです。
ユーザーがレポートを実行すると、Exploreは必要なメトリックと属性を含むテーブルを特定し、テーブルを結合する必要があるかどうかを判別します。必要なメトリックと属性が同じテーブルにある場合、接続(または結合)は行われません。この例は、チケットIDをステータス別にカウントするレポートです。
ただし、必要なメトリックと属性が複数のデータテーブルに分かれている場合は、テーブルが結合されます。この例は、チケット更新を担当者名別にカウントするレポートです。この場合、Ticket updates、Tickets、およびUsersテーブルが結合され、結果が生成されます。
Exploreデータテーブルは、LEFT JOINメソッドを使用して接続します。つまり、テーブルが結合されると、右側のテーブルから一致する行がない場合でも、レポートは左側のテーブルからすべての行を返します。上記の例では、担当者名ごとにチケットIDをカウントしようとすると、担当者の有無にかかわらずすべてのチケットが返されます。
場合によっては、大量のデータや高速なレポート実行が必要となるため、技術的に複数のデータテーブルにデータを格納できないことがあります。この例として、Backlogデータセットがあります。このデータセットは、データの格納に1つのテーブルのみを使用します。
0 コメント
サインインしてコメントを残してください。