documentation azetone v5...page 2 sur 36 © azetone 2017 azetone dashboard v5 bienvenue sur azetone...

Documentation

Azetone v5

Dernière MAJ : novembre 2017

sur 36 © Azetone 2017

Azetone Dashboard v5

Bienvenue sur Azetone v5 !

La version 5 Azetone est notre toute nouvelle plateforme d’administration intégrée à notre nouvelle

architecture et notre nouvelle génération de SDK iOS et Android (nom de code "NextGen"). Nous avons

construit cette nouvelle génération avec pour objectif une évolutivité et une capacité d'extension

accrue. Cela signifie que nous avons la possibilité d'apporter de nouvelles modifications et d'ajouter

encore plus de nouvelles fonctionnalités majeures à votre console d’administration sans avoir à modifier

ou à mettre à jour nos SDK dans vos applications.

Profitez de nos toutes dernières fonctionnalités et restez à l'écoute sur le déploiement régulier de

nouvelles améliorations.

Veuillez noter que des détails techniques supplémentaires peuvent toujours être trouvés sur notre

plate-forme de documentation en ligne http://docs.azetone.com

Préférences de compte utilisateur

Dès que vous créez un compte sur le Dashboard Azetone, vous allez entrer vos coordonnées,

notamment un email et un mot de passe, votre créer un projet d'application. Ces deux éléments

peuvent être consultés et modifiés dans le menu « Réglages » en haut à droite de votre écran.

Via Mon compte, vous pouvez visualiser et modifier toutes les informations de votre compte ainsi que

votre mot de passe via les 2 premiers onglets. Vous trouverez également un historique de vos

connexions au tableau de bord dans le dernier onglet. Si vous avez un rôle d'Admin ou de Super Admin

pour votre entreprise, vous pourrez également créer et gérer des utilisateurs via le troisième onglet.

http://docs.azetone.com/

© Azetone 2017 sur 36

Le tableau de bord d'Azetone propose 4 type de rôles pour les utilisateurs du Tableau de bord.

1. SuperAdmin: si vous êtes celui qui a créé le compte sur notre Dashboard ou votre compte a été

paramétré ainsi par votre gestionnaire de compte Azetone pour votre entreprise, vous disposez

d’un rôle de «Super Admin». Ce rôle (il n'y a qu'un seul pour chaque compte) a tous les

privilèges pour gérer les applications et les services dans le Dashboard et peut créer, modifier,

promouvoir ou rétrograder et révoquer des utilisateurs.

2. Admin: le SuperAdmin a la possibilité de créer des rôles d’Admin qui ont des privilèges

quasiment similaires au SuperAdmin. Les administrateurs peuvent eux aussi créer, gérer et

révoquer d'autres utilisateurs, à l'exception évidemment du SuperAdmin.

3. Editeur: Le rôle d'éditeur offre à l'utilisateur un accès complet Dashboard pour créer des

heatmaps, des tests A/B et des personnalisations (à condition que ces services aient été activés

par un utilisateur Admin). L'éditeur peut également afficher tous les rapports mais ne peut pas

gérer d'autres utilisateurs.

4. Lecteur: Le lecteur, comme son nom l'indique, peut accéder et afficher n'importe quel rapport

existant de heatmaps, de test A/B ou de personnalisation, mais il n'a pas la capacité de créer de

nouvelles heatmaps de nouveaux tests ou de nouvelles variantes. Il ne peut pas non plus gérer

d'autres utilisateurs.


Paramètres de l'application

Via "Mes applications", vous pouvez créer de nouveaux projets d'applications et basculer d’une

application à l’autre. Cela peut se faire très facilement grâce à la fonction "Créer une application" et au

sélecteur affiché ci-dessous.


Mise en œuvre et configuration du SDK

Une fois que notre SDK a été intégré dans votre application, vous pourrez contrôler l'activation des

différentes fonctionnalités du SDK en utilisant les interrupteurs des modules que vous souhaitez utiliser.

Même avec tous les modules activés, notre SDK a un impact quasi-indétectable sur les performances de

l'application. Le panneau de configuration permet néanmoins d'activer les fonctionnalités nécessaires

uniquement lorsque vous en avez besoin et vous économiserez la mémoire et la bande passante utilisée

et vous limiterez la consommation de données au minimum.

Pour accéder à ce panneau de contrôle, sélectionnez « Application » dans le menu de gauche, puis

l'onglet Configuration SDK.

La section A/BTesting contrôle les fonctions d’ A/B Test et de personnalisation dans le SDK et elle est

divisée en 2 parties. Le premier commutateur (Fonctionnalités du SDK) permet d’activer ou désactiver la

gestion et le suivi des variantes (visuelles et universelles) de l'application. Le deuxième (Visual Editor

Mode) active ou désactive la possibilité de connecter l'application en mode Administrateur à la fonction

Visual Editor de notre tableau de bord pour créer de nouveaux tests A/B visuels.

La section Heatmaps contrôle notre fonction Heatmaps et UX Analytics. Lorsque la fonctionnalité du SDK

est activée, elle collectera et enverra des données d'analyse gestuelle (finger tracking) et d'analyse

générale UX à nos serveurs. Lorsque le mode Heatmaps est activé, le mode Heatmaps Administrateur du

Dashboard collectera automatiquement les captures d'écran de l'application pour y superposer les


cartes de chaleur. Veuillez noter que les données pour les gestes sont collectés et stockés (quand la

fonctionnalité SDK des Heatmaps est activée) même lorsque les captures d'écran n'ont pas été

téléchargées sur le tableau de bord. Aussi tôt téléchargées, les cartes de chaleur apparaîtront

instantanément avec les données utilisateur existantes.

