Ready to get your game on?
In this Braze Innovation Series session, we show how brands can use gamification to spark curiosity, inspire repeat behavior, and unlock richer first-party data — without heavy development lifts or unmanageable timelines.
We break down the real magic behind high-performing gamified experiences, including:
- Why gamification works — and how simple mechanics like streaks, challenges, and rewards can transform passive scrolling into meaningful action.
- How to concept and design experiences that resonate, from the initial idea to polished creative that feels native to your brand.
- What it takes to build games directly inside Braze, using custom code IAMs, dynamic logic, and real-time behavioral data.
- How to measure the impact, so you can prove (and improve) performance with clear, actionable KPIs.
This on-demand session is packed with examples, frameworks, and practical techniques your team can use right away. If you’re exploring new ways to boost engagement, create more opportunities for personalization, and deliver experiences customers actually want, this is the perfect place to start.
Transcript:
All right. Thank you everybody for joining our installment of the Braze Innovation Series, where we’ll be diving into all things gamification. I’m really excited for the folks who’ve joined today to walk through a couple of key components of how we think about gamification.
Today on the call is myself — my name is Bobby Tichy, I’m the chief solutions officer here at Stitch — and I’m also joined by Scott, Rick, Hannah, and Mike. Scott is a marketing strategist on our team. Rick is a technical producer along with Hannah. And then Mike is a solution architect on our team as well.
As we’re going through, if you all have questions, feel free to go ahead and throw them in the chat. Don’t feel like you have to wait until the end, and we’ll get to them throughout the time today. And if we don’t get to them, we’ll get to them at the end of the webinar itself.
There are going to be four key things that we chat through today. First is more around strategy — why gamification, why we think it’s an important strategy to begin with, but then how do you even start to think about what a game should look like for you and for your customers. Next is actually designing the gamification experience. Then we’ll talk through building the game itself and what that looks like in and around Braze. And then lastly, we’ll talk through measuring success. So how do we make sure that based on everything that we do and everything that we build in the game, we’re able to report on it and see if it was successful or not?
So to kick us off, Scott, I’ll kick it over to you to start talking through how we set the strategy for gamification.
Yeah, thanks Bobby. Thanks everyone for being here to hear me nerd out about gamification strategy. So, what is gamification? It is really just motivation through design. It’s building specific rewards, intuitive actions, and fun experiences for our customers to really get them to exhibit the behavior we want them to. So it’s giving them familiar mechanics — points, milestones, achievement streaks — to help them see progress and recognize the value of their actions through whatever experience you’ve put them through.
So this makes our customers more inclined to return, explore, and take action, giving those clear signals and providing meaningful touch points. The result of this, which we would love to see for you in the future, is higher engagement, richer data, stronger activation, and deeper loyalty experiences.
So, why does gamification matter from a business perspective? We know it boosts engagement and retention, so interactive experiences encourage users to stay active and return to your app. We know it drives conversion, so gamified incentives create more urgency and motivate purchases or desired actions. It enhances the personalization aspect, so we can have dynamic gamification that adapts to user behavior, providing tailored experiences that increase relevance and effectiveness. And it collects valuable first-party or zero-party data that you’re looking for to learn more about your customers and provide better segmentation. But the overall goal of what it does for you is create a better user experience and a better customer experience.
So the four major components when we start to look at how do we actually build the game are, first, we’re talking about defining strategy. So we really want to clarify what we’re gamifying, why, and what business problem it’s going to solve. We need to set some clear goals and objectives with what we’re going to do. So when we move on to designing the experience — which is establishing the game world, how the game actually works, if there’s an emotional arc over a long-term game that we want players to feel and follow, that they understand the rule structure and mechanics that we’re asking them to complete, the narrative and story, as well as the different player types that exist and how personalization applies to it — we should also definitely be including legal and finance in this.
When we think about building from a core components perspective and the things that we have to stack out to actually make this experience engaging and sticky, we’re looking at rewards and incentives, we’re looking at the progression and feedback model, challenges and competition that we can layer in there, and how we relate this back to social interaction on a broader scale. Lastly, we look at the iterate and optimize phase. So we measure, refine, and improve long-term engagement through a continuous feedback loop.
Is there such a thing as a too simple or too complex game?
I think you can definitely go too complex. Where if we have multiple steps in a game where the rules are unclear, or you’re really trying to stretch it out — like you have to do 37 different things — that’s going to lose a lot of people and they’re not going to get to the reward. When you go simple, you can start very, very simple and get people used to building this ecosystem out. So there’s too complex. I wouldn’t say there is too simple.
Awesome. Thanks.
Right. So, what types of gamification can you actually build once you’ve established the strategy and the upfront thinking about design, narrative, and how rewards could play into this? So there are four main types.
The first one is progression. So this is around pathing and habit building. We really want to guide users towards a high value, repeat behavior. This meets various business objectives, whether it’s retention, habit formation, increased visit frequency, or purchase frequency. And some example mechanics that you can layer in here are levels and streaks.
The next one we move on to is education and mastery. So this is providing that real value unlock of your brand. We show users how to get to key behavior faster and really reinforce that. So this is around feature adoption, reducing confusion, lowering the friction point for customers, and that can be everything from a tutorial, a quiz, or an achievement milestone.
Then we move on to enjoyment. So this is around play and delight. This is creating that intrinsic fun experience and really engaging with your brand and having your brand being seen in a different light. So this leads to high session engagement, emotional affinity, and a positive brand score. This is mini-games, seasonal events, and randomness and collectibles that you insert. This is for the fans, if you will.
And then when we move on to social status, this is around competition and community, so really trying to motivate users through recognition and shared experiences. This is around network effects, viral amplification, and long-term stickiness within your brand, and this is best represented through leaderboards or community goals.
Not necessarily as a strategist, but as a consumer, what is your favorite type of game?
I mean, if you want to get deep into how games are actually built, there are generally different types of audiences you build for. I’m a big fan of enjoyment, just because who doesn’t love a fun game? From a business perspective — always going back to being a strategist — I think progression is really helpful for building those habits and getting users stickier within your program.
See, I love the — I don’t know that Taco Bell meant it to be a competition, but when they launched earlier this year the “Are you Cantina or are you Caliente?” quiz, everybody at Stitch was doing it to figure out which one they were because everyone wanted to be Caliente. I thought that was hilarious.
Yeah.
Yeah. And so here are some mock-ups of different types of games and gamified experiences you can create. So we have a great swipe example here. This is really good for collecting preference data on users. What seems like a simple action of “I’m this” or “I’m that” is really helping us generate a better understanding of who you are as a user, and then we can do follow-up comms around that.
Spin to win is another really great one, especially in the retail or hospitality space. If you’re trying to really get users to feel like they’re getting something unique — even if it will always flip to 10% off — the option of feeling like you could win something more is a great motivator.
We see progression on the next one, which is great for just about any brand if you’re looking at progressive profiling or finding ways to motivate users to give you more of that zero-party data and buy into your brand longer as a process.
And then matching games are just a ton of fun in the QSR space, where you’re specifically having users get more familiar with individual products that you have while also trying to win something as a reward — which is a product from your QSR brand. So it’s a great way to just reinforce the value there.
And lastly, when we’re talking about all the pieces that need to be involved in the up-front strategy piece, we know that CRM teams are not on an island by themselves and often work with a ton of different cross-functional partners. So really trying to get everyone to buy in on the experience you’re building, knowing that you’ll rely on your data and analytics team, your loyalty team, your e-commerce team, your legal and finance team heavily, as well as your creative team to produce assets, and your product team to actually get the game live. It takes a village, so just being very mindful of those constraints as they come forward.
Awesome. Thanks, Scott. So as we think about the strategy, we’ve got a good foundation there of what kinds of games there are, why we should do these games, the different benefits they give us as a brand but also to our customers. Next, we think about how do we actually design that experience? So, Hannah, I’ll kick it over to you to start walking us through how to concept and create these games.
Awesome. Thank you. So like Scott just walked us through, all the way from strategy to being able to see some end examples, this is everything that’s going to be in between. So at the beginning, the kind of requirements you always want to keep top of mind is definitely that you’re solving your goal for your business, that your timeline is realistic, and all the dev that goes into it. Make sure that if it’s a game revolved around a limited time offering, or if it’s something that’s always going to be available, you keep the timeline top of mind. As Bobby had touched on, how simple or how complex that timeline will define a lot of those things.
Next, when you move to that proof of concept, making sure that the development is possible, making sure that it flows with the brand and with the look of the app. If it goes full screen or if it’s partial screen, making sure whatever is showing in the background complements the game and doesn’t distract from it.
So next, you’ll go to starting to make those wireframes, really bringing that game to life. With the wireframes, you want to keep in mind that if it’s a mobile game, your screen size is going to vary. Rick goes into more depth on this on the next slide, but just making sure that it’s always accessible as you’re building out that design. As you move from wireframes to high-fidelity mock-ups, make sure that your text is always readable, that your legal copy is always where it needs to be and is accessible. But also making sure that if there are animations, we go through a few different approaches for animations and transitions. Make sure to test those ones in the app to make sure it gives the ideal user experience and doesn’t come off as too busy or too distracting when you actually test it.
And then next, which we touch on more, is the development — so rapid prototyping. This is where collaboration between design and the devs comes in handy a lot, so that way you can test and make sure your transition isn’t too distracting. “What are our other options?” Design can hop in and help optimize it for that ideal user experience.
I think that step one to step two is really important, because I think a lot of times we might come up with a great idea, or a client might come up with a great idea, and then we build it out in a proof of concept and we realize, oh, it’s not nearly as great as what we thought it was. So we’ve got to make a small tweak before we keep going.
Yeah, 100%.
Now I’ll pass it off to Rick.
Okay. I’ll jump in. Yeah. Unless you have more to add.
All you.
Okay. So there’s a ton of information on this slide. I think this might be our most info-heavy slide that we have today. I’m not going to cover each bullet point here — there’s just a lot to cover — but I’m going to try to hit the highlights.
So a big part of making an impactful interactive experience is knowing when and how to use a specific technology — like when to use a programmatic animation such as HTML, CSS, or JavaScript, and when to use an animated GIF. We’ll talk a little bit about this later on as well.
Having a background in both design and development is not necessary. I kind of want to emphasize this up front. It is my background — I actually started out as a designer. Way back in the day, we were web designers, and web designers would end up becoming web developers too. Part of that now, of course, is that we have front-end development, back-end development, and robust development teams. A lot of that is really specified in specific silos. And when we’re developing the way that we do with IAMs, I think it’s best to get rid of those silos. We want to work very closely together both as designers and developers. So it’s not required that we have a background in both, but it’s really, really helpful.
And as a result of that, we have an opportunity as designers working as developers — or developers in this case working as designers — to design with development in mind. So we can create our assets for production knowing what our dimensions are going to be, our file size budgets. We’re making our animations easy to use, whether we’re doing it with a programmatic solution or as a GIF animation. We’re thinking about how the elements are going to live inside of that page, within the HTML DOM, how they’re going to render — and that’s not just a hierarchy of rendering, but also how the elements are going to layer on top of each other. Whether we should preload images, whether we should use a sprite sheet to reduce HTTP requests — these are all things that we need to think about as designers going into development for these experiences, especially within Braze.
We have to make sure that we live within the limitations that are set within that platform. And it’s a very robust platform. Effectively, if you can think it, we can do it. But it still does have a five megabyte requirement, so we have to make sure that all of the code and images and everything that we use lives within five megabytes. That’s kind of one of the big challenges that we have, one of the things that we have to consider, especially as designers. And that’s why we want to think about those things right up front. It’s very important for us to put all that up front in our design process so that we’re designing and then exporting those assets in a way that can be used effectively.
Rick, there are a couple of abbreviations and acronyms on this slide, like HTML DOM and WCAG. Could you explain those a little bit more?
Sure. So the DOM is the Document Object Model, and basically without getting too technical, it’s the way that when a web page is loaded, it renders the elements on a page. So everything is nested within HTML tags, and those could be text, paragraphs. We use DIVs a lot — DIVs are just a divisional area that allow us to specify something. They can make a background color, we can overlap things with them. DIVs are very powerful.
HTML5 introduced a whole host of very specific objects that we can use within HTML. I think the big one is probably video, and we can use those here too. That’s all part of what we can do within the DOM. So when I say the DOM, what I’m really referring to is the way that the objects are rendering on screen, either within a website in a traditional sense or within the in-app experience. Everything that you see there is effectively part of a web page.
Got it. Awesome. Okay, great. And then what about WCAG?
Oh yeah. So WCAG — that stands for… I apologize that I don’t actually have the full name. Web… something. Basically, they’re an organization that defines best practices web developers should be using to render things for people who might have disabilities or need extra assistance in viewing a web page. We’re talking about things like text sizes, colors — color contrast is very important, having enough color contrast.
When we’re designing for these, those are things that we’re taking into account right off the bat. This is all part of that rapid prototyping, and I’ll talk about this in a little bit as well, where we’re making sure that we build with accessibility in mind. And the WCAG is the organization that defines those accessibility standards. They have three different rating systems — A, double A, and triple A. Triple A is very restrictive, so the higher that you go, the more restrictive it becomes. We shoot for AA, which is the industry standard. Almost every organization that I’ve ever worked with goes for AA compliance. AAA would be for organizations where people with accessibility issues are specifically their main demographic. So we want to make sure that we’re giving ourselves the freedom to make something really pretty, but also still taking into account that people with disabilities or accessibility issues have an opportunity to use the experience the way that we want them to. Finding that balance is kind of the trick, and that’s where the AA comes in.
Okay, great. And why don’t you jump into the rapid prototype mindset next?
Yeah, yeah. So let’s talk about rapid prototyping. This is a fun concept. Back in the day, we had web designers who were acting as both designers and developers. Rapid prototyping is kind of going back to that same mindset, where we have a small team — whether it is a single individual or a small group — but they have to work closely together, and that’s the key. It’s really kind of an agile system — a literal agile mindset, not necessarily an agile workflow. But that all happens together, right?
A lot of that design and development and even the conceptualization — what Scott was mentioning — is all happening with overlapping roles. So we have designers working as strategists, and then they take those and create assets for development purposes. They’re handing off assets that can be dropped right into Braze that we can use immediately within our web applications — formatted the correct size, using the right colors, that sort of thing.
And so having this rapid prototyping mindset means that as you’re designing, you’re also developing at the same time. Those roles overlap. And strategy can be part of that too — this idea doesn’t work, let’s try a different idea, we’re rebuilding this system so that it looks a little different and operates in a different way. That’s all what’s happening within that rapid prototyping mindset.
Now, it is more waterfall. I made a joke about it being agile and it’s not agile. I wouldn’t recommend this to larger development teams. This works best for something like an in-app message, where you have a smaller group of highly talented individuals working on creating something quickly. That’s where that “rapid” comes in. So that’s kind of the rapid prototyping mindset.
Hannah, is there anything else I should add with this? Or Bobby, did you have a…
Oh, no, I was actually going to ask Hannah — as you’re thinking about IAMs, especially versus email, what are the kind of big differences or extra flexibility that you have within IAM?
You have so much flexibility. It’s so nice. You can make code so pretty, you don’t have to worry about tables. It’s so great. You can have animations. The five megabyte limit is still there, but you have a lot more flexibility. You can use JavaScript to get the pretty swipes. You’re not just restricted to GIFs, where GIFs default on some email clients to just showing the first frame. You have that flexibility as long as you test it.
A big thing with this rapid prototyping is why we always prefer it — so that way if we need to pivot on something, you know as soon as possible, which helps the timeline not drag out. Like you had touched on earlier, when we build games, a lot of us hop in because we’re excited to play it. We’re all excited to test it. You’re kind of killing two birds with one stone. We share it with everybody at Stitch because we’re all excited to see it since the stuff’s always cool, but then we’re also testing on multiple devices and all different screen sizes. People all have different user experiences. So where my eye goes might not be the exact same place where Rick’s eye goes.
I personally, knowing that I have a background in UX testing, like to try and break it. I’ll see if I click somewhere random on the screen — does it break it? It usually doesn’t because Rick and Mike have already tested that. And so making sure that the data is logging correctly when someone does a really weird user experience, that all comes into play when you do that rapid prototyping because you’re able to catch those things early on if you need to.
Awesome. Great. Thank you both. Pivoting now — we’ve gone through the process of not only the strategy, but then how we start to think about the game, how we design it, and build out that rapid prototype. Mike, we’ll kick it over to you to start talking through how we actually build the game, shortly after I walk through the anatomy of these games.
So like I said, we’ve walked through the strategy, we’ve walked through the design. So how do we actually go about building these games inside of Braze? And Rick mentioned it earlier that anything that you can think of within an in-app message, you can essentially do within Braze. And that’s what’s really nice about the complexity and power of Braze.
But especially if you’re starting with your first IAM, it will likely be better to start with an out of the box template. The main reason being is you don’t want to put a lot of time and effort into something you’re not sure your audience or customers will be receptive to. So there’s a good conversation around, is this going to be an out of the box gamification or IAM? Or is this going to be something that we really build out that’s going to be custom and be a multi-level type of experience?
So we want to think about all those things as we’re going into the game. The next thing is about data collection and how we actually leverage that data. Every single thing that you do inside of a game — so for example the swipe game, every time you swipe left or swipe right — every single one of those situations is then cataloged and recorded inside of Braze. That’s really important because we might need someone to finish the game or take a certain number of actions. Every single action that they take, we can then write to their Braze profile and use it for future reference, which is also really important because it’s not only important to think about the design or the prototype of the game — we want to think about what happens after the game.
So for example, if there is a matching game and someone matches fries or a burger or something like that, we want to take that and then put them down another journey or experience that’s similar to that. We don’t want it to just stop right there, right? We want to think about the whole lifecycle of our customer and how they’re interacting with our brand. So it’s really important to not only have the game but then also think about what’s going to happen next after the game.
And then lastly is integration with the rest of your stack. Especially when we’re thinking about types of games that might reward points or dollars or anything like that, we want to make sure it’s interconnected with our CDP, our loyalty platform, as well as our data warehouse and analytics tool, so that way we can measure it the right way and see if it was successful, and then use that as a starting point for our next game as well.
So, what this can look like — Mike, I’ll kick it over to you to walk through the left-hand side here of how these games really come to life.
Yeah. Awesome. Thank you so much, Bobby. So in this slide, I’ll talk a little bit about what a Braze in-app message can look like when you treat it as more of a mini-experience rather than just a simple pop-up. So adding custom code into that can help you achieve a lot, actually. For instance, in this specific example, we’re using an external JavaScript library called Hammer.js, and this basically helps us facilitate that swiping motion for the swipe game.
Obviously, this isn’t only limited to external JavaScript libraries. You can create and add your own custom JavaScript functions. So here, what we’re doing for the swipe game is we’re logging each swipe locally to assign a persona and then ultimately personalize the reward delivery. So as soon as the user hits that reward, that’s when we collect all that data and we send it over to Braze. So in this example, if the user were to swipe four times to the left, they would get the classic burger persona. On the other hand, if they had swiped four or more times to the right, they would have seen a completely different reward delivery. It’s pretty cool to use that custom JavaScript function feature.
That leads us straight into the enhanced data strategy and personalization piece. So in the same way that we can use custom JavaScript to create different functionality in terms of the game itself, we can also leverage those JavaScript functions to collect the necessary data. In this case, we’re collecting them as custom attributes, which we will touch on in a future slide. We can grab all of that data, send it over to Braze, and then we can use that for future segmentation and messaging.
So as I said before, in this example this person landed on a classic burger persona, so we can use that in the future to have a personalized banner on the home screen. We can personalize an email, maybe even a follow-up in-app message in the future. It’s pretty cool to use the custom code feature. So Bobby, I’ll kick it over to you for the UX optimization and terms and conditions portion.
Yeah. Similar to what Scott was saying earlier, we want to keep these games more on the simple side versus complex. So any time a game can be less than 60 seconds, that’s nirvana for us. We want to keep it as simple and straightforward as possible while making sure that, like Mike was saying, we’re collecting the data that we want so that way we can propagate that down to whatever next action or experience we want our customers to have.
The other key component here — which no one likes to talk about legal things, but it’s really important — is that we have our terms and conditions integrated throughout the game as well. Typically, that means right at the beginning of the game and then at the end of the game as well. But just always make sure you’re checking with your legal and compliance teams to figure out exactly where they want that verbiage to live.
And then Mike and Rick, I’ll let you guys talk to bringing these games to life through animation.
Awesome. Thank you. So like Bobby said, Rick and I will talk to you through what — Rick, I’m assuming you would agree with me — one of the bigger components to bringing an in-app message to life and actually prettying it up and giving the user an overall better experience is animation. Rather than just having static images, we can have really cool animations, right?
So there are really two options when it comes to animations with Braze in-app messages. The first one being the programmatic animation route. Last slide I talked a little bit about Hammer.js and how we use that to facilitate the swipe feature. In the instance of animation, we’re really building based off of HTML, CSS, and JavaScript, so as far as animation goes, we can treat it like we would a web page in a browser. Right?
So what makes the swiping gestures that you’re seeing right now smooth is we’re taking custom JavaScript functions and telling it exactly what to do. The way that the cards work is you can tap on the card and then you can move it around the screen, drag it around, and then you flick it essentially in whichever direction you’re wanting to go. If for some reason the code doesn’t register that swipe, it’ll anchor back to its original position. That’s all animation done through CSS and through JavaScript, and you can get a little bit more fancy with it too.
I know the first instance of the swipe game that we built, whenever you would swipe either to the left or to the right, you would have an emoji that kind of showed up on screen and then it would float up. Hannah and Rick are nodding because they remember it. They would show up all around the screen and then kind of float up until they were out of field of view.
So really, anything that you can think of to do, you can create. Again, keeping in mind the five megabyte limit. So whenever you start to get a little bit more complex with your animation — maybe you want something a little bit more robust, maybe you’re wanting to layer those animations together — it starts to get a little bit heavy for the in-app message, and again, we’ve got to take into consideration that five megabyte limit. So that takes us into the second option as far as animations go, and Rick, I’ll kick over to you for that.
Yeah. Thanks, Mike. So the second option in this case being the use of GIF animations. GIFs are really powerful in that we use external applications like Adobe After Effects, Adobe Photoshop, or things like DaVinci Resolve that allow us to use animation tools in a professional sense. These animation tools can do anything from videos to motion graphic design. We use those tools to create videos that are then exported as GIF animations.
These GIF animations can be very fancy, but they also have some limitations, and I really want to bring those up. Specifically, they’re limited to 256 colors. I think that’s kind of the big one that generally causes the most frustration. We have to be really mindful of what colors we’re using, and we have tools that can maximize the colors we use to really make sure that it doesn’t look like a GIF animation — not like what we had back in the day with the little hammer guy on the webpage. They can be really robust and very smooth. But they are still limited to 256 colors.
The graphics themselves are also dithered, so there might be some color interpolation that happens. We have to be mindful of that. Again, we have tools that allow us to really push this as much as possible to make it, from a visual perspective, still look very robust, but we are limited to 256 colors.
GIFs do allow for transparency, so we can use these within a webpage and overlap them on top of other elements or behind them. We can use that transparency. But keep in mind that that transparency counts as one of the 256 colors, and that transparency does not allow for alpha channel opacity, which means that it’s either transparent or it’s not transparent.
With PNGs for example, which are not animated, we can use the full spectrum of transparency and that really allows for some very robust images that could be split on screen, especially when we’re talking about overlapping elements. But with GIF animations, you really only have the one color of transparency, so you have to be really mindful of how any shades — think of a drop shadow for example, this is where that tends to come up a lot — how that drop shadow is going to appear and what color is going to be behind it to display on screen.
We can kind of work with it. We’re actually doing this with some of our clients right now, which is why it’s top of mind for me. Layering in that transparency as part of the GIF animation can really help overcome that limitation from being something that’s a deal breaker.
And again, as we mentioned, and it’s worth repeating over and over, we have five megabytes. Ideally we don’t want to get anywhere near that five megabyte limit. So the fewer megabytes we use overall for our in-app experiences as part of these games, the better. That being said, games are fun and visual, so they do have a lot of on-screen graphics, and we kind of want to lean into that generally — as you can see on screen right now.
But yeah, so those are kind of the limitations with using GIF animations. We can use GIF animations in line with JavaScript animations — we combine these two effects a lot, and it looks really good. So we have a lot of options when it comes to deciding if this is going to be a programmatic solution or an image-based solution or GIF animation.
Rick, a question from the audience — “Are SVG animations available?”
SVG animations are available. This is one of the things that we’re currently experimenting with. Braze supports it, so we are finding use cases to use it as much as we can. This is still kind of a new technology, so a bit of unexplored territory, but yeah, let’s go for it. SVG animations are the future, and I think they remove the file size concern — file sizes are generally a lot smaller with SVGs. We can use more than 256 colors and they allow for that full alpha channel transparency, so there are a lot of benefits to using them.
Awesome. Thanks. Mike, back to you.
All right. Awesome. Thank you, Bobby. So for this slide I’m going to talk about the question that is always on a marketer’s mind, right? And that is, how can we take this gameplay and turn it into actual tangible data?
The really cool thing about using custom code when it comes to Braze in-app messages is we have access to using the Braze Bridge Object in really any way that we want to. If you take a look at this snippet on the top right, what we’re doing is we’re submitting the swipe counts for left and right as individual custom attributes, right? So there’s going to be a custom attribute for the left swipes, and there’s going to be another custom attribute for the right swipes.
So it’s pretty cool because we can actually send this data over to Braze almost in real time thanks to that Braze Bridge immediate data flush. The way that we coded it in this instance is it doesn’t send until the user hits the end card. We have to keep in mind the data points that come into play, so we don’t really want to collect every single swipe as they do it. The best way to do it is to collect a tally of the swipe counts, and at the end we send it over to Braze. That way we only have to update Braze once. We don’t have to worry about the data points at that point.
Using all of that information — we touched on it a couple of previous slides — we use that information to personalize the end screen. So it’s not really limited to only custom attributes. We can really collect anything that we want. We can log clicks, whenever somebody presses the close button. We can collect whenever a user clicks on a certain option. We can collect whenever a user swipes. We can also collect events. A lot of the things that we do with our clients is we collect whenever a user starts a session — at least for the in-app message. We can send an event with certain information, what campaign it is a part of. We can send whenever it’s completed. We can send whenever a user collects a reward. There’s really a lot that we can do as far as data collection.
And again, using that Braze Bridge data flush object, it gets sent to Braze and lives on their profile or anywhere else pretty much instantly. Then we can start collecting that data and leveraging it for emails, for more in-app messages, for push. And we use that with Liquid.
I know a project that Rick and I worked on recently — we had a data collection process as part of an in-app message experience, and this in-app message wasn’t served only once. A user could really access it whenever they wanted. And based on the first time that they played through that experience, playing it multiple times throughout the week, they saw different experiences. So if they had already collected a reward from the first time they played it, the second time they played it, they wouldn’t get that reward assigned to them again because they already got those points.
So there’s a lot that you can do as far as data collection, logic for the game, and overall experience. You can tailor an experience to a user based off of data that we’ve collected in the past. So yeah, it’s pretty cool. You’re taking a game that is supposed to be a playful, quick interaction and then turning it into essentially an ongoing opportunity to connect with a user on a way deeper level. You get that personalization.
Awesome. Thanks, Mike.
No problem. And the other thing to keep in mind here is what it looks like with the whole end-to-end architecture. So from the time a game launches all the way through — a little bit like what we talked about earlier — how do we integrate this into the rest of our MarTech stack?
So the game launches, the player interacts like Mike was just walking us through. We can collect all of that interaction data and bring that into Braze and capture it, add it to the Braze profile. And then we want to make sure we’re integrating other elements of our tech stack to make sure that we are redeeming points — like on the top there — integrating to our loyalty system or pushing it into additional messaging. So maybe someone doesn’t finish the game, or maybe they do, and we put them on two different canvases or two different splits within a single canvas to either encourage them to finish the game or tell them what’s next or what they can expect in the future.
But then also we want to make sure all of that data — so everything that we collect, especially the conversions, any kind of transactions, how we’re measuring the success of these games — comes through down into Currents. So that way we can have it within our data warehouse and then report on it, not only within Braze but outside of Braze as well. So that way we can see a holistic picture of whether or not this game was a success.
And speaking of measuring success, Scott, I’ll kick it back over to you to walk us through making sure that we’re measuring what matters and how we’re thinking about that specifically for a game.
Yeah, exactly. We’ve gone through the whole process of building a game — we know what the game should be from a strategy perspective, the creative, and the technical build side. So now when you’re thinking about how do we actually see if this was successful and build this out for further iterations, we’re looking at defining really clear goals and objectives for what specifically we want the behavior outcome to be and what we want to influence the user to do. So this has got to align back to our broader business goals or our broader marketing goals. An example of a KPI that could fit into here is boosting purchase frequency.
And then once we’ve really nailed down that top piece, we can look at how we determine our actual success metrics or big KPIs. So if we’re looking at establishing a game world with how it works and that emotional arc, what KPIs do we really want people to be able to say they checked off for us? Like, it could be days between purchase — did we see that increase or decrease? What did we do to really move the needle forward?
And then we’re looking at designing for data collection. So we’re going to get all of these users coming in to interact with our game. We want to see the building of tracking and analytics right into the game itself so that we know we’re measuring behavior, progress, and can get results reliably. So that KPI could be capturing custom events and exporting to a data warehouse.
And then lastly, as all good marketers, we’re always trying to analyze and optimize the work we put out, so we’re looking to continuously review that data, assess its performance, and then adapt campaign elements for better insights and improved outcomes. So that could be, you know, reviewing reports in the campaign retrospective. Yeah, and I think that’s one thing we all know as marketers — marketing’s never done. Same thing with gamification. So after we finish a game or a game completes over a period of time, how do we take that to make the next game even better? And as we’re thinking about KPIs, we always think about them in two ways. One is increasing revenue, or is it increasing engagement? And you can see some of the key categories that we’ve outlined here, but all of these either fall back to revenue or engagement. Even something like retention and recovery — we’re trying to bring people back, to re-engage them, to drive another transaction. Even brand perception is all about driving revenue and driving engagement. So how do we make sure that everything that we do — obviously gamification, but even things outside of that — is driving to one of these key KPIs?
Awesome. Well, thank you everybody for joining. We really appreciate it. There are two questions from the audience.
First, from Rihanna, “What is possible with Braze IAM?” I think the team has already shared over the course of the last 45 minutes that anything is possible, right? So as long as it fits within that five megabyte storage limit, anything is possible.
Next is from Alexandra, “What are the benefits to building in Braze using IAM versus custom dev with the product team?” The biggest benefit of launching first with Braze is that Braze has some nice simple out of the box templates that you can leverage for your first few gamifications. And that’s really important because especially as you’re launching it — especially if you’re a lean team — you want to figure out how you can launch these things quickly so that you’re not spending a lot of time and effort on something you’re not sure how the audience is going to react to.
Versus if you know that your audience is really receptive to gamification and you’d see a lot of revenue and engagement from it, that’s where it probably makes sense to think about more custom development. Maybe it’s a multi-week type of game where you have people continuously coming back to the app and consistently getting something out of it. That drives a little bit more engagement and a little bit more revenue, but also takes a little bit more time to develop.
Thank you all again for your time today. Really appreciate it. We’ll share the recording out with all of the registered attendees, and we really appreciate your time today. Talk to you soon.
