Advanced Settings

Like ads.txt, app-ads.txt is a text file that app developers upload to their developer website listed on Google Play and the App Store. It lists the ad sources authorized to sell that developer’s in-app inventory. Just like on the web, the IAB created this standard to let buyers know who is and isn’t authorized to buy and sell specific in-app inventory. It is a key step that protects app developers from unauthorized reselling or inventory fraud.

Publishers who adopt app-ads.txt are likely to earn more revenue, as many brand buyers and advertisers require publishers to have a valid app-ads.txt file and will not buy inventory on apps without one. 

How app-ads.txt Works and Benefits Mobile Apps

A demand-side platform (DSP) looking to bid on app inventory scans the app-ads.txt file on a developer’s website to verify which ad sources are authorized to sell that app’s inventory. The DSP will only accept bid requests from ad sources listed on the file and authorized by the app developer.

How app-ads.txt can benefit your mobile apps:

• Access to premium brand demand: Having a valid and properly formatted app-ads.txt file makes your app inventory eligible for campaigns from premium advertisers and brand buyers who rely on the standard to verify trusted supply sources.
• Fraud reduction: By publicly listing only the partners you authorize, app-ads.txt helps block unauthorized sellers and spoofed inventory, ensuring that revenue from your apps goes directly to you.

Implement app-ads.txt

Step 1. Add Your Developer Website to the App Stores

Add your developer website domain to your app listings on Google Play and the App Store. Use one canonical root domain (for example, yourstudio.com) across all apps. Buyers and monetization partners use this URL to discover and verify your app-ads.txt file.

Step 2. Create Your app-ads.txt File

Create a plain-text file named app-ads.txt (UTF-8) in the root directory of your developer website. In this file, list all authorized partners using the exact format they provide. Each ad network you work with can share the specific lines you need to include:

partner-domain.com, <YOUR_ACCOUNT_ID>, DIRECT|RESELLER, <CERT_ID (optional)>

Place your OWNERDOMAIN line at the top of the file so that your app-ads.txt, store listings, and business domain all align under one identity. This helps buyers connect your file to Sellers.json and verify ownership clearly:

OWNERDOMAIN=yourstudio.com

For example (this is illustrative only; use your partners’ exact lines):

OWNERDOMAIN=yourstudio.com

vungle.com, <YOUR_VUNGLE_PUBLISHER_ACCOUNT_ID>, DIRECT, c107d686becd2d77
google.com, pub-<YOUR_ADMOB_PUBLISHER_ID>, DIRECT, f08c47fec0942fa0
example-ssp.com, <YOUR_ID>, RESELLER, <CERT_ID>

Make sure your file uses UTF-8 character encoding and that your web server serves it as Content-Type: text/plain. Every authorized seller should appear exactly as listed by each ad network or exchange.

For full field definitions and formatting requirements, review the IAB Tech Lab’s Authorized Sellers for Apps specification.

Step 3. Add Liftoff to Your app-ads.txt File

Add Liftoff to your app-ads.txt file by updating your Seller ID and including the most up-to-date Liftoff Monetize entries.

Replace <YOUR_VUNGLE_PUBLISHER_ACCOUNT_ID> with your actual Publisher Account ID (Seller ID). You can find this in the top right corner of your Liftoff Monetize Dashboard, as shown: 

Entering this incorrectly or omitting it can prevent buyers from validating your inventory and may lead to lost revenue.

vungle.com, 53c9a946adeed4cbd2w5555a, DIRECT, c107d686becd2d77

After adding your Seller ID line, include the latest Liftoff Monetize list of authorized entries and paste the text block in your TXT file. Keeping this list current ensures your app remains eligible for Liftoff’s premium brand demand and maximizes access to advertiser budgets. Liftoff sends monthly email updates with any missing or new entries.

Download this file for our latest entries: Liftoff Monetize App-Ads.txt.

Step 4. Link Your Developer Website in the Liftoff Dashboard

In your Liftoff Monetize Dashboard, set the Developer website to the same root domain you listed in the app stores (for example, yourstudio.com).

Note: The IAB Sellers.json specification allows only one domain per Seller ID (Liftoff account). A Seller ID cannot validly represent more than one entity.

Step 5. Publish the app-ads.txt File

Host the file at the root of your domain so that it’s reachable at: https://yourstudio.com/app-ads.txt.
Serve it with HTTP header `` (UTF-8). If your file is hosted on a different root domain, keep it to one cross-domain redirect; internal redirects on the same root are fine.

Quick checks:

https://yourstudio.com/app-ads.txt     # should show plain text
curl -I https://yourstudio.com/app-ads.txt   # look for Content-Type: text/plain

Re-validate whenever you add or remove partners, change domains, or move hosting to ensure buyers always see the latest authorization list.