Gestion des évènements avec Event Tracker et Event Getter

La plateforme Azetone vous permet de gérer deux grands types d’échanges dynamiques d’information

entre nos serveurs et vos applications mobiles :

- Tout d’abord avec notre Event Tracker, vous pouvez collecter des évènements particuliers dans

votre application pour les réutiliser sur nos serveurs (par exemple comme critères de

segmentation utilisateur ou comme objectifs dans vos tests A/B). il faudra pour cela tagger ces

évènements dans l’application puis les paramétrer dans le Dashboard.

- Et avec Notre Event Getter, vous pouvez injecter dans votre application des informations par

exemple pour appliquer des variantes de test ou de personnalisation dès le (premier) lancement

de votre application

Ces gestions d’évènements sont importantes car elles permettent d’exploiter au maximum la puissance

de la plateforme Azetone.

L’Event tracker permet notamment d’enrichir les segmentations réalisées avec le Profile Builder

avec des informations spécifiques à votre application mais aussi de remonter des clés de

synchronisation (par exemple des identifiants -éventuellement cryptés pour garantir une

confidentialité totale) pour importer par la suite des segments entiers de votre solution de CRM

ou de DMP.

L’Event Getter, lui, permet d’aller au-delà du fonctionnement standard des SDK Azetone. En

effet, pour garantir un impact absolument minimal sur les performances de votre application,

notre SDK fonctionne par défaut en mode asynchrone et en tâche de fond. Le SDK est donc

systématiquement en mode « pull » par rapport à nos serveurs, en venant solliciter par exemple

des variations qu’une fois des temps de traitement et une bande passante suffisamment

disponibles. L’Event Getter permet d’utiliser le SDK Azetone en mode « push », c’est-à-dire

d’injecter des données dans l’application, si besoin dès son lancement, pour en faire un

traitement à la volée.


Event Tracker

Le Dashboard Azetone permet de configurer les évènements taggués et remontés via Event Tracker.

Dans la section « Tracker », vous pourrez retrouver la liste de tous les évènements taggués dans le code

de l’application. Il n’est pas nécessaire pour le développeur de faire quelque traitement ou configuration

que ce soit dans l’application même. C’est au niveau du Dashboard que l’on va indiquer le type de

donnée remontée pour chaque évènement. Cela permet de simplifier au maximum l’intégration de la

solution dans le code de votre application.


Event Getter

Via l’Event Getter, vous avez la possibilité de pousser vers votre application des données qui vont

pouvoir être traitées en priorité, sans attendre que le SDK Azetone vienne récupérer, mettre en cache et

proposer ces éléments à votre application. Cela permet donc de travailler en mode synchrone

(« push ») entre nos serveurs et votre application et ainsi d’envoyer des données ou d’appliquer une

variation quasi-instantanément à votre application.

Le cas d’usage typique est d’appliquer un test A/B à de nouveaux utilisateurs, y compris des utilisateurs

ayant tout juste installé l’application et si besoin dès le tout premier écran de votre application. Nos

serveurs frontaux répondent instantanément à toute requête d’un Event Getter pour projeter à la volée

une variation à tous les utilisateurs concernés par le test. Un « time-out » (durée maximale avant

abandon) peut-être programmé pour garantir dans tous les cas des temps d’attente maximum à

l’utilisateur.


Définir vos profils utilisateurs avec Profile Builder

Vous êtes certainement impatient de consulter vos Heatmaps ou de commencer votre premier Test A/B,

mais avant de vous lancer, nous vous recommandons de passer un peu de temps avec notre Créateur de

Profil (Profile Builder) Cet outil vous permettra d'exploiter la richesse incroyable des données de clients

collectées par les applications mobiles et de les combiner avec d'autres sources de données clients pour

vous offrir les segments de clientèle ou les profils les plus importants et les plus pertinents pour votre

entreprise.

Vous pourrez ensuite utiliser ces profils pour analyser vos rapports UX et vos Heatmaps, cibler les tests

A/B ou même personnaliser votre application en fonction du segment utilisateur.

Les profils peuvent être définis avec différents types de critères :

1. Des critères de sélection qui sont directement collectés par notre SDK : ce sont principalement

des événements système ou des événements d'applications comme :

• Catégorie « Device » (périphérique) incluant la plate-forme (par exemple, iOS, Android),

type de périphérique (par exemple, iPhone, iPad, iPod ...), modèle de téléphone (par

exemple, iPhone 5, 5s, 6, 6s ...), pays, version de l'application, Datapack ID etc…

• Catégorie « Usage » (utilisation de l’application), comprenant le nombre de lancements

d'applications (total ou par période), date du premier lancement, date du dernier

lancement, etc.

2. A partir de notre Event Tracker : notre Event Tracker vous permet de remonter tout type de

données de votre application sur nos bases de données serveur. Chacun de ces nouveaux

champs de données peut ensuite être utilisé comme critère supplémentaire pour segmenter vos

utilisateurs (cela peut être une ID utilisateur, une information utilisateur telle que le genre, l'âge,

etc. ... ou toute autre donnée ou action de l'utilisateur)


3. Utilisation de segments importés via API ou importation directe. Notre Profile Builder a la

capacité unique de se synchroniser avec des sources de données externes. Il peut se brancher

nativement à des solutions de partenaires tiers telles que des solutions comme FollowAnalytics,

Azure Mobile Engagement ou importer des segments entiers de CRM ou DMP en fonction d'un

identifiant utilisateur unique définie (email, téléphone, ID utilisateur, ID de périphérique ...) qui

peut être adapté à un identifiant collecté via notre suivi d'événements (Event Tracker)

4. Les segments calculés constituent une autre source de segmentation. Ils peuvent être le résultat

d'utilisateurs qui ont été exposés ou qui ont converti sur des variations spécifiques (A / B Testing

ou Personnalisation).

