Jeux de données Explore

Vos données Zendesk sont segmentées en plusieurs jeux de données. Chaque jeu de données contient des mesures et des attributs que vous pouvez utiliser pour créer des requêtes et générer des rapports. Vous devez sélectionner un jeu de données spécifique avant de pouvoir interroger vos données avec Zendesk Explore.

Si vous avez besoin d’aide pour gérer vos jeux de données et en choisir un, consultez Utilisation des jeux de données.

Si vous avez besoin d’aide pour créer une requête, consultez Création de requêtes.

Conseil : vous avez besoin d’aide pour trouver les mesures et attributs qu’il vous faut pour évaluer votre succès et prendre des décisions informées ? Alors consultez le guide Les mesures clés du service client.

Cet article vous explique comment choisir le bon jeu de données pour vos rapports et présente des informations plus avancées sur la façon dont vos jeux de données stockent vos informations commerciales. Cet article aborde les sujets suivants :

• Choix du bon jeu de données
• Structure des jeux de données

Choix du bon jeu de données

Les jeux de données sont disponibles pour les produits ci-dessous. Choisissez un produit pour en savoir plus au sujet de chaque jeu de données et découvrir les mesures et attributs que vous pouvez utiliser avec.

• Jeux de données Support
  • Tickets : indicateurs clés de tickets, tels le nombre de tickets, les activités des tickets et les types de tickets.
  • Ticket updates : informations sur les mises à jour apportées aux tickets pendant leur durée de vie.
  • Backlog history : informations sur vos tickets non résolus à la fin de n’importe quelle date donnée.
  • SLAs : informations sur les performances de vos accords sur les niveaux de service (SLA).
• Jeux de données Talk :
  • Calls : informations sur les activités de vos agents et de votre centre d’appels.
• Jeux de données Chat :
  • Engagement : information sur les interactions de vos clients avec Chat.
• Jeux de données Guide
  • Answer Bot : informations sur l’efficacité de votre utilisation d’Answer Bot.
  • Knowledge Capture : informations pour mieux comprendre l’efficacité des articles à des fins de réduction du nombre de tickets.

Structure des jeux de données

Les jeux de données Explore contiennent toutes les informations disponibles pour votre produit ou les fonctionnalités de votre produit. Pour interroger vos données efficacement et éviter les données en double ou incohérentes, Explore regroupe vos données dans plusieurs tableaux de données différents. Vous pouvez envisager chaque tableau de données comme une sorte de boîte dans laquelle sont stockées vos données. Ces tableaux de données ne sont pas isolés les uns des autres, ils sont reliés par des attributs spéciaux de points de connexion qui jouent le rôle d’identifiants uniques pour chaque ligne de données dans le tableau.

Dans l’exemple de graphique ci-dessous, les données de ticket sont stockées dans le tableau de données Tickets et les données d’utilisateur sont stockées dans le tableau de données Users. Ces tableaux de données sont reliés dans les jeux de données à l’aide d’attributs spéciaux de points de connexion.

Par exemple, Ticket ID est le point de connexion pour le tableau de données Ticket et Requester ID est le point de connexion pour le tableau de données Users.

Quand un utilisateur exécute une requête, Explore détermine quels tableaux contiennent les mesures et attributs requis, et s’il est nécessaire de relier ces tableaux. Si les mesures et attributs requis se trouvent tous dans un même tableau, aucune connexion (ou jointure) n’est réalisée. Un exemple est une requête qui compte les ID de ticket par statut.

Mais si les mesures et attributs requis se trouvent dans plusieurs tableaux de données différents, ces tableaux doivent être reliés. Un exemple est une requête qui compte les mises à jour de ticket par nom de l’assigné. Dans ce cas, les tableaux Ticket updates, Tickets et Users sont reliés pour générer le résultat.

Les tableaux de données Explore sont reliés en utilisant la méthode de JOINTURE GAUCHE. Cela signifie que quand les tableaux sont reliés, la requête renvoie toutes les lignes du tableau sur la gauche, même s’il n’y a pas de correspondances avec le tableau sur la droite. Dans l’exemple ci-dessus, un nombre d’ID de ticket par nom de l’assigné renverra tous les tickets avec ou sans assigné.

Dans certains cas, il n’est pas techniquement possible de stocker les données dans plusieurs tableaux de données car le volume de données est trop élevé ou les requêtes doivent s’exécuter rapidement. Le jeu de données Tickets non traités en est un exemple. Il n’utilise qu’un seul tableau pour stocker les données.