Apple has published details on their privacy requirements for the App Store. According to Apple’s announcement, app developers must define which data are collected by their apps and any SDKs they have integrated.

To help you answer this questionnaire with respect to your integration of the Vungle SDK, refer to the following table, which maps Vungle's data collection and use to the data types that Apple asks about in its questionnaire.

A couple of disclaimers:

• This list is only applicable to Apple privacy questionnaire, and it does not address data or privacy questions that may be raised by other parties. Please always refer to our Privacy Policy for more detailed information.
• This list only describes Vungle's SDK and data collection. This list does not describe a developer’s overall app data collection and use, or that of any other SDK.

You can pass alternative identifier signals to Liftoff. Alternative ID signals unlock premium brand demand and improve monetization. Supported alternative ID types include:

• LiveRamp RampID (via LiveRamp Envelope)
• UID2.0
• EUID

Alternative IDs are passed to Liftoff via the Vungle SDK. They allow buyers who transact on alternative IDs to recognize impressions and bid accordingly.

Pass Multiple Alternative IDs Simultaneously

Publishers using LiveRamp’s Authenticated Traffic Solution (ATS) SDK/API can use the RideAlong feature to simultaneously pass other alternative IDs (e.g., UID2.0 or EUID) alongside RampIDs in LiveRamp Envelopes to Liftoff. Contact your LiveRamp representative to enable RideAlong IDs for your account.

Integration Options

There are two methods for sending alternative IDs to Liftoff. The table below summarizes which IDs are supported via each method and path.

We recommend using the API method, especially for publishers on MAX, AdMob, or LevelPlay, where alternative IDs cannot currently reach Liftoff via mediation. The API method also provides broader coverage across both bidding and waterfall traffic.

For MAX, AdMob, and LevelPlay

These platforms do not currently pass alternative IDs to Liftoff in their mediation bid requests. Publishers using these platforms should use Option 1, the API method, to ensure that Liftoff receives their alternative IDs.

For Other Mediation Partners

Liftoff is ready to ingest alternative IDs from additional mediation partners beyond those listed in the table above. If your mediation partner isn't listed and you'd like to pass alternative IDs to Liftoff, contact your Liftoff account manager or reach out to monetize@liftoff.io.

Option 1 (Recommended): API Method

The API method provides broader coverage across bidding and waterfall traffic. Coverage via the mediation method is limited to bidding traffic.

Requirements

1. Liftoff Monetize SDK integrated in your app
2. Alternative ID(s) available in your app. Your app must be generating at least one supported alternative ID type:
   • RampID
   • UID2.0
   • EUID
3. Liftoff account configured for alternative IDs:
   • Contact your Liftoff account manager or reach out to monetize@liftoff.io to enable alternative ID ingestion for your app.
   • If not enabled, alternative IDs passed via the API will not be used.

Implementation

1. Set each alternative ID as custom data before loading an ad using the key/value pairs below.

   Parameter	Type	Description
   key	String	The key identifying the alternative ID type. Supported keys: liveramp_envelope: LiveRamp Envelopes (containing RampIDs and RideAlong IDs) uidapi: UID2.0 tokens euid: EUID tokens
   value	String	The envelope or token string generated by your app.

2. Notify your Liftoff account manager or reach out to monetize@liftoff.io so we can confirm we are receiving your alternative IDs.

Best Practice

To ensure maximum buyer eligibility and monetization impact, set alternative IDs:

• Before every ad request
• As early as possible in the ad load lifecycle
• Whenever the user identity changes

Example

VungleAds.firstPartyData.addCustomData("liveramp_envelope", value: "1234")
VungleAds.firstPartyData.addCustomData("uidapi", value: "1234")
VungleAds.firstPartyData.addCustomData("euid", value: "1234")


// Only call clear to stop data flow
VungleAds.firstPartyData.clearAll()

[VungleAds.firstPartyData addCustomData:@"liveramp_envelope" value:@"1234"];
[VungleAds.firstPartyData addCustomData:@"uidapi" value:@"1234"];
[VungleAds.firstPartyData addCustomData:@"euid" value:@"1234"];

// Only call clear to stop data flow
[VungleAds.firstPartyData clearAll];

Option 2: Mediation Method

Coverage via the mediation method is limited to bidding traffic. The API method provides broader coverage across bidding and waterfall traffic.

Requirements

1. Liftoff Monetize SDK integrated in your app
2. Alternative ID(s) available in your app. Your app must be generating at least one supported alternative ID type:
   • RampID
   • UID2.0
   • EUID
