Ask a Developer: myDNA Senior Software Developer Elliott Millar on Integrating Braze, Leveraging AWS EventBridge, and Prioritizing Pre-Project Research
Developers play a key role in ensuring that our customers are able to smoothly integrate and take advantage of the Braze platform to support their marketing efforts. To learn more about the work that developers do in connection with Braze and what their experiences are like, I sat down with Elliott Millar, Senior Software Developer at myDNA, a leading genetic wellness brand. Here’s what he had to say*:
Can you tell us a little bit about myDNA and your role there?
myDNA is a genetic wellness company based out of Melbourne, Australia. We give people advice based on their genetic results. Our customers simply send us their cheek swab and we process their DNA results and give them their DNA insights and recommendations to work with their genetics.
myDNA started with pharmacogenomic products, which can help healthcare practitioners prescribe their patients’ medications more accurately, and this has made a big difference to a lot of lives. Now there’s a lot of rich DNA research showing how genetics affect aspects of our wellness like diet, exercise, sleep, and skin aging—to name a few—so myDNA now has a general wellness product, too; that product gives people their DNA insights and recommendations, plus personalized meal and fitness plans based on their genetic results through our myDNA Unlocked app. This is where Braze comes in. We use Braze to serve this personalized content to our customers via the app to help them change their behaviors and achieve their wellness goals.
I’m the Senior Software Developer at myDNA. I’ve been in the role since October and one of the first projects I led was integrating Braze into myDNA Unlocked. I’m a full-stack developer, so I can work on pretty much anything in our software suite, whether it’s hitting a SQL database, setting up our .net backend, doing things with React Native, or dealing with Objective-C. It doesn’t really matter—drop me in wherever.
You mentioned that integrating Braze was one of your first projects at myDNA—can you talk about what the timeline of that project was like?
Well, I picked it up in November and the process ended up taking three months and a bit, not including the winter holidays. That’s starting once the project was in my hands. Before I got involved, there was an onboarding process where they worked to set up what custom events and custom attributes were being collected with Braze, so all that stuff would be prepared when we got underway. I think that was about six or eight weeks before I started on the project.
Did you do any research before starting on the Braze integration project?
I did a crazy amount of research. I watched something like 20 hours of videos on LAB [Learning at Braze] and read through so many documentation pages—there’s an amazing amount of it—because I needed to know everything about this piece of software; how else would I know if it’s working, or what it’s supposed to do? I also needed to know everything from the perspective of our customer experience (CX) team, since they’re the ones who will primarily be owning Braze. How are we actually going to be using it? How does it work with iOS and Android? At the start, I wasn’t really sure who was going to be taking part in this project, and if I’m leading a project, I need to know everything about what's going on so I can assign work, figure out everything, and get proper estimates.
So I checked out tutorials on Liquid personalization, Connected Content, custom attributes and custom events, how to integrate, what IP warming is and how to do it, how to approach push priming, those kinds of things. Learned a lot of different things to be aware of with Connected Content, like the risk of smashing your own APIs, or how you should use deltas, instead of chewing through 450 million data points just because stuff’s happening in your systems. And in the documentation, there’s everything from how to set up your webhooks to how Braze APIs and SDKs work.
And when I was done, I went and created a section in our Confluence to basically filter down all of this info I was getting from Braze into a nice consumable format for the other devs. That way, even if they needed to get up to speed in 24 hours, all the information they needed was in one central location. I always built out a massive document that diagrammed out our integration with Braze, based on all the research I’d done. So when the time came to do it, I felt prepared.
Can you talk a little bit about why the decision was made to integrate Braze?
With Braze, the business case and everything was done long before my time at myDNA. But from my perspective, there’s a really big benefit in giving our CX team the reins and really allowing them to interact with the customers directly, without any dev interaction or intervention. Our old approach had required a lot of development work to implement and allow new features to go out, which made it harder for the CX team to control what interactions and content was going out to users.
As part of that process, we basically found that there were three main touchpoints we had to figure out when it came to taking advantage of Braze:
Installing the SDK into our mobile app to support the CX team’s control over messaging
Managing fast-moving, time-sensitive data by connecting Braze to AWS EventBridge
Handling less-urgent data by using Braze together with Hightouch, FiveTran, and other technologies
Can you walk us through that first touchpoint, the one related to the SDK and messaging?
Well, before we integrated Braze into our mobile app, we’d been using Expo, which is a tool we used to wrap our app and deploy it to Apple’s App Store and Google Play. Braze doesn’t support Expo, so before we could integrate with Braze, we had to eject Expo and start using a bare workflow. That meant a decent amount of tech debt we had to handle, like setting up a new build pipeline. Plus, in our case, we had to integrate Objective-C for iOS and Java for Android, as well as React Native, in order to get things up and running. That was a big chunk of work, but we had a great team internally to help out and make it all happen. [Note: Braze recently updated our iOS and Android SDKs to leverage Swift and Kotlin, respectively.]
We deployed the mobile app and it all worked, no drama, which was great. And once we got the Braze SDK running in our mobile app, that meant we could use it to capture all the user engagement happening in there. So, it’s firing off custom events when users are interacting with the system, and it’s also obviously receiving help to inform and power all the different messaging channels that the CX team is using, like push notifications, in-app messages, Content Cards, all of that good stuff.
At that point, we were able to move our post-insight journey over to Braze. That’s what we call the flow that happens after one of our customers gets their DNA results. We want our CX team to be able to interact with those customers, to really congratulate them when they’re doing a good job on their meal planning, their workout planning, all that good stuff. The CX team is building out some amazing Canvases to kick off different user journeys across push, in-app messages, Content Cards, and emails.
We did have some issues with push notifications at first, related to the Expo ejection, but we managed to come up with a really awesome way to address them using AWS EventBridge. So, instead of firing push notifications via Expo, we just piped into our EventBridge pipeline, so when Braze goes, hey, I have a custom event to send with our push, the message gets sent out with dynamic content. That bypassed the issue related to Expo, because as soon as a user has a relevant update, Braze will pick up the push token and away they go. But before those Pre- and Post-Insight journeys had been migrated to Braze, everything was able to just keep working as it was through the CRM.
Speaking of EventBridge, can you talk a little about how you’re using that in connection with Braze?
Well, it all started when I was thinking through what sorts of data we were going to need to pull across when it came to Braze. In essence, there’s two different subsets of data that we had to figure out. There’s the really critical stuff that needs to get into Braze ASAP—that’s your timely, fast-moving data. On the other hand, there’s also additional data that really isn’t as time-sensitive, but still needs to be ported into Braze. For the slow-moving stuff, it can go through our Hightouch data sync, which I’ll get to later. But for the fast-moving data, we decided to leverage EventBridge.
What’s fast-moving data? Well, when someone registers for our product, we need them to receive a welcome email from Braze as soon as possible. We have a registration step function that handles this whole pipeline of different things that could be activated for a new user who is registering. As part of that, when the user is set up in our CRM, we need all that information to go over to Braze, so that user can start receiving content, like that welcome email. So we’ve got to figure out a way to get that data across.
As it turned out, EventBridge works really well for that use case. We created a new events repository hosting that AWS architecture, and because we use AWS CDK [Cloud Development Kit] for all our setup and deployment, doing that was super easy. We just created a myDNA event bus in AWS, and we said that if you want to subscribe to it, all you have to do is write a new rule in your CDK for the particular service you're running, get it attached to that bus, and then for anything that hits that bus, we’ll do the standard pattern mapping.
With this approach, we have a Braze service running that says, hey, I want to listen to key user events like order updates, customer registrations, and a handful of other specific things, and I want that data to go across to Braze—but without all those different microservices being tied to Braze. EventBridge makes that possible. Plus, we have a two-way street going. So whether we’re moving data to Braze or having webhooks fired from Braze, they can all go through the main EventBridge architecture.
We have a specific entry point for Braze used by a Braze webhook, which just sends off an event to EventBridge and says, hey, I want to kick off this particular event for this user with these parameters. And then whatever the services are that we have sitting there can listen to that, then subscribe and then kick off what they want.
So now we have this awesome architecture set up where we can send stuff off to Braze that’s decoupled from everything else. So our registration step function will fire and say, hey, I created a new user, and our Braze service will receive that. And it runs a step function that says, hey, I’m going to go do XYZ and then send it off to Braze. As part of that, we have a callback pattern—after all, if the Braze setup fails, that’s a critical failure, since we can’t successfully complete the registration without Braze creating that user. This way, if the Braze task fails, then the step function for overall registration fails. And that’s all just taken care of under the hood by AWS, which is great.
Something I haven’t mentioned is that we needed an entry point for Braze. We were looking to hand over the keys to the CX team so they can have control over what actions are fired in our app. One of those actions was releasing insights. That journey was really tied to our CRM—it would say, basically, here are our engagement events, on this day release this insight, three days later release this insight, etc. And we wanted to change that journey to be more dynamic for users.
To make that happen as part of a Braze campaign or Canvas, we needed to be able to showcase insights on an individual basis to users, and that meant finding a way to hit some endpoint in our service to port in the right information. Thankfully, Braze has two awesome features for making that happen—webhooks and Connected Content.
During the integration, we were doodling around, trying to figure out how to do it. And I stumbled on this video from AWS that was literally our exact use case—how do you fire a webhook from an external service that will trigger an event to EventBridge. It ended up being a step-by-step video tutorial that literally walks you through how to create the API gateway and set up the right mapping template. And if you follow it, this approach will let you take the body input, map it to an EventBridge detail object and then send it off to your bus and that’s it; it’s now strongly secured with an API key. You now have an entry point which anyone can send data to in the format you want with that auth, and it will fire to your event bus. And we were like, “This is perfect.”
What can you tell us about touchpoint three and how you’re using Braze and your Hightouch data sync?
The third touchpoint is super simple. It’s just using Hightouch, Fivetran, and some other technologies to gather data from other locations, transform it into a nice data warehouse-compatible format, and then pipe that into Braze on an ongoing basis.
This is really intended for the slow-moving data I talked about earlier; that is, stuff that’s either important to have but doesn’t become less important to have over time, or additional metadata—you know, like a user’s age group—that will be used at some point but isn’t needed in the moment. Because the information isn’t urgent, we have it set up so the sync kicks off and just asks, basically, has anything changed? Yes? Great, here are the deltas. No? Then do nothing.
Interested in digging deeper into the technical side of the Braze platform? Get exclusive stories, learnings, and insights straight from our product, design, and engineering (PDE) organization at the Building Braze product blog and explore the ins-and-outs of our product with Braze documentation.
*This conversion has been edited for length and clarity.
Michael Ludden is Director of Developer Marketing at Braze, based out of Austin. When he’s not building for developers in his day job, he’s hanging out with his newborn son Liam, his fur buddy Charlie the Golden Retriever, and his lovely wife Tanya. And when he’s not doing those things, he’s probably sleeping.