> For the complete documentation index, see [llms.txt](https://developers-apps-in-toss.toss.im/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-apps-in-toss.toss.im/guide/en/monetization/in-app-ad.md). # In-app ads In-app ads are the fastest way to generate revenue from your app without paid payments. By registering ads in Apps in Toss, you can start generating revenue from the very first day your app is launched, without any separate payment features. This document clearly explains how ad revenue is generated and which ads should be placed where. ### What are in-app ads? In-app ads are ads shown to users inside the app screen. They are shown naturally without interrupting the service flow, and generate revenue from that exposure. Ad revenue is determined in two ways. * How many times they are shown **(impressions)** * How much you earn each time it is shown **(eCPM)**
Impressions This is the number of times an ad actually appears on the user's screen. The more there are, the more revenue opportunities you have, but too many can hurt the user experience.
eCPM Revenue per 1,000 ad impressions. The higher it is, the greater the revenue, and it is affected by ad type and user attention. The more focused the user is, the greater the ad effect and the higher the unit price; if attention is low, the unit price goes down.
Multiplying these two gives you the estimated revenue. `Estimated revenue = Impressions × eCPM ÷ 1,000` For example, if an ad was shown 100,000 times today and the eCPM is 5,000 won, then 100,000 × 5,000 ÷ 1,000 = 500,000 won. *** ### In-app ad types It is most effective to use the three ads below together. Using them in combination rather than using only one can greatly increase overall revenue. #### Interstitial ads Ads that appear in full screen at screen transition points. * Feature: forced exposure (users have to see it) * Recommended placement: just before or after screen transitions (e.g., from the results screen to the next step) * Impressions: medium * eCPM: medium * Suitable situations: points where the flow breaks (level complete, booking complete, etc.), moments when users naturally pause
#### Rewarded ads Ads that play when the user directly selects 'Watch ad.' * Feature: voluntary viewing, high attention * Recommended placement: when a reward is needed (e.g., extra benefits, continue) * Impressions: low * eCPM: highest * Suitable situations: point grants, additional feature offerings, structures like 'watch an ad to get benefits'
#### Banner ads Ads fixed at the top or bottom of the screen and continuously shown. * Feature: always visible (traffic that accumulates automatically) * Recommended placement: main screen, list screen * Impressions: highest * eCPM: lowest * Suitable situations: screens with long usage time, screens visited repeatedly
*** ### Benefits of in-app ads * You can choose interstitial, rewarded, and banner ads and show them in places that fit the service flow. * Ad revenue starts from the first day the app is launched, so you can begin monetization right away. * You can use ads as a trigger to encourage users to keep using the service, increasing retention. * In game services, 'continue after watching an ad' can let users keep playing stages they were challenging, naturally encouraging reuse. *** ### Set up in the console #### 1. Register business information To integrate in-app ads, you must first register your business information. Your business information must be registered before you can proceed to the next steps: agreeing to the terms and entering settlement information. For instructions on how to register, [Guide](https://developers-apps-in-toss.toss.im/prepare/register-business.html)please refer to it. #### 2. Enter settlement information When you integrate in-app ads, ad revenue is generated. To receive settlement for your revenue, [register settlement information](https://developers-apps-in-toss.toss.im/guide/settlement)You need to. Enter your settlement information in the 'Info' tab of the workspace, then request review. Review takes an average of 2 to 3 business days. {% hint style="warning" %} **Please be sure to check** Please enter the account holder name exactly as it appears on the copy of the bankbook, without any differences in even a single letter. If it is entered differently, settlement may be delayed. {% endhint %} #### 3. Create an ad group Apps in Toss in-app ads follow Google AdMob ad policies. If you do not comply with the policies, ads may be limited or suspended.
**3-1. Ad group name** It is easier to manage if you include both the ad type and placement. Since you will manage multiple ad groups during operation, please give them names that will be immediately understandable later. * e.g.) Main\_InterstitialAd, GameEnd\_RewardedAd **3-2. Ad type** **Banner** * Ads that always float at the top or bottom of the screen. * As you use the app, exposures accumulate automatically, creating steady revenue. * However, once users become familiar with it, they tend to ignore it, so the unit price is the lowest. **Interstitial** * Ads that appear in full screen at screen transition points. * Because users cannot ignore them, the unit price is higher than banners. * It feels natural when inserted at moments when the flow is interrupted, such as level clears or content transitions. **Rewarded** * Ads that start only when the user directly taps 'Watch ad.' * Because users focus until the end to receive the reward, the unit price is the highest. * It is effective when connected to moments that benefit the user, such as granting points or items. **3-3. Reward** Fill in only when Rewarded ads are selected. Please enter the exact name and quantity of the reward the user actually receives. Since this is displayed on the user's screen, it is better to use the same terms as those used in the service. * e.g.) Reward unit in service: chance / quantity and amount: 1 **3-4. Mediation** Mediation is a technology that connects multiple ad networks and automatically selects in real time the ad with the highest revenue. The ad network that matches the category registered in 'App info' will be set automatically. You can change it to another category, but the changed content is not reflected in App info and is applied only when creating an ad group. After registering, you can check the ad group ID on the detail screen. * It may take up to 2 hours for the ad group ID to be registered with Google. * Please develop using the ad group ID provided after creating the ad group. *** ### Ad operation policy #### Toss Ads SSP policy Please make sure to follow the policies below. If you violate them, ad exposure may be restricted. Even if it is not written in this policy, **Actions that artificially induce ad exposure, clicks, or performance, or mislead users, may be considered policy violations.** If the service is terminated due to a policy violation, all partners must follow the service termination policy. | Type | Prohibited actions | Specific examples | Policy criteria | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Degraded UI/UX quality | Actions that blur the distinction between ads and content, induce ad consumption or clicks unrelated to the user's intent, or configure the UI to interfere with normal service use |

