Mobile push

L’intégration de Mobile push permet d’envoyer des messages push (Notifications mobile) à des appareils mobiles à partir d’un Journey. Les données relatives à l’interaction du contact avec ces notifications peuvent être recueillies et utilisées pour faire avancer le contact dans le Journey ou l’inciter à exécuter une action précise.

Intégrez facilement notre SDK à votre application mobile pour diffuser des notifications push et des messages in-app qui suscitent un fort engagement de la part des utilisateurs grâce à nos fonctions avancées de personnalisation omnicanale.

Les notifications push servent à tenir les utilisateurs informés en leur communiquant des informations pertinentes ou des actualités importantes au moment où elles apparaissent à l’écran. Peu importe si l’application est exécutée en arrière plan ou inactive : les notifications push veillent à ce que le contenu en question soit affiché instantanément ; l’utilisateur prend ainsi de la valeur et vous obrenez des possibilités de conversion.

De plus, des messages In-app sont envoyés aux contacts qui utilisent actuellement l'application sans avoir besoin de donner leur autorisation. Les messages In-app peuvent être utilisés à la place des notifications Push pour les contacts qui les ont désactivés.

 

Comment fonctionne Selligent Mobile Push ?  

Le contact installe l’application du client. Lorsque le contact lance l’application, des données concernant l’appareil (token, ID de l’appareil, plate-forme, etc.) sont envoyées et enregistrées dans une liste d'audience Selligent dédiée. Lorsqu'un contact s'enregistre, une fiche est créée dans une liste d’audiences liée. Naturellement, un contrôle est effectué afin de vérifier si l’appareil existe déjà dans la table Appareils. Si c'est le cas, il ne se passe rien à part la mise à jour du champ lastmodified_dt.

Lorsque le contact se connecte à l’application, la liste d’audiences liée peut être mise à jour avec des informations supplémentaires, notamment l’e-mail, la langue, le sexe, etc. Le contact est maintenant un contact connu. En outre, le fait qu’un contact se soit connecté/déconnecté ou inscrit/désinscrit est également enregistré dans la table Appareils.

Que se passe-t-il si plusieurs contacts utilisent le même appareil ? Dans ce cas, si un contact se connecte, l’appareil sera lié à sa fiche. Si un deuxième contact lance l’application et se connecte, l’appareil sera lié à la fiche de ce deuxième contact.

À partir de là (lorsque le contact a installé l’application et existe dans Selligent Campaign), des notifications push peuvent être envoyées aux contacts connus et anonymes. Un composant Push dédié est disponible dans le Journey pour permettre d'envoyer des notifications Push ainsi que des messages In-app.

Lorsque le message est reçu, ouvert ou lorsque le contact clique sur un bouton, ces informations sont utilisées dans le Journey Selligent (ou peuvent l’être). Il est possible, en outre, d’utiliser des événements personnalisés avec des paramètres personnalisés, et d’enregistrer et d’utiliser également ces informations dans une table des événements de Selligent Campaign.

 

Push Notification vs Messages in-app

Comme indiqué dans l'introduction, Selligent offre la possibilité d'envoyer des notifications Push ou des messages In-app. Mais quelle est la différence entre les deux ?

Les notifications Push sont des messages envoyés aux utilisateurs de l'application même s'ils ne l'utilisent pas actuellement. Ils doivent donner l'autorisation de recevoir des notifications Push, dite Opt-in. Les messages In-app sont envoyés lorsque les utilisateurs de l'application sont dans l'application, et aucune autorisation Opt-in spécifique n'est requise.

La solution mobile Selligent offre la possibilité d'utiliser ces deux types de messages ainsi qu'un seul et même composant dans le Journey pour les envoyer. Par conséquent, vous ne devez configurer le composant qu'une seule fois. Vous pouvez choisir d'envoyer une Notification push, un Notification in-app ou, si l'appareil est désactivé pour les notifications Push, un Notification in-app.

La façon dont les notifications Push et les messages In-app sont envoyés diffère légèrement.

Les notifications Push sont poussées vers les services Selligent et, de là, envoyées aux services Android ou IOS chargés de les envoyer aux appareils. Cette opération s'effectue en temps réel. L'interaction avec le message sur l'appareil mobile est suivie par le SDK (kit de développement) Selligent, qui renvoie ensuite les informations aux services Selligent.

Les messages In-app sont envoyés aux services Selligent, où ils finissent dans une file d'attente jusqu'à ce qu'ils soient récupérés (ils ne sont donc pas poussés vers les appareils). Le SDK les récupèrera à un intervalle prédéfini (non pas en temps réel). Cet intervalle peut être configuré dans l'application. Les messages In-app récupérés peuvent être ouverts directement ou ajoutés à la boîte de réception. C'est le développeur qui s'occupe de la façon de gérer les messages dans l'application.

Les messages In-app peuvent avoir une dated'expiration. Lorsque cette date est atteinte et que le message n'est pas récupéré, ce dernier est supprimé.