5. Les profils groupés qui peuvent être utilisés pour regrouper ou combiner tout type de profil

existant avec des opérateurs standards tels que AND, OR ou NOT. Cela vous donnera une grande

souplesse dans la manière dont vous souhaitez définir précisément vos profils et les ré-utiliser

dans la plate-forme Azetone.

6. Un profil aléatoire peut également être créé, ce qui permet d’isoler par exemple une population

témoin dont on peut suivre l’utilisation en dehors de toute personnalisation ou test A/B.

Tip: Pour créer un profil avec vos devices de test (smartphones, tablettes…), le plus simple est d’utiliser l’identifiant unique généré par le SDK Azetone sur chaque device sur lequel il est installé. Appelé « Datapack ID », il est accessible directement dans l’application en activant le mode Admin Azetone (via un quintuple double ou triple-tap selon que vous êtes sur iOS ou Android). Le Datapack ID se trouve en haut à droite des boites de dialogue Heatmaps Mode ou Visual Editor Mode et ces ID peuvent être saisis pour constituer un profil de test parmi les critères via la catégorie « Device » puis « Datapack ID »

Ces profils peuvent être définis comme "verrouillés" et rester tels quels avec leurs utilisateurs initiaux

(définir le profil comme "verrouillé") ou évoluer au fil du temps selon si des nouveaux utilisateurs

correspondent ou non aux critères que vous avez définis (profil "automatique").

Notez qu'un profil peut être défini avec plusieurs critères et que chacun de ces critères sera traité par

défaut avec une relation AND (sauf pour les profils groupés).

Tip: A noter que le classement de vos profils a son importance ! Si un utilisateur appartient à des profils différents et s'il est inclus dans un test A/B déclenché sur le profil classé précédemment, il sera automatiquement exclu d'un test A/B appliqué sur un (ou les) profil (s) suivant (s) Chaque nouveau profil créé sera ajouté par défaut à la fin de la liste des profils, mais vous pouvez réorganiser la hiérarchie des profils à volonté en utilisant les flèches haut et bas à droite en face de chaque nom de profil.


Vous pouvez obtenir plus de détails sur la façon dont un profil a été configuré et sur la façon dont il

évolue au fil du temps en cliquant sur l'icône


Analyser l'expérience utilisateur de votre application

Une fois que vous avez créé vos profils, vous pourrez visualiser chaque rapport et cibler toute action

sur le tableau de bord Azetone en fonction de ces segments. Cela vous fournira des informations

uniques sur la façon dont les utilisateurs utilisent réellement votre application et sur comment

améliorer et personnaliser leur expérience utilisateur mobile.

Avec nos rapports d’UX Analytics, vous obtenez une vue très complète de la façon dont les

utilisateurs interagissent avec votre application. Il existe 2 types de rapports que vous pouvez

consulter :


• La vue globale des données fournira des points de données clés sur l'utilisation globale de votre

application par profil utilisateur, par plate-forme, par périphérique, par période et par type de

geste

• Le module Heatmaps (pour iOS ou pour Android selon votre application) affichera visuellement

chaque geste réalisé par les utilisateurs sur chaque vue de votre application. Encore une fois, ces

Heatmaps peuvent être filtrées par de multiples critères pour une meilleure compréhension de

votre expérience utilisateur par profile, par orientation écran ou encore par catégorie de

smartphone

UX Analytics : vue générale des rapports

Dès que le SDK d'Azetone est intégré à votre application, nos serveurs commenceront à collecter

des points de données pour chaque session, chaque vue et chaque geste pour chacun des

utilisateurs de votre application. Un résumé des indicateurs clés sera affiché dès les premiers

tableaux. C'est une excellente façon d'identifier en un coup d'œil comment et où les utilisateurs

interagissent avec votre application.

Les éléments suivants fournissent une meilleure idée de la façon dont les utilisateurs interagissent

avec l’interface utilisateur : quels gestes ils font ou encore le nombre moyen d'interactions par

utilisateur dans chaque profil…

A noter que tous les rapports sont filtrables par plateforme, par mobile, par profil utilisateur, par

récurrence et par date.


Ces tableaux et rapports ne sont qu'une analyse de haut niveau des données recueillies par le SDK

Azetone et juste un aperçu des enseignements qui peuvent être obtenus avec la plate-forme d'Azetone.

Par exemple l’analyse des gestes par pages permet de voir d’un coup d’œil quelles sont les pages les

plus manipulées (par rapport à celle qui sont les plus vues)


La répartition des gestes par page quant à elle permet de détecter simplement des manipulations

inattendues ou erronées

Quant aux analyses de début et de fin de session ou de pages précédentes et suivantes permet de

comprendre en détail le comportement des utilisateurs au sein de l’application, là encore par mobile,

par période, par segment client…


Si vous avez souscrit une licence Enterprise, vous aurez accès à l'ensemble de données UX Analytics

d’Azetone pour vos applications. Azetone et ses partenaires peuvent également vous fournir un rapport

d'Analyse UX Mobile personnalisé en fonction des dimensions et segments dont vous pourriez avoir

besoin.

- Vous pouvez consulter un exemple de rapport ici https://app.powerbi.com/view?r=eyJrIjoiOWE0YTlmMDktODk5Yi00OTc3LWI1NDQtZTAyODhjN2I1

ZGNkIiwidCI6IjQ0ZGYyOTg4LTg4YTgtNDQ4Ni1iMzA4LTEzYjBmNTRlMzY2MCIsImMiOjh9

