Pergunte a um desenvolvedor: Elliott Millar, desenvolvedor de software sênior da myDNA, sobre como integrar o Braze, aproveitar o AWS EventBridge e priorizar a pesquisa pré-projeto

Publicados: 2022-04-30

Os desenvolvedores desempenham um papel fundamental para garantir que nossos clientes possam integrar e tirar proveito da plataforma Braze para apoiar seus esforços de marketing. Para saber mais sobre o trabalho que os desenvolvedores fazem em relação ao Braze e como são suas experiências, conversei com Elliott Millar, desenvolvedor de software sênior da myDNA, uma marca líder de bem-estar genético. Aqui está o que ele tinha a dizer*:

Você pode nos contar um pouco sobre myDNA e seu papel lá?

myDNA é uma empresa de bem-estar genético com sede em Melbourne, Austrália. Damos conselhos às pessoas com base em seus resultados genéticos. Nossos clientes simplesmente nos enviam seu esfregaço de bochecha e processamos seus resultados de DNA e damos a eles insights e recomendações de DNA para trabalhar com sua genética.

O myDNA começou com produtos farmacogenômicos, que podem ajudar os profissionais de saúde a prescrever os medicamentos de seus pacientes com mais precisão, e isso fez uma grande diferença para muitas vidas. Agora, há muitas pesquisas ricas de DNA mostrando como a genética afeta aspectos do nosso bem-estar, como dieta, exercícios, sono e envelhecimento da pele – para citar alguns – então o myDNA agora também tem um produto geral de bem-estar; esse produto fornece às pessoas insights e recomendações de DNA, além de planos personalizados de refeições e condicionamento físico com base em seus resultados genéticos por meio do aplicativo myDNA Unlocked. É aqui que entra o Braze. Usamos o Braze para fornecer esse conteúdo personalizado aos nossos clientes por meio do aplicativo para ajudá-los a mudar seus comportamentos e atingir suas metas de bem-estar.

Sou o Desenvolvedor de Software Sênior da myDNA. Estou na função desde outubro e um dos primeiros projetos que liderei foi integrar o Braze ao myDNA Unlocked. Eu sou um desenvolvedor full-stack, então posso trabalhar em praticamente qualquer coisa em nosso pacote de software, seja acessar um banco de dados SQL, configurar nosso backend .net, fazer coisas com React Native ou lidar com Objective-C. Isso realmente não importa - me deixe em qualquer lugar.

Você mencionou que integrar o Braze foi um de seus primeiros projetos no myDNA – você pode falar sobre como era a linha do tempo desse projeto?

Bem, eu peguei em novembro e o processo acabou levando três meses e um pouco, sem contar as férias de inverno. Isso está começando uma vez que o projeto estava em minhas mãos. Antes de me envolver, havia um processo de integração em que eles trabalhavam para configurar quais eventos personalizados e atributos personalizados estavam sendo coletados com o Braze, para que todas essas coisas fossem preparadas quando começássemos. Acho que isso foi cerca de seis ou oito semanas antes de eu começar o projeto.

Você fez alguma pesquisa antes de iniciar o projeto de integração Braze?

Eu fiz uma quantidade louca de pesquisa. Eu assisti algo como 20 horas de vídeos no LAB [Learning at Braze] e li tantas páginas de documentação—há uma quantidade incrível—porque eu precisava saber tudo sobre esse software; de que outra forma eu saberia se está funcionando ou o que deveria fazer? Eu também precisava saber tudo da perspectiva de nossa equipe de experiência do cliente (CX), já que eles são os principais proprietários da Braze. Como vamos realmente usá-lo? Como funciona com iOS e Android? No início, eu não tinha certeza de quem iria participar deste projeto e, se estou liderando um projeto, preciso saber tudo sobre o que está acontecendo para poder atribuir trabalho, descobrir tudo e obter estimativas adequadas.

Então eu verifiquei tutoriais sobre personalização de líquidos, conteúdo conectado, atributos personalizados e eventos personalizados, como integrar, o que é aquecimento de IP e como fazê-lo, como abordar o push priming, esse tipo de coisa. Aprendeu muitas coisas diferentes para estar ciente com o Conteúdo Conectado, como o risco de quebrar suas próprias APIs ou como você deve usar deltas, em vez de mastigar 450 milhões de pontos de dados apenas porque coisas estão acontecendo em seus sistemas. E na documentação, há tudo, desde como configurar seus webhooks até como as APIs e SDKs do Braze funcionam.

E quando terminei, criei uma seção em nosso Confluence para basicamente filtrar todas essas informações que eu estava recebendo do Braze em um bom formato consumível para os outros desenvolvedores. Dessa forma, mesmo que precisassem se atualizar em 24 horas, todas as informações de que precisavam estavam em um local central. Eu sempre construí um documento enorme que diagramava nossa integração com o Braze, com base em todas as pesquisas que fiz. Então, quando chegou a hora de fazer isso, eu me senti preparado.

Você pode falar um pouco sobre por que foi tomada a decisão de integrar o Braze?