Remarque : il est également possible de définir le nombre maximum de messages à conserver sur le serveur. Ce nombre étant défini dans les services Selligent, l'équipe Selligent le modifiera si vous le souhaitez.

Il est recommandé d'utiliser une boîte de réception pour les messages In-app. Le développeur de l'application doit en équiper l'application et décider de la façon de gérer les messages. La boîte de réception n'est cependant pas obligatoire. Si le développeur de l'application choisit d'afficher directement les messages In-app, cette option est elle aussi possible.

Selligent fournit également une option Opt-out dédiée, tant pour les notifications Push que pour les messages In-app. Les notifications Push sont désactivées dans les paramètres de l'appareil. Les messages In-app peuvent toujours être récupérés et affichés dans la boîte de réception. Le développeur de l'application peut cependant prévoir une option Opt-out pour les messages In-app. Cette option est ensuite définie dans l'application, et non dans l'appareil.
Lorsque la valeur Opt-out=0, l'appareil est activé. Si la valeur =1, l'appareil est désactivé. Lorsque la valeur=2, l'ID de l'appareil a été modifié.

Remarque 1 : si la même application est installée sur plusieurs appareils, l'option Opt-out sur un appareil ne sera pas automatique sur les autres. Si vous souhaitez qu'elle le soit, vous devrez gérer ce comportement dans le Journey.

Remarque 2 : la réinitialisation de l'appareil entraînera la perte de son ID.

 

Contenu in-app

Le contenu In-app, personnalisé, s'affiche dans l'appli elle-même. À l'exécution du Journey contenant les composants Push, ce contenu est envoyé au serveur. L'appli récupère le contenu au moyen du kit de développement (SDK) et l'affiche dans un conteneur de l'appli. Il peut s'agir d'un URL, d'une image ou d'un objet HTML. Lorsqu'un utilisateur affiche du contenu ou clique dessus, cet événement est renvoyé. Ce schéma est plus ou moins comparable à celui des messages In-app :

Une seule et même application peut avoir plusieurs conteneurs affichant du contenu In-app. Chaque conteneur peut compter un nombre illimité de contenus In-app de type HTML. Pour les images et les URL, chaque conteneur ne peut afficher qu'un seul contenu.

Remarque : si aucun contenu ne s'affiche dans le conteneur, ce dernier peut être masqué. C'est le développeur de l'appli qui décide de ce qui doit se produire en l'absence de contenu (voir la documentation technique).

Les conteneurs et contenus se voient attribuer une catégorie. Ainsi, seul le contenu de la catégorie A s'affiche dans le conteneur de la catégorie A, la catégorie d'un conteneur étant définie par le développeur de l'appli. (Consulter la documentation technique pour de plus amples informations).

Notez également qu'un seul type de contenu peut s'afficher dans un conteneur. Le contenu s'affiche exclusivement sous une forme HTML, image ou URL. Toute combinaison de ces différents types est impossible. Si cette règle n'est pas respectée, aucun support ne sera assuré en cas de problème. Le développeur de l'appli doit communiquer la catégorie et le type de contenu attendus. Le concepteur du Journey doit prendre ces informations en compte.

Un conteneur se caractérise également par le nombre de contenus In-app qu'il peut contenir. Cela s'applique au contenu HTML uniquement. Si un seul est autorisé, seul le dernier s'affiche. Si plusieurs contenus sont autorisés, ils s'affichent l'un après l'autre, le dernier récupéré s'affichant toujours en haut.

Le contenu In-app peut également contenir plusieurs liens, bien qu'un maximum de 2 soit recommandé afin de ne pas utiliser trop d'espace (recommandation IOS).

Notez qu'il est impossible de naviguer au sein du contenu In-app. Les liens du contenu In-app ne sont pas destinés à naviguer dans le contenu In-app lui-même.

Le contenu In-app peut s'afficher durant une session unique ou durant plusieurs sessions jusqu'à ce qu'un nouveau contenu soit disponible. Ainsi, pour un contenu à session unique, du moment que l'utilisateur ne ferme pas l'appli mais qu'il navigue d'une page à l'autre, le même contenu s'affiche.

Remarque : il est possible d'envoyer une bannière Push pour informer l'utilisateur de la disponibilité du nouveau contenu. Pour ce faire, vous devez utiliser un deuxième composant Push pour envoyer le message. Cette procédure n'est pas automatique lors de la création du contenu In-app.

La configuration du contenu In-app est définie dans le composant Push, tout comme les messages Push et les Notifications in-app (voir la section9).

Quelques exemples :

Pour les appli ayant plusieurs conteneurs et chacune son propre contenu In-app, vous devez créer un Journey avec plusieurs composants Push, créer le contenu In-app de chaque composant, puis attribuer une catégorie au contenu et aux conteneurs de l'appli. Le contenu In-app approprié s'affiche dans le conteneur correspondant.

 

