The Secret to Billions of Won in Monthly Ad Revenue: Why the Alarmy Team Built Its Own SSP

The Journey to Billions of Won in Monthly Ad Revenue

“Three days to integrate the AdMob SDK, a week to set up mediation, but why is the eCPM so low?”

If you've ever tried app ad monetization, you've probably experienced this at least once.

Integrating countless ad networks individually, configuring complex waterfall setups, and running endless A/B tests to optimize eCPM (revenue per thousand impressions). Plus, the reality that true revenue optimization eventually requires building your own AdServer. For most engineering teams, this is practically an impossible mission.

Running Alarmy, the world's #1 alarm app, and managing billions of won in monthly ad revenue ourselves, our team had the exact same struggles. We took all of our accumulated know-how and technical expertise and baked it into a unified solution called DARO.

Today, out of all that, I want to talk about our SSP (Supply-Side Platform).

In this post, we'll look at how the DARO SSP implements the OpenRTB protocol and what kind of architecture it actually uses to maximize revenue.

Why Do We Need an SSP?

The Evolution of Programmatic Advertising

First, to understand why SSPs are so important, we need to take a look at the evolution of programmatic advertising.

Do you remember the early 2000s, when publishers had to negotiate with advertisers one by one? It was an inefficient era where negotiating each campaign took weeks, and a significant amount of inventory was left unsold.

The game completely changed with the introduction of RTB (Real-Time Bidding) in 2009. Real-time auctions are now completed in hundreds of milliseconds, and as of 2025, the vast majority of global digital ad spend is traded programmatically.

The Role of an SSP

An SSP is the core infrastructure of this innovation.

The core value of an SSP isn't just connecting multiple advertisers. It provides the technical infrastructure to integrate directly with countless DSPs (Demand-Side Platforms) and put each of the publisher's ad placements up for real-time auction.

Realistically, it's impossible for an engineer to sign individual contracts with dozens of DSPs, integrate each of their SDKs, and implement the OpenRTB protocol from scratch. An SSP solves all this complexity with a single, unified interface.

Three Realistic Reasons Why Building Your Own SSP is Hard

You might be thinking, "If it's so great, why don't we just build an SSP ourselves?"

The reality isn't quite that simple.

First, the technical barriers are massive.

• Building globally distributed data centers

• Maintaining 99.99% uptime

• Perfectly implementing the OpenRTB protocol

• Optimizing via real-time data analysis

Second, the operational costs are substantial. Even mid-sized AdTech companies spend billions of won annually on infrastructure costs. Large platforms operate on an entirely different scale.

Third, economies of scale come into play. DSPs are reluctant to integrate with SSPs that lack sufficient traffic. Among DARO's partner DSPs, some even required a minimum of 1 billion bid requests per day. It's a classic chicken-and-egg problem.

Ultimately, an SSP is a realm of "partnerships" rather than "building." That's why you need a proven solution like DARO.

Let's dive into how these SSPs actually work, starting with the core component: the OpenRTB protocol.

OpenRTB: The Standard Protocol for Global Ad Trading

What is OpenRTB?

For an SSP and a DSP to communicate, they need a common language. That is exactly what OpenRTB (Open Real-Time Bidding) provides.

Established by the IAB Tech Lab in 2010, how does this protocol work? Let's take a look through a real-world example.

Data Structure

The heart of OpenRTB is its intricately designed data structure.

A Bid Request is a JSON object describing the ad opportunity, consisting of a nested structure that includes Impression (ad slot info), Site/App (publisher context), Device (device info), and User (user data). The DSP must analyze this and return a Bid Response within a short timeframe, which the industry generally requires to be within hundreds of milliseconds.

OpenRTB also handles all ad formats in a standardized way. Banners define size and position; Videos define playback time and bitrate according to the VAST (Video Ad Serving Template) standard; and Native ads define individual assets like titles, images, and CTA buttons. Thanks to this unified structure, publishers can manage all ad formats with a single system.

The 100-Millisecond War

A user opens an app. The moment an ad slot appears, the following happens:

1. Bid Request 생성 (10ms)
   - Impression: "배너 광고, 320x50 사이즈"
   - Device: "iPhone 14, iOS 17"
   - User: "관심사: 스포츠, 위치: 서울"
   
2. DSP들에게 동시 전송 (20ms)
   - 30개 DSP에 병렬 요청
   
3. DSP 응답 수집 (50ms)
   - DSP A: 100원 입찰
   - DSP B: 150원 입찰
   - DSP C: 120원 입찰
   
4. 경매 및 광고 송출 (20ms)
   - 승자: DSP B
   - 광고 렌더링

Total elapsed time: 100 milliseconds

This entire process happens in the blink of an eye, completely unnoticed by the user.

The Realistic Challenges of Implementing OpenRTB

