Karrot's User Behavior Log Management Platform: Building the Event Center

Karrot shifted its schema management approach from Git- and code-centric methods to a UI-centric Event Center in order to handle its growing volume of user behavior logs more consistently and safely. Logs are the starting point for experiment design, product improvement, and decision-making, but as their numbers grew, naming inconsistencies, review bottlenecks, and operational complexity increased significantly.

Log collection starts from the SDK in the mobile app and is processed through a pipeline that flows through the event server, GCP Pub/Sub, GCP Dataflow, GCS, and BigQuery. Invalid events are separated into a DLQ and stored in a separate table, and an additional time-window-based deduplication is performed at the batch stage to improve accuracy.

At the core of this system is the user behavior event schema. When each event specifies an owner and domain, and defines the meaning and type of common fields and custom parameters, a table is automatically generated per event in BigQuery, allowing queries to be run directly like columns without needing to parse JSON.

Previously, this schema was written directly as Spark StructType JSON and managed via Git. This approach created the following problems:

• Writing schema files required coding knowledge, and attributes like metadata, nullable, and type had to be filled in one by one.
• Nested structures appeared frequently, leading to frequent JSON writing mistakes, and even minor typos or missing brackets caused CI failures.
• After writing a PR, it had to go through review by the data value team, leading to repeated revisions and re-reviews.
• Event naming was inconsistent, as in home_feed vs homeFeed, or show_article vs shown_article.
• Screen names and documentation were scattered across teams, causing different standards to be applied to the same screen.

To solve this, Karrot first established a company-wide common event system. User behavior logs follow a service - screen - action hierarchical structure, and names use the format client_{action}_{service}_{screen}_{object}. Actions are defined in past tense, and elements use snake_case, while the internal notation within each element follows camelCase, ensuring consistency.

The next step was building the Event Center. It allows services and screens to be registered, and events occurring on a specific screen to be defined via the UI, while the system automatically handles naming convention application, Spark StructType JSON generation, validation, and BigQuery View Table creation. As a result, anyone can register an event schema with just a few clicks, greatly reducing dependence on review and CI processes.

Operational convenience was also enhanced. After inserting logging code, developers can check logs generated under their own ID in the Event Center in near real time, verifying parameter values and whether collection is occurring. QA can be done without separate queries or app access, allowing logging errors to be found quickly.

Defined schemas are also converted into type-safe code via a CLI. Currently, Swift, Kotlin, and TypeScript types are generated per platform, and developers can use the generated types as-is to catch field name mistakes or type errors at compile time.

Remaining challenges are also clear.

• The event addition process still involves a lot of clicking and input, requiring faster UX.
• Only a single screen can be registered, so screens with differing states like success/failure need separate management.
• More precise automation is needed to identify whether an event occurred at a specific element within a screen.
• Design automation extending to Figma integration and automatic code generation is the next goal.
• Expanding analytics tools to handle metric calculations like CTR, PV, and AU, as well as experiment metric configuration, within the UI is also under consideration.

Ultimately, the Event Center is not an internal tool for a single team, but a foundation for changing the way Karrot as a whole handles user behavior logs. It enables data analysts, data engineers, frontend engineers, and those responsible for the mobile division and webviews to collaborate on the same set of rules, and it is evolving to connect not just log collection but also interpretation and utilization.