Pour les appli ayant un conteneur affichant plusieurs contenus HTML, vous devez une fois de plus créer un Journey avec plusieurs composants Push, définir le contenu In-app HTML de chaque composant, puis attribuer une catégorie au contenu qui correspond à la catégorie du conteneur.

 

Fonctionnalités des notifications Push

Voici un aperçu des fonctionnalités prises en charge par les notifications Push actuelles.

La notification d'arrière-planest prise en charge pour IOS : l'utilisateur de l'application peut désactiver les notifications Push lorsque l'application est exécutée en arrière-plan. C'est le paramètre défini dans les paramètres système. Selligent prend ce paramètre en considération.Par défaut, le mode arrière-plan est activé. Ce mode est nécessaire à l'utilisation des messages In-app.

Exemples de mode arrière-plan : continuer de lire le son lorsque l'application est fermée, continuer de recevoir des mises à jour d'emplacement, etc.

Multiple app support(support de plusieurs applications) : un seul et même composant Push peut être utilisé par plusieurs applications. Un client avec plusieurs marques peut avoir une application propre à chaque marque et utiliser des notifications Push pour chacune de ces marques en utilisant le même service. Selligent permet de lier les différentes applications à un seul composant Push. Le client peut choisir d'utiliser les mêmes listes pour toutes les marques ou d'utiliser des listes distinctes par marque dans un seul et même environnement.

Pour pouvoir assurer la prise en charge de plusieurs applications, l'ID des applications sera stocké dans la table Appareils. Ce qui permet d'avoir une entrée distincte par application et par appareil dans la table Appareils.

