Level Up! CookieRun: Kingdom Data | 2025 데브시스터즈 엔지니어링 데이 - Data

Summary

Main theme

How Cookie Run: Kingdom uses data effectively in game development—focusing on the “trinity” needed for game analytics and the practical difficulties in implementing it.

---

1) Advantages of data roles in a game company (Cookie Run: Kingdom context)

• Large and diverse data availability
  • “More than 10 rounds of data” saved daily (per subtitle phrasing).
  • 12M+ global users have visited to date.
  • Content updates every 4 weeks, continuously accumulating data.
• Understanding a complex system/game world
  • Multiple game types/features (e.g., collectible RPG, SNG) create many interacting variables—data helps interpret complexity.
• Cross-functional collaboration
  • Analysts support game professionals by informing decisions across disciplines using data.

---

2) The “three things” needed for game analysis (trinity)

1. A data environment that can extract data reliably (without interruptions)
2. Game understanding tailored to game mechanics and context (examples/industry knowledge)
3. A data culture that turns data into execution and enables continuous improvement

The speaker emphasizes that achieving all three is hard in practice.

---

3) Reality #1: Building and operating a data environment (technology + tooling)

Key technical obstacles

• Building the logging pipeline is a foundational challenge.
• Providing analysts freedom via DW dashboards (Data Warehouse dashboards).
• Handling high-volume, high-speed processing to keep visualization productive.

Tooling and platform choices

• The talk references tools beyond spreadsheets, including:
  • Databricks
  • Tableau (also described as “well-established” at Devsisters).

Cost and scalability constraints

• “Capacity is the cost”—storage expands into daily spend.

Cost-optimization strategies

• Appropriate storage policies
  • Stop retaining unnecessary data.
• Use views to avoid processing across all segments for performance reasons.
• Dashboard lifecycle management
  • Only build dashboards that are maintainable.
  • Split dashboards into Main vs. “ed” (likely “exposed”/secondary) and note that Main dashboards require daily maintenance.
  • Distinguish dashboards that are one-time vs discard.
• Specific storage optimization efforts mentioned:
  • S3 persistence tiering
  • DV snapshot storage cycle tuning (subtitle phrasing)

Schema/query optimization

• Managing schemas to support lighter read/write:
  • Creating dedicated temporary-table space to reduce overhead.

---

4) Reality #2: “Game understanding” risks misanalysis

• The game is highly complex with many interactions, creating risks such as:
  • Misanalysis due to incorrect assumptions
  • Misinterpreting indicators, since negative outcomes can still be intentional planning decisions
• The speaker argues against over-reliance on public opinion and stresses:
  • Reading design documents
  • Attending meetings about direction
• Requires reviews and cross-team input because no single person can fully own correctness—especially around analysis errors.

Analyst capability gap mentioned

• Few analysts are simultaneously:
  • strong in statistics
  • strong in coding
  • strong in game understanding
• Emphasis: become an analyst who understands development processes/principles, not only “playing games.”

---

5) Prologue to the “final boss”: Data culture (organizational behavior)

Even with good tooling and correct understanding, the speaker claims data culture determines whether data truly drives decisions. Technical fixes are solvable; changing people/organization is harder.

Practical problems with data culture

1. Indifference / outsider effect

   • Analysts aren’t developers, so their advice may be treated as “outsider advice.”
   • Departments may hesitate to act or let issues slide.

2. “Our game isn’t that kind of game” resistance

   • Teams may reject trends due to game identity and feasibility.
   • The analyst should set limits based on process, user base, and implementation difficulty—while still pushing proposals confidently.

3. “Do we really need data to make a game?”

   • Some aspects of gaming rely on intuition; planners may be too busy to validate everything.
   • Decision-makers vary: some use data actively, others do not.
   • Counter-argument: data is essential for:
     • accumulating experience
     • transferring knowledge
     • diagnosing why plans fail and improving next time
     • capturing company-specific know-how

---

6) Concrete initiative: Build analysis reports (process + formatting)

To address cultural issues and improve usefulness, the team changed how analysis is delivered.

“Three keywords” for build analysis reports

1. Lower the HUD
   • Make content easy to read even for non-statistical readers.
   • Use a column-like style instead of a heavy research-paper tone.
2. Demeter omakase (intended as “omakase”)
   • Data isn’t just a buffet of metrics—analysts “serve” guidance like a menu, clarifying how each metric should be used in proposals.
3. Deliver quickly
   • Send reports immediately after builds finish so insights can apply to the next planning cycle.

Delivery mechanics

• Store reports in Notion, one by one, to make ongoing guidance accessible.
• Mentions “build view count is increasing” as a proxy for adoption.

Evidence/examples mentioned

• Product example: “Wanggu Decoration”
  • Sales dropped after the 2nd release (compared to the initial release).
  • Hypothesis: demand decreased due to overlapping user experience comments/needs.
  • The improvement made in the 3rd release led to better sales.
• Notes that content-related metrics (e.g., too many draws) can harm user experience, leading to later improvements.

---

7) Data request handling improvements (speed + ease + client-like clarification)

The speaker describes categories of data requests and how the team reduced friction.

Process changes

• Reduce “clumsiness,” improve omakase, and increase speed.
• Streamline intake so many people can request comfortably.
• Improve accessibility:
  • Discuss face-to-face or via Google (subtitle phrasing unclear; likely Google Meet/Docs).
• Use a “reverse constraints” approach:
  • Even when requests are abstract, clarify by asking the requester directly, then suggest how to inspect the data specifically.
• Speed play
  • Visit within one hour of receiving requests and discuss the investigation approach.

Stated outcome

• After starting this approach, data volume increased ~3x (more extracted data driven by more usage/requests).

---

8) Helping the development process directly (not just analysis)

A structural reason data orgs feel “external” is that data teams may not participate in real development execution.

Proposed solution

The data team supports development more directly by handling extraction and related tasks, including:

• live operations support
• building simulators/analysis tooling with code

Example: gacha probability tuning

• Analyze historical pulls and estimate how lowering probabilities changes pull counts.
• Created a simulator to support decision-making.

---

9) Communication as the “most important” final piece

• Key ingredient: senior decision-maker participation.
• Regular meetings with PD under a program name: “Level Up Kingdom Data.”
  • PD sets long-term direction; the team selects and proposes analysis topics.
• Broader open meetings:
  • Make build analysis report discussions cross-departmental.
  • Important figures attend in person; some listen online.

“Data pocketing” and cultivating data “star players”

• An initiative to help team members easily view and use data in planning/development.
• Analysts proactively suggest:
  • adding data slides
  • using specific datasets when writing proposals
• Cultural philosophy:
  • Don’t assume analysis is always correct—actively seek reviews and incorporate multiple opinions.
• Goal:
  • cultivate individuals in each department who teach peers how to use data.

---

End: Main speakers / sources

• Lee Ji-yeok — presenter; data engineer (described as at “Studio Kingdom Surgersell”) and previously in data engineering roles related to the game ecosystem.
• Jiyong Lee — named in the subtitles; previously data engineer at Devsisters Kingdom Server Cell, and recently Data TF Lead focusing on data analysis.