Mobile APP
Introduction au tagging d'application mobile
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 au maximum les appels vers les solutions partenaires afin d'améliorer les performances de votre application et l'expérience utilisateur. Un appel unique est émis vers les serveurs de Commanders Act pour chaque action enregistrée dans l'application. Les informations liées à 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 un ralentissement du temps de chargement des applications.
Remarque : Toutes les solutions ne sont pas compatibles avec cette méthode. Comme 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 annonces) 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 à chaque clic sur un élément. (votre équipe IT devrait avoir implémenté cela 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 body en POST comme présenté ici :
Spécificité des événements Mobile App– Étape 3 : les serveurs de CommandersAct envoient les informations reçues aux différentes destinations. Il y a autant de hits sortants qu'il y a de solutions partenaires vers lesquelles 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 chacune des solutions.
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 tagging 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 tagging de l'application
Le plan de tagging 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 des destinations mobiles est la même que celle 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 du personnel technique ou des départements IT.
Ces éléments doivent être fournis :
Le plan de tagging CommandersAct de l'application, qui indique à l'équipe IT quels événements déclarer et sur quels écrans ou éléments.
Documentation technique se rapportant à 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 : test de la configuration dans un environnement de test
Le SDK Commanders Act peut être testé avec différents 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 à gauche (3) :
Ces éléments s'afficheront 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 events, vous pouvez vous référer à notre exemples de codes d'events
***
Exécution de 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 procédez aux options avancées pour éditer 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 sur 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 apps” 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 sur votre environnement de test, vous devez soumettre votre application aux app stores (Apple Store ou Android Market) et attendre leur approbation des changements afin qu'ils incluent la nouvelle version dans leurs catalogues.
Mis à jour
Ce contenu vous a-t-il été utile ?