Demandez à un développeur : Elliott Millar, développeur de logiciels senior myDNA, sur l'intégration de Braze, l'utilisation d'AWS EventBridge et la priorisation de la recherche avant le projet

Les développeurs jouent un rôle clé en s'assurant que nos clients sont en mesure d'intégrer en douceur et de tirer parti de la plate-forme Braze pour soutenir leurs efforts de marketing. Pour en savoir plus sur le travail que font les développeurs dans le cadre de Braze et sur leurs expériences, j'ai rencontré Elliott Millar, développeur de logiciels senior chez myDNA, une marque leader dans le domaine du bien-être génétique. Voici ce qu'il avait à dire* :

Pouvez-vous nous en dire un peu plus sur myDNA et votre rôle là-bas ?

myDNA est une société de bien-être génétique basée à Melbourne, en Australie. Nous donnons des conseils aux gens en fonction de leurs résultats génétiques. Nos clients nous envoient simplement leur écouvillon de joue et nous traitons leurs résultats ADN et leur donnons leurs informations ADN et leurs recommandations pour travailler avec leur génétique.

myDNA a commencé avec des produits pharmacogénomiques, qui peuvent aider les professionnels de la santé à prescrire les médicaments de leurs patients avec plus de précision, et cela a fait une grande différence dans de nombreuses vies. Maintenant, il y a beaucoup de recherches riches sur l'ADN montrant comment la génétique affecte des aspects de notre bien-être comme l'alimentation, l'exercice, le sommeil et le vieillissement de la peau, pour n'en nommer que quelques-uns. myDNA a donc maintenant un produit de bien-être général aussi ; ce produit donne aux gens leurs informations et recommandations sur l'ADN, ainsi que des plans de repas et de remise en forme personnalisés basés sur leurs résultats génétiques via notre application myDNA Unlocked. C'est là qu'intervient Braze. Nous utilisons Braze pour proposer ce contenu personnalisé à nos clients via l'application afin de les aider à changer leurs comportements et à atteindre leurs objectifs de bien-être.

Je suis développeur logiciel senior chez myDNA. J'occupe ce poste depuis octobre et l'un des premiers projets que j'ai dirigés a été l'intégration de Braze dans myDNA Unlocked. Je suis un développeur full-stack, donc je peux travailler sur à peu près n'importe quoi dans notre suite logicielle, qu'il s'agisse d'accéder à une base de données SQL, de configurer notre backend .net, de faire des choses avec React Native ou de traiter avec Objective-C. Peu importe, déposez-moi n'importe où.

Vous avez mentionné que l'intégration de Braze était l'un de vos premiers projets chez myDNA. Pouvez-vous nous parler de la chronologie de ce projet ?

Eh bien, je l'ai récupéré en novembre et le processus a fini par prendre trois mois et un peu, sans compter les vacances d'hiver. Cela commence une fois que le projet était entre mes mains. Avant que je ne m'implique, il y avait un processus d'intégration où ils ont travaillé pour configurer les événements personnalisés et les attributs personnalisés qui étaient collectés avec Braze, afin que tout cela soit préparé lorsque nous avons commencé. Je pense que c'était environ six ou huit semaines avant que je commence le projet.

Avez-vous fait des recherches avant de commencer le projet d'intégration Braze ?

J'ai fait une quantité folle de recherches. J'ai regardé quelque chose comme 20 heures de vidéos sur LAB [Learning at Braze] et lu tant de pages de documentation - il y en a une quantité incroyable - parce que j'avais besoin de tout savoir sur ce logiciel ; sinon, comment pourrais-je savoir si cela fonctionne ou ce qu'il est censé faire ? J'avais également besoin de tout savoir du point de vue de notre équipe d'expérience client (CX), car ce sont eux qui seront principalement propriétaires de Braze. Comment allons-nous réellement l'utiliser ? Comment ça marche avec iOS et Android ? Au départ, je ne savais pas vraiment qui allait participer à ce projet, et si je dirige un projet, j'ai besoin de tout savoir sur ce qui se passe pour pouvoir assigner du travail, tout comprendre et obtenir des estimations appropriées.