Pour les conditions générales applicables, contactez votre représentant Azetone ou notre réception

Azetone à l'adresse [email protected]

Affichage de vos Heatmaps (iOS and Android)

Une fois cliqué, une boîte de dialogue permettra d'entrer un mot de passe unique. Ce mot de passe sera

régénéré pour chaque session. Le mot de passe doit être entré sur votre appareil après avoir activé le

mode Heatmaps avec le geste spécial Administrateur d'Azetone. Dès que vous avez réussi à intégrer le

SDK d'Azetone, chacun des gestes de vos utilisateurs sera capturé et stocké sur nos serveurs.

Cependant, pour un rendu de ces résultats, vous devrez activer au moins une fois notre mode

d'administration de Heatmaps. Cela peut être fait en cliquant sur le bouton :

Une fois cliqué, une boîte de dialogue ouvrira l'affichage d'un mot de passe unique. Ce mot de passe

sera régénéré pour chaque session de tableau de bord. Le mot de passe doit être entré sur votre

appareil après avoir activé le mode Heatmaps avec le geste spécial Administrateur d'Azetone (5 double

ou triple « taps » (c.a.d. avec 2 ou 3 doigts) selon que vous êtes respectivement sur iOS ou Android)

https://app.powerbi.com/view?r=eyJrIjoiOWE0YTlmMDktODk5Yi00OTc3LWI1NDQtZTAyODhjN2I1ZGNkIiwidCI6IjQ0ZGYyOTg4LTg4YTgtNDQ4Ni1iMzA4LTEzYjBmNTRlMzY2MCIsImMiOjh9

https://app.powerbi.com/view?r=eyJrIjoiOWE0YTlmMDktODk5Yi00OTc3LWI1NDQtZTAyODhjN2I1ZGNkIiwidCI6IjQ0ZGYyOTg4LTg4YTgtNDQ4Ni1iMzA4LTEzYjBmNTRlMzY2MCIsImMiOjh9

mailto:[email protected]


Sur iOS, le mode Admin est activé mais en tapant 5 fois avec 2 doigts (quintuple double-tap) sur

l'écran de votre application Sur Android, appuyez sur 5 fois avec 3 doigts (et non 2). Assurez-vous de

toucher une partie de l'écran qui n'a pas de bouton ou d'élément actif. Notez que le mode Admin

peut être invoqué n'importe où sur n'importe quelle vue de votre application.

Ce geste spécial va afficher un menu contextuel en bas de l'écran avec 2 options : mode Heatmaps

et mode Visual Editor. Pour ce module, appuyez sur le mode Heatmaps. Entrez le mot de passe

unique présenté dans le tableau de bord dans la boîte de dialogue et appuyez sur "Activer". Une

bordure rouge autour restera visible autour de l'écran de votre application tant que le Mode

Heatmaps est actif. Le mode Heatmaps peut être désactivé en répétant un deuxième fois le geste

administrateur d'Azetone (quintuple double-tap (iOS) ou quituple triple-tap (Android)).

Dès que le mode Heatmaps est activé, une connexion sécurisée entre vers le Dashboard et le SDK

Azetone est établie. Le SDK va d'abord transmettre une liste exhaustive de toutes les vues

disponibles dans votre application. Aucun marquage (tags) ni aucune action n'est nécessaire pour

lancer cette transmission. La liste des vues de l'application apparaîtra en haut de l'écran. Si rien

n'apparaît pas encore, naviguez sur une ou plusieurs vues de votre application. Après quelques

instants sur la vue, une capture d'écran sera automatiquement effectuée et téléchargée vers le

Dashboard. Après avoir parcouru toutes les vues de votre application, vous verrez tous les captures

d'écran sur votre tableau de bord puis chaque type de gestes s'affiche sur les écrans de l'application.

Attendez qu’au minimum quelques centaines de gestes soient collectés avant qu'une image claire

des interactions ne soit visible.

Chaque Heatmap (carte de chaleur) pour chaque vue de l'application peut être filtrée :

• par profil (en utilisant les profils définis dans le Générateur de profil),

• par orientation (Portrait ou Paysage)

• par date (prédéfinie -7 ou 30 jours- ou période personnalisée)

• par famille de périphériques (smartphone / tablette)

• et par type de geste


Tip: Les cartes de chaleurs sont le mieux représentées lorsqu'elles sont agrégées en au moins centaines, milliers ou millions de gestes. Si le nombre total de gestes présenté est trop faible, n'hésitez pas à ajuster vos filtres pour visualiser un nombre plus important d’interactions.


Optimisez votre Appli avec l’A/B Testing

Une fois que vous avez installé le SDK d'Azetone et que vous avez créé vos profils dans notre Profile

Builder (facultatif), vous êtes prêt à créer et déployer vos premiers tests A/B ! Si vous ne savez pas par

où commencer, nous vous recommandons de regarder vos Heatmaps pour évaluer quelles parties de

votre application sont souvent utilisées ou sous-utilisées et où vos utilisateurs peuvent être en difficulté

avec votre interface utilisateur. Lorsque vous êtes prêt à créer votre premier test A / B, vous avez 2

façons de faire :

• Utilisation de notre mode Visual A / B Testing : C'est de loin le moyen le plus simple de créer

une variante pour votre application. Il vous permet de modifier quasiment n'importe quelle

propriété de n'importe quel élément de l'interface utilisateur de votre application en

cliquant simplement sur notre Visual Editor. Il s'agit d'un excellent moyen de modifier à tout

moment un élément UI de votre application et ne nécessite aucun tagging préalable de

votre application avant sa soumission au store.

• Utilisation de notre mode de test A / B universel: c'est la manière la plus avancée de créer

