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 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.
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
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 :
-
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.
- Updates History : 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). Notez que ce jeu de données n’est visible que si vous avez appliqué des politiques SLA aux tickets. Consultez Définition et utilisation des politiques 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 pour le chat en direct et la messagerie :
- Engagement : information sur les interactions de vos clients avec Chat.
- Chat Concurrency : informations sur le traitement de plusieurs engagements par chat simultané par vos agents.
- Messaging tickets : informations sur tous les canaux de messagerie, y compris les canaux de messagerie Web, mobile et sociale. Ces informations incluent le nombre de tickets, les délais de résolution, la satisfaction, etc.
-
Jeux de données Guide
- Knowledge Capture : informations pour mieux comprendre l’efficacité des articles à des fins de réduction du nombre de tickets.
- Team Publishing : (Guide Enterprise uniquement) informations qui vous aident à comprendre l’activité de votre équipe dans Guide, notamment quand des articles sont créés, publiés, modifiés, etc.
- Knowledge Base : informations qui vous aident à savoir à quelle fréquence sont consultés les articles du centre d’aide, quels articles reçoivent des votes pour ou contre, et plus encore.
- Search : informations sur les recherches effectuées par les utilisateurs et les termes qu’ils ont recherchés dans votre base de connaissances.
- Community : informations sur les activités des forums de votre communauté, comme le nombre de publications et de commentaires, le nombre de votes pour et contre, les membres de la communauté, etc.
-
Jeux de données Sell
- Sell : informations sur votre pipeline de ventes Zendesk Sell.
- Calls : informations sur vos appels commerciaux Zendesk Sell, comme les appels entrants et sortants, heure des appels, et plus.
- Products : informations sur vos ventes de produits, comme le nombre de produits vendus au fil du temps ou les produits qui se vendent le mieux.
- Activities : informations sur le volume d’activités Sell et la contribution de l’équipe commerciale, notamment le nombre d’e-mails envoyés, d’appels passés, de tâches terminées, de rendez-vous assurés et de visites effectuées.
-
Jeux de données Answer Bot
- Article Recommendations : informations sur les performances des articles du centre d’aide recommandés automatiquement aux clients.
- Flow Builder : informations sur les performances de l’assistant dans tous les canaux Zendesk.
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 un rapport, 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 un rapport 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 un rapport 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, le rapport 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 rapports doivent s’exécuter rapidement. Le jeu de données Backlog en est un exemple. Il n’utilise qu’un seul tableau pour stocker les données.
0 Commentaires
Vous devez vous connecter pour laisser un commentaire.