Published on December 08, 2020/Last edited on December 08, 2020/6 min read
Marketing today can be a high-pressure, fast-paced endeavor—something that can make the difference between a successful customer relationship and a customer who decides to walk away from your brand. Consumers increasingly engage digitally with brands in real time across different platforms (think web vs. mobile) and different channels (think email vs. in-app messages), and they expect cohesive, relevant experiences as they do.
But things don’t alway go according to plan.
When broken brand experiences happen, there can be many different causes. Poor data hygiene. Human error. Batched data processing. But there’s one potential cause that hasn’t gotten as much attention as it deserves: Race conditions.
A race condition occurs when electronics, software, or any other system is dependent on the sequence or timing of other uncontrollable events. Though they’re not inherently malicious, a race condition becomes an issue when one or more of the possible resulting behaviors is undesirable.
Here’s a real-world example: You’ve likely experienced a race condition yourself if you’ve ever flipped two light switches to the same bulb at the same time—the lightbulb is getting the “off” message and “on” message nearly simultaneously, and there’s no way to predict what the outcome will be. In most cases you’ll have an illuminated staircase, but every so often, you’ll end up with a dark descent to the basement…
In the software space, race conditions are typically found with operating systems that use “asynchronous logging”. In layman’s terms, this is a process that dictates that when multiple calls are being made to the same server, whichever information gets there first will be processed first.
This approach is what helps many programs run quickly and efficiently, because there’s no dependency on certain tasks being completed before other tasks can begin. But with great speed comes great responsibility, and programmers have to keep in mind the nuances of their data processing when working in this kind of environment.
You nailed it—Braze is a platform that runs using asynchronous processing to maximize speed and flexibility. This means you can be sure your messages will fire without delay when you schedule them, and that events and attributes will be added to each user profile as quickly as they’re received. It also means that—as with any other asynchronously run system—there is a risk that race conditions may crop up when it comes to campaign setup.
For example, let’s say a marketer at a hypothetical brand, PantsLabyrinth, wants to send out a triggered email about hot deals on capri pants the moment a user clicks “submit” on an email capture form. In this scenario, the intended behavior is that when “submit’ is clicked, the user is created, their email address is added to their profile, and a custom event fires to trigger an email to that customer.
However, what if our friends at PantsLabyrinth are sending all of this data in separate calls from their server via API? We hope that the data to create the user and add the email is processed prior to the event so we can target them with the message, but there’s a chance that, due to asynchronous processing, the trigger event will win this “race”. If this is the case, the event will fire, but won’t have a user with an email to target, and the campaign will be dropped. The other tricky thing is that these calls are firing constantly, and near-simultaneously. So some users might get the message just fine, while others won’t receive anything.
The good news is there are a few things Braze does automatically to prevent this behavior, and a few best practices you can put into place to avoid a race condition scenario within your marketing program.
The Braze support team says that they most frequently see race condition tickets crop up when marketers are triggering campaigns to new user profiles, or when the filtering for a message is dependent on an attribute that’s added at the same time as the trigger.
Welcome emails like the one above, customer journeys with hyper-specific entry criteria, or when inbound data is siloed in different systems (a custom event is in a different call than a necessary attribute) are all situations where it’s worth taking a second look before you press “send.”
Unexpected race conditions can be a side-effect of any system built for speed with asynchronous processing. If you keep in mind best practices, test your setup before launch, and double-check documentation, you’ll reap the benefits of Braze, and beat race conditions to the finish line.
To learn how to better use data and create meaningful consumer experiences, check out Data Agility 101.
Sign up for regular updates from Braze.