des variantes pour votre application et cela vous permettra d'approfondir l'évolution des

éléments d'interface utilisateur. Il peut aller jusqu'à l'activation ou la désactivation de blocs

de code, de modules ou même de fonctionnalités complètes de l'application. Ce mode

nécessite un marquage (taggage) des propriétés des éléments que vous souhaitez contrôler

via le Dashboard, ce qui sera habituellement mis en place par un développeur. Une fois que

ces balises sont configurées, ce mode peut être utilisé aussi bien par les développeurs ou

que par des spécialistes du marketing.

Visual A/B Testing

Après avoir sélectionné les Visual A / B Testing dans la barre de menu de gauche, vous pourrez créer un

nouveau test A / B en utilisant notre Visual Editor pour iOS ou pour Android en fonction de la plate-

forme sur laquelle vous souhaitez travailler. Vous verrez également une liste de tous les tests actifs ou

déployés ainsi que des tests encore en mode brouillon (non encore terminés) ou en cours de

publication.

Cliquez sur Nouveau test A/B visuel (iOS ou Android) pour commencer à créer un nouveau test A / B .


Initialiser le mode Visual Editor Tout comme avec notre mode Heatmaps, cliquez sur Activer le mode Visual Editor pour créer vos

variantes d'application. Une boîte de dialogue ouvrira l'affichage d'un mot de passe unique. Ce mot de

passe sera généré à nouveau lors de chaque session de l’éditeur visuel. Ce mot de passe doit être entré

sur votre appareil après avoir activé le mode Visual Editor avec le geste administratif spécial d'Azetone.

Sur votre appareil, le mode Admin est activé en tapant sur l'écran de votre application 5 fois avec 2

doigts (quintuple double-tap) sur iOS ou 5 fois avec 3 doigts (quintuple triple-tap) sur Android. Assurez-


vous de toucher une partie de l'écran qui n'a pas de bouton ou d'élément actif. Notez que le mode

Admin peut être invoqué n'importe où sur n'importe quelle vue de votre application.

Ce geste spécial présentera un menu contextuel en bas de l'écran avec 2 options: mode Heatmaps et

mode Visual Editor. Pour ce module, appuyez sur le mode Visual Editor. Entrez le mot de passe unique

présenté dans le tableau de bord dans la boîte de dialogue et appuyez sur "Activer". Une bordure bleue

autour de l'écran de votre application reste activée tant que Visual Editor Mode est actif. Le mode

Editeur Visual peut être désactivé en répétant le geste administratif d'Azetone (quintuple double ou

triple-tap).

Tip: Nous avons choisi d'activer un système de communication hautement sécurisé entre votre application et notre tableau de bord en mode Admin afin d'éviter tout risque d'activité frauduleuse avec votre application. La communication en mode Admin se produit via une connexion Web sécurisée à l'aide d'un port spécial (8081 pour iOS et 8082 pour Android). Dans certains cas, l'utilisation de notre Visual Editor dans un environnement d'entreprise (derrière un pare-feu) peut ne pas fonctionner car votre politique de sécurité n'a pas ouvert l’accès ces ports. Il vous faudra alors contacter votre administrateur réseau pour ouvrir ce port ou utiliser un réseau ouvert (non filtré par un pare-feu) pour connecter notre Visual Editor à votre appareil.

Création de variantes d’un test A/B Dès que le Mode Visual Editor est activé dans l'application, le tableau de bord reconnaît la

communication avec l'application via le SDK d'Azetone en indiquant "Appareil connecté : 1" en haut à

droite du tableau de bord. Peu de temps après, l'écran sera grisé et la page active de l'application sera

affichée dans le tableau de bord. La première partie qui est collectée est l'arborescence de tous les

éléments présents dans la page ou la vue de l'application. Il apparaît à gauche de l'écran et un aperçu

complet de la page de l'application est affichée au centre de l'écran.

Une fois que vous avez terminé, tout élément de la page peut être sélectionné soit via l'arborescence

des éléments, soit directement en plaçant la souris sur n'importe quel élément de l'interface utilisateur

de l'application. Pour chaque élément, les propriétés applicables seront affichées à droite de l'écran dès

que l’élément est sélectionné. Assurez-vous de cliquer sur "désélectionner" ou cliquer à nouveau sur le

même élément avant d'essayer de sélectionner un autre élément.

Pour créer une variante, modifiez simplement les propriétés de l'élément sélectionné et cliquez sur

"OK". Si le bouton "OK" est grisé, cela signifie que cette modification n'est pas possible en ce moment,

généralement parce qu'un test A / B est déjà en cours d'exécution sur cette propriété. Une variante peut

consister en autant de mises à jour que vous souhaitez sur n'importe quelle propriété disponible d'un

élément sur une page donnée. Vous verrez les différentes mises à jour que vous créez s’incrémenter

dans le coin supérieur droit de l'écran. Si vous souhaitez supprimer une mise à jour spécifique de votre

variante, cliquez simplement sur le "x" rouge à côté de celui-ci dans la liste "Mises à jour en cours". Une


fois qu'une variante est terminée, cliquez sur Enregistrer. Pour créer une autre variante, revenez au

Visual Editor et à l'arborescence pour sélectionner et modifier toute propriété.

Tip: Avec les versions 4.1 et ultérieures de nos SDK, les positions (coordonnées X et Y) et les tailles (Hauteur et Largeur) peuvent être éditées directement à partir du Visual Editor. Nous vous recommandons de tester vos changements de taille et de position sur différentes tailles d'écran avant de déployer une variation sur un grand nombre d'appareils. Si votre application utilise la mise en page automatique (auto-layout), nous avons choisi de ne pas passer outre le repositionnement automatique des objets sur la page pour éviter tout conflit de mise en page. Dans ce cas, nous recommandons de demander à un développeur d’utiliser notre mode de test Universal A / B pour ajuster les tailles et les positions