J'ai donc consulté des didacticiels sur la personnalisation Liquid, le contenu connecté, les attributs personnalisés et les événements personnalisés, comment intégrer, ce qu'est le réchauffement IP et comment le faire, comment aborder l'amorçage push, ce genre de choses. J'ai appris beaucoup de choses différentes à prendre en compte avec le contenu connecté, comme le risque de casser vos propres API, ou comment vous devriez utiliser les deltas, au lieu de parcourir 450 millions de points de données simplement parce que des choses se passent dans vos systèmes. Et dans la documentation, il y a tout, de la configuration de vos webhooks au fonctionnement des API et SDK Braze.

Et quand j'ai eu fini, je suis allé créer une section dans notre Confluence pour filtrer toutes ces informations que je recevais de Braze dans un joli format consommable pour les autres développeurs. De cette façon, même s'ils avaient besoin de se mettre à niveau en 24 heures, toutes les informations dont ils avaient besoin se trouvaient dans un emplacement central. J'ai toujours construit un document massif qui schématise notre intégration avec Braze, basé sur toutes les recherches que j'ai faites. Alors quand est venu le temps de le faire, je me suis senti préparé.

Pouvez-vous nous expliquer un peu pourquoi la décision a été prise d'intégrer Braze ?

Avec Braze, le business case et tout a été fait bien avant mon arrivée chez myDNA. Mais de mon point de vue, il y a un très gros avantage à donner les rênes à notre équipe CX et à lui permettre d'interagir directement avec les clients, sans aucune interaction ou intervention des développeurs. Notre ancienne approche avait nécessité beaucoup de travail de développement pour mettre en œuvre et permettre la sortie de nouvelles fonctionnalités, ce qui rendait plus difficile pour l'équipe CX de contrôler les interactions et le contenu qui étaient envoyés aux utilisateurs.

Dans le cadre de ce processus, nous avons essentiellement constaté qu'il y avait trois points de contact principaux que nous devions déterminer lorsqu'il s'agissait de tirer parti de Braze :

• Installation du SDK dans notre application mobile pour prendre en charge le contrôle de l'équipe CX sur la messagerie

• Gestion des données rapides et urgentes en connectant Braze à AWS EventBridge

• Traitement des données moins urgentes en utilisant Braze avec Hightouch, FiveTran et d'autres technologies

Pouvez-vous nous expliquer ce premier point de contact, celui lié au SDK et à la messagerie ?

Eh bien, avant d'intégrer Braze dans notre application mobile, nous utilisions Expo, un outil que nous utilisions pour envelopper notre application et la déployer sur l'App Store d'Apple et Google Play. Braze ne prend pas en charge Expo, donc avant de pouvoir intégrer Braze, nous avons dû éjecter Expo et commencer à utiliser un flux de travail nu. Cela signifiait une quantité décente de dette technologique que nous devions gérer, comme la mise en place d'un nouveau pipeline de construction. De plus, dans notre cas, nous avons dû intégrer Objective-C pour iOS et Java pour Android, ainsi que React Native, afin de faire fonctionner les choses. C'était un gros morceau de travail, mais nous avions une excellente équipe en interne pour aider et faire en sorte que tout se produise. [ Remarque : Braze a récemment mis à jour nos SDK iOS et Android pour tirer parti de Swift et Kotlin, respectivement.]

Nous avons déployé l'application mobile et tout a fonctionné, pas de drame, ce qui était super. Et une fois que nous avons exécuté le SDK Braze dans notre application mobile, cela signifiait que nous pouvions l'utiliser pour capturer tout l'engagement des utilisateurs qui s'y passait. Ainsi, il déclenche des événements personnalisés lorsque les utilisateurs interagissent avec le système, et il reçoit également de l'aide pour informer et alimenter tous les différents canaux de messagerie que l'équipe CX utilise, comme les notifications push, les messages intégrés à l'application, les cartes de contenu, tous de ces bonnes choses.

