Traduit de l'anglais à l'aide de l'IA
Veuillez noter que cet article a été traduit à l'aide de la technologie IA. Bien que nous travaillions à maintenir l'exactitude, certains détails peuvent ne pas refléter parfaitement le texte original. Si vous avez des doutes sur une information, veuillez vous référer à la version anglaise.
Qu'est-ce que le SDK ?
SDK signifie "Software Development Kit". C'est un ensemble d'outils et de programmes logiciels utilisés par les développeurs pour créer des applications pour des plateformes spécifiques. Le SDK de Contentsquare est l'équivalent de la balise de suivi pour le web, mais pour les applications, pas pour le bureau ou la navigation web sur mobile. Il aura le même rôle qu'une balise sur un site web :
- Il est intégré dans votre application. C'est le même pour tous les clients.
- Une fois installé sur votre appareil, le SDK de Contentsquare suivra les données et les enverra aux serveurs de Contentsquare.
Comment les données sont-elles collectées ?
Les données sont collectées via le SDK de Contentsquare pour Android et iOS (ce sont 2 SDK distincts avec des fonctionnalités similaires).
Le SDK est facile à installer (une ligne de code) et démarre automatiquement lorsque l'application se lance.
Si l'appareil a une connexion Internet, le SDK récupérera le fichier de configuration unique (stocké sur notre serveur) lié à l'ID de l'application. Une fois qu'il obtient la configuration, il l'applique et commence à suivre.
Voir le schéma
Une implémentation minimale est requise avant que le SDK ne commence à suivre : vous devez implémenter le code pour suivre les vues d'écran.
Les données sont-elles échantillonnées ?
Oui, si cela est stipulé dans votre contrat. Nous échantillonnons les données au niveau utilisateur. Un utilisateur est une application installée sur un appareil unique. Le taux d'échantillonnage est déterminé pour chaque application (selon le contrat) et peut être modifié si nécessaire. (Pour plus d'informations, contactez votre CSM).
Comment une session est-elle définie chez Contentsquare ?
Une session se termine après 30 minutes d'inactivité. Si vous cachez ou fermez l'application, votre session continuera tant que vous revenez dans les 30 minutes. Notez que les sessions sans au moins une vue d'écran seront rejetées.
Que signifie deux groupes d'écran avec le même nom d'écran consécutivement dans Journey Analysis ?
Les vues de deux groupes d'écran avec le même nom d'écran consécutivement dans Journey Analysis indiquent que l'utilisateur a mis l'application en arrière-plan (appel téléphonique, lecture de texte, autre application, etc.) et est revenu à l'application avant le renouvellement de la session. Ce comportement déclenchera automatiquement une nouvelle vue de groupe d'écran, avec le même nom d'écran dans le parcours utilisateur.
Voir l'image
Le consentement de l'utilisateur est-il requis avant que la session puisse commencer ?
Le consentement de l'utilisateur n'est pas toujours requis. La session peut commencer dans les deux cas :
- Le consentement de l'utilisateur est requis. Le SDK ne suivra aucune donnée tant que le consentement n'a pas été approuvé. Une fois le consentement approuvé, il est envoyé au SDK en appelant l'API opt-in. La session commencera à partir de la première vue d'écran.
- Le consentement de l'utilisateur n'est pas requis. Le SDK commencera à suivre les données utilisateur à partir de la première vue d'écran.
Comment activer les fonctionnalités in-app de CS ?
L'activation des "fonctionnalités in-app" vous permet d'activer et de désactiver les fonctionnalités du SDK à l'aide d'une URL personnalisée ("deeplink") disponible via un QR code. Assurez-vous que l'application est lancée sur votre mobile, ouvrez le modal des fonctionnalités in-app depuis le menu et scannez le QR code. Si vous n'avez pas de mobile, vous pouvez copier le lien de ce même modal et le coller sur votre Émulateur (Android) ou Simulateur (iOS), pour déclencher la fonctionnalité.
Combien de temps faut-il pour que les données soient disponibles sur CS ?
Environ 10 secondes après la fin d'une session.
Qu'est-ce qu'une vue d'écran ?
Une vue d'écran est l'équivalent d'une vue de page pour le web. Les vues d'écran sont déclenchées lorsque l'API SDK "Send Screenview" est appelée dans le code de l'application cliente.
Exemple : de l'"écran d'accueil" à l'"écran de mon compte".
Le suivi des écrans nécessite une implémentation manuelle de l'équipe de vos développeurs.
Chaque vue d'écran envoie également un "nom d'écran", qui est utilisé pour identifier les différents écrans de l'application.
Comment les instantanés sont-ils capturés dans Experience Analytics Mobile ?
Pour capturer des instantanés, utilisez les 'fonctionnalités in-app' sur votre téléphone mobile et appuyez simplement sur le bouton d'instantané qui sera visible sur chaque écran que vous parcourez. Ces instantanés ne peuvent être pris que par vous sur votre appareil. Ils ne sont pas capturés depuis les appareils de vos utilisateurs finaux. Cette méthode est sûre pour éviter d'identifier directement des données personnelles. Notez qu'un événement de vue d'écran déclenché est requis avant que des instantanés puissent être capturés.
Les mappings pour les applications fonctionnent presque de la même manière que pour les projets web. Le SDK génère des vues d'écran avec un nom d'écran. Les noms d'écran sont fournis par le développeur qui met en œuvre le suivi des écrans. Vous créez un mapping avec l'Assistant de mapping ou en sélectionnant les noms d'écran que vous souhaitez ou en créant des conditions sur les noms d'écran comme vous en avez l'habitude pour le web.
Les Webviews sont-ils pris en charge ?
Les WebView sont des containers ouvrant du contenu web. Ils peuvent jouer un rôle critique dans la compréhension du comportement d'un utilisateur à travers les modules analytics ou la session Replay.
Les snapshots contenant des webviews rendront le contenu, vous permettant de créer des zones et d'afficher des métriques sur les webviews.
Ils sont entièrement pris en charge dans Experience Analytics Mobile pour iOS, Android, React Native et Flutter.
En savoir plus sur le processus d'implémentation pour Android
En savoir plus sur le processus d'implémentation pour iOS
Quel est l'impact dans Experience Analytics des modules Mobile sans suivi Webview ?
Voir des exemples dans les modules Experience Analytics Mobile ⌄
Session Replay - Comment fonctionne la politique d'échantillonnage ?
Session Replay - Rétention des données
Par défaut, la rétention des données est
fixée à 30 jours et peut être prolongée
à 92 jours, selon votre contrat.
Notez que si vous prolongez la rétention
des données à 92 jours,
ces 92 jours ne seront pas rétroactifs. Vous devrez attendre 62 jours pour obtenir un temps de rétention complet de 92 jours pour Session Replay.
Session Replay - Masquage automatique des données personnelles
Comme les informations personnelles ne peuvent pas être stockées, par défaut, Session Replay pour les applications masquera le contenu de ce qui est affiché sur l'IU (textes et images). Cependant, comme le masquage complet des données personnelles peut rendre la lecture difficile à évaluer, CS propose de masquer/démasquer des composants spécifiques par type et instance afin que le masquage soit plus spécifique, et ne masque que la partie qui pourrait réellement transmettre des données personnelles. Ces méthodes nécessitent un effort d'implémentation spécifique de la part de votre équipe de développeurs. Veuillez consulter la documentation d'implémentation.
Processus d'implémentation du masquage des données personnelles iOS
Processus d'implémentation du masquage des données personnelles Android
Pourquoi la méthode de masquage est-elle différente pour iOS et Android ?
Afin de fournir la meilleure performance et qualité, nous avons adopté des approches différentes sur Android et iOS pour nous adapter à chaque plateforme. Alors que sur Android, nous convertissons chaque élément de l'IU en images (y compris le texte), sur iOS, nous sommes capables de collecter des propriétés de texte et de style pour les rendre avec précision. Les images et le texte seront donc floutés sur Android, tandis que sur iOS, le texte sera remplacé par « lalala » et les images par des espaces réservés.
En ce qui concerne le stockage des données personnelles, aucune donnée personnelle ne sera démasquée. Le masquage est effectué du côté du SDK puis envoyé, donc Contentsquare ne stocke que ce que vous voyez réellement dans la lecture.
Quels sont les différents types d'applications mobiles ?
Les applications mobiles natives sont conçues pour être « natives » à une plateforme, que ce soit Apple iOS ou Android de Google. Elles sont écrites dans le langage natif du système d'exploitation, sont téléchargeables depuis le magasin pour l'utilisateur final, et fonctionnent sur le système d'exploitation de l'appareil.
Bénéfices : Elles ont été développées spécifiquement pour la plateforme, elles peuvent fonctionner plus rapidement et intuitivement, et tirer pleinement parti des capacités matérielles de l'appareil.
Ces applications sont installées sur des appareils
tout comme les applications natives,
mais elles ne sont pas entièrement développées dans le langage natif du système d'exploitation : elles sont écrites et/ou rendues dans des langages non natifs.
Pourtant, elles sont téléchargeables depuis
le magasin pour l'utilisateur final
et fonctionnent sur le système d'exploitation de l'appareil.
Bénéfices : Même si les applications hybrides ne sont pas aussi rapides ou fiables que les applications natives, elles ont une plus grande capacité à rationaliser le processus de développement. Vous n'avez pas à construire et à maintenir des applications pour des plateformes séparées, votre entreprise peut économiser du temps et des ressources. C'est idéal pour les applications qui livrent principalement du contenu.
Quelles sont les technologies de développement prises en charge par Experience Analytics Mobile ?
Sur les applications mobiles natives
-
iOS: Swift / Objective-C
-
Android: Java / Kotlin
Sur les applications multiplateformes
-
Applications s'affichant dans une IU native mais écrites avec des composants IU non natifs :
-
React Native est un cadre (maintenu par Facebook) utilisé pour écrire des applications en Javascript. L'IU créée repose sur des Vues IU natives.
-
Xamarin est un cadre (maintenu par Microsoft) utilisé pour écrire des “applications” en .NET et les afficher dans des composants IU natifs.
-
NativeScript est un cadre similaire à React Native utilisé pour écrire des “applications” en Javascript et les afficher dans des composants IU natifs.
-
-
Applications écrites dans des langages non natifs et affichées dans des composants IU non natifs:
-
Flutter est un cadre (maintenu par Google) utilisé pour écrire des applications en Dart et les afficher sur un canevas en utilisant des widgets propriétaires personnalisés pour construire l'IU.
-
-
Applications mobiles basées sur le web écrites et affichées dans une IU web.
Leur pile combine généralement un cadre d'emballage et une bibliothèque front-end spécialisée dans les composants IU multiplateformes :-
Les wrappers : Capacitor (maintenu par Ionic) & Apache Cordova (maintenu par Adobe et également connu sous le nom de PhoneGap dans sa forme commerciale) sont des cadres enveloppant une application HTML/JavaScript dans un container natif qui peut accéder aux fonctions de l'appareil sur plusieurs plateformes
-
Ionic est la bibliothèque front-end la plus populaire qui est généralement utilisée avec Capacitor ou Cordova. Mais les applications peuvent également utiliser des bibliothèques front-end standard ou un simple front end.
-
Les applications mobiles basées sur le web sont téléchargeables depuis le store et s'exécutent sur le système d'exploitation de l'appareil.
Quelles sont les spécificités de Flutter ?
Flutter est un cadre créé par Google. Il est utilisé pour écrire des applications en Dart et les afficher sur un canevas en utilisant des widgets propriétaires personnalisés pour construire l'IU. Parce que les widgets sont des éléments IU que les développeurs utilisent pour construire l'IU, l'analyse de l'IU doit être effectuée par le plug-in Flutter de Contentsquare, qui est responsable de générer le chemin de vue cible pour le suivi des gestes et générer des captures pour le zoning.
En savoir plus sur les cibles de zoning de Flutter
Contrairement aux applications iOS & Android natives, Flutter a la particularité de générer un arbre IU très profond (composé de widgets). Cela signifie des cibles très longues, impactant la performance & la consommation de données lors de la génération d'événements de geste ou de la capture de snapshots. Par conséquent, il a été décidé de compresser les cibles afin de réduire l'impact.
Note : Les applications Flutter ne captureront que ce qui est visible à l'écran. C'est similaire à la méthode de “capture statique” pour Android.