Vous pouvez créer jusqu'à 8 variantes différentes à tester. Une fois que toutes vos variantes sont prêtes,

vous pouvez les consulter et cliquer sur « Enregistrer et affecter des objectifs » pour passer à l'étape

suivante.

Définition des objectifs de conversion La page Visual Editor suivante vous permettra de sélectionner une conversion. Par défaut, la conversion

est définie comme un clic sur n'importe quel bouton sur n'importe quelle page de votre application.

Pour accéder au bouton approprié, naviguez simplement dans votre application à la page appropriée et

sélectionnez votre action de conversion préférée. Une fois terminé, cliquez sur "Enregistrer", puis

"Enregistrer les objectifs et déployer"


Vous allez ensuite accéder à une nouvelle page vous permettant de décrire et de programmer votre

expérience de test A / B.

Configuration des paramètres de l'expérience Cette page révèle certaines fonctionnalités uniques de la solution d'Azetone.

D'abord sur la population cible, vous avez 2 niveaux de sélection :

La première consiste à choisir le profil sur lequel vous souhaitez concentrer votre test A / B. Il existe de

nombreux avantages à exécuter votre test A / B sur un profil de client homogène.

• Tout d'abord, la conception d'une variante pour un profil de client spécifique améliorera vos

chances d'avoir un impact réel sur les conversions.

• Ensuite, en exécutant ce test A / B sur une population donnée, vous augmenterez vos

espérances d’augmentations de conversions et vous réduirez le temps nécessaire pour identifier

quelle variante surperforme de manière fiable par rapport aux autres.

• Et enfin, vous voudrez peut-être répéter le même test ou un test similaire sur vos autres profils

de clients et vous découvrirez que chacun de vos profils de clients pertinents conduira (très

souvent) à différents résultats de performance.

Deuxièmement, le déploiement de chaque variante peut être géré en fonction de vos objectifs

d'expérience utilisateur. Une variante peut être affichée dans votre application soit immédiatement

après avoir recueilli tous ses éléments ou propriétés nécessaires (donc dès que possible) soit en

conservant l’intégrité de l’expérience utilisateur au cours d’une session (c’est-à-dire uniquement à la

session suivante).

Le cas d'utilisation de ces contrôles est le suivant :

- Si votre variante est suffisamment "limitée", vous accepterez de sacrifier la cohérence de l'expérience

utilisateur au cours d'une session pour afficher votre variante dès que possible car elle ne dérangera pas


vraiment l'utilisateur. De même, si vos utilisateurs n'ouvrent pas très fréquemment votre application,

vous ne souhaiterez pas retarder l’apparition d’une variante à une prochaine session. Dans ces cas,

sélectionnez « dans les plus brefs délais »

- Inversement, si votre variante est visuellement radicalement différente de l'original et que vous ne

souhaitez pas perturber votre expérience d'utilisateur mobile, vous donnerez la priorité à la cohérence

de la session et choisirez l'apparence de la variante "uniquement lors de l'activation suivante"

Déploiement de votre expérience L'écran final avant de publier votre expérience aux utilisateurs résume les éléments clés de votre test A /

B : quels utilisateurs ciblez-vous, le nombre estimé de jours qu'il faudra pour que votre test soit terminé

et un aperçu des variations attribuées aux différents utilisateurs.

En cliquant sur Publier, l'expérience sera envoyée au serveur pour le traitement. L'expérience sera

publiée comme étant « en cours de traitement » pour une courte durée. Après quelques minutes dès

que nos serveurs auront préparé l'expérience et alloué les variantes, l'expérience sera automatiquement

déplacée vers la section « Tests actifs »


Rapports Pour chaque test A / B, vous avez accès à un rapport complet qui vous fournit des informations

instantanées sur la performance de vos différentes variantes. Pas besoin d'être un expert pour

comprendre ces rapports. Les variations (chacune avec un aperçu miniature zoomable) afficheront le

nombre d'utilisateurs, les vues et les conversions enregistrées par le SDK Azetone. Les taux de

conversion seront automatiquement calculés ainsi que la probabilité pour toute variation de battre

l'original.

Vous pouvez décider de déployer une variation à tous vos utilisateurs à n'importe quel moment, mais si

les pourcentages ne sont pas significatifs (plus de 95% de chance de faire mieux que l’original), attendez

que le champ "Chance" devienne vert. Cela signifie que vous avez une très haute certitude statistique

que cette variation est le meilleur choix pour une population donnée (seuil de 95% au test du Chi 2 pour

les statisticiens parmi vous !). Le déploiement d'une variation pour tous les utilisateurs ciblés est aussi

simple qu'un clic sur le bouton "Utiliser la variation" – ou bien "garder la variation A" dans le cas où la

vue par défaut (c.a.d. la variation A ou les valeurs par défaut que vous avez codées dans votre App)

surpasse toute vos tentatives de variantes.


Vous trouverez également sous ce tableau une analyse de performance comparative des variations au fil

du temps pour chaque variante.

Test A / B universel

L’Universal A / B Testing peut être parfois perçu comme plus rudimentaire, mais il est en même temps

plus puissant que le Visual A / B Testing. Bien que le test A / B visuel soit très simple pour changer

n'importe quel élément UI et bien qu’il ne requiert aucune préparation préalable, le test A / B universel

(même s’il nécessitera une certaine préparation) permet de modifier de façon significative la mise en

page, l'ergonomie, les fonctionnalités de votre application et même l'activation ou la désactivation de

