Skip to main content

Vue d’ensemble

La personnalisation mobile couvre trois surfaces d’affichage, et chacune a son propre modèle d’intégration. Deux mécanismes sous-tendent ces modèles : le remplacement d’image, où la plateforme push pointe vers un lien Reelevant et où l’image est générée par destinataire au moment de l’affichage ; et la résolution avant envoi, où votre plateforme push demande à Reelevant le contenu de chaque notification et injecte les valeurs dans le message envoyé.

Prérequis

  • Un Workflow publié avec un Channel correspondant à la surface : Push Notification Image, In-App Popup ou In-App Inbox.
  • Un identifiant de destinataire que votre plateforme push peut injecter dans le lien Reelevant, généralement le même que celui utilisé pour les campagnes e-mail.
  • Pour le modèle de résolution avant envoi, un Workflow se terminant par un Output Node JSON Template.

Modèle 1 — Remplacement d’image

C’est le modèle par défaut, le plus rapide, et il fonctionne sur les trois surfaces.
1

Publier le Workflow

Copiez le lien du Channel depuis la modale d’intégration.
2

Déclarer le lien dans la plateforme push

Utilisez-le comme média enrichi de la notification, ou comme image de la scène in-app ou de la carte du centre de notifications. Ajoutez l’identifiant du destinataire en paramètre d’URL.
3

Garder un texte générique

Le titre et le corps de la notification proviennent de la campagne, pas de Reelevant : le même texte est donc envoyé à tout le monde.
Les images enrichies sur l’écran de verrouillage sont gérées par la plateforme mobile elle-même : iOS exige une extension de service de notification et l’attribut mutable-content (documentation Apple), Android lit le champ image de la notification (documentation Firebase Cloud Messaging). Vérifiez avec votre plateforme push laquelle des deux options elle prend en charge avant de planifier un visuel sur l’écran de verrouillage.
Certaines configurations push envoient les notifications de l’écran de verrouillage en texte seul. Dans ce cas, le visuel personnalisé apparaît une fois la personne arrivée dans le centre de notifications ou sur une scène in-app, et l’écran de verrouillage reste générique.

Modèle 2 — Résolution avant envoi

Utilisez ce modèle lorsque le texte de la notification doit changer selon le destinataire, et pas seulement le visuel. Votre plateforme push, ou le système qui déclenche l’envoi, demande à Reelevant les valeurs personnalisées pour chaque destinataire et les injecte dans la notification envoyée.
La réponse contient les champs déclarés dans l’Output Node JSON Template, par exemple un titre, un message et un lien d’image. Votre plateforme push associe ces champs au titre, au corps et à l’image de la notification.
Cette requête a lieu au moment de l’envoi, pour chaque destinataire : elle ajoute donc de la charge à votre fenêtre d’envoi. Regroupez les appels selon les recommandations de votre plateforme push, et définissez un repli lorsque le Workflow ne renvoie aucun contenu.
Les détails d’implémentation, les codes de réponse et les exemples de code figurent dans la documentation d’intégration mobile.

Les données de navigation mobile dans les Workflows

Les bibliothèques mobiles Reelevant collectent les événements de navigation in-app et les envoient au DataHub, comme les événements de site web sur le web. Une fois collectés, ils sont disponibles dans les Workflows via le Data Node Website Events, ce qui permet de construire des conditions sur les produits consultés dans l’application. C’est cette donnée qui distingue un push générique d’un push qui réagit à ce que la personne a fait dans l’application la veille.

Mesure

La disponibilité des métriques push et in-app varie selon la surface. Voir Mesure messagerie et mobile.