3. Supported mediation partner that passes alternative IDs as extended IDs (EIDs) in the bid request per the OpenRTB specification:
   • Google Ad Manager (GAM): RampID, UID2.0, EUID
   • Xandr: RampID, UID2.0
   • Nimbus: RampID, UID2.0

Implementation

1. Complete the required integration steps with your mediation partner to configure passing alternative IDs. Contact your mediation partner directly for guidance and current documentation.
2. Notify your Liftoff account manager or reach out to monetize@liftoff.io so we can confirm we are receiving your alternative IDs via your supported mediation partner.

As of May 25, 2019, the General Data Protection Regulation (GDPR) will be enforced in the European Union. To comply with GDPR, developers have the following options.

• Option 1 (recommended): You, the Publisher, integrate with a Consent Management Platform (CMP) that complies with IAB TCF v2 for your user consent flow. You should wait for the CMP to establish consent status before loading an ad. The Vungle SDK will read the TCF v2 string provided by the CMP. Liftoff does not check CMPs for full compliance with the TCF or applicable privacy laws.
• Option 2: Publisher controls the GDPR consent process at the user level, then communicates the user’s choice to Vungle. To do this, developers can collect the user’s consent using their own mechanism, and then use Vungle APIs to update or query the user’s consent status. Refer to the sample code below for details.
• Option 3: Allow Vungle to handle the requirements. Vungle will display a consent dialog before playing an ad for a European user, and will remember the user’s consent or rejection for subsequent ads.

To use Vungle APIs to update or query the user’s consent status (as recommended in Option 2), use these functions for Vungle SDK v.7.0.0 and higher:

// GDPR - Opt In
VunglePrivacySettings.setGDPRStatus(true)
      
// GDPR - Opt Out
VunglePrivacySettings.setGDPRStatus(false)

// GDPR - Opt In
[VunglePrivacySettings setGDPRStatus:YES];
  
// GDPR - Opt Out
[VunglePrivacySettings setGDPRStatus:NO];

Optionally, you can also set the GDPR message version: this is an arbitrary string that can be used to identify the message with which the user was prompted when making their selection.

// GDPR - Set Message Version
VunglePrivacySettings.setGDPRMessageVersion("v1.2.3")

// GDPR - Set Message Version
[VunglePrivacySettings setGDPRMessageVersion:@"v1.2.3"];

As of July 1, 2020, California Consumer Privacy Act (CCPA) will be enforced and publishers must update to iOS SDK 6.7.0 or higher to comply with CCPA. In accordance with CCPA, the consent status is opted in by default unless VunglePrivacySettings.setCCPAStatus() has been explicitly called to set it as opted out.

// CCPA - Opt In
VunglePrivacySettings.setCCPAStatus(true)
      
// CCPA - Opt Out
VunglePrivacySettings.setCCPAStatus(false)

// CCPA - Opt In
[VunglePrivacySettings setCCPAStatus:YES];
  
// CCPA - Opt Out
[VunglePrivacySettings setCCPAStatus:NO];

Generally speaking, the Children’s Online Privacy Protection Act (COPPA) regulates the collection, use, and disclosure of personal information for children under the age of 13 by certain websites and online services (including mobile apps). Compliance with COPPA is a legal issue and we suggest you seek the advice of an attorney in determining compliance. Additionally, for more information on COPPA, please refer to the Federal Trade Commission's COPPA FAQ.

Vungle has tools to assist publishers with COPPA compliance. In addition to use of settings on the Monetize Dashboard, Vungle offers features within the Vungle SDK using the COPPA API. This is available for early access with iOS SDK v.6.11.0.

COPPA Compliance at the App Level

Vungle provides tooling in the Monetize Dashboard to indicate COPPA compliance for each app. When defining your app in the Monetize Dashboard, you must indicate to Vungle whether your app is directed toward children under age 13. Depending on your setting, Vungle will globally treat all traffic for the app as subject to COPPA or not. If you indicate that your app is not directed toward children under 13, COPPA settings will not apply at the app level, and can then be indicated at a more granular level (see COPPA Compliance at the Device Level).

COPPA Compliance at the Device Level

Starting with SDK v.6.11 early access, Vungle provides an optional method for you to indicate at the device level whether the user within the given mobile app is under or over the age of 13 by using the SDK COPPA API. The SDK COPPA API is most appropriate in cases of apps that legally can implement an age screen or age gate in accordance with COPPA, rather than treating all users as under 13. If you believe your app as a whole is primarily directed to children under the age of 13 as set forth in COPPA and related guidance, the COPPA Dashboard settings are more appropriate for you.

Recommendations for Using Vungle's COPPA Compliance Tools

Pursuant to the Vungle SDK License and Publisher Terms, it is the publisher’s responsibility to ensure compliance with applicable laws, including COPPA. Vungle is not liable for COPPA violations resulting from incorrect settings communicated via the SDK COPPA API. Consider the following recommendations to help you ensure COPPA compliance.