À ce stade, nous avons pu déplacer notre voyage post-insight vers Braze. C'est ce que nous appelons le flux qui se produit après qu'un de nos clients a obtenu ses résultats ADN. Nous voulons que notre équipe CX soit en mesure d'interagir avec ces clients, de vraiment les féliciter lorsqu'ils font du bon travail dans leur planification de repas, leur planification d'entraînement, toutes ces bonnes choses. L'équipe CX est en train de créer des canevas incroyables pour lancer différents parcours d'utilisateurs via des messages push, des messages intégrés à l'application, des cartes de contenu et des e-mails.

Nous avons eu quelques problèmes avec les notifications push au début, liés à l'éjection de l'Expo, mais nous avons réussi à trouver un moyen vraiment génial de les résoudre en utilisant AWS EventBridge. Ainsi, au lieu de déclencher des notifications push via Expo, nous nous sommes simplement dirigés vers notre pipeline EventBridge, donc quand Braze va, hé, j'ai un événement personnalisé à envoyer avec notre push, le message est envoyé avec un contenu dynamique. Cela a contourné le problème lié à Expo, car dès qu'un utilisateur dispose d'une mise à jour pertinente, Braze récupère le jeton push et s'en va. Mais avant que ces parcours pré- et post-insight ne soient migrés vers Braze, tout pouvait continuer à fonctionner tel quel via le CRM.

En parlant d'EventBridge, pouvez-vous nous en dire un peu plus sur la façon dont vous l'utilisez en lien avec Braze ?

Eh bien, tout a commencé lorsque je réfléchissais aux types de données dont nous allions avoir besoin pour Braze. Essentiellement, il y a deux sous-ensembles différents de données que nous avons dû comprendre. Il y a les éléments vraiment critiques qui doivent entrer dans Braze dès que possible - ce sont vos données rapides et rapides. D'autre part, il existe également des données supplémentaires qui ne sont vraiment pas aussi sensibles au facteur temps, mais qui doivent encore être transférées dans Braze. Pour les choses lentes, cela peut passer par notre synchronisation de données Hightouch, sur laquelle je reviendrai plus tard. Mais pour les données en mouvement rapide, nous avons décidé de tirer parti d'EventBridge.

Qu'est-ce que les données en mouvement rapide ? Eh bien, lorsque quelqu'un s'inscrit à notre produit, nous avons besoin qu'il reçoive un e-mail de bienvenue de Braze dès que possible. Nous avons une fonction d'étape d'enregistrement qui gère tout ce pipeline de différentes choses qui pourraient être activées pour un nouvel utilisateur qui s'enregistre. Dans ce cadre, lorsque l'utilisateur est configuré dans notre CRM, nous avons besoin de toutes ces informations pour passer à Braze, afin que l'utilisateur puisse commencer à recevoir du contenu, comme cet e-mail de bienvenue. Nous devons donc trouver un moyen de faire passer ces données.

En fin de compte, EventBridge fonctionne très bien pour ce cas d'utilisation. Nous avons créé un nouveau référentiel d'événements hébergeant cette architecture AWS, et parce que nous utilisons AWS CDK [Cloud Development Kit] pour toute notre configuration et notre déploiement, cela a été très facile. Nous venons de créer un bus d'événements myDNA dans AWS, et nous avons dit que si vous voulez vous y abonner, tout ce que vous avez à faire est d'écrire une nouvelle règle dans votre CDK pour le service particulier que vous exécutez, de l'attacher à ce bus , puis pour tout ce qui touche ce bus, nous ferons le mappage de modèle standard.

Avec cette approche, nous avons un service Braze en cours d'exécution qui dit, hé, je veux écouter les événements utilisateur clés comme les mises à jour des commandes, les enregistrements des clients et une poignée d'autres choses spécifiques, et je veux que ces données soient transmises à Braze, mais sans que tous ces différents microservices soient liés à Braze. EventBridge rend cela possible. De plus, nous avons une rue à double sens. Ainsi, que nous déplacions des données vers Braze ou que nous lancions des webhooks depuis Braze, ils peuvent tous passer par l'architecture principale d'EventBridge.

Nous avons un point d'entrée spécifique pour Braze utilisé par un webhook Braze, qui envoie simplement un événement à EventBridge et dit, hé, je veux lancer cet événement particulier pour cet utilisateur avec ces paramètres. Et ensuite, quels que soient les services que nous avons, nous pouvons écouter cela, puis nous abonner et lancer ce qu'ils veulent.

