Custom Implementations

MAX has flexible and customizable integration settings which you can adjust to maximize revenue. This page summarizes common advanced use cases.

Consult your dedicated support and account team to ensure that your implementation is tested before you launch your app with MAX.

When you integrate third-party SDKs into your Mobile Property, you are solely responsible for such integrations. You and the third-party SDK provider must ensure compliant data processing and treatment of any end user- or device-based privacy choices or flags.

Show an interstitial or rewarded video ad unit only to users above a predicted CPM value that you calculate.
  • If you calculate this predicted CPM value by geo, per ad format, you can use the ad unit price floor function in the MAX ad unit page. When there is no fill, implement exponential retry logic to ensure that the ad request is not stuck in a loop of retries but you are not missing out on the opportunity to potentially receive a fill when/if asked within longer intervals in between the ad requests.
  • If you pre-calculate this user level value in ranges for an ad unit, you can create multiple ad units per range or tier (e.g. TIER1 RV, TIER2 RV) and each ad unit can have a unique waterfall with optimized price points based on the tier.
    • When separated by user “tier”, AppLovin recommends that you use the “selective init” feature (see Advanced Settings: “Selective Init”). If you remove certain networks from the waterfall associated with that user’s tier, selective init will ensure that only the active SDKs will be initialized (e.g. low-end users only see Google bidding and Google AdMob & Meta and have a faster init process while your top-tier users under a separate ad unit ID still have all top tier SDKs initialized with associated ad unit price floor or the network price floors).
    • By default, if you do not define an ad unit by using the selective init functionality, MAX initializes all active networks available across all ad units associated with that package.
    • Note that when you use selective init, any ad unit(s) that you do not specify are excluded from serving ads for the current session.
  • If you dynamically assign this user level value per ad request within the session but still keep it as a range or a tier (not as granular as impression level and dynamic), you can create a single MAX ad unit ID and leverage the “create a waterfall” feature.
    • In this implementation, you are responsible for communicating the granular segmentation logic “tier” through custom keywords.
    • When/if keywords are passed (e.g. segment:low_tier), that ad unit ID only goes through the associated segment. For example, the low-tier segment is exposed to shorter, more appropriately priced lines in a unique waterfall within the same ad unit ID.
Dynamically change the user experience and waterfall based on the user or user segment (e.g. app version, session time, predicted value, content of the app/page).
  • Depending on the number of users and dimensions you want to granularly target, the most effective tool is custom keywords. You can pass the app version, session time duration, predicted value, or any other identifier as custom keywords.
  • You determine the taxonomy, but the AppLovin ad server requires key/value pair syntax to communicate with your app. You can use these keywords individually or you can group them together with other variables like “HAS IDFA”, “Device Type”, “Age”, “Gender” where applicable by using the “create a waterfall” feature.
  • After you set the keywords and pass them to MAX in each ad request, create a MAX ad unit (a single ad unit ID per ad format), then create unique waterfalls within that ad unit page, based on the grouping of keywords using the “create a waterfall” feature (e.g. +section:homepage, +app_version:4.5 only sees direct sold & Google bidding and Google AdMob Private Marketplace Deals as the content here is premium)
Show app-open interstitials that load faster with a shorter waterfall.
  • There are several approaches to showing an interstitial right after app launch. This is a common process known as “prestitial”, “welcomestitial” in non-gaming apps.
  • You can leverage a traditional interstitial, a custom interstitial that you design, or a prestitial ad unit if you immediately want an interstitial to be shown with a one per user/per day frequency.
    • Using a developer hosted/controlled fullscreen “interstitial” where MAX provides MREC, native content: You have full control over the close button, sizing of the ad response returned, and the caching process. To ensure that there is always an ad on screen, you may leverage MREC and native demand in this “interstitial” container. For MAX, an MREC ad unit ID is leveraged and you handle the rest. Note that MAX MREC ad units have built-in support for mediating native demand using MAX-designed native templates. You can include additional native sources but the built-in support should help you maximize revenue and save development time at once.
Initialize a subset of SDKs for a subset of users.
  • Selective init: If you expect certain networks to be ineligible to serve in specific ad units (e.g. initialize with a different rewarded video ad unit ID to activate a conservative list of SDKs on low end devices to reduce ANRs) or you want to enter different network app IDs for a subset of users (e.g. COPPA users for several networks will require a different app ID), you may want to make sure that only the relevant SDKs associate with that ad unit ID.
  • By default, if you do not define an ad unit by using the selective init feature (see Advanced Settings: “Selective Init”), MAX initializes all active networks available across all active ad units associated with that package name. If you have different app IDs for the same network in different ad units associated with the app package name, MAX ad server will use each network app ID value to initialize randomly. This breaks the initialization process for several network SDKs and causes them to be removed from the waterfall.
  • By default, if you have different app IDs for the same network in different waterfalls within a single ad unit ID, MAX ad server will use each network app ID value to initialize randomly. This breaks the initialization process for several network SDKs and causes them to be removed from the waterfall. App IDs must be identical for networks across all ad networks within a single ad unit. To leverage different app IDs, use selective init and create different ad unit IDs.
  • Note that when you use selective init, any ad unit(s) that you do not specify are excluded from serving ads for the current session.
Manually set refresh rate by user, by demand source for banners/MRECs.
  • MAX has built-in sequential caching for banners and has full automated control over the refresh cycle. This allows you to reduce the manual work needed and ensure that refresh behavior is consistently functional regardless of the user behavior within the app between sections or between different ad experiences shown.
  • If you want to manually set the refresh rate (e.g. for non-gaming apps with multiple app sections for the user to navigate, in-feed banner ads), see Advanced Settings: “Customize Banner / MREC Ad Refresh” for instructions. To set demand partner-specific refresh rates, leverage the client side network name.
Serve native ads in banner and MREC ad units.
  • MAX has built-in support for mediating native in banner and MREC ad units for several demand partners. You can use MAX-defined templates to pull in additional native demand from the same networks for banners & native at once. You can create a network placement ID associated with native and update the banner MAX ad unit page with this ID without doing any additional development work.
  • To run this with other ad formats or other ad networks, use the custom SDK network function.
Lockscreen interstitials.
You can find instructions at Interstitial Ads: “Lock Screen Ads”. Note that not all network SDKs support this feature. Contact your account team for more information.
Swipable custom native in interstitials.
MAX supports this as a “manual” native ad unit. You design and manage the interstitial container, close button, and resizing.
Dynamically change the user experience and waterfall based on the user or user segment (e.g. app version, session time, predicted value, content of the app/page).
If you want to show ads from different waterfalls associated with the same ad unit by using the keyword functionality, AppLovin recommends that you disable the auto-enabled sequential caching feature and load interstitials separately. This ensures that the interstitial loads associated with each waterfall do not impact each other. MAX does not allow two interstitial ads at once if you use the same ad unit ID. You must wait for the initial ad load to finish. Alternatively, instead of keywords, you can leverage two different interstitial ad unit IDs and show the relevant ad as needed.