Mobile APP
Introduction au taggage d'applications mobiles
CommandersAct’s SDK vous permet de déclencher des destinations depuis une application mobile.
Commanders Act propose un SDK dit « super light » que vous pouvez inclure dans le code de votre application mobile ; son objectif est de réduire les appels aux solutions partenaires autant que possible afin d'améliorer les performances de votre application et l'expérience utilisateur. Un appel unique est envoyé aux serveurs de Commanders Act par action enregistrée dans l'application. Les informations relatives à la page consultée ou à l'élément cliqué sont ensuite envoyées séparément aux solutions partenaires par les serveurs de Commanders Act ; cela permet d'éviter de ralentir la vitesse de chargement des applications.
Remarque: Toutes les solutions ne sont pas compatibles avec cette méthode. Puisque le light SDK envoie les informations de l'application aux serveurs des solutions partenaires, elles ne peuvent pas « revenir » vers l'application. Les solutions d'adserving (celles affichant des publicités) et les fournisseurs de notifications push ne sont donc pas compatibles avec cette méthode.
Le principe de fonctionnement de base du light SDK de Commanders est :
– Étape 1: la data layer mobile et le SDK de CommandersAct sont appelés dans le code source de l'application chaque fois que l'écran se charge ou qu'un élément est cliqué. (votre équipe IT doit avoir mis cela en place au début du projet).
– Étape 2: le SDK de CommandersAct émet des appels vers les serveurs de CommandersAct et envoie automatiquement le contenu de la data layer mobile. Voici la structure des hits server-side : https://collect.commander1.com/events?tc_s=${siteID}&token=${YOUR_SOURCE_KEY}
${siteID} et ${YOUR_SOURCE_KEY} doivent être fournis au SDK et seront remplacés automatiquement.
Le reste des paramètres est envoyé dans le corps en POST comme présenté ici :
Spécificité des events Mobile App– Étape 3: Les serveurs de CommandersAct envoient les informations reçues vers les différentes destinations. Il y a autant de hits sortants qu'il y a de solutions partenaires auxquelles vous souhaitez transmettre des informations.
Ex : si vous souhaitez émettre un appel à la fois vers Criteo et Google, un hit sera envoyé aux serveurs de chaque solution.
L'implémentation de nos SDKs sur une application mobile est un projet qui se compose des étapes listées ci-dessous :
Définition du plan de taggage de l'application mobile : sélection et définition des événements.
Création d'une source mobile et des destinations
Implémentation du SDK CommandersAct dans le code source de l'application.
Tests d'acceptation de l'implémentation dans un environnement de test.
Publication
Étape n°1 : définition du plan de taggage de l'application
Le plan de taggage correspond à la liste des événements qui seront envoyés.
Étape n°2 : création d'une source mobile et configuration des destinations dans l'interface CommandersAct
Création d'une source pour iOS, Android ou les deux.
Implémenter ou sélectionner des destinations.
L'implémentation d'une destination mobile est la même que celle d'une destination cloud-base
Étape n°3 : implémentation du SDK dans le code source des applications
L'implémentation du SDK est réalisée par du personnel technique ou des départements IT.
Ces éléments doivent être fournis :
Le plan de taggage CommandersAct de l'application, qui permet à l'équipe IT de savoir quels événements déclarer et sur quels écrans ou éléments.
Documentation technique se référant à chaque application. Elle doit contenir des éléments clés pour configurer le SDK et des captures d'écran d'exemples de configuration.
Cliquez ici pour lire la documentation technique correspondante. iOS : https://github.com/CommandersAct/iOSV5/ android : https://github.com/CommandersAct/androidv5/
L'ID du site (numéro de compte Commanders Act) et celui de la source key sont nécessaires pour configurer le SDK. Ces deux éléments peuvent être récupérés dans l'interface.
Étape n°4 : Tester la configuration dans un environnement de test
Le SDK Commanders Act peut être testé avec de nombreux outils différents :
Tests pour iOS avec XCode
Le SDK Commanders Act pour iOS peut être testé avec le logiciel de développement d'Apple « XCode » :
https://itunes.apple.com/fr/app/xcode/id497799835
Vous devrez connecter votre iPhone à votre Mac.
Ouvrez XCode, allez dans “Window” ), > “Devices” (2), puis sélectionnez votre appareil dans la colonne de gauche (3) :
Ces éléments seront affichés lorsque vous analyserez les logs mobiles :
Numéro de version du SDK Commanders Act exemple pour le module de consentement : « Commanders Act Privacy module init with version: 5.2.0 »
ID du site Commanders Act
Événements Server-Side envoyés contenant toutes les propriétés que vous avez envoyées aux serveurs de Commanders Act (méthode POST). Pour plus d'informations sur la construction des events, vous pouvez vous référer à notre exemples de codes d'événements
***
Exécuter des tests pour Android ou iOS avec Charles Debugger
Le SDK Commanders Act pour les systèmes iOS et Android peut être testé avec le proxy “Charles Debugger”, téléchargeable gratuitement ici : https://www.charlesproxy.com/
La première chose à faire est de configurer votre téléphone afin qu'il puisse communiquer avec Charles.
Dans les paramètres de votre téléphone, allez dans l'onglet de configuration du Wi‑fi.
Sélectionnez votre réseau et accédez aux options avancées pour modifier les paramètres Wi‑fi.
Ajoutez un proxy manuellement :
Nom du proxy (serveur)(1) : IP de l'ordinateur (vous pouvez la trouver dans l'onglet « Local IP address » des options de Charles)
Port (2) : 8888
Enregistrer.
Allez dans l'application Charles et autorisez-la à se connecter au téléphone.
Naviguez sur le web avec votre téléphone et dans Charles (sur votre ordinateur) appliquez un filtre “Commander” pour voir les hits server-side affichés dans la section « Overview ». Ils ressemblent à ceci : https://collect.commander1.com/events?tc_s=XXXX&token=XYZZ
Lorsque vous allez dans la zone “Request”, vous pourrez voir toutes les variables et les valeurs correspondantes qui sont envoyées via le SDK Commanders Act.
Protocole HTTPS :
La plupart du temps, les appels server-side sont effectués via un protocole https.
Voir les hits https avec Charles nécessite une configuration plus complexe. Vous devrez ouvrir le navigateur de votre téléphone pendant que Charles tourne sur votre ordinateur et aller à cette URL depuis votre téléphone http://www.charlesproxy.com/getssl/
Téléchargez le certificat et installez‑le ; vous devrez entrer son nom pour deux applications « VPN and applications » et « Wi‑fi ».
Retournez dans Charles > “SSL proxy settings” > “SSL Proxying” > cochez « Enable SSL Proxying » > Cliquez sur « Add » et tapez « * » dans le champ « Host » (pour autoriser n'importe quel hôte).
Procédez ensuite aux tests de la même manière que pour les hits http.
Étape n°5 : publication
Lorsque l'implémentation est correcte dans votre environnement de test, vous devez soumettre votre application aux app stores (Apple Store ou Android Market) et attendre qu'ils approuvent les modifications et intègrent la nouvelle version dans leurs catalogues.
Mis à jour
Ce contenu vous a-t-il été utile ?