Career
← Back to all posts

GD → Data → Ad Mon: Why I Kept Adding Roles Instead of Picking a Lane

My career looks like I couldn't decide what I wanted to be. The truth is each role made the previous one 10× more effective.

7 min read · Du Che Anh

If you look at my LinkedIn, it looks like I changed jobs four times in three years. I didn't. I was at the same company (VNG Corporation) the entire time. What happened was that I kept absorbing adjacent roles — not because I was bored, but because I kept hitting walls that only the next skill could break.

Here's the actual sequence, and why each transition happened.

Act 1: Game Designer who couldn't prove anything

I started at VNG in late 2022 as a Game Designer on casual zombie-shooter titles. Level design, player progression, engagement hooks — the stuff you'd expect. And I liked it. I was decent at it.

But I had a problem: I couldn't prove any of my design decisions were right.

I'd design a new level flow, the team would ship it, and then we'd look at the numbers. Sometimes retention went up. Sometimes it went down. Sometimes nothing changed. And every time, the conversation in the design review was the same: "I think this works because..." followed by someone else saying "I think it doesn't because..."

Opinions. That's all we had.

So I started learning Python on the side. Not because I wanted to become a data analyst — because I wanted to win design arguments with evidence instead of feelings. I wrote my first A/B test analysis script using Mann-Whitney U because I got tired of someone senior overruling my design with "I just don't think players like that" when we had actual data sitting in a database that nobody was querying.

That first script changed everything. Not because the test proved I was right (it didn't, actually — the control won). It changed things because suddenly we had a number. A confidence interval. Something that wasn't anyone's opinion. The team started asking me to run tests on their designs too.

The lesson: I didn't plan to become a data person. I just needed to answer a question that my current skills couldn't answer.

Act 2: Data Analyst who actually understood the game

About a year and a half in, the team formally asked me to take on the data analyst role. I didn't stop being a game designer — I did both.

This is where things started compounding.

Most data analysts in gaming studios come from a pure analytics or engineering background. They can build dashboards, run queries, and produce reports. But when a product manager asks "why did D7 retention drop this week," the analyst typically responds with: "here are the numbers, broken down by cohort and country." Which is technically correct and completely useless. The PM wanted an explanation, not a spreadsheet.

Because I was also the game designer, I could look at the same D7 drop and say: "we shipped a difficulty spike in level 14 on Tuesday. Players who churned are disproportionately in the level 12–16 band. The spike is too steep — here's the A/B test I'm setting up to validate a smoother curve."

That's not a data insight. That's not a design insight. It's both, and it's only possible because I held both roles.

I built 20–30 Tableau dashboards during this period. But the reason they were useful wasn't because I'm good at Tableau. It was because I designed them as a game designer who knew which questions the team would ask, and as a data analyst who knew where the answers lived. Every parameter, every tooltip, every filter was there because I'd needed that exact view myself the week before.

I also built BigQuery pipelines during this time — the less glamorous part that nobody talks about. Schema design, partitioning, clustering, pre-aggregating heavy queries. I got query costs down to near-zero. Not because I love infrastructure, but because slow dashboards don't get used, and dashboards that don't get used mean the team goes back to making decisions on gut feeling. I'd already lived through that. I wasn't going back.

The lesson: being a data analyst who also designs the game means you don't just report what happened — you know why it happened and what to do about it.

Act 3: Ad Monetization Specialist who sees the whole picture

About a year into the dual GD/DA role, I started working more closely with the ad monetization team. And I noticed the same pattern: smart people making decisions without the full picture.

The ad mon team understood eCPM, fill rates, and ad network mechanics deeply. But they didn't understand the game. They'd suggest adding a rewarded video after every level completion because the eCPM was high. They didn't consider that players who just beat a hard level are in a flow state, and interrupting that flow kills session length, which kills D7 retention, which kills LTV. The eCPM looks great on the ad dashboard. The retention chart tells a different story.

And on the UA side, the team was making campaign decisions based on CPI and early ROAS without understanding what was happening inside the game that affected those numbers. A game design change that improved D30 retention by 3% would show up in UA numbers six weeks later as improved ROAS — but the UA team had no visibility into why their campaigns suddenly performed better.

So I took on ad monetization. Not as a separate job, but as the third layer on top of design and data.

Now I could design an ad placement, predict its impact on retention using my cohort dashboards, model the expected ARPDAU uplift, and A/B test the result with statistical confidence. One person, three lenses, one decision framework.

This is where the real results started showing up. At VNG, I grew ARPDAU 20–30% across the portfolio — not by showing more ads, but by redesigning how ads were called. Session delay configs, IV/RV pacing, placement timing. Every decision was informed by game design (when is the player emotionally available for an ad?), data (what does the retention curve look like for players who see X ads per session?), and monetization mechanics (how does the ad network reward or punish your call pattern?).

When I later joined Corochti, I inherited a game with no intentional monetization. I took it from zero to ×9 LTV in five months, enabled profitable UA campaigns, and designed ad pacing that preserved D30 retention. I couldn't have done any of that with just one of the three skills.

The lesson: ad monetization isn't a standalone discipline. It's a design problem and a data problem wearing a revenue hat.

The compounding effect

Here's what most people miss about cross-functional skills: they don't add. They multiply.

A game designer who also does data is not 2× valuable. They're 10× valuable, because they can do things that neither role can do alone. Add monetization and you're not 3× — you're solving problems that most studios need three people and two weeks of meetings to even frame correctly.

I didn't plan this career path. I just kept hitting walls that the next skill could break:

Each transition was an answer to a specific problem, not a career pivot. And because I kept the previous roles while adding new ones, the skills stacked instead of replaced each other.

The downside nobody talks about

It's not all compounding returns. There's a real cost to this path.

You're hard to categorize. Recruiters don't know what box to put you in. Job listings say "Game Designer" or "Data Analyst" or "Ad Monetization Specialist" — not "all three." I've had recruiters skip my profile because it didn't match their keyword filter cleanly.

You're constantly context-switching. On a typical day at Corochti, I go from sprint planning to a Figma mockup to a BigQuery query to an ad waterfall analysis to a Tableau dashboard to a UA campaign review. That's six cognitive modes in one day. It's exhausting and it's not for everyone.

People question your depth. Three years, four role titles — it looks like I couldn't pick a lane. The work speaks for itself, but you have to get past the first impression for people to see that.

I'm fine with all of these tradeoffs. The alternative is being a specialist who ships a great design and then watches someone else's bad monetization decision kill its retention. I've been that person. It's worse.

Should you do this?

If you're a game designer who's curious about data: learn SQL and Python. Not to become a data analyst, but to answer the questions your designs create. Start with A/B testing your own features. The moment you can say "this design improved D1 retention by 4% with 95% confidence," you become the most trusted designer in the room.

If you're a data analyst in gaming who doesn't play the games: start playing. Not casually — analytically. Ask yourself why the FTUE is structured the way it is. Why ads are placed where they are. What the economy is optimizing for. The data makes more sense when you understand the design intent behind it.

If you're already doing two of the three: the third one is closer than you think. The transition from data to monetization, or from design to data, is a matter of months — not years. And the compounding kicks in immediately.

This is the third in a series about game design, data, and monetization in F2P mobile games. I'm Du Che Anh — Product Owner & Lead Game Designer at Corochti Studio, previously at VNG Corporation. If your studio needs someone who can hold all three lenses at once, I'm open to consulting and freelance work. anh@ducheanh.com