☑️Integration Checklist
Double-check your integration with this checklist. These key components will help ensure a seamless Immersive ads SDK integration, minimizing errors before your app goes live.
Double-check your integration with this checklist. These key components will help ensure a seamless Immersive ads SDK integration, minimizing errors before your app goes live.
It is important that you replace the PubScale placeholder with your game’s assets, which is displayed when there's no ad available.
2. Assign Unique Ad Tag for Ad Units
Ensure each ad unit has a unique Ad Tag assigned. Example: Home_Screen_Unit or level_fail_ad_unit. This allows us to analyze the performance of each ad unit for further optimization.
Ensure the Ad tag and Ad choices icon are sufficiently large and clearly visible, with distinct colour contrast.
We recommend the Ad Tag and Ad Choices Icon be at least 30x30px
Make sure the ad elements(Header, Icon, CTA, BigImage) do not overlap.
When adjusting ad size, ensure uniform scaling (equal values for X and Y) to prevent stretching and trimming of ad elements (Big Image, Ad icon, Buttons)
Ensure ad units do not overlap with other on-screen elements.
Ensure templates are customized to fit longer text without overlap or extending outside the frame.
Headline should be at least 25 characters long, and CTA text should be at least 15 characters long
Ensure ad units are prepared to display both landscape and portrait images. This can be done by selecting the suitable Display Template or crafting a custom Display template.
Build the application to an actual device. Verify if the impression indicator turns green when the ad is in the camera view and if the click indicator turns green when you tap on the ad.
If the Impression indicator is not green, find the fix here.
If the Click indicator is not green, find the fix here.
Ensure that when a popup or overlay appears over an ad unit, the background ad unit is disabled to prevent accidental clicks, avoiding potential policy issues due to high CTR.
To disable the ad, call HideAd() on nativeAdHolder, and to enable it again use UnHideAd()
Ensure the ad unit is disabled even when it's completely hidden by the overlay.
Before sending a build to our QA for testing, ensure the Status Visualizer is enabled.
You don't need to disable it; it will be automatically turned off in the live build.
To Allow Subsequent Ad Requests:
This is to be done only if your ad is placed on panels or popups
If your ad is placed on panels or popups, disable AutoFetch() and manually call FetchAd() only when the UI panel or overlay is active.
When fetching an ad manually, include a counter. If it's been over 15 seconds since the last ad impression, fetch a new one; otherwise, keep showing the current ad.
Subscribing to Event_AdLoaded on NativeAdHolder records the last ad load time. This prevents multiple ad requests, especially during frequent panel openings and closings.
Avoid Ad Unit Triggering Multiple Requests:
To address this issue, ensure that AutoFetch() is disabled whenever FetchAd() is called manually.
5. Rollout with A/B Test
If you plan to roll out with an A/B test where ads are shown to some of the users while others don't see them, make sure to follow the steps below:
The first step would be to remove the PubScaleManager prefab from the first scene
Once a response is received from the A/B test service (such as Firebase Remote config)
If the user is to be shown ads, you can instantiate PubScaleManager like any GameObject or it can also be loaded from the Resources folder
Once the PubScaleManager is instantiated, it will begin Caching Ads
In addition to the above, the default state of all Native ad Game Objects needs to be Disabled. Otherwise, when the native ad object requests an ad, the PubScaleManager will get dynamically instantiated (lazy loaded) and begin caching ads.
The main goal is to prevent the PubScaleManager from being loaded for users who are not supposed to see ads. If active, it will cache ads which will not get shown impacting Show Rate negatively driving down ecpm.
Doing the above steps (2) and (3) ensures the A/B test happens correctly.
The downloaded ad textures build up in memory and may need manual handling in certain cases.
The accumulated textures are cleared when a scene change or reload happens. However, in the following cases, you should manually manage texture memory
Single scene setup
Long-running gameplay scene
Gameplay Restart/ Progression happens without any scene reload or change
Destroying texture assets is an expensive operation. The SDK avoids doing so during gameplay as what would be a good time for the SDK could be bad timing for the game and lead to a framerate drop at a critical point
You can manually invoke Resource.UnloadUnusedAssets() at a strategic point when the gameplay is not demanding to free up the texture memory
If you don't want to use Unity's UnloadUnusedAssets API, you can handle the textures at the level of each NativeAdHolder.
Here is a script that can be used as is or modified to suit your needs
For display templates that show a subset of the ad media:
Do not delete the unused media game object and keep its reference and settings in the DisplayHandler script as it is. No change is required.
Uncheck it's Image component (but let it remain on the game object)
Make adjustments to ensure it does not overlap any displayed ad elements
When the ad loads, the ad icon and big media are loaded into memory (even if not shown). As in the script above you can get the reference to the texture and destroy at a convenient point in the game flow when the intensity is low.