Nous avons déjà présenté les arguments stratégiques : l’ère du « blast » est révolue, et les notifications déclenchées par le comportement sont ce que les plateformes récompensent et que les abonnés tolèrent. Ce guide est l’autre moitié : comment déclencher réellement des notifications push à partir d’événements d’application sur iOS, de l’instrumentation à la transmission à l’équipe marketing. Il est écrit pour le développeur qui effectue le câblage, avec le code que vous expédierez et les conventions qui le rendent maintenable.
L’architecture en un paragraphe
Votre application déclenche des événements nommés avec des propriétés typées. PushEngage fait correspondre ces événements aux règles de déclenchement configurées dans le tableau de bord, et les campagnes sont envoyées — immédiatement, avec un délai, ou sous forme de séquence multi-étapes avec des conditions de sortie. La division du travail est le point clé : l’ingénierie instrumente chaque événement une fois ; le marketing crée, modifie et supprime des campagnes basées sur ces événements pour toujours, sans autre build. Votre instrumentation est une API pour votre équipe marketing.
trackEvent : le signal polyvalent
Le SDK iOS 1.0 a introduit trackEvent, le cheval de bataille pour les signaux comportementaux personnalisés :
PushEngage.trackEvent(name: "product_viewed",
properties: [
"sku": "WCJ-1042",
"category": "outerwear",
"price": 189.00,
"in_stock": true
],
profileId: currentUserId, // ties the event to an identified subscriber
provider: nil,
eventType: nil) { success, error in
if !success { log(error) }
}Trois règles que le SDK applique, alors concevez-les dès le départ :
- Les valeurs des propriétés doivent être des chaînes de caractères, des nombres ou des booléens. Les tableaux, les dictionnaires et les dates sont rejetés côté client — aplatissez-les avant de les envoyer.
- Les noms d’événements et les clés de propriétés ne doivent pas être vides. Le gestionnaire d’achèvement vous indique quand la validation échoue ; enregistrez-le dans les builds de débogage.
- Les gestionnaires d’achèvement arrivent sur une file d’attente d’arrière-plan. Transmettez à la file principale avant de toucher l’interface utilisateur.
Passez profileId chaque fois que l’utilisateur est identifié — c’est ce qui permet à une campagne de suivre un client sur plusieurs appareils au lieu de suivre un appareil.
sendTriggerEvent : câblage des campagnes de déclenchement classiques
Pour les campagnes créées dans le générateur de déclencheurs du tableau de bord — abandon de panier, abandon de navigation, parcours personnalisés — l’application déclenche sendTriggerEvent avec les noms de campagne et d’événement configurés par le responsable marketing, plus les jetons de données que le modèle de notification rendra :
let trigger = TriggerCampaign(campaignName: "cart_abandonment",
eventName: "add_to_cart",
data: [
"productname": "Waxed Canvas Jacket",
"price": "$189",
"cartlink": "myapp://cart"
])
PushEngage.sendTriggerEvent(triggerCampaign: trigger) { success, error in
// background queue — dispatch before UI work
}Les jetons data sont intégrés dans la copie de la notification — c’est ainsi que « Votre veste en toile cirée vous attend » est personnalisée sans que le responsable marketing n’ait à toucher au code. Nous avons parcouru la séquence complète de récupération de panier dans le guide de l’abandon de panier dans l’application mobile ; cet appel en est le moteur.
addAlert : baisse de prix et réapprovisionnement, intégrés
Les deux déclencheurs de commerce à plus forte intention ne nécessitent même pas de campagnes personnalisées — ce sont des citoyens SDK de première classe. Lorsqu’un utilisateur surveille un produit, enregistrez l’alerte :
let alert = TriggerAlert(type: .priceDrop, // or .inventory
productId: "WCJ-1042",
link: "myapp://product/WCJ-1042",
price: 189.00,
data: ["size": "M"])
PushEngage.addAlert(triggerAlert: alert) { success, error in }PushEngage gère la surveillance, la correspondance et l’envoi lorsque le prix baisse ou que le stock revient. Si vous avez lu notre guide des notifications de baisse de prix, c’est l’enregistrement côté application qui fait fonctionner ces campagnes.
Une taxonomie d’événements évolutive
La dette d'instrumentation est réelle : six mois plus tard, personne ne se souvient si l'événement est addToCart, cart_add ou CartUpdated. Choisissez des conventions dès le premier jour — noms en snake_case, ordre objet_action, clés de propriété singulières — et couvrez l'ensemble du commerce de base :
| Événement | Propriétés clés | Campagnes qu'il alimente |
|---|---|---|
product_viewed | sku, catégorie, prix | Abandon de navigation, personnalisation |
product_saved | sku, prix | Baisse de prix, réapprovisionnement, accroches de reconquête |
cart_updated | valeur_panier, nombre_articles, article_principal | Abandon de panier |
purchase_completed | valeur_commande, nombre_articles | Conditions de sortie, post-achat, objectifs |
search_performed | requête, nombre_résultats | Récupération sans résultats, segments d'intérêt |
onboarding_step | étape, terminée | Branchement de la série d'intégration |
Six événements, instrumentés une fois, alimentent la série d'intégration, la récupération du panier, les accroches de reconquête et tous les segments que votre équipe marketing demandera cette année.
Testez la boucle avant de la transmettre
Définissez PushEngage.enableLogging = true dans les builds de débogage et observez les événements quitter l'appareil. Déclenchez chaque événement à partir d'une build de test, confirmez qu'il arrive dans la vue des événements du tableau de bord, et envoyez une campagne de test de bout en bout par déclencheur. Les applications d'exemple du dépôt SDK incluent un écran de déclenchement fonctionnel dont vous pouvez vous inspirer. Quinze minutes de vérification ici permettent d'économiser l'enquête ultérieure sur « pourquoi la campagne n'a pas fonctionné » — qui est généralement une faute de frappe dans le nom de l'événement d'un côté du contrat.
La transmission : ce que le marketing possède à partir d'ici
Une fois que les événements circulent, votre partie est terminée. Le marketing crée les règles de déclenchement, rédige le contenu, définit les délais et les conditions de sortie, teste les variantes A/B et attache le suivi des objectifs pour l'attribution des revenus — tout cela dans le tableau de bord, sans ticket. Publiez le tableau de taxonomie des événements dans votre wiki d'équipe comme contrat entre les deux parties. Ensuite, regardez la file d'attente des requêtes pour « peux-tu envoyer une notification push » disparaître tranquillement — ce qui était le but depuis le début. Pour la stratégie que ces campagnes devraient suivre, confiez à votre équipe marketing le guide de marketing par notification push.