• Use the SDK COPPA API for mixed-audience apps. Use the SDK COPPA API if:
  • You have confirmed you are a “mixed-audience app” under COPPA
  • You have implemented an age gate or age screen
  • You have stated that for your app “COPPA settings will NOT apply” in the Publisher Dashboard (otherwise, a COPPA-compliant setting in your Dashboard will override any API settings to the contrary)
• Use the Dashboard for apps directed towards children under 13: In cases where it is clear that your app is primarily directed to children under the age of 13, use the COPPA settings section in the Publisher Dashboard instead of the SDK COPPA API.
• Conflicting settings between API and Dashboard: As noted above, you can establish COPPA settings at the app level (but not at the user level) on the Publisher Dashboard, and at the device/user level by using the SDK COPPA API. Under the current release of SDK COPPA API functionality, in the event of a conflict between the settings in Publisher Dashboard and those passed via the SDK COPPA API, the COPPA-compliant setting takes precedence.
  
  For example, if your app setting on the Publisher Dashboard is COPPA-compliant, and that same app also enables use of the SDK COPPA API and identifies a given user as over 13, Vungle will defer to the Dashboard setting, which states that all the users in this app are protected by COPPA regulations. If, on the other hand, your app setting on the Publisher Dashboard states that your app is not directed toward users under the age of 13, but a call to the SDK COPPA API identifies a given user as under age 13, Vungle will override the dashboard setting and treat that user as being protected by COPPA regulations.

COPPA API

To ensure that the user’s COPPA status can be used on SDK initialization, the SDK COPPA API should be called before calling the init method. To update Vungle about a user’s COPPA status:

1. Use VunglePrivacySettings.setCOPPAStatus(bool) where BOOL is set to `true` for a user who is under the age of 13 and falls under COPPA regulations; `false` for a user known to be over the age of 13.
2. Then call [[VungleSDK sharedSDK] startWithAppID: options: error:], as shown:

Usage example:

// COPPA - Opt In
VunglePrivacySettings.setCOPPAStatus(true)
      
// COPPA - Opt Out
VunglePrivacySettings.setCOPPAStatus(false)

// COPPA - Opt In
[VunglePrivacySettings setCOPPAStatus:YES];
  
// COPPA - Opt Out
[VunglePrivacySettings setCOPPAStatus:NO];

You can prevent passing the IDFV from the device to the SDK.

Sample code:

// Publish IDFV
VunglePrivacySettings.setPublishIdfv(true)
        
// Restrict Publishing IDFV
VunglePrivacySettings.setPublishIdfv(false)

// Publish IDFV
[VunglePrivacySettings setPublishIDFV:YES];

// Restrict Publishing IDFV
[VunglePrivacySettings setPublishIDFV:NO];

You can find creativeID as a string property available in each ad instance. This value can be used for debugging, or can be shared if issues are identified with specific creatives. In the provided example, the creative ID is used to output details of the loaded interstitial ad when the app is notified of load success.

func interstitialAdDidLoad(_ interstitial: VungleInterstitial) {
    print("[TestApp log] interstitialAdDidLoad placementId:\(interstitial.placementId) eventId:\(interstitial.eventId) creativeId:\(interstitial.creativeId)")
}

- (void)interstitialAdDidLoad:(VungleInterstitial *)interstitial {
  NSLog(@"[TestApp log] interstitialAdDidLoad placementId: %@ eventId: %@ creativeId: %@", interstitial.placementId, interstitial.eventId, interstitial.creativeId);
}

For rewarded ads, you can set some optional parameters before loading and playing the ad.

• You can set the user ID to identify the user that is interacting with the ad.
• You can also customize texts used to incentivize the user to finish the ad experience and receive the reward (these texts are shown in an alert that would be presented if the user attempts to close the ad before completion).

Sample code:

  rewardedAd.setUserId(userId: "YOUR USER ID")
  rewardedAd.setAlertTitleText("Custom Alert Title")
  rewardedAd.setAlertBodyText("Custom Alert Body")
  rewardedAd.setAlertCloseButtonText("Custom Alert Close")
  rewardedAd.setAlertContinueButtonText("Custom Alert Continue")

  // customize rewarded alert
  [self.rewardedAd setUserIdWithUserId:@"YOUR USER ID"];
  [self.rewardedAd setAlertTitleText:@"Custom Alert Title"];
  [self.rewardedAd setAlertBodyText:@"Custom Alert Body"];
  [self.rewardedAd setAlertCloseButtonText:@"Custom Alert Close"];
  [self.rewardedAd setAlertContinueButtonText:@"Custom Alert Continue"];