Com Braze, o caso de negócios e tudo foi feito muito antes do meu tempo na myDNA. Mas, da minha perspectiva, há um grande benefício em dar as rédeas à nossa equipe de CX e realmente permitir que eles interajam diretamente com os clientes, sem qualquer interação ou intervenção do desenvolvedor. Nossa abordagem antiga exigia muito trabalho de desenvolvimento para implementar e permitir que novos recursos fossem lançados, o que tornava mais difícil para a equipe CX controlar quais interações e conteúdo estavam sendo enviados aos usuários.

Como parte desse processo, basicamente descobrimos que havia três pontos de contato principais que precisávamos descobrir quando se tratava de aproveitar o Braze:

  • Instalando o SDK em nosso aplicativo móvel para dar suporte ao controle da equipe CX sobre as mensagens

  • Gerenciamento de dados rápidos e sensíveis ao tempo conectando o Braze ao AWS EventBridge

  • Manipulação de dados menos urgentes usando Braze junto com Hightouch, FiveTran e outras tecnologias

Você pode nos orientar nesse primeiro ponto de contato, aquele relacionado ao SDK e às mensagens?

Bem, antes de integrarmos o Braze em nosso aplicativo móvel, usávamos o Expo, que é uma ferramenta que usamos para embrulhar nosso aplicativo e implantá-lo na App Store da Apple e no Google Play. O Braze não suporta Expo, então antes de podermos integrar com o Braze, tivemos que ejetar o Expo e começar a usar um fluxo de trabalho simples. Isso significava uma quantidade razoável de dívidas tecnológicas que tínhamos que lidar, como configurar um novo pipeline de construção. Além disso, no nosso caso, tivemos que integrar Objective-C para iOS e Java para Android, bem como React Native, para colocar as coisas em funcionamento. Isso foi um grande trabalho, mas tínhamos uma ótima equipe interna para ajudar e fazer tudo acontecer. [ Nota: o Braze atualizou recentemente nossos SDKs para iOS e Android para aproveitar o Swift e o Kotlin, respectivamente.]

Implantamos o aplicativo móvel e tudo funcionou, sem drama, o que foi ótimo. E assim que o SDK do Braze rodasse em nosso aplicativo móvel, isso significava que poderíamos usá-lo para capturar todo o envolvimento do usuário acontecendo lá. Então, está disparando eventos personalizados quando os usuários estão interagindo com o sistema, e também está obviamente recebendo ajuda para informar e alimentar todos os diferentes canais de mensagens que a equipe CX está usando, como notificações push, mensagens no aplicativo, cartões de conteúdo, todos daquelas coisas boas.

Nesse ponto, fomos capazes de mudar nossa jornada pós-insight para Braze. Isso é o que chamamos de fluxo que acontece depois que um de nossos clientes obtém seus resultados de DNA. Queremos que nossa equipe CX possa interagir com esses clientes, para realmente parabenizá-los quando estiverem fazendo um bom trabalho no planejamento das refeições, no planejamento dos treinos, todas essas coisas boas. A equipe do CX está criando alguns Canvas incríveis para iniciar diferentes jornadas do usuário em push, mensagens no aplicativo, cartões de conteúdo e e-mails.

Tivemos alguns problemas com notificações push no início, relacionados à ejeção da Expo, mas conseguimos encontrar uma maneira realmente incrível de resolvê-los usando o AWS EventBridge. Então, em vez de disparar notificações push via Expo, nós apenas canalizamos para nosso pipeline EventBridge, então quando Braze for, ei, eu tenho um evento personalizado para enviar com nosso push, a mensagem é enviada com conteúdo dinâmico. Isso ignorou o problema relacionado à Expo, porque assim que um usuário tiver uma atualização relevante, o Braze pegará o token de push e partirá. Mas antes que essas jornadas Pré e Pós-Insight fossem migradas para o Braze, tudo podia continuar funcionando como estava por meio do CRM.

Falando em EventBridge, você pode falar um pouco sobre como você está usando isso em relação ao Braze?

Bem, tudo começou quando eu estava pensando em quais tipos de dados precisaríamos obter quando se tratasse de Braze. Em essência, há dois subconjuntos diferentes de dados que tivemos que descobrir. Há o material realmente crítico que precisa entrar no Braze o mais rápido possível - esses são seus dados oportunos e rápidos. Por outro lado, também há dados adicionais que realmente não são tão sensíveis ao tempo, mas ainda precisam ser portados para o Braze. Para as coisas lentas, ele pode passar por nossa sincronização de dados Hightouch, que falarei mais tarde. Mas para os dados em movimento rápido, decidimos aproveitar o EventBridge.

O que são dados em movimento rápido? Bem, quando alguém se registra em nosso produto, precisamos que ele receba um e-mail de boas-vindas da Braze o mais rápido possível. Temos uma função de etapa de registro que lida com todo esse pipeline de coisas diferentes que podem ser ativadas para um novo usuário que está se registrando. Como parte disso, quando o usuário está configurado em nosso CRM, precisamos que todas essas informações passem para o Braze, para que o usuário possa começar a receber conteúdo, como aquele e-mail de boas-vindas. Então, temos que descobrir uma maneira de transmitir esses dados.