Alors maintenant, nous avons cette architecture géniale configurée où nous pouvons envoyer des choses à Braze qui sont découplées de tout le reste. Ainsi, notre fonction d'étape d'enregistrement se déclenchera et dira, hé, j'ai créé un nouvel utilisateur, et notre service Braze le recevra. Et il exécute une fonction pas à pas qui dit, hé, je vais faire XYZ et ensuite l'envoyer à Braze. Dans le cadre de cela, nous avons un modèle de rappel - après tout, si la configuration de Braze échoue, il s'agit d'un échec critique, car nous ne pouvons pas terminer l'enregistrement avec succès sans que Braze crée cet utilisateur. De cette façon, si la tâche Braze échoue, la fonction d'étape pour l'enregistrement global échoue. Et tout cela est pris en charge sous le capot par AWS, ce qui est génial.

Quelque chose que je n'ai pas mentionné, c'est que nous avions besoin d'un point d'entrée pour Braze. Nous cherchions à remettre les clés à l'équipe CX afin qu'elle puisse contrôler les actions déclenchées dans notre application. L'une de ces actions consistait à publier des informations. Ce parcours était vraiment lié à notre CRM - il disait, en gros, voici nos événements d'engagement, ce jour-là, publiez cet aperçu, trois jours plus tard, publiez cet aperçu, etc. Et nous voulions changer ce parcours pour qu'il soit plus dynamique pour les utilisateurs .

Pour que cela se produise dans le cadre d'une campagne Braze ou d'un canevas, nous devions être en mesure de présenter des informations sur une base individuelle aux utilisateurs, ce qui signifiait trouver un moyen d'atteindre un point final de notre service pour transférer les bonnes informations. Heureusement, Braze dispose de deux fonctionnalités impressionnantes pour y parvenir : les webhooks et le contenu connecté.

Pendant l'intégration, nous gribouillions, essayant de comprendre comment le faire. Et je suis tombé sur cette vidéo d'AWS qui était littéralement notre cas d'utilisation exact : comment déclencher un webhook à partir d'un service externe qui déclenchera un événement sur EventBridge. Cela a fini par être un didacticiel vidéo étape par étape qui vous explique littéralement comment créer la passerelle API et configurer le bon modèle de mappage. Et si vous la suivez, cette approche vous permettra de prendre l'entrée du corps, de la mapper à un objet de détail EventBridge, puis de l'envoyer à votre bus et c'est tout ; il est maintenant fortement sécurisé avec une clé API. Vous avez maintenant un point d'entrée auquel n'importe qui peut envoyer des données dans le format que vous voulez avec cette authentification, et il se déclenchera sur votre bus d'événements. Et nous étions comme, "C'est parfait."

Que pouvez-vous nous dire sur le point de contact trois et sur la façon dont vous utilisez Braze et votre synchronisation de données Hightouch ?

Le troisième point de contact est super simple. Il utilise simplement Hightouch, Fivetran et certaines autres technologies pour collecter des données à partir d'autres emplacements, les transformer en un format agréable compatible avec l'entrepôt de données, puis les transférer dans Braze de manière continue.

Ceci est vraiment destiné aux données lentes dont j'ai parlé plus tôt; c'est-à-dire des éléments qu'il est important d'avoir mais qui ne deviennent pas moins importants avec le temps, ou des métadonnées supplémentaires, comme le groupe d'âge d'un utilisateur, qui seront utilisées à un moment donné mais qui ne sont pas nécessaires pour le moment. Parce que l'information n'est pas urgente, nous l'avons configurée pour que la synchronisation démarre et demande simplement, en gros, quelque chose a changé ? Oui? Super, voici les deltas. Non? Alors ne rien faire.

Dernières pensées

Vous souhaitez approfondir le côté technique de la plate-forme Braze ? Obtenez des histoires exclusives, des apprentissages et des idées directement de notre organisation produit, conception et ingénierie (PDE) sur le blog du produit Building Braze et explorez les tenants et les aboutissants de notre produit avec la documentation Braze .

*Cette conversion a été modifiée pour plus de longueur et de clarté.