Application mobile
Introduction au taggage des 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 autant que possible les appels vers les solutions partenaires afin d'améliorer les performances et l'expérience utilisateur de votre application. Un appel unique est émis vers les 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. Étant donné que le light SDK envoie les informations de l'application vers les serveurs des solutions partenaires, celles-ci 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 opérationnel 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 chargement d'écran ou lorsqu'un élément est cliqué. (vos équipes IT doivent avoir mis cela en place au début du projet).
– Étape 2: le SDK de CommandersAct effectue 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 événements Mobile App– Étape 3: Les serveurs de CommandersAct transmettent l'information reçue aux différentes destinations. Il y a autant de hits sortants qu'il y a de solutions partenaires auxquelles vous souhaitez envoyer 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 dans une application mobile est un projet qui consiste en les é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.
Implémenter une destination mobile est la même chose qu'implémenter des destinations cloud-based
Étape n°3 : implémentation du SDK dans le code source des applications
L'implémentation du SDK est réalisée par des équipes techniques ou des services IT.
Ces éléments doivent être fournis :
Le plan de taggage CommandersAct de l'application, qui indique aux équipes IT 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 la configuration du 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 : tests de la configuration dans un environnement de test
Le SDK Commanders Act peut être testé avec de nombreux outils :
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
Server-Side events 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 événements, vous pouvez vous référer à notre exemples de codes d'événements
***
Exécution de tests pour Android ou iOS avec Charles Debugger
Le SDK Commanders Act pour les systèmes d'exploitation 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 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
Enregistrez.
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 saisir son nom pour deux usages « 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).
Ensuite procédez 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 ?