Braze Reflection: Personalized EOY Wrapped — Custom HTML Paginated IAM
Braze Reflection: Personalized EOY Wrapped — Custom HTML Paginated IAM
We recently worked on our biggest user-facing project yet:
- 12-intensive-weeks, entirely focused on this single use case.
- 11.4M Reachable Audience.
- 10000+ lines of Custom HTML Code with 100+ asset links and tons of Liquid logic.
- Design, Data, Marketing, Braze Support, and Braze Experts. It truly takes a village.
- 90.3% conversion rate with $3.4M revenue.
Keep scrolling to read more about some valuable lessons learned along the way!
With 10000+ lines of code, use a code editor, like VS Code.
Pretty straightforward. The Braze IAM HTML Editor does not function smoothly when you have this many lines of code.
Every character update will have about a 1–2 second delay, and it’s extremely painful to edit even one sentence directly on the Braze Editor.
But command + a / command + c works very well, so we found ourselves constantly select-all/copy/pasting from one editor to the other.
And now that we think about it, this lesson could/should apply anytime you’re working with HTML, even for much smaller IAMs as well as email.
Finalize the full list of stakeholders early on, and demo the WIP as early as possible.
And sometimes, we might not know the full list of stakeholders from the beginning. As the project progresses and grows, different stakeholders might become necessary that weren’t originally.
But different stakeholders will have different perspectives and feedback, so it’s good to get the project in front of them as early as possible.
We wanted to wait until our visuals looked presentable and the majority of our data was accurate before surfacing our progress to outside of the immediate team.
However, we may have waited too long, as we received new (and great) feedback a little too close to the launch date.
And maybe it would’ve been better to share with the wider team, way before we were ready, to show them the quick progress we were able to make in a short amount of time.
Think through the END TO END launch process, and test it early on.
We spent about 90% of the timeline perfecting our IAM. After all, this channel was going to be the main content that our users were going to see.
However, the IAM was going to be delivered by a button-click on a Content Card. And we neglected to consider the user experience, the UI limitations, and technical details of the Content Card aspect until way later in the project.
The biggest issue was that due to our total IAM size, there was a significant time delay between the CC button click and IAM rendering. Ranging from anywhere between 2 seconds to 1 whole minute, with an average of 10 seconds.
10 seconds of inactivity, blank, and confusion after a user excitedly clicks a button and sees no change… is unacceptable from both a brand and product perspective.
Had we tested this much earlier, we would’ve taken different approaches to how we wrote the code and how we hosted the images. See next lesson for details.
With so many image assets, avoid the Braze Media Library and Catalogs.
Braze recommends their users to always use the Braze Media Library.
There’s no cost associated with the Media Library; it’s simply that using a native asset storage would work the best as the Braze SDK has a more direct access to its own Media Library than external sources.
This could help with displaying images even in areas of poor connection.
However, the Braze Media Library’s load time is not nearly as quick as some of the other global solutions, e.g. Amazon S3.
Simply from changing the hosting source of all our images and font files from Braze to S3, our IAM load time significantly improved. From about 3 seconds to seamless.
Also, we had to move away from using Braze Catalogs to organize and render dynamic values, as using a Catalog creates a network request whenever the IAM is triggered. This also creates a delay before the IAM is rendered.
Therefore, we had to swap every single image link from the Braze link to the S3 link, and we also had to remove all Catalogs and rewrite the logic solely using Liquid.
Had we known all of these things from the beginning, we could’ve saved significant time from rewriting and restructuring our assets and code.
Always be prepared for curveballs, emergencies, last-minute fixed, delayed launch dates, and anything else.
With any long-term projects with a clear launch date, we personally like to set a very conservative “launch-ready” date, something like 2 weeks in advance.
That gives us 1 week to QA, and 1 week to be on stand-by in case anything goes wrong or any changes are required.
And maybe 2 weeks isn’t actually enough time to be launch-ready.
But this lesson isn’t about “How much fixed time we should set aside before launch date”.
Even at the end, we stayed on our toes and kept a flexible, open mind which allowed us to smoothly navigate until we eventually got across the finish line.
The end phase of a project is a sensitive one as everyone is eager and excited to finally go to market with all their hard work.
And it’s super important to stay patient until all issues are resolved, all stakeholders are aligned, and the final, FINAL checkboxes are checked. ✅
Thank you!
Thank you for reading, and please reach out with any questions.
fornowmarketing.com
allan@fornowmarketing.com