Queuing is supported(la mise sur file d'attente est prise en charge) : dans la mesure où plusieurs applications peuvent utiliser le même service, la mise sur file d'attente, désormais disponible, permet d'optimiser les performances. Plusieurs fils sont utilisés pour distribuer la charge. Il existe deux systèmes de mise sur file d'attente : Azure ou SQL. Cela permet, en cas de problème avec le service, de reprendre là où on était avant le problème.

Remarque : le nombre de notifications Push pouvant actuellement être envoyées s'élève à environ 3 000 par minute. Dans la prochaine version, nous visons les 20 000 par minute minimum.

Il est possible d'envoyer les types de messages (notifications Push et messages In-app) suivants.

  • Alertes (non-applicable au contenu in-app)
  • HTML
  • URL
  • image
  • cartes avec marqueurs (non-applicable au contenu in-app)

Il est possible d'envoyer les types de messages suivants.

  • Notifications Push
  • Messages In-app
  • Contenu in-app

Vous pouvez utiliser les boutons suivants dans un message :

  • Appeler
  • Envoyer un SMS
  • Ouvrir le client de messagerie
  • Ouvrir le navigateur
  • Ouvrir une autre application
  • Ouvrir une méthode dans l'application
  • Définir la réaction au niveau du Journey
  • Ouvrir le magasin (Open the store)
  • Fermer la notification
  • Réponses avec clavier/fichiers(non-applicable au contenu in-app)

  • Réponses avec image (non-applicable au contenu in-app)

Remarque technique : le feedback sur l'envoi des notifications Push est enregistré dans la table des Interfaces. Envoi correct du message, renvoi d'une erreur, etc., toutes ces indications sont enregistrées et peuvent être utilisées dans les Journeys à des fins de reciblage. Les statuts enregistrés sont : in progress, succeeded, failed (en cours, réussi, échoué)

 

Installation

L'installation complète est effectuée par l'équipe Selligent qui exécutera les étapes nécessaires à l'installation des services et de la plate-forme, ainsi qu'à la configuration des fichiers nécessaires.

De son côté, le client doit néanmoins effectuer deux actions :

  • Créer l'application à l'aide du kit de développement (SDK) Selligent (Des templates d'application utilisant le SDK sont disponibles sur Connect)
  • Le client doit fournir des informations sur les tables à utiliser et les données requises dans Selligent, sur les événements à suivre et sur le fichier dans lequel il convient d'enregistrer les tables.

Remarque : après l'installation par l'équipe Selligent, une clé ClientPublicKey et une clé SelligentPrivateKey sont communiquées au client. Ces clés, permettant de sécuriser la communication, sont communiquées au SDK lors de l'initialisation. Consultez le document Using the SDK (Utilisation du SDK) pour plus d'informations à ce sujet.

Création de l'application à l'aide du kit de développement (SDK) Selligent

Pour pouvoir utiliser Selligent Mobile push, le client doit utiliser le SDK Selligent dans son application mobile. Ce SDK contient une série de méthodes que le client peut utiliser pour envoyer des informations à Selligent et enregistrer des données dans les listes Selligent.

Documentation disponible :

Remarque: Lorsque vous utilisez le SDK Selligent une url doit être spécifié pour se connecter au service Pushevents.. Cette URL a toujours la structure suivante: [url d'installation] + "Mobilepush / api /". En cas de doute, contactez Selligent support pour obtenir la bonne URL.

Informations à fournir à Selligent

Tables à utiliser et champs à mettre en correspondance

Selligent fait appel à une série de tables permettant à Mobile Push d'enregistrer les informations relatives aux appareils utilisés, au contact et aux événements déclenchés par les contacts. Le client peut indiquer les noms des tables à utiliser et l'emplacement où celles-ci doivent être enregistrées dans la base de données Campaign. Par ailleurs, si vous souhaitez que d'autres informations soient envoyées à Selligent Campaign, informez-en l'équipe Selligent qui pourra alors configurer des correspondances de champs supplémentaires pour prendre en compte votre demande.

Une liste d’audiencescontenant toutes les données sur les appareils (ID et token de l’appareil, pays, plate-forme, version du SDK,version du système, fuseau horaire, etc.) et des informations sur des événements spécifiques tels que Se connecter, Se déconnecter, S’inscrire et Se désinscrire. C’est la liste d’audiences maîtresse qui sera utilisée dans le Journey. Cette liste d’audiences est automatiquement mise à jour lorsqu’un contact lance l’application pour la première fois. Elle est ensuite mise à jour chaque fois que des modifications y sont apportées (p. ex. changement de fuseau horaire)

Voici une brève description de certains champs de la table :

  • Optout : ce champ est défini sur 0 (abonné) ou sur 1 (désabonné). Lorsqu'un contact installe l'application, il accepte ou non les notifications. S'il les accepte, le champ Optout est défini sur 0, s'il les refuse, il est défini sur 1. Si le contact bloque ensuite les notifications dans les paramètres IOS, lors du lancement suivant de l'application, le champ Optout sera défini sur 1.
  • Enregistrement : création d'un compte/utilisateur depuis l'application. La valeur du champ Enregistrement est définie sur 1 lorsqu'un compte a été créé depuis l'application.
  • Connecté : défini sur 1 lorsque le contact se connecte. Défini sur 0 lorsque le contact se déconnecte. La connexion de l'utilisateur identifie ce dernier et permet de créer un lien entre la fiche présente dans la table Appareils et l'utilisateur présent dans la liste d'audience. Pour pouvoir se connecter, l'utilisateur doit figurer sur la liste d'audience principale.

Remarque : il est possible de se connecter dans l'application sans s'enregistrer via l'application.

  • USER_ID : ID du contact de la liste d'audience à laquelle la fiche de l'appareil est liée
  • Pays : contient une concaténation du pays et de la langue (ex. : fr_BE)
  • Plate-forme : Android ou IOS
  • Device_type : le type d'appareil sur lequel l'application est installée. Exemple : iPad5
  • First_login : date et heure de la première connexion du contact
  • Last-login : date et heure de la dernière connexion
  • Login_count : nombre de connexions du contact (peut être utilisé pour contacter les personnes qui ne se sont pas encore connectées après l'installation de l'application)
  • Device_id : l'ID de l'appareil.
  • Device_token : champ technique basé sur l'ID de l'appareil et l'ID de l'application.
  • Pushoptout : valeur Opt-out de la Notification push. Valeur=0 signifie activé ; valeur=1 signifie désactivé.
  • IAMoptout :valeur Opt-out du Notification in-app.
  • App_ID :l'ID de l'application. Elle permet de stocker plusieurs applications dans la même liste Appareils.
  • Identité :si disponible, ce champ contient le nom de l'appareil ou le pseudo de l'utilisateur.

Une liste d’audiencescontenant les données relatives à un contact connu. Un lien n:1 (un contact peut avoir plusieurs appareils) est créé avec la liste des appareils.

Une fiche de contact est automatiquement créée dans la liste d'audience lorsqu’un contact s'enregistre ou crée un compte pour l’application. Cette liste sera mise à jour avec d’autres informations lorsqu'elles seront disponibles. La liste d’audiences peut contenir tous les champs nécessaires pour stocker des informations sur le contact. Assurez-vous que ces champs sont inclus dans la correspondance de champs.

Une liste de données contenant les informations pour les événements PushReceived, PushOpened, ClickButton et UserCustomEvent.

Événements à enregistrer:Vous pouvez également configurer les événements à suivre.

  • Message reçu
  • Message ouvert
  • Bouton cliqué
  • Événements personnalisés

Nous vous conseillons vivement de suivre et d'enregistrer les informations relatives à tous ces événements.

Pour chaque événement, 10 paramètres par défaut peuvent être envoyés. Ces paramètres permettent au client d’envoyer des données supplémentaires lorsque l’événement est exécuté. (Exemple : pour l’événement PushOpened, enregistrer l’heure ; un événement personnalisé peut être un contact qui termine une formation avec des informations sur le score obtenu.) D’autres paramètres peuvent être ajoutés, le cas échéant, mais la correspondance de champ doit alors, elle aussi, être étendue et l'équipe Selligent doit être informée.

Niveau de consignation de la trace

Il existe quatre niveaux de trace.

  • Debogage (16) : tout.
  • Informations (8) : erreurs, avertissements et informations.
  • Avertissement (4) : erreurs et avertissements (les erreurs et avertissements ne bloquent pas l'application (ex. : certification Apple non définie, clé Android non définie).
  • Erreur (2) : erreurs seulement.

 

Configuration de l'interface dans Campaign

Le composant Mobile Push est un composant basé sur une interface.

Remarque technique :
Le composant Mobile Push est un composant fondé sur une interface. Les interfaces sont des composants personnalisés qui permettent à Selligent d'interagir avec un logiciel externe. En fonction du logiciel externe, tout est possible : envoyer des Notifications push, envoyer des Notifications mobile (SMS), créer des fiches ERP, etc. Cela implique que, selon les paramètres définis dans l’interface liée, l’aspect, les paramètres et la fonctionnalité du composant peuvent différer dans le Journey. Les interfaces sont configurées sous « Processus ». Elles sont de 2 types : l'interface Plugin (un fichier DLL est utilisé pour définir l'interface) et l'interface Fichier, qui peut générer des fichiers de sortie (TXT, CSV, Excel, SPSS et Word). Le composant Mobile Push est lié à une interface basée sur un plugin.
Le plugin détermine également les variables nécessaires et les événements qui peuvent être utilisés. Selon ces variables et événements, un composant d'interface peut avoir différents champs d'entrée pour les variables et différents déclencheurs (flèches dans un Journey) pour les événements.
Pour en savoir plus sur les interfaces, consultez la rubrique Interfaces.


Pour pouvoir envoyer des messages push, une interface basée sur un plug-in doit être définie à l’aide du plugin Selligent Mobile Push

  • Pour ce faire, lancez Selligent Campaign, accédez à l'entrée Processus et activez l'onglet Interface.
  • Cliquez sur « Créer une nouvelle Interface Plugin ».
  • Dans le champ Plugin, sélectionnez le plugin Selligent Mobile Push.
  • Cliquez sur « Configurer ». Si le plugin Selligent Mobile Push est utilisé, une URL vers le service push doit être fournie (p. ex. : [SelligentCampaign_install]/SelligentPushEventApi/PushServices.svc)


Une fois configurée, l’interface peut être utilisée dans un Journey en la faisant glisser et en la déposant sur le canevas à partir de la liste des interfaces dans le navigateur, à gauche.

 

Configuration du composant Push dans un Journey

Si des messages push sont envoyés à partir d’un Journey, la liste d’audiences utilisée dans ce dernier doit être la liste dans laquelle sont enregistrés les appareils, et non les contacts. En effet, un contact peut avoir plusieurs appareils ; si on utilise la liste d’audiences Contacts, Selligent ne sait pas vers quel appareil le message doit être envoyé étant donné qu’il peut y en avoir plusieurs. Pour les Notifications push, la liste d’audiences Appareils est la liste d’audiences maîtresse.

  1. Créez donc un Journey et ajoutez la liste d'audience Appareils.
  2. Ajoutez le composant Mobile Push par glisser/déposer depuis l'arborescence des interfaces à gauche :

Général

  • Nom
  • Programmation :programmé ou instantané.
  • Son : son émis à la réception de la Notification push.
  • Badge : Sur les appareils IOS uniquement, lorsqu'une notification est reçue, un badge s'affiche sur l'icône de l'application. Le numéro sur le badge indique le nombre de notifications reçues qui n'ont pas encore été ouvertes. Ce numéro est toujours incrémenté du nombre présent dans les propriétés du badge de la notification. L'ouverture de l'application réinitialise le badge.
  • Distribution :
    • Notification push : pour envoyer une Notification push.
    • Notification in-app : pour envoyer un Notification in-app.
    • Notification in-app si Notification push indisponible : pour envoyer une Notification push, mais, si indisponible, un Notification in-app.
    • Contenu in-app: contenu à afficher dans un conteneur de l'appli
  • Type : Il s’agit du type de message qui sera envoyé. Tous les types ne sont pas disponibles à la distribution (le contenu In-app ne peut avoir que du contenu de type HTML, image et URL).
  • Catégorie: applicables au contenu In-app uniquement et obligatoire. Le fait de définir une catégorie de contenu permet d'afficher uniquement le contenu d'une catégorie spécifique d'un conteneur (exemple: créer un conteneur n'affichant que le contenu d'une catégorie Accueil).
  • Bannière Push : utilisée uniquement pour les messages Push.
    • Titre : titre affiché lorsqu'un message Push est reçu dans le centre de notification ou sur l'écran Verrouiller (selon les paramètres IOS).
    • Contenu :
  • Message : utilisé pour les messages Push et de l'application, ainsi que pour le contenu in-app.
    • Titre : titre du message s'affichant dans la boîte de réception de l'application ou dans le conteneur de l'appli
    • Contenu : contenu du message ou contenu in-app

Remarque : toutes les valeurs de la bannière Push et des champs Message doivent être placés entre des guillemets simples.

Alerte (non applicables au contenu in-app): simple notification texte. Le champ de texte est défini comme le contenu du message.

Remarque : utilisez des guillemets lorsque vous saisissez le texte de l'alerte. Si vous utilisez des champs personnalisés, ajoutez-les avec le signe +.

Ex.: ‘Hello’+MASTER.FIRSTNAME

HTML : contenu HTML contenant du texte, des liens, des images ou tout autre élément HTML5. Notez cependant que les notifications HTML sont recommandées pour la mise en forme des messages. (Exemple : si vous placez un lien dans ce message HTML, il s'affichera dans la fenêtre de notification, mais le contact ne pourra pas revenir)

Remarque : la longueur maximum de l'alerte et des messages HTML est limitée à 500 caractères. Si vous avez besoin d'un nombre plus élevé de caractères, vous pouvez augmenter la longueur du champ dans la base de données.

Image : l'URL de l'image est indispensable. Vous pouvez télécharger une image de la fenêtre Gestion d'images (qui permet d'accéder aux images dans Campaign) ou utiliser d'autres images en saisissant l'URL correspondante. Lors de l'envoi d'une notification d'image, l'URL de l'image est envoyée et l'image est rendue lorsque la notification s'affiche.

URL :l'URL de la page est saisie. Le contenu de l'URL s'affiche dans la fenêtre de notification et le contact est en mesure de naviguer.

Vous pouvez utiliser l'URL d'une page Selligent Campaign. Il est possible d'utiliser des champs de personnalisation dans cette page.

Si vous souhaitez personnaliser la page affichée dans le message (vous adresser au contact avec son prénom, par exemple), vous devez utiliser deux Journeys.

Exemple :

Carte (non applicables au contenu in-app): lors de la sélection d'une carte, vous devez définir les marqueurs à afficher sur cette carte. Au moins un marqueur doit être défini. C'est pourquoi, lorsque vous sélectionnez ce type, un onglet supplémentaire est ajouté à la boîte de dialogue : Marqueurs. Dans cet onglet, vous pouvez commencer à ajouter des marqueurs : utilisez le bouton « Ajouter un marqueur » :   

Définissez un titre et une description pour le marqueur. Ces éléments s'affichent dans la fenêtre d'informations lorsque vous cliquez sur le marqueur de la carte.  Définissez une latitude et une longitude pour le marqueur .

Remarque : un maximum de 100 points est autorisé. Tous les points définis s'affichent sur la carte. Selon la taille d'écran de l'appareil, il convient donc d'adapter le zoom et le centre de la carte de manière à ce que tous les points soient toujours visibles en zoom maximum.

  • Texte : utilisé comme titre du message qui sera affiché à la réception de la Notification push.
  • Contenu : contenu du message. Il dépend du type de message. S’il s’agit d’images, le bouton « Télécharger » apparaît.

 

Liens

Si une action ou une interaction est requise dans le message, des liens peuvent être utilisés et ajoutés à la Notification push.

Seuls trois liens au maximum peuvent être ajoutés au message Push et In-app. Dans le cas d'un contenu In-app, seuls deux liens sont recommandés. Pour les images du contenu In-app, il est conseillé d'en utiliser qu'un seul (recommandations IOS).

Pour chaque lien, vous pouvez définir un libellé, un type et une cible. Les types de liens disponibles sont les suivants :

  • Définir la réaction dans le Journey: Ce qui se passe lorsqu’on clique sur un lien est défini dans le Journey même : rediriger vers un autre Journey  envoyer un e-mail, etc.  Un clic sur le lien présent dans la notification fermera cette dernière

Remarque : actuellement, pour des raisons techniques, le composant Push mobile est suivi d'un Composant Page en cas de clic sur ce lien.

  • Téléphone : passer un appel téléphonique au numéro défini. (ex. 3228888888)
  • SMS : ouvre l’application SMS par défaut pour envoyer un SMS au numéro indiqué. (ex. 3228888888)
  • E-mail : ouvre l’application de messagerie par défaut pour envoyer un e-mail à l’adresse indiquée (vous@entreprise.com).
  • Navigateur : ouvre le navigateur par défaut sur une URL définie. (http://www.selligent.com)
  • Application : ouvre une application définie, notamment Facebook, 'X' (anciennement Twitter), etc. ((eg. fb:// pour IOS ; com.twitter.android pour Android))

La syntaxe de la cible diffère en fonction de la plate-forme. Aucune conversion automatique n’est actuellement effectuée pour corriger la syntaxe pour IOS ou Android. Il est recommandé de créer deux composants push distincts dédiés à chaque plate-forme.

  • Ouvrir une méthode dans votre application (ex. MethodName .C'est la même methode pour IOS et Android)
  • Bouton Close notification (Fermer la notification)(simple) : ferme le message de notification et enregistre cet événement « Clic » dans la table des événements.
  • Open the store (Ouvrir le magasin) : ouvre l'application de stockage (iTune ou Market) pour télécharger une application définie
  • Réponse  (non applicable pour le contenu In-app) :une réponse est envoyée, codée en dur.
  • Réponse avec clavier  (non applicable pour le contenu In-app): permet de fermer la notification et d'afficher le clavier et la zone de texte. Après saisie du texte, un bouton Envoyer est disponible. La réponse saisie est envoyée au service web et stockée dans la table Événements.
  • Réponse avec image  (non applicable pour le contenu In-app): l'application dispose de deux boutons, l'un pour prendre une photo, l'autre pour sélectionner un fichier. Le suivi de l'interaction sur ces liens n'est pas assuré.

Exemple :

Lorsque vous cliquez sur le lien « Envoyer une image », « Envoyer » ou « Annuler », un événement est détecté et envoyé au service web. Lorsque ce fichier est envoyé à Selligent, il est stocké dans la table Événements en mode binaire.

Remarque : Avant d'être envoyé à Selligent, un fichier est tout d'abord mémorisé sur l'appareil. Cette opération s'effectue en deux temps afin d'éviter de perdre le fichier au cas où quelque chose se passerait mal durant le processus.

Un exemple d'utilisation peut être un concours, pour lequel des personnes doivent envoyer une photo contenant le produit d'une marque.

Remarque : les boutons ajoutés au message push agissent comme des capteurs qui envoient le contact vers un emplacement externe. Ils peuvent être utilisés comme des événements dans un Journey pour faire avancer le contact.

Example d'un message HTML avec liens:

Avancé

  • Plate-forme de l’appareil : détermine la plate-forme (IOS ou Android) vers laquelle le message est envoyé. Ces informations sont disponibles dans la liste d’audiences.

  • Token de l’appareil : un appareil spécifique auquel la Notification push doit être envoyée. Ces informations sont disponibles dans la liste d’audiences (ex. : DEVICES.DEVICE_TOKEN). Le token de l'appareil est une combinaison de l'ID de l'appareil et de l'application. Si plusieurs applications sont installées sur l'appareil, avec le même SDK, le jeton de l'appareil permettra de différencier les applications.

Remarque : le jeton de l'appareil n'est utilisé que pour envoyer des notifications Push.

  • ID appareil :champ permettant de récupérer l'ID de l'appareil de la cible (ex. : MASTER.DEVICE_ID). Il s'agit de l'ID de l'appareil.

Remarque : l'ID de l'appareil est utilisé pour pouvoir envoyer des messages In-App.

  • Date d'expiration :s'applique uniquement aux messages In-app, pour définir la date après laquelle les messages non récupérés ne seront plus livrés

Remarque : Lorsqu’un contact installe l’application mobile et la lance, des informations relatives à la plate-forme utilisée et à l’appareil sont enregistrées dans la liste d’audiences.

  • N'afficher que contenu In-app qu'une seule fois :si le paramétrage est Vrai, le contenu ne s'affiche que durant une session. S l'utilisateur quitte l'appli puis y accède de nouveau, le contenu n'est plus disponible. Si le paramétrage n'est pas Vrai, le contenu reste disponible jusqu'à ce qu'un nouveau soit disponible sur le serveur pour ce conteneur.

 

Événements générés par le composant Mobile Push

Le composant Push mobile génère une série d'événements, basés sur les boutons créés dans le message.

L'interaction sur ces boutons peut être utilisée pour pousser le contact plus loin dans le Journey.

Example

Les liens« Accéder à la promo » et « Me le rappeler ultérieurement » sont des liens simples. L'interaction sur ces liens peut être utilisée comme événement dans le Journey.

À partir de 1.3, il est également possible d'utiliser des événements par défaut pour un message - comme Envoyer, Afficher, Non livré et Après livraison - comme événement dans le Journey.

Exemple :

Lorsque le contact reçoit la Notification push, un lien est disponible pour demander le coupon. Lorsque le contact clique sur le bouton, un e-mail est envoyé avec le coupon.

Remarque : le Journey utilisant la liste Appareils, vous devez activer l'utilisation de listes liées dans le composant Audience/l'onglet Données pour pouvoir personnaliser le message et envoyer un e-mail.

 

Utilisation de Mobile Push dans un Journey Selligent

Si des messages push sont envoyé à partir d’un Journey, la liste d’audiences utilisée dans ce dernier doit être la liste dans laquelle sont enregistrés les appareils, et non les contacts. En effet, un contact peut avoir plusieurs appareils ; si on utilise la liste d’audiences Contacts, Selligent ne sait pas vers quel appareil le message doit être envoyé étant donné qu’il peut y en avoir plusieurs. Pour les Notifications push, la liste d’audiences Appareils est la liste d’audiences maîtresse.

Voici un exemple de Notification push envoyée à une audience limitée. :

Le filtre appliqué à la liste Appareils ciblera uniquement des appareils spécifiques. L'objectif est de relancer des contacts afin qu'ils utilisent l'application. Dans cet exemple, nous supposons qu'un utilisateur qui ne s'est connecté qu'une seule fois il y a plus d'une semaine est un nouvel utilisateur et qu'il pourrait être intéressant de le relancer. Les utilisateurs qui se sont connectés plusieurs fois par le passé, mais qui ne se sont plus connectés depuis un mois, sont considérés comme ayant abandonné l'application. La première partie de la condition vérifie les utilisateurs actuellement non enregistrés ou non connectés.

La Notification push elle-même est un message texte avec un bouton Remind me later (Rappelez-moi ultérieurement). Pour les contacts qui cliquent sur ce lien, un événement est déclenché et enregistré dans la liste des événements, ce qui nous permet d'utiliser ces informations et de les cibler dans un autre Journey.

Voici un exemple de Journey déclenché à l'aide d'informations enregistrées dans des événements déclenchés sur un appareil :

L'audience est filtrée sur la base du filtre suivant : seuls les contacts ayant appuyé sur le lien« Remind me later » (Rappelez-moi ultérieurement) au cours des deux derniers jours sont ciblés :

Autre exemple d'utilisation de la Notification push, après un Composant Fractionnement basé sur les règles lors d'une vérification des informations dans le profil Site du contact.

Dans ce cas, le profil Site est directement lié à la liste des appareils et la liste d'audience du Journey est définie de manière à utiliser les profils Site :

Le Composant Fractionnement basé sur les règles utilise ensuite un champ dans ce profil Site pour détecter des centres d'intérêt et envoyer des notifications correspondant à leurs intérêts :

 

Rapports Mobile push

Des rapports sur Mobile Push sont disponibles sur l’interface de base du portail. Pour y accéder, ouvrez le Journey contenant l'interface Push et sélectionnez-la dans l'arborescence à gauche.

 

Q&R

Mobile push est-il également disponible pour les clients internes ?

Oui, il est également disponible pour les clients internes, mais les services Selligent Mobile Push seront déployés sur l'installation Selligent pour tous les clients (Saas et internes).

D'un point de vue de la sécurité, cela signifie que les ports nécessaires doivent être ouverts sur l'installation du client.

Avons-nous un reporting sur les interactions mobiles ?

Le composant Mobile Push est un composant d'interface. Les rapports Mobile Push se trouvent dans le portail, avec les autres rapports d'interface. Le champ Statut dans la table d'interface peut indiquer si le push a été envoyé, s'il y a une erreur ou s'il est en cours de traitement.

En outre, tous les événements liés au SDK Selligent Mobile sont stockés dans la table PushEvents (push reçu, push ouvert, bouton cliqué, événement personnalisé par l'utilisateur).

Pouvons-nous suivre le comportement de l'utilisateur au sein de l'application et utiliser ces informations dans Selligent Campaign ?

Oui, des événements personnalisés peuvent être créés dans l'application. Ils permettent de suivre le comportement de l'utilisateur et de renvoyer les informations à la plate-forme de sorte à enrichir les profils.

Chaque événement personnalisé peut être enregistré à divers niveaux selon la manière dont l'environnement a été défini. Les informations peuvent être enregistrées dans les tables PushEvents ou dans l'une des deux listes d'audiences contenant les appareils et les utilisateurs.

Mobile push est-il gratuit ?

Oui.

Est-il possible, à partir d'un message push, d'être redirigé vers une section spécifique de l'application ?

Oui, un bouton spécifique permet d'ouvrir l'application sur une section spécifique.

Est-il possible de suivre un utilisateur de l'application qui visite un page Web à partir d'un message de notification ?

Oui. Le mécanisme Campaign standard peut être utilisé pour suivre un utilisateur qui visite une page. Ce mécanisme se base sur la fonctionnalité de suivi de Campaign.

Existe-t-il un support multilingue ?

Lorsque des messages doivent être envoyés dans différentes langues, qui doivent être traitées dans le Journey lui-même, en créant le message dans la langue adéquate. La langue du destinataire peut être basée sur la langue de l'appareil qui est disponible par défaut. Il est possible d'ajouter une propriété personnalisée pour la langue de l'application.

Lors de l'utilisation de notifications de type URL, où doit se situer l'URL ?

Dès que l'URL spécifiée est accessible à partir de l'environnement, son contenu s'affiche. L'URL peut se trouver sur le serveur Selligent ou ailleurs. Cela n'a aucune importance.

Peut-on envoyer des notifications à des utilisateurs anonymes ?

Pour pouvoir envoyer des notifications, seuls sont indispensables un token de l'appareil et l'ID de l'appareil. Le jeton est nécessaire pour pouvoir envoyer les messages. L'ID est nécessaire pour recevoir les événements.

Peut-on envoyer des notifications aux utilisateurs qui ne sont pas enregistrés ou connectés ?

Oui. Tous les utilisateurs ayant installé l'application peuvent recevoir des messages de Selligent.

Est-il possible de mesurer le taux d'ouverture d'un message push ?

Tous les événements liés à la notification sont mémorisés dans Selligent : push open (push ouvert), click button (clic sur le bouton).