parties entières de code dans votre application.

Dans la phase de préparation initiale un marquage (plan de taggage) sera nécessaire pour pouvoir

contrôler n'importe quel élément donné à partir du tableau de bord, et un développeur ou une

personne très compétente sur le plan technique sera requis pour effectuer les tâches nécessaires. Une

fois que les tags sont placées, un personne sans compétences technique particulière peut prendre en

charge et utiliser le module de test Universal A / B, mais ce module nécessitera toujours une solide

compréhension des implications des modification de chaque tag pour l'application permettant de jouer

avec des mises en page, des blocs de codes, etc.


Créer une nouvelle expérience La création d'un nouveau test universel A / B est assez semblable à la façon dont vous définissez les

paramètres de l'expérience dans le mode Visual A / B testing. La principale différence est que tout tag

qui a été inséré dans l'application avant compilation apparaîtra automatiquement dans la liste

déroulante "Tags disponibles". Cette liste est dynamique et évoluera lorsque vous affectez le test A / B à

n'importe quelle étiquette donnée. Afin d'éviter les conflits, toute tag inclus dans un test actif sera

automatiquement exclu de la liste des prochains "tags disponibles".

Dans la section Population cible, vous avez 2 niveaux de sélection : le premier permet notamment de

choisir le profil sur lequel vous souhaitez concentrer votre test A / B. Il existe de nombreux avantages à

exécuter votre test A / B sur un profil de client homogène.

• Tout d'abord, la conception d'une variante pour un profil de client spécifique améliorera vos

chances d'avoir un impact réel sur les conversions.


• Ensuite, en exécutant ce test A / B sur une population donnée, vous augmenterez vos

espérances d’augmentations de conversions et vous réduirez le temps nécessaire pour identifier

quelle variante surperforme de manière fiable par rapport aux autres.

• Et enfin, vous voudrez peut-être répéter le même test ou un test similaire sur vos autres profils

de clients et vous découvrirez que chacun de vos profils de clients pertinents conduira (très

souvent) à différents résultats de performance.

Dans la section "Variations", vous pouvez créer jusqu'à 8 variations pour chaque élément et sélectionner

