Chiedi a uno sviluppatore: Elliott Millar, sviluppatore software senior di myDNA sull'integrazione di Braze, sull'utilizzo di AWS EventBridge e sulla priorità della ricerca pre-progetto
Pubblicato: 2022-04-30Gli sviluppatori svolgono un ruolo chiave nel garantire che i nostri clienti siano in grado di integrare senza problemi e sfruttare la piattaforma Braze per supportare i loro sforzi di marketing. Per saperne di più sul lavoro svolto dagli sviluppatori in relazione a Braze e su come sono le loro esperienze, mi sono seduto con Elliott Millar, Senior Software Developer presso myDNA, un marchio leader nel benessere genetico. Ecco cosa aveva da dire*:
Puoi parlarci un po' di myDNA e del tuo ruolo lì?
myDNA è un'azienda di benessere genetico con sede a Melbourne, in Australia. Diamo consigli alle persone in base ai loro risultati genetici. I nostri clienti ci inviano semplicemente il loro tampone guanciale e noi elaboriamo i risultati del loro DNA e forniamo loro informazioni e consigli sul DNA per lavorare con la loro genetica.
myDNA è iniziato con prodotti farmacogenomici, che possono aiutare gli operatori sanitari a prescrivere i farmaci ai loro pazienti in modo più accurato, e questo ha fatto una grande differenza in molte vite. Ora c'è un sacco di ricca ricerca sul DNA che mostra come la genetica influenzi aspetti del nostro benessere come dieta, esercizio fisico, sonno e invecchiamento della pelle, solo per citarne alcuni, quindi myDNA ora ha anche un prodotto per il benessere generale; quel prodotto fornisce alle persone informazioni e consigli sul DNA, oltre a piani personalizzati di pasti e fitness basati sui loro risultati genetici attraverso la nostra app myDNA Unlocked. È qui che entra in gioco Braze. Usiamo Braze per offrire questo contenuto personalizzato ai nostri clienti tramite l'app per aiutarli a cambiare i loro comportamenti e raggiungere i loro obiettivi di benessere.
Sono lo sviluppatore software senior presso myDNA. Sono nel ruolo da ottobre e uno dei primi progetti che ho condotto è stato l'integrazione di Braze in myDNA Unlocked. Sono uno sviluppatore full-stack, quindi posso lavorare praticamente su qualsiasi cosa nella nostra suite di software, sia che si tratti di colpire un database SQL, configurare il nostro back-end .net, fare cose con React Native o gestire Objective-C. Non importa davvero, lasciami entrare ovunque.
Hai menzionato che l'integrazione di Braze è stato uno dei tuoi primi progetti su myDNA: puoi parlare di come era la sequenza temporale di quel progetto?
Bene, l'ho ritirato a novembre e il processo ha richiesto tre mesi e un po', escluse le vacanze invernali. Questo inizia una volta che il progetto è stato nelle mie mani. Prima di essere coinvolto, c'è stato un processo di onboarding in cui hanno lavorato per impostare gli eventi personalizzati e gli attributi personalizzati che venivano raccolti con Braze, in modo che tutte le cose sarebbero state preparate quando siamo partiti. Penso che siano state circa sei o otto settimane prima che iniziassi il progetto.
Hai fatto qualche ricerca prima di iniziare il progetto di integrazione Braze?
Ho fatto una quantità pazzesca di ricerche. Ho guardato qualcosa come 20 ore di video su LAB [Learning at Braze] e ho letto così tante pagine di documentazione - ce n'è una quantità incredibile - perché avevo bisogno di sapere tutto su questo software; in quale altro modo potrei sapere se funziona o cosa dovrebbe fare? Avevo anche bisogno di sapere tutto dal punto di vista del nostro team di customer experience (CX), dal momento che sono quelli che possederanno principalmente Braze. Come lo useremo effettivamente? Come funziona con iOS e Android? All'inizio, non ero davvero sicuro di chi avrebbe preso parte a questo progetto, e se sto guidando un progetto, ho bisogno di sapere tutto su quello che sta succedendo in modo da poter assegnare il lavoro, capire tutto e ottenere stime adeguate.
Quindi ho controllato i tutorial sulla personalizzazione dei liquidi, il contenuto connesso, gli attributi personalizzati e gli eventi personalizzati, come integrare, cos'è il riscaldamento IP e come farlo, come avvicinarsi al push priming, questo tipo di cose. Ho imparato molte cose diverse di cui essere a conoscenza con Connected Content, come il rischio di distruggere le tue API o come dovresti usare i delta, invece di masticare 450 milioni di punti dati solo perché stanno accadendo cose nei tuoi sistemi. E nella documentazione, c'è tutto, da come configurare i tuoi webhook a come funzionano le API Braze e gli SDK.
E quando ho finito, sono andato e ho creato una sezione nella nostra Confluence per filtrare sostanzialmente tutte queste informazioni che stavo ottenendo da Braze in un bel formato consumabile per gli altri sviluppatori. In questo modo, anche se avevano bisogno di mettersi al passo in 24 ore, tutte le informazioni di cui avevano bisogno erano in un'unica posizione centrale. Ho sempre creato un enorme documento che illustrava la nostra integrazione con Braze, sulla base di tutte le ricerche che avevo fatto. Quindi, quando è arrivato il momento di farlo, mi sono sentito preparato.
Puoi parlare un po' del motivo per cui è stata presa la decisione di integrare Braze?
Con Braze, il business case e tutto è stato fatto molto prima del mio tempo in myDNA. Ma dal mio punto di vista, c'è davvero un grande vantaggio nel dare le redini al nostro team CX e consentire loro di interagire direttamente con i clienti, senza alcuna interazione o intervento da parte degli sviluppatori. Il nostro vecchio approccio richiedeva molto lavoro di sviluppo per implementare e consentire l'uscita di nuove funzionalità, il che rendeva più difficile per il team CX controllare quali interazioni e contenuti venivano inviati agli utenti.
Come parte di questo processo, abbiamo fondamentalmente scoperto che c'erano tre punti di contatto principali che dovevamo capire quando si trattava di sfruttare Braze:
Installazione dell'SDK nella nostra app mobile per supportare il controllo del team CX sulla messaggistica
Gestione dei dati in rapido movimento e sensibili al tempo collegando Braze ad AWS EventBridge
Gestione dei dati meno urgenti utilizzando Braze insieme a Hightouch, FiveTran e altre tecnologie
Puoi guidarci attraverso il primo punto di contatto, quello relativo all'SDK e alla messaggistica?
Bene, prima di integrare Braze nella nostra app mobile, utilizzavamo Expo, che è uno strumento che abbiamo utilizzato per avvolgere la nostra app e distribuirla su App Store di Apple e Google Play. Braze non supporta Expo, quindi prima che potessimo integrarci con Braze, abbiamo dovuto espellere Expo e iniziare a utilizzare un semplice flusso di lavoro. Ciò significava una discreta quantità di debito tecnologico che dovevamo gestire, come la creazione di una nuova pipeline di costruzione. Inoltre, nel nostro caso, abbiamo dovuto integrare Objective-C per iOS e Java per Android, oltre a React Native, per far funzionare le cose. È stata una grossa fetta di lavoro, ma internamente abbiamo avuto una grande squadra per aiutare e far sì che tutto accadesse. [ Nota: Braze ha recentemente aggiornato i nostri SDK iOS e Android per sfruttare rispettivamente Swift e Kotlin.]
Abbiamo distribuito l'app mobile e tutto ha funzionato, nessun dramma, il che è stato fantastico. E una volta che Braze SDK è in esecuzione nella nostra app mobile, ciò significava che potevamo usarlo per catturare tutto il coinvolgimento degli utenti che si verificava lì. Quindi, attiva eventi personalizzati quando gli utenti interagiscono con il sistema e ovviamente riceve anche aiuto per informare e potenziare tutti i diversi canali di messaggistica che il team CX sta utilizzando, come notifiche push, messaggi in-app, schede contenuti, tutto di quella roba buona.
A quel punto, siamo stati in grado di spostare il nostro viaggio di approfondimento su Braze. Questo è ciò che chiamiamo il flusso che si verifica dopo che uno dei nostri clienti ha ottenuto i risultati del DNA. Vogliamo che il nostro team CX sia in grado di interagire con quei clienti, di congratularsi davvero con loro quando stanno facendo un buon lavoro sulla pianificazione dei pasti, sulla pianificazione dell'allenamento, tutte quelle cose buone. Il team CX sta costruendo alcune fantastiche Canvas per dare il via ai diversi viaggi degli utenti attraverso push, messaggi in-app, schede contenuti ed e-mail.
All'inizio abbiamo riscontrato alcuni problemi con le notifiche push, relative all'espulsione di Expo, ma siamo riusciti a trovare un modo davvero fantastico per risolverli utilizzando AWS EventBridge. Quindi, invece di inviare notifiche push tramite Expo, abbiamo semplicemente reindirizzato la nostra pipeline EventBridge, quindi quando Braze va, ehi, ho un evento personalizzato da inviare con il nostro push, il messaggio viene inviato con contenuto dinamico. Ciò ha aggirato il problema relativo a Expo, perché non appena un utente ha un aggiornamento pertinente, Braze raccoglierà il token e se ne andrà. Ma prima che i viaggi Pre- e Post-Insight fossero migrati a Braze, tutto poteva semplicemente continuare a funzionare come era attraverso il CRM.
A proposito di EventBridge, puoi parlare un po' di come lo stai usando in relazione a Braze?
Bene, tutto è iniziato quando stavo riflettendo sul tipo di dati che avremmo dovuto raccogliere quando si trattava di Braze. In sostanza, ci sono due diversi sottoinsiemi di dati che dovevamo capire. Ci sono le cose davvero critiche che devono entrare in Braze al più presto: sono i tuoi dati tempestivi e in rapido movimento. D'altra parte, ci sono anche dati aggiuntivi che in realtà non sono così sensibili al tempo, ma devono comunque essere trasferiti in Braze. Per le cose lente, può passare attraverso la nostra sincronizzazione dei dati Hightouch, di cui parlerò più avanti. Ma per i dati in rapido movimento, abbiamo deciso di sfruttare EventBridge.
Cosa sono i dati in rapido movimento? Bene, quando qualcuno si registra per il nostro prodotto, abbiamo bisogno che riceva un'e-mail di benvenuto da Braze il prima possibile. Abbiamo una funzione di fase di registrazione che gestisce l'intera pipeline di cose diverse che potrebbero essere attivate per un nuovo utente che si sta registrando. Come parte di ciò, quando l'utente è configurato nel nostro CRM, abbiamo bisogno di tutte queste informazioni per passare a Braze, in modo che l'utente possa iniziare a ricevere contenuti, come quell'e-mail di benvenuto. Quindi dobbiamo trovare un modo per far passare quei dati.
Come si è scoperto, EventBridge funziona davvero bene per quel caso d'uso. Abbiamo creato un nuovo repository di eventi che ospita l'architettura AWS e, poiché utilizziamo AWS CDK [Kit di sviluppo cloud] per tutta la nostra configurazione e distribuzione, farlo è stato semplicissimo. Abbiamo appena creato un bus di eventi myDNA in AWS e abbiamo detto che se vuoi iscriverti ad esso, tutto ciò che devi fare è scrivere una nuova regola nel tuo CDK per il particolare servizio che stai eseguendo, collegarlo a quel bus , e quindi per tutto ciò che colpisce quel bus, eseguiremo la mappatura del modello standard.
Con questo approccio, abbiamo un servizio Braze in esecuzione che dice, ehi, voglio ascoltare gli eventi chiave degli utenti come aggiornamenti degli ordini, registrazioni dei clienti e una manciata di altre cose specifiche, e voglio che i dati vengano trasmessi a Braze, ma senza che tutti quei diversi microservizi siano legati a Braze. EventBridge lo rende possibile. Inoltre, abbiamo una strada a doppio senso. Quindi, sia che stiamo spostando i dati su Braze o che i webhook vengano attivati da Braze, possono passare tutti attraverso l'architettura EventBridge principale.
Abbiamo un punto di ingresso specifico per Braze utilizzato da un webhook Braze, che invia semplicemente un evento a EventBridge e dice, ehi, voglio dare il via a questo particolare evento per questo utente con questi parametri. E poi, qualunque sia il servizio che abbiamo seduto lì, può ascoltarlo, quindi iscriversi e quindi dare il via a ciò che vogliono.
Quindi ora abbiamo questa fantastica architettura configurata in cui possiamo inviare materiale a Braze che è disaccoppiato da tutto il resto. Quindi la nostra funzione di registrazione si attiverà e dirà, ehi, ho creato un nuovo utente e il nostro servizio Braze lo riceverà. E esegue una funzione di passaggio che dice, ehi, vado a fare XYZ e poi lo spedisco a Braze. Come parte di ciò, abbiamo un modello di callback: dopotutto, se l'installazione di Braze non riesce, si tratta di un errore critico, poiché non possiamo completare correttamente la registrazione senza che Braze crei quell'utente. In questo modo, se l'attività Braze ha esito negativo, la funzione di passaggio per la registrazione generale non riesce. E questo è tutto appena curato da AWS, il che è fantastico.
Qualcosa che non ho menzionato è che avevamo bisogno di un punto di ingresso per Braze. Stavamo cercando di consegnare le chiavi al team CX in modo che possano avere il controllo su quali azioni vengono attivate nella nostra app. Una di queste azioni è stata il rilascio di approfondimenti. Quel viaggio era davvero legato al nostro CRM: direbbe, in pratica, ecco i nostri eventi di coinvolgimento, in questo giorno rilasciamo questa intuizione, tre giorni dopo rilasciamo questa intuizione, ecc. E volevamo cambiare quel viaggio per essere più dinamico per gli utenti .
Affinché ciò accadesse come parte di una campagna Braze o Canvas, dovevamo essere in grado di mostrare agli utenti informazioni dettagliate su base individuale e ciò significava trovare un modo per raggiungere un endpoint nel nostro servizio per trasferire le informazioni giuste. Per fortuna, Braze ha due fantastiche funzionalità per farlo accadere: webhook e contenuto connesso.
Durante l'integrazione, stavamo scarabocchiando, cercando di capire come farlo. E mi sono imbattuto in questo video di AWS che era letteralmente il nostro caso d'uso esatto: come si attiva un webhook da un servizio esterno che attiverà un evento su EventBridge. Alla fine è stato un tutorial video passo-passo che ti guida letteralmente attraverso come creare il gateway API e impostare il modello di mappatura giusto. E se lo segui, questo approccio ti consentirà di prendere l'input del corpo, mapparlo su un oggetto di dettaglio EventBridge e quindi inviarlo al tuo bus e il gioco è fatto; ora è fortemente protetto con una chiave API. Ora hai un punto di ingresso a cui chiunque può inviare dati nel formato desiderato con quell'autorizzazione e si attiverà sul bus dell'evento. E noi dicevamo: "Questo è perfetto".
Cosa puoi dirci sul touchpoint tre e su come stai utilizzando Braze e la sincronizzazione dei dati Hightouch?
Il terzo punto di contatto è semplicissimo. Sta solo usando Hightouch, Fivetran e alcune altre tecnologie per raccogliere dati da altre posizioni, trasformarli in un bel formato compatibile con il data warehouse e quindi inviarli a Braze su base continuativa.
Questo è davvero inteso per i dati a movimento lento di cui ho parlato prima; cioè, cose che sono importanti da avere ma che non diventano meno importanti da avere nel tempo, o metadati aggiuntivi, come la fascia di età di un utente, che verranno utilizzati a un certo punto ma non sono necessari al momento. Poiché le informazioni non sono urgenti, le abbiamo impostate in modo che la sincronizzazione inizi e ci venga chiesto, in pratica, è cambiato qualcosa? Sì? Ottimo, ecco i delta. No? Allora non fare niente.
Pensieri finali
Interessato a scavare più a fondo nel lato tecnico della piattaforma Braze? Ottieni storie esclusive, apprendimenti e approfondimenti direttamente dalla nostra organizzazione di prodotti, design e ingegneria (PDE) sul blog del prodotto Building Braze ed esplora i dettagli del nostro prodotto con la documentazione Braze .
*Questa conversione è stata modificata per lunghezza e chiarezza.