Goal: We are in the auctions business where every auction has a start/end date & time. Users indicate interest by registering or Save/Liking/Browse an auction.
The goal was to be able to send near-realtime comms to recipients without needing extensive engineering support to build a trigger system, built and managed right inside Braze.
Challenges:
- While users saving/registering were client side events, these needed to be mapped to a server side event (eg: Auction Opened / Closing)
- Users could save/register weeks or maybe even months prior to an auction meaning a canvas couldnt essentially trigger a user into its journey, as users could redo the same action on another auction at any time thereon.
- Auction dates could change at a future date/time
- Most importantly, the quickest possible Canvas recurrence in Braze is 1 day, meaning if a user got one email within a day, they could miss another relevant auction which could start / end at any time (on the hour / middle) during the same day if still in the canvas.
Architecture:
The Canvas
- The philosophy behind the Canvas was akin to a Cat chasing its own tail.
- Our base canvas serves as a Notifications Engine that runs one-time thru API(triggered via Postman) to a dummy email account, sends a webhook email campaign per requirement (Auction Open / Auction Closed etc etc), adds around an hour's delay.
- The last critical node in the canvas uses webhook to call the canvas back, making this an eternally running and effectively "Hourly canvas".
- Since it runs for only one dummy user, the system load is almost none.
Each of the above nodes per campaign are their own webhook email / SMS campaigns that send to a pre-built audience. As every node in the canvas seems to take away some time of processing, the delay is adjusted depending on how many nodes exist for campaigns.
Individually every campaign has a limiting threshold to not resend to the same client within an hour, to avoid duplicate comms for whatever unforseen reasons.
Mapping Client Activity to Server side triggering:
- Every hour when each campaign runs, it uses a Braze Catalog that hosts every Auction's open/close date & time along with a unique Auction ID.
- Using Liquid, we shortlist every Sale ID that qualifies to receive an email in that hour.
- Our CDP sends a custom attribute array to every user's profile for last 6 months Auction IDs that they have registered / saved / browsed.
- The liquid inside every campaign loops thru the 2 data sets to qualify the user to know IF they should receive comms in that hour.
- If they dont qualify, the campaign ABORTS.
Benefits:
De-coupling the architecture from triggering to comms lets us do variants at the campaign level, set audience exclusion / widening rules at will for one or many of those campaigns and ease the interplay as required.
Storing server side data on a catalog that syncs hourly with our backend Snowflake data ensures that any updates to Auction open/close date/times reflect seamlessly, rather than rely on adding such info on client side events, which cant be relied upon.
Result:
These campaigns now drive the most conversions bringing in qualified interested audiences to actually place a timely bid on items that they might be interested in and convert.