The theory seems simple enough, but what about the actual implementation?

First, massive throughput. A large-scale SSP has to process millions of queries per second. To reliably handle billions of requests a day, a highly advanced architecture—featuring distributed processing, in-memory caching, and asynchronous message handling—is essential.

Second, extreme speed requirements. When you factor in network latency, the actual processing time shrinks even further. Connection reuse, data compression, parallel processing... you have to shave off milliseconds at every single stage.

Third, security and policy compliance.

• HTTPS/TLS 1.2+ encryption

• sellers.json / ads.txt policy compliance

• GDPR/CCPA consent processing

You have to satisfy all of these requirements simultaneously.

Implementing OpenRTB, DARO reliably handles these millisecond-level auctions through auto-scaling cloud infrastructure, intelligent traffic routing, and real-time performance monitoring. Instead of dealing with complex protocol implementations, engineers can instantly access the global programmatic ecosystem with just a single SDK integration.

OpenRTB is more than just a technical standard; it's the foundation of the rapidly growing programmatic ad market. Now, let's take a concrete look at how DARO actually implemented this standard through our system architecture.

How is the DARO SSP Implemented?

The Tech Stack We Chose

When building the DARO SSP, the most important factor for us was using "battle-tested technologies."

Why we chose the Go + Fiber v3 combination

• Go's lightweight goroutines: handling tens of thousands of concurrent connections

• Fiber v3's zero memory allocation: extreme performance optimization

Based on this stack, we built a high-performance system capable of reliably processing massive volumes of bid requests.

Dual support for OpenRTB 2.x/3.x

We made sure to leverage all the benefits of the latest standards while maintaining compatibility with legacy DSPs. This maximized the number of demand sources we could access.

The Core of Real-Time Bidding: "Orchestration"

Simply processing things fast isn't everything.

The real challenge of real-time bidding lies not in simple parallel processing, but in "orchestration." DARO dynamically orchestrates the differing response times, protocol versions, and data formats of dozens of DSPs in real-time, converging them into a single auction. For example, it finds the sweet spot where we don't wait around for the slowest DSP but still capture the highest bid, wrapping up the entire auction within hundreds of milliseconds.

Scalable Architecture

We designed the system following DDD (Domain-Driven Design) principles.

AdUnit (광고 단위)
  ├── 자체 비즈니스 규칙 캡슐화
  └── 독립적인 도메인 엔티티
Bidder (입찰자)
  ├── DSP별 프로토콜 구현
  └── 단일 인터페이스로 통합
Publisher (퍼블리셔)
  ├── 수익 최적화 로직
  └── Floor Price 관리

Even when adding a new DSP, we only need to implement the interface without impacting the existing system. In reality, major domestic and global DSPs are reliably integrated on top of this structure, and new partners are continuously being added at a rapid pace.

This structure isn't just for the sake of technical elegance. The ad-tech market changes rapidly, and new ad formats, protocols, and DSPs will keep emerging. DARO's domain-centric modular structure serves as the foundation for responding nimbly to these shifts.

The Core of Data-Driven Optimization: The Event Analysis System

Every bidding event that occurs per auction, from BidRequest all the way to Click, is streamed in real-time via Kafka. These billions of data points piling up daily are analyzed in ClickHouse to forge even smarter revenue optimization strategies.

Alongside this, our support for Win Notice URLs (NURL) and Loss Notice URLs (LURL) achieves both transparency and optimization simultaneously. The DSP learns exactly why their bid failed, and DARO analyzes this data to adjust Floor Prices. For instance, if bidding competition is fierce during a specific time block, we raise the Floor Price to maximize revenue, and lower it during less competitive hours to boost the Fill Rate.

Beyond Tech: Proven Monetization Know-How

In this post, we looked at how the DARO SSP implemented OpenRTB and what actual technical challenges we've solved as we grew.

However, DARO's true value isn't just in its technical infrastructure. The fact that the accumulated know-how of the Alarmy team—gained from directly managing billions of won in monthly ad revenue—is baked into every corner of the system is what sets it apart.

At what hours should we tweak the Floor Price to maximize revenue? How should we react when a particular DSP's response slows down? Where is the optimal sweet spot between Fill Rate and eCPM? The answers to these questions don't come from docs or theory; they only emerge from years of battle-tested experience.

In other words, choosing DARO doesn't just mean adopting an SSP. It means directly applying the trial-and-error the Alarmy team endured while generating billions in revenue, the optimization know-how we discovered along the way, and the operational strategies we continue to improve every single day, right into your own app.

You can integrate all of this in just three days with a single SDK.

Stop wrestling with complicated ad tech. Engineers should focus on building a better app, and leave ad monetization to DARO, who has already paved the way.

With DARO, your app can also become the star of a billion-won monthly revenue story.