|

| | Ad call behavior tampering | Actions that change or bypass the SDK's default event flow or ad call method | |

| | Abnormal traffic and performance manipulation | Actions that distort traffic and ad performance by automated or artificial means | | | | Reward/engagement-based click inducement | Providing rewards or benefits at the same time as an ad click | | | | Ad hiding or overlap | Actions that intentionally hide ads or obscure them with other UI elements so that users cannot clearly recognize the presence of the ad |

• Transparent ad

• Insert the ad DOM behind another card UI

| • The ad must have a clearly verifiable visible state | #### UX / Product Principle operating principles Ads must also follow Toss's UX principles. | **Toss Principle** | **Application criteria** | **example** | | ------------------------------ | --------------------------------------------------------------------------------- | ------------------------------------------------------ | | **Simplicity** | Ads must be clear and understandable without additional explanation | "View now", "Watch ad" etc. clear CTA | | **Clear Action** | Users should be able to predict what action will occur after clicking an ad | Provide a notice when moving externally | | **No Deception (UX Red Rule)** | Ads must not appear in unexpected moments, forms, or positions, or mislead users. | When ads are disguised as content | | **Value First** | Ads must not interfere with the customer's service goals. | Do not insert ads during payment/account opening flows | #### Usage restrictions and sanctions If Apps in Toss ad placements or services violate this policy, sanctions may be imposed. **Restriction procedure** In principle, restrictions are applied step by step according to the accumulation of violations. Depending on the type or severity of the violation, even a single violation may result in an immediate 30-day suspension or a permanent suspension. ※ Violations identified at the same time are counted as one violation regardless of the number of violation slots. If violations are identified separately later, the violation count accumulates.
**Handling of unjust gains** Revenue generated through policy violations, invalid traffic, or other fraudulent means may be considered unjust gains. If unjust gains are identified, payment of that amount may be withheld or rejected. Amounts already paid may also be recovered. **Appeals process** * If you receive a notice of usage restriction, **you can file an appeal within 30 days**. * Appeal materials can be submitted through Channel Talk. * The submitted materials will be reviewed according to internal standards, and additional materials may be requested if necessary. * Review may take about one week on business days. * Appeals are **reviewed with a focus on whether the sanction was appropriate**. The sanction will not be lifted simply because the violation has been corrected or a recurrence prevention plan has been submitted. * The sanction may be lifted if the submitted materials do not substantiate the violation that was the basis for the sanction, or if it is confirmed that there was a clear error in the sanction decision. * Repeated or serious violations may result in a permanent restriction on service use. *** ### Integrate development Please be careful not to expose ads to users too frequently. When testing in-app ads, you must use the test ID. Using a production ID may result in sanctions. While the ad is playing, please pause the app sound temporarily and resume it automatically when the ad ends. [Interstitial/Rewarded ads Interstitial/rewarded ad load and show API and SDK integration method](/documentation/api-and-sdk-en/common/monetization/iaa/interstitial-rewarded-ad.md) [Banner ads (WebView) WebView banner ad SDK initialization, attachment, and event callback API](/documentation/api-and-sdk-en/common/monetization/iaa/web-banner.md) [Banner ads (React Native) How to use the InlineAd component for React Native banner ads](/documentation/api-and-sdk-en/common/monetization/iaa/rn-banner.md) *** ### Check ad performance and settlement details You can select a period and operating system (OS) to check the items below. * Total ad impressions, eCPM, total estimated revenue * Performance data is updated every day at 10:00 AM.
**Settlement details** * Revenue from the 1st to the last day of each month is updated on the 1st of the following month. * Revenue finalized on the 1st of the following month is deposited on the last day of that month. The settlement structure is [Guide](https://developers-apps-in-toss.toss.im/guide/settlement#id-1)please refer to it. *** ### Analyze ads You can check whether the ads in my mini app are being displayed correctly and view trends in ad frequency and eCPM. See with data whether you are showing ads too often and which ad types are effective for revenue. {% hint style="info" %} **Please note** To view actual data in the analysis tab, you need to update to SDK 2.7.0 or later. Data accumulates from after the SDK update, so please update the SDK first. {% endhint %} #### Ad exposure status You can check how far ads have progressed through each stage, from request to exposure.
| Stage | Description | | ---------------- | ------------------------------------------------------------------------------------- | | Ad request | The number of times the app requested ads from the ad server. | | Ad received | The number of times the ad server successfully returned an ad. | | Exposure attempt | The number of times an attempt was made to show the received ad on the user's screen. | | Exposure success | The number of times the ad was actually shown on the user's screen. | {% hint style="info" %} **Try using it like this** * If ad reception is low compared to ad requests: the ad network may not have enough ads to fill (No Fill). * If exposure attempts are low compared to received ads: the ad was received but not actually shown. `load`and `show` Please check the timing of the call. * If success is low compared to exposure attempts: there is a failure during the ad rendering process. Please check the SDK version or the call order. {% endhint %} #### Ad exposure frequency and eCPM You can check the exposure frequency and eCPM trends for each ad type (banner, interstitial, rewarded). * Bar graph (left Y-axis): average daily ad impressions per user (by ad type) * Line graph (right Y-axis): eCPM (KRW)
{% hint style="info" %} **Try using it like this** * If the exposure frequency has increased but eCPM has dropped, ad fatigue may be the cause. * If the eCPM of rewarded ads is higher than other types, it may be a good idea to increase the share of rewarded ads. * If you turn on 'View by OS,' you can compare performance between iOS and Android. {% endhint %} #### Ad exposure share and eCPM You can check together the share of ad exposure relative to app usage time and the eCPM trend. * Bar graph (left Y-axis): exposure share (%) by ad type * Line graph (right Y-axis): eCPM (KRW)
{% hint style="info" %} **Try using it like this** * Ad exposure share is the ratio of ad exposure time to total time spent. * If the ad share is too high, the user experience may suffer and churn may increase. * If there is an ad type with low eCPM relative to its share, reduce that type's placement and switch to a type with higher eCPM. * Usually, rewarded ads have a high eCPM even with a small share, and banner ads have a low eCPM even with a high share. * Banner ads are not yet supported. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developers-apps-in-toss.toss.im/guide/en/monetization/in-app-ad.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.