le type de propriété que vous souhaitez contrôler. Il existe 4 catégories principales : Texte (avec un

champ de texte libre), couleur (avec un sélecteur de couleur), image (avec un uploadeur d'images) et un

champ personnalisé (pour passer n'importe quel paramètre prédéfini directement à votre Application).

Ce dernier sera utilisé par exemple pour passer des coordonnées X-Y, des tailles, des entiers ou des

déclencheurs pour activer ou désactiver des blocs de code, etc.

Rapport de test A / B universel Une fois l'expérience publiée, les résultats du test A / B peuvent être vérifiés en cliquant sur le bouton

d'action du test actif approprié. Le rapport comprendra le nombre d'utilisateurs, les vues et les

conversions enregistrées par le SDK Azetone. Les taux de conversion seront automatiquement calculés

ainsi que la possibilité pour toute variation de faire mieux que l'original.

Vous pouvez décider de déployer une variation à tous vos utilisateurs à n'importe quel moment, mais si

les pourcentages ne sont pas significatifs (plus de 95% de chance de faire mieux que l’original), attendez

que le champ "Chance" devienne vert. Cela signifie que vous avez une très haute certitude statistique

que cette variation est le meilleur choix pour une population donnée (seuil de 95% au test du Chi 2 pour

les statisticiens parmi vous !). Le déploiement d'une variation pour tous les utilisateurs ciblés est aussi

simple qu'un clic sur le bouton "Utiliser la variation" – ou bien "garder la variation A" dans le cas où la

vue par défaut (c.a.d. la variation A ou les valeurs par défaut que vous avez codées dans votre App)

surpasse toute vos tentatives de variantes.


Création d'un test groupé (test multi-varié) Par défaut, le test A / B dans l’Universal A / B Testing gère une propriété unique à la fois. Cependant, il

est possible de regrouper jusqu'à 4 propriétés différentes et ce avec 8 différentes variantes chacune en

créant un test groupé (multi-varié) où des variations multiples mais coordonnées sont créées et

déployées dans votre application.

Les groupes de variations sont créés par simple glisser-déposer vous pouvez assembler les différentes

propriétés pour former uniquement des scénarios cohérents pour vos utilisateurs.


Un testé groupé peut ensuite être déployée de manière similaire à d'autres tests A / B visuels ou

universels en tirant parti du Profile Builder Azetone.


De même, les rapports, les contrôles et les options de déploiement sont semblables à ceux trouvés dans

les rapports de Universal A / B testing traditionnels.


Avec la personnalisation, optimisez la pertinence et l’efficacité de votre

appli pour vos utilisateurs

Après avoir exécuté des tests A / B similaires sur différents segments d'utilisateurs, vous verrez

rapidement que tous vos clients ne réagissent pas de la même manière à vos variantes. Vous réaliserez

même que certaines variantes fonctionnent bien avec un segment avec d'autres variantes qui

fonctionnent beaucoup mieux avec d'autres. A partir de ce constat, vous allez faire vos premiers pas

vers une expérience utilisateur vraiment personnalisée.

Avec la personnalisation de l'application, nous utilisons des blocs de construction similaires aux tests A /

B mais avec une approche et des objectifs tout à fait différents.

Tout d'abord, l'idée de la personnalisation de l'application doit être jugée au niveau de l'application bien

plus qu'au niveau de l'objet ou de la page. Cela signifie au-delà de la visualisation ou de la conversion sur

un élément spécifique, les indicateurs de performance de personnalisation d'une application doivent

être définis au niveau de l'application et c'est là que l’UX Analytics peut aider à déterminer si la

personnalisation produit un impact et des performances réelles sur la rétention, l'attrition,

l'engagement, la satisfaction de vos utilisateurs...

Au global, tout comme pour l’Universal A / B testing, nous avons 2 modules de personnalisation :

Universel et Universel groupé

Personnalisation universelle Avec la Personnalisation universelle, vous utiliserez un tag placée dans le code (le plus souvent une

balise personnalisée pour activer un bloc ou une fonction de code) et vous attribuez différentes valeurs

à cette expérience

L'une des principales différences avec les tests A / B est que vous attribuerez un profil (à partir de vos

segments existants du Profile Builder) directement à chaque variation. Vous pouvez déployer jusqu'à 20

variantes différentes d’un tag à 20 profils différents.

Le déploiement et le suivi sont semblables aux tests A / B et les rapports offriront une analyse de chaque

vue de la personnalisation et, le cas échéant, d'une conversion associée !


Personnalisation groupée La personnalisation groupée permet un scénario de personnalisation plus complexe et plus flexible. Cela

vous permettra, par exemple, de personnaliser à la volée des blocs entiers ou des parcours complets

dans votre application en modifiant de manière synchronisée le texte, la couleur, l'image et les

fonctionnalités derrière un bloc (ou un bouton) en une seule fois. Cela peut également être utilisé pour

personnaliser un funnel complet d'acquisition ou de conversion multi-étapes basé sur les profils

utilisateur.

Vous pouvez déployer pour une combinaison de tag jusqu'à 30 combinaisons de variantes différentes à

30 profils différents !


Q&R

Comment Azetone influe-t-il sur la performance de mon application? La performance et la stabilité de notre SDK ont toujours été nos principales priorités, car nous estimons

que vous ne devriez accepter aucun compromis dans l'expérience utilisateur lors de l'utilisation d’un

solution de Mobile UX Analytics, d’A / B Testing ou de Personnalisation. Nous avons fait un très grand

nombre de tests et d'optimisation et nous pouvons garantir que notre SDK aura un impact absolument

imperceptible sur vos utilisateurs. Demandez-nous des benchmarks et des témoignages clients!

Comment Azetone affecte-t-il la mémoire de l'appareil, le réseau et l'utilisation de la

batterie ? Nous avons choisi les meilleures technologies et les meilleurs développeurs pour vous proposer un SDK

avec l'empreinte mémoire la plus basse dans sa catégorie ! D’ailleurs, 100% de notre SDK a été

développé en interne sans inclure ni librairie ou ni routine tierce. En ce qui concerne le réseau et la

batterie, notre SDK communique avec nos serveurs avec des échanges super optimisés (seulement

quelques Ko) et vous avez la possibilité de moduler la fréquence des échanges entre les applications et

nos serveurs à partir d'un appel tous les 15 Minutes pour un appel jusqu’à toutes les 15 heures. Et ces

communications ne nécessitent pas que l'application soit active au premier plan.

Comment vos serveurs fonctionnent-ils lorsqu'ils font face à des pics d’utilisation ? Nos serveurs sont configurés avec une redondance complète et avec une architecture à 3 niveaux qui

permet d'absorber tout type de pic de charge. En outre, nous sommes hébergés sur Azure ce qui nous

permet de déployer instantanément de nouveaux serveurs au niveau du pays et de la région concernée,

au plus près de nos utilisateurs finaux pour un meilleur temps de réponse.

Que se passe-t-il si les serveurs Azetone subissent une panne ? Dans le cas très improbable de l'indisponibilité de notre architecture de serveur redondante à 3 niveaux,

vos campagnes d'analyse, de personnalisation et d'analyse UX existantes continuent sans être affectées.

Comme notre architecture globale permet à notre SDK de fonctionner en mode complètement

autonome (tout comme quand un utilisateur final est temporairement hors réseau), nos serveurs

peuvent être inaccessibles pour une période de temps et notre SDK conservera les variations et

collectera les données d'utilisation comme d'habitude. A la prochaine connexion disponible avec nos

serveurs, l'historique d'utilisation sera simplement reconstruit comme si rien ne s’était passé.


Quelle est la sécurité des transmissions entre Azetone et les Applis ? Nous avons à cœur de garantir au maximum la sécurité et la confidentialité des données de nos clients.

Les communications entre nos SDK et nos serveurs sont cryptées en SSL avec une clé unique par

application. Nous activons également un canal de communication Web sécurisé lors de l'activation de

notre Visual Editor. En outre, cette session d'édition visuelle est sécurisée via un mot de passe de

session unique qui garantit que seul un administrateur certifié peut créer une variation d'application.

Comment garantissez-vous la confidentialité des utilisateurs finaux ? Par défaut, nous ne collectons aucune information identifiable spécifique à l’utilisateur final. Nous

créons notre propre identifiant unique exclusif pour chaque périphérique connecté à nos serveurs et ne

conserverons que les informations que vous allez décider d'entrer dans nos systèmes.

Par exemple, vous utiliserez peut-être notre « event tracker » pour collecter des informations de votre

application afin de créer des profils utilisateur. Cela pourrait être une information identifiable par le

client (numéro de client, numéro de tel. Email…), mais vous pouvez utiliser un cryptage unidirectionnel

de ces données et de l'associer à des données chiffrées similaires en provenance de vos propres

systèmes CRM ou DMP. Cela vous permet de créer des segments de clients pleinement opérationnels

sans aucune donnée utilisateur identifiable dans nos systèmes !

documentation azetone v5...page 2 sur 36 © azetone 2017 azetone dashboard v5 bienvenue sur azetone...

Documents