Como se viu, o EventBridge funciona muito bem para esse caso de uso. Criamos um novo repositório de eventos que hospeda essa arquitetura da AWS e, como usamos o AWS CDK [Cloud Development Kit] para toda a nossa configuração e implantação, foi super fácil fazer isso. Acabamos de criar um barramento de eventos myDNA na AWS e dissemos que, se você quiser assiná-lo, tudo o que você precisa fazer é escrever uma nova regra em seu CDK para o serviço específico que você está executando, conectá-lo a esse barramento , e então para qualquer coisa que atinja esse barramento, faremos o mapeamento de padrões padrão.

Com essa abordagem, temos um serviço Braze em execução que diz, ei, quero ouvir os principais eventos do usuário, como atualizações de pedidos, registros de clientes e um punhado de outras coisas específicas, e quero que esses dados passem para o Braze, mas sem que todos esses microsserviços diferentes estejam vinculados ao Braze. EventBridge torna isso possível. Além disso, temos uma via de mão dupla. Portanto, se estamos movendo dados para o Braze ou tendo webhooks disparados do Braze, todos eles podem passar pela arquitetura principal do EventBridge.

Temos um ponto de entrada específico para o Braze usado por um webhook do Braze, que apenas envia um evento para o EventBridge e diz, ei, quero iniciar esse evento específico para esse usuário com esses parâmetros. E então, quaisquer que sejam os serviços que temos sentados lá, podem ouvir isso, então se inscrever e então lançar o que eles querem.

Então agora temos essa arquitetura incrível configurada onde podemos enviar coisas para o Braze que são dissociadas de todo o resto. Portanto, nossa função de etapa de registro será acionada e dirá, ei, criei um novo usuário e nosso serviço Braze receberá isso. E ele executa uma função de etapa que diz, ei, vou fazer XYZ e depois enviá-lo para o Braze. Como parte disso, temos um padrão de retorno de chamada - afinal, se a configuração do Braze falhar, isso é uma falha crítica, pois não podemos concluir com êxito o registro sem que o Braze crie esse usuário. Dessa forma, se a tarefa Braze falhar, a função de etapa para o registro geral falhará. E tudo isso é cuidado sob o capô pela AWS, o que é ótimo.

Algo que não mencionei é que precisávamos de um ponto de entrada para Braze. Estávamos procurando entregar as chaves para a equipe CX para que eles pudessem ter controle sobre quais ações são disparadas em nosso aplicativo. Uma dessas ações foi liberar insights. Essa jornada estava realmente ligada ao nosso CRM – basicamente, aqui estão nossos eventos de engajamento, neste dia lançar este insight, três dias depois lançar este insight etc. E queríamos mudar essa jornada para ser mais dinâmica para os usuários .

Para que isso acontecesse como parte de uma campanha ou Canvas do Braze, precisávamos mostrar insights individualmente para os usuários, e isso significava encontrar uma maneira de atingir algum ponto final em nosso serviço para portar as informações corretas. Felizmente, o Braze tem dois recursos incríveis para fazer isso acontecer: webhooks e conteúdo conectado.

Durante a integração, estávamos rabiscando, tentando descobrir como fazer isso. E me deparei com este vídeo da AWS que era literalmente nosso caso de uso exato - como você dispara um webhook de um serviço externo que acionará um evento para EventBridge. Acabou sendo um tutorial em vídeo passo a passo que literalmente orienta você sobre como criar o gateway de API e configurar o modelo de mapeamento correto. E se você a seguir, essa abordagem permitirá que você pegue a entrada do corpo, mapeie-a para um objeto de detalhe EventBridge e depois envie para o seu ônibus e pronto; agora está fortemente protegido com uma chave de API. Agora você tem um ponto de entrada para o qual qualquer pessoa pode enviar dados no formato desejado com essa autenticação, e ele será acionado no seu barramento de eventos. E nós ficamos tipo, “Isso é perfeito”.

O que você pode nos dizer sobre o ponto de contato três e como você está usando o Braze e sua sincronização de dados Hightouch?

O terceiro ponto de contato é super simples. É apenas usar Hightouch, Fivetran e algumas outras tecnologias para coletar dados de outros locais, transformá-los em um formato compatível com data warehouse e, em seguida, canalizá-los para o Braze continuamente.

Isso é realmente destinado aos dados lentos sobre os quais falei anteriormente; ou seja, coisas que são importantes, mas não se tornam menos importantes ao longo do tempo, ou metadados adicionais - você sabe, como a faixa etária de um usuário - que serão usados ​​em algum momento, mas não são necessários no momento. Como a informação não é urgente, nós a configuramos para que a sincronização inicie e apenas pergunte, basicamente, alguma coisa mudou? Sim? Ótimo, aqui estão os deltas. Não? Então não faça nada.

Pensamentos finais

Interessado em aprofundar o lado técnico da plataforma Braze? Obtenha histórias, aprendizados e insights exclusivos diretamente de nossa organização de produto, design e engenharia (PDE) no blog do produto Building Braze e explore os detalhes de nosso produto com a documentação do Braze .

*Esta conversão foi editada por motivos de duração e clareza.