Learn how we developed BUDS to simplify customer segmentation and enhance target marketing efficiency.
1. What is BUDS?
Have you ever heard of personalized or customized marketing? Personalized marketing is a marketing strategy that offers customized messages and experiences based on customer characteristics and preferences. To deliver such customized messages and services, one should be able to target customers using clearly defined criteria. This is where BUDS comes in.
With just a few clicks and without needing to write your own queries, BUDS allows you to identify, save, and work with your desired customer groups (or segments).
As illustrated in the image below, once the customer filter conditions are selected (primary address + order category within the last week) and their respective values are entered (Gyeonggi-do and Chicken), the number of customers living in Gyeonggi-do who ordered chicken in the past week is returned, along with value distributions, which can be used for various marketing purposes. Previously, filtering customers by specific criteria required SQL queries, which posed a high barrier for many. BUDS was developed to streamline this process.
BUDS stands for Baemin User Data System, which coincidentally also refers to the buds of a plant. The idea is to nurture and make better use of data, transforming “data buds” into full blossoms.
The data source for BUDS is the Customer Data Platform (CDP), which includes hundreds of data attributes that define our customers.
Recently, BUDS was recognized for its robust customer targeting technology by Delivery Hero Group, the parent of Woowa Brothers, and will soon be offered as a global solution. Soon, all entities around the world will be using BUDS as their main engine for customer targeting (segmentation).
2. How did BUDS start?
Let’s Optimize Marketing Efficiency
Back in the planning stage for BUDS, there were too many Marketing Admin services (such as Push Admin, SMS Admin, and Coupon Admin) and manual activities within Woowa. It became clear that these admin services and tasks needed to be integrated or automated. Thus, the “Marketing Efficiency” project was initiated.
To define the project initiatives, we met with marketers, interviewed them, observed their meetings, and analyzed existing data and materials to better understand their overall workflow.
We identified that marketing can be broadly classified into three processes:
- Customer analysis and targeting
- Campaign (such as push, SMS, coupon) setup and execution
- Analysis of results and re-targeting
As it was difficult to revamp the entire end-to-end process at once, we started with the areas that could benefit the most in terms of efficiency. This led us to specify our project initiatives around “Customer analysis and targeting.”
Let’s Improve Targeting Efficiency
Targeting can be defined as a process of identifying customer groups that meet certain selection criteria. This process allows us to manage customer experience by delivering only the necessary messages and to optimize customer communication costs.
Two major challenges were identified in the targeting workflow:
- Using SQL is difficult and time-consuming when analyzing customers and extracting targets.
- It is not convenient to manually download the extracted target files and upload them to downstream systems (such as Coupon Admin and Push Admin).
SQL is a language that requires time to learn, resulting in marketers spending more time on learning and reviewing the SQL query codes rather than focusing on diverse marketing scenarios. There were many errors when using complex SQL queries received from colleagues with modifications.
Downloading the files to the local PC environment and uploading them to other systems also caused errors and exposed potential security risks.
Therefore, we arrived at the following objective: allow anyone to easily and quickly analyze customers and use the results for targeting activities without needing to use SQL.
We expected this would reduce and optimize the time spent writing and reviewing the SQL codes from four hours to under one minute while also eliminating various errors and security issues.
3. How BUDS was built?
As mentioned earlier, the BUDS system required the implementation of Customer Data Platform (CDP), which contains data attributes that define customers, as well as the main BUDS interface.
CDP (Customer Data Platform)
Next, each attribute was defined with a type (e.g., text, numeric, date) and the operators available for each type (e.g., equal to, greater than, between two values). The attributes were structured in a three-level taxonomy (Orders > Last one week > Number of orders) to be linked to frontend services.
Together with data engineers, we also created a pipeline: Data Lake > Data Warehouse > Data Mart, enabling attributes to be aggregated, stored, and sent to BUDS via ElasticSearch, where the attributes could be retrieved from the server.
BUDS (Baemin User Data System)
BUDS utilizes the CDP data and allows targeting of specific customers with just a few clicks. Once an attribute (primary address) to be used as a filter is selected, and the operator (equals) and value (Gyeonggi-do) are entered, a single condition (primary address = Gyeonggi-do) is created.
BUDS allows users to add such conditions and use them in multiple combinations to identify customer segments.
User interface designs were benchmarked from commercial solutions such as Braze, Amplitude, and Salesforce. Furthermore, Figma wireframes were used to depict diagrams to facilitate easy understanding and communication between designers, frontend engineers and backend engineers.
Merging CDP and BUDS
The actual system development was split into a two-track approach for efficiency and continued for about five months. The CDP was developed by myself and the data engineers, while BUDS was implemented by designers, as well as frontend and backend engineers, with the last month spent on merging the two.
This merging step involved expressing CDP data on the BUDS user interface, with the data aggregated into ElasticSearch via the CDP. With the completion of this stage, the BUDS MVP1 (Minimum Viable Product) was released.
Now, marketers were no longer required to write complex, time-consuming queries. Instead, they could easily identify and target customers with just a few clicks.
As illustrated in the example below, we can find and target customers who have opted for push notifications, recently shown interest in the Baemin Club banner, and have high order volumes.
Post-MVP1 Improvements
Once click-based targeting was available with the rollout of MVP1, we focused on improving its features and expanding the service domains.
- Feature Improvements
System integration > Query segment (described below) > Scheduling > Analysis - Domain Expansion
Baemin > Rider > Vendor > Expansion as a Global Service
4. Challenges in Building BUDS
As mentioned earlier, the aim of BUDS was to “allow anyone to easily analyze and target customers without SQL. However, with CDP data alone, it was difficult to meet all the requirements from stakeholders who had been working with SQL for a long time.
Users say:
- I still prefer to use queries but want to save the query-extracted customer list on BUDS as customer segments.
- I want to use BUDS features like system sync and scheduling even for the query-generated segments.
- It would be nice to combine and use the query-generated and BUDS-generated segments together.
On top of these additional requirements, corporate security policies were also tightened, making it impossible for marketers to download query results as files, which created a situation where they had to use BUDS for query-based targeting as well.
What Was Difficult
To save the query results as segments and enable these segments (“query segments”) to use BUDS features, their storage structure should be identical to that of the segments on BUDS (“general segments”) created by combining CDP data. However, this was not the case and much discussion was required with the engineers to find feasible solutions.
The differences between the two segment types are summarized below:
- General segment: Segments defined on BUDS using criteria based on CDP data attributes. The segment information stores the criteria (Order category in the last 1 week = Chicken) rather than the resulting customer ID list. On a daily basis, after the CDP data update, a fresh list of customer IDs that meet the stored criteria is extracted. Therefore, the list of customer IDs for the same BUDS segment may differ from day to day.
- Query segment: Users can load and execute the query codes already stored in the internal query execution system (Zeppelin notebook), and save the list of customer IDs from the query result. As this approach stores static data, the list of customer IDs in this query segment does not change over time.
As aligning and unifying these two segment structures was a massive undertaking and would still require computing resources to view segments – resulting in subpar performance, it was decided to keep the segment types separate.
How it was Resolved
To maintain the separate storage structures, the following were decided:
- General segments and query segments are to be stored separately in different tables and their features, such as system sync, are managed separately.
- Since the two segments are based on totally different approaches for segment generation and extraction, separate user interfaces are to be developed to prevent user confusion.
While the two would be managed separately, it was necessary to find a way to work with both segment types at the same time for instances like retargeting the customers targeted in previous campaigns, comparing segments, or excluding customers who were targets of previous campaigns.
- As the two segments store different data, they cannot be directly joined. Thus, we devised a way to convert query segments into general segments. This involved extracting the customer ID list for a specific query segment and providing CDP data attributes for those customer IDs.
- As shown below, marketers could now generate general segments by adding criteria to find customers included in a specified query segment.
While it would have been great to consider and design this feature from the beginning for a better structure, it still seems like a good, quick solution for a requirement that is very different from the initial product concept (enabling solutions without SQL).
5. BUDS continues to evolve to satisfy diverse needs
To date, BUDS has delivered great results and achievements. It was selected as the Project of the Year in 2022, and in 2023, a decision was made to make it a global service, recognized for its excellence by the Delivery Hero Central Team.
The most rewarding moment is when I hear our fellow marketer colleagues say, “Thank you for building BUDS.” Today, BUDS has become an enterprise-wide targeting tool with significant traffic of around 2,000 requests per week from more than 150 marketers.
We have other exciting future plans on the horizon for BUDS, including real-time synchronization of batch data, globalization within Delivery Hero entities, and the integration of AI technology. We are also conducting research on Text-To-SQL technology to move away from the current click-based interface and introduce a prompt-based conversational interface.
If you have any inquiries related to Segmentum, please feel free to reach out to the BUDS Team at [email protected].
If you like what you’ve read and you’re someone who wants to work on open, interesting projects in a caring environment, check out our full list of open roles here – from Backend to Frontend and everything in between. We’d love to have you on board for an amazing journey ahead.
