Building Event Center: Karrot's User Event Management Platform

Karrot reorganized company-wide logging rules and built an admin platform called Event Center to handle the large volume of daily user events more consistently and safely. It shifted the existing Git-based, code-centric workflow toward a UI-centric approach, automating manual work as much as possible.

User events are the starting point for product improvement, experiment design, and data-driven decision-making. Karrot's collection pipeline roughly flows as follows.

• The mobile app's SDK sends events based on conditions or intervals.
• The event server performs basic validation before forwarding to GCP Pub/Sub.
• GCP Dataflow performs real-time validation, short-window deduplication, and data flattening.
• Valid data is stored in GCS and BigQuery, while invalid events are separated into a DLQ Pub/Sub and a separate BigQuery table.
• The data then goes through one more round of batch deduplication to improve accuracy, after which it is loaded in an immediately queryable form.

Schema is not simple metadata—it is the standard that defines the meaning and ownership of an event. Each event is tagged with an owner and domain, and custom parameters beyond common fields are also documented. When a schema is added, BigQuery automatically creates a table for that event, and values that were bundled in JSON become queryable like regular columns.

Previously, schemas were managed as Git-based code. Files had to be written directly in Spark StructType JSON format, requiring CI validation and PR review, and as nested structures grew deeper, a single bracket or comma became a source of failure. As a result, problems kept accumulating.

• Writing schemas itself was complex and error-prone.
• Long review and revision cycles slowed down deployment.
• Event names were inconsistent, like home_feed versus homeFeed.
• Even the same screen was called by different names across teams, leaving documentation scattered.

To solve this problem, Karrot changed two things at once. One was establishing a company-wide user event system, and the other was creating an Event Center UI that made it easy to follow those rules. Event names follow a 3-tier structure of Service → Screen → Action(Event), unified into the format client_{action}_{service}_{screen}_{object}.

In Event Center, services, screens, and events are managed in one place. Users don't need to know Spark StructType JSON or validation rules—the system handles naming rule application, schema generation, validation, and BigQuery View Table creation on their behalf. Events can be viewed grouped by screen, making it immediately clear which events occur on which screens.

QA has also become faster. After adding logging code, developers can search for events using their own user ID to check, in near real time, whether the event was collected and what parameter values it contains. Values like item_id can be instantly verified without having to open BigQuery directly.

Finally, CLI code generation was added. Based on the schema defined in Event Center, platform-specific type code is automatically generated and converted into Swift for iOS, Kotlin for Android, and TypeScript for Webview. As a result, typos or type mismatches are caught at compile time, and IDE autocomplete can also be used, greatly improving logging safety.