diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..db403c5 --- /dev/null +++ b/404.html @@ -0,0 +1,1171 @@ + + + +
+ + + + + + + + + + + + + + +Banner ads are rectangular advertisements, consisting of either images or text, that are integrated into an app's layout. These ads remain on the screen while users engage with the app and can automatically refresh after a designated time interval. If you're new to mobile advertising, banner ads provide an excellent starting point for your ad implementation journey.
+This guide demonstrates how to seamlessly integrate banner ads from AdMob into a Godot app. Alongside code snippets and detailed instructions, it also provides guidance on appropriately sizing banners and directs you to additional resources for further assistance.
+This document is based on:
+ +When developing and testing your Godot apps, it's crucial to use test ads rather than live production ads. Failure to do so can result in the suspension of your AdMob account.
+The most straightforward method to load test ads is by utilizing our dedicated test ad unit ID for Android and iOS banners:
+ +This particular ad unit ID has been purposefully configured to deliver test ads for every request. You can safely employ it during your coding, testing, and debugging phases. However, remember to replace this test ad unit ID with your own when you are ready to publish your app.
+For a more comprehensive understanding of how the Mobile Ads SDK's test ads function, please refer to our documentation on Test Ads.
+The code sample below demonstrates how to utilize the AdView. In this example, you'll create an instance of an AdView, load an ad into it using an AdRequest, and enhance functionality by handling various life cycle events.
+The initial step in utilizing a banner ad is to create an instance of an AdView within a GDScript attached to a Node.
+The constructor for an AdView in Godot has the following parameters:
+unit_id
: The AdMob ad unit ID from which the AdView should load ads.AdSize
: The AdMob ad size you wish to utilize (refer to AdView sizes for specifics).AdPosition
: The position at which the banner ad should be positioned. The AdPosition.Values
enum enumerates the valid ad position values.Take note of the distinct ad units used based on the platform. When making ad requests on iOS, you should utilize an iOS ad unit, while for Android, you must use an Android ad unit.
+In addition to utilizing predefined AdSize constants, you can also specify a custom size for your ad:
+The second phase in utilizing the AdView involves crafting an AdRequest and then passing it to the load_banner()
method.
To tailor the behavior of your ad, you can connect to various events in the ad's lifecycle, such as loading, opening, closing, and more. To monitor these events, you can register a AdListener
:
Upon completion of using the AdView, remember to call Destroy() to release allocated resources and free up memory.
+That's all there is to it! Your app is now fully prepared to showcase banner ads from AdMob.
+Below is a table presenting the standard banner ad sizes:
+Size in dp (WxH) | +Description | +Availability | +AdSize constant | +
---|---|---|---|
320x50 | +Standard Banner | +Phones and Tablets | +BANNER | +
320x100 | +Large Banner | +Phones and Tablets | +LARGE_BANNER | +
300x250 | +IAB Medium Rectangle | +Phones and Tablets | +MEDIUM_RECTANGLE | +
468x60 | +IAB Full-Size Banner | +Tablets | +FULL_BANNER | +
728x90 | +IAB Leaderboard | +Tablets | +LEADERBOARD | +
Provided width x Adaptive height | +Adaptive banner | +Phones and Tablets | +N/A | +
Screen width x 32/50/90 | +Smart banner | +Phones and Tablets | +N/A | +
Adaptive banners represent the evolution of responsive ads, enhancing performance by dynamically optimizing ad size for each device. Unlike smart banners, which supported only fixed heights, adaptive banners empower you to specify the ad's width, which is then used to determine the most suitable ad size.
+To select the optimal ad size, adaptive banners rely on fixed aspect ratios instead of fixed heights. This results in banner ads that maintain a consistent proportion of the screen across various devices, offering the potential for improved performance.
+When working with adaptive banners, it's important to note that they consistently return a set size for a particular device and width. Once you've tested your layout on a specific device, you can count on the ad size remaining unchanged. However, keep in mind that the banner creative's size may vary across different devices. Therefore, we recommend that your layout accommodates potential differences in ad height. In rare instances, the complete adaptive size may not be filled, and a standard-sized creative will be centered in that space instead.
+This document is based on:
+ +Width Knowledge: You must have knowledge of the width of the view where the ad will be placed. This should account for the device's width and any safe areas or cutouts that may be present.
+Plugin Version: Make sure you are using the latest version of the Google Mobile Ads Godot plugin. For mediation, ensure you are also using the latest version of each mediation adapter.
+Optimal Width Usage: Adaptive banner sizes perform best when they utilize the full available width. In most cases, this equates to the full width of the device's screen. Take into account any safe areas that may apply.
+Ad Sizing: The Google Mobile Ads SDK automatically sizes the banner with an optimized ad height based on the provided width when using the adaptive AdSize APIs.
+Adaptive Banner Sizes: You can obtain adaptive ad sizes using three functions: AdSize.get_landscape_anchored_adaptive_banner_ad_size
for landscape, AdSize.get_portrait_anchored_adaptive_banner_ad_size
for portrait, and AdSize.get_current_orientation_anchored_adaptive_banner_ad_size
for the current orientation at the time of execution.
Stable Sizing: The size returned for a given width on a specific device will remain constant. Therefore, once you've tested your layout on a particular device, you can be confident that the ad size will not change.
+Anchored Banner Height: The anchored banner height is always within certain limits. It will never exceed 15% of the device's height or fall below 50 density-independent pixels (dp).
+Full Width Banners: For full-width banners, you can use the AdSize.FULL_WIDTH
constant instead of specifying a specific width.
Follow these steps to implement a simple adaptive anchor banner in Godot:
+Obtain Adaptive Ad Size:
+DisplayServer.window_get_size().x
be useful.AdSize.FullWidth
flag.AdSize.get_current_orientation_anchored_adaptive_banner_ad_size(width)
, to obtain an adaptive AdSize
object for the current orientation.Create a AdView:
+AdView
object with your ad unit ID, the adaptive size obtained in step 1, and the desired position for your ad.Ad Request Creation:
+load_ad()
function on your prepared ad view to load your adaptive anchor banner, just as you would with a standard banner request.Below is a script example that loads and refreshes an adaptive banner: +
In this context, we use functions like AdSize.get_current_orientation_anchored_adaptive_banner_ad_size
to retrieve the size for a banner in an anchored position, aligning with the current interface orientation. To pre-load an anchored banner for a specific orientation, you can make use of the appropriate function, either AdSize.get_portrait_anchored_adaptive_banner_ad_size
or AdSize.get_landscape_anchored_adaptive_banner_ad_size
.
This document is based on:
+ +Note
+Try the newer adaptive banners instead.
+To use Smart Banners, use the AdSize.get_smart_banner_ad_size()
function for the ad size when creating a AdView. For example:
Interstitial ads are expansive, full-screen advertisements that overlay an app's interface and persist until they are closed by the user. They are most effective when strategically placed during natural pauses in the app's execution, such as between levels of a game or immediately after the completion of a task.
+This document is based on:
+ +When developing and testing your Godot apps, it's crucial to use test ads rather than live production ads. Failure to do so can result in the suspension of your AdMob account.
+The most straightforward method to load test ads is by utilizing our dedicated test ad unit ID for Android and iOS interstitial:
+ +This particular ad unit ID has been purposefully configured to deliver test ads for every request. You can safely employ it during your coding, testing, and debugging phases. However, remember to replace this test ad unit ID with your own when you are ready to publish your app.
+For a more comprehensive understanding of how the Mobile Ads SDK's test ads function, please refer to our documentation on Test Ads.
+The code sample below demonstrates how to utilize the Interstitial. In this example, you'll create an instance of an Interstitial, load an ad into it using an AdRequest, and enhance functionality by handling various life cycle events.
+To load an interstitial ad, utilize the InterstitialAdLoader
class. Pass in an InterstitialAdLoadCallback
to receive the loaded ad or any potential errors. It's worth noting that, similar to other format load callbacks, the InterstitialAdLoadCallback
leverages LoadAdError
to provide comprehensive error details.
The FullScreenContentCallback
manages events associated with the display of your InterstitialAd
. Before presenting the InterstitialAd
, ensure that you configure the callback:
Interstitial ads are ideally displayed during organic breaks in the app's progression. Examples include between game levels or after a user accomplishes a task. To present an interstitial ad, employ the show()
function.
Upon completion of an InterstitialAd
, it's important to invoke the destroy()
function before releasing your reference to it:
This action signals to the plugin that the object is no longer in use and that the memory it occupies can be reclaimed. Neglecting to call this method can lead to memory leaks.
+Consider Relevance:
+Pause App Activity:
+Optimize Loading Time:
+InterstitialAdLoader.new().load()
before invoking show()
. This ensures that your app has a fully loaded interstitial ad ready when it's time to display one.Avoid Overloading with Ads:
+Remember that implementing interstitial ads should enhance, not detract from, the user experience in your app.
+Rewarded video ads are immersive, full-screen video advertisements that provide users with the choice to watch them entirely. In return for their time and attention, users receive in-app rewards or benefits.
+This document is based on:
+ +When developing and testing your Godot apps, it's crucial to use test ads rather than live production ads. Failure to do so can result in the suspension of your AdMob account.
+The most straightforward method to load test ads is by utilizing our dedicated test ad unit ID for Android and iOS rewarded:
+ +This particular ad unit ID has been purposefully configured to deliver test ads for every request. You can safely employ it during your coding, testing, and debugging phases. However, remember to replace this test ad unit ID with your own when you are ready to publish your app.
+For a more comprehensive understanding of how the Mobile Ads SDK's test ads function, please refer to our documentation on Test Ads.
+The code sample below demonstrates how to utilize the Rewarded. In this example, you'll create an instance of an Rewarded, load an ad into it using an AdRequest, and enhance functionality by handling various life cycle events.
+To load an rewarded ad, utilize the RewardedAdLoader
class. Pass in an RewardedAdLoadCallback
to receive the loaded ad or any potential errors. It's worth noting that, similar to other format load callbacks, the RewardedAdLoadCallback
leverages LoadAdError
to provide comprehensive error details.
For apps that necessitate additional data in server-side verification Android/iOS callbacks, the custom data feature of rewarded ads can be employed. Any string value assigned to a rewarded ad object is transmitted to the custom_data
query parameter of the SSV callback. If no custom data is set, the custom_data
query parameter will be absent in the SSV callback.
The following code snippet illustrates how to establish custom data on a rewarded ad object before soliciting an ad:
+Note
+The custom reward string is percent escaped and might require decoding when parsed from the SSV callback.
+The FullScreenContentCallback
manages events associated with the display of your RewardedAd
. Before presenting the RewardedAd
, ensure that you configure the callback:
When presenting a rewarded ad, you'll employ an OnUserEarnedRewardListener
object to manage reward-related events.
Upon completion of an RewardedAd
, it's important to invoke the destroy()
function before releasing your reference to it:
This action signals to the plugin that the object is no longer in use and that the memory it occupies can be reclaimed. Neglecting to call this method can lead to memory leaks.
+A Rewarded Interstitial is a specific form of incentivized ad format that allows you to provide rewards in exchange for ads that appear automatically during natural app transitions. Unlike regular rewarded ads, users are not obligated to actively opt in to view a Rewarded Interstitial; they are seamlessly integrated into the app experience.
+This document is based on:
+ +When developing and testing your Godot apps, it's crucial to use test ads rather than live production ads. Failure to do so can result in the suspension of your AdMob account.
+The most straightforward method to load test ads is by utilizing our dedicated test ad unit ID for Android and iOS rewarded interstitial:
+ +This particular ad unit ID has been purposefully configured to deliver test ads for every request. You can safely employ it during your coding, testing, and debugging phases. However, remember to replace this test ad unit ID with your own when you are ready to publish your app.
+For a more comprehensive understanding of how the Mobile Ads SDK's test ads function, please refer to our documentation on Test Ads.
+The code sample below demonstrates how to utilize the Rewarded interstitial. In this example, you'll create an instance of an Rewarded interstitial, load an ad into it using an AdRequest, and enhance functionality by handling various life cycle events.
+To load an rewarded interstitial ad, utilize the RewardedInterstitialAdLoader
class. Pass in an RewardedInterstitialAdLoadCallback
to receive the loaded ad or any potential errors. It's worth noting that, similar to other format load callbacks, the RewardedInterstitialAdLoadCallback
leverages LoadAdError
to provide comprehensive error details.
For apps that necessitate additional data in server-side verification Android/iOS callbacks, the custom data feature of rewarded ads can be employed. Any string value assigned to a rewarded ad object is transmitted to the custom_data
query parameter of the SSV callback. If no custom data is set, the custom_data
query parameter will be absent in the SSV callback.
The following code snippet illustrates how to establish custom data on a rewarded interstitial ad object before soliciting an ad:
+Note
+The custom reward string is percent escaped and might require decoding when parsed from the SSV callback.
+The FullScreenContentCallback
manages events associated with the display of your RewardedInterstitialAd
. Before presenting the RewardedInterstitialAd
, ensure that you configure the callback:
When presenting a rewarded interstitial ad, you'll employ an OnUserEarnedRewardListener
object to manage reward-related events.
Upon completion of an RewardedInterstitialAd
, it's important to invoke the destroy()
function before releasing your reference to it:
This action signals to the plugin that the object is no longer in use and that the memory it occupies can be reclaimed. Neglecting to call this method can lead to memory leaks.
+This guide explains how to provide targeting information to an ad request.
+This document is based on:
+ +RequestConfiguration
is an entity used to gather targeting details that can be globally applied through a static method within MobileAds
. And is applied by MobileAds.set_request_configuration(request_configuration)
To comply with Children's Online Privacy Protection Act (COPPA), you can set the "tag for child-directed treatment" option. This signifies that you want your content to be treated as child-directed for COPPA purposes. It's important to ensure that you have the authority to make this decision on behalf of the app owner. Please be aware that misusing this setting can lead to the termination of your Google account.
+As an app developer, you can indicate whether your content is child-directed when making ad requests. When you specify that your content is child-directed, Google will take steps to disable Interest-Based Advertising (IBA) and remarketing ads for that particular ad request.
+To implement this setting, you can use RequestConfiguration.new().tag_for_child_directed_treatment = int
with the following options:
Use tag_for_child_directed_treatment
with RequestConfiguration.TagForChildDirectedTreatment.TRUE
to indicate that your content should be treated as child-directed for COPPA compliance. This will prevent the transmission of the Android advertising identifier (AAID). This will prevent the transmission of the Advertising Identifier, IDFA.
Use tag_for_child_directed_treatment
with RequestConfiguration.TagForChildDirectedTreatment.FALSE
to specify that your content should not be treated as child-directed for COPPA purposes.
Use tag_for_child_directed_treatment
with RequestConfiguration.TagForChildDirectedTreatment.UNSPECIFIED
if you do not want to specify how your content should be treated in ad requests with respect to COPPA.
The following example indicates that you want your content treated as child-directed for purposes of COPPA:
+var request_configuration := RequestConfiguration.new()
+request_configuration.tag_for_child_directed_treatment = RequestConfiguration.TagForChildDirectedTreatment.TRUE
+MobileAds.set_request_configuration(request_configuration)
+
You can configure your ad requests to receive treatment for users in the European Economic Area (EEA) who are below the age of consent. This feature is designed to assist with compliance under the General Data Protection Regulation (GDPR). It's important to note that GDPR may impose additional legal obligations, so it's advisable to consult with legal counsel and review the European Union's guidelines. Google's tools are meant to support compliance but do not replace publishers' legal responsibilities. Learn more about how the GDPR affects publishers.
+When using this feature, an ad request will contain a "Tag For Users under the Age of Consent in Europe" (TFUA) parameter. This parameter deactivates personalized advertising, including remarketing, for all ad requests. It also prevents requests to third-party ad vendors like ad measurement pixels and third-party ad servers.
+Similar to the child-directed settings, you can utilize the property in RequestConfiguration.new()
class to set the TFUA parameter: tag_for_under_age_of_consent = int
. It offers the following options:
Use tag_for_under_age_of_consent
with RequestConfiguration.TagForUnderAgeOfConsent.TRUE
to indicate that you want the ad request to receive treatment for users in the European Economic Area (EEA) under the age of consent. This will also prevent the transmission of the Android advertising identifier (AAID). This will also prevent the transmission of the Advertising Identifier, IDFA.
Use tag_for_under_age_of_consent
with RequestConfiguration.TagForUnderAgeOfConsent.FALSE
to specify that you do not want the ad request to receive treatment for users in the European Economic Area (EEA) under the age of consent.
Use tag_for_under_age_of_consent
with RequestConfiguration.TagForUnderAgeOfConsent.UNSPECIFIED
to indicate that you have not specified whether the ad request should receive treatment for users in the European Economic Area (EEA) under the age of consent.
Here's an example indicating your intention to include TFUA in your ad requests:
+var request_configuration := RequestConfiguration.new()
+request_configuration.tag_for_under_age_of_consent = RequestConfiguration.TagForUnderAgeOfConsent.UNSPECIFIED
+MobileAds.set_request_configuration(request_configuration)
+
The tags to enable the Child-directed setting and tag_for_under_age_of_consent
property should not both simultaneously be set to true
. If they are, the child-directed setting takes precedence.
To ensure compliance with Google Play's Inappropriate Ads Policy, which encompasses associated offers within ads, it's essential that all ads and their associated offers displayed in your app align with your app's content rating. This applies even if the content itself complies with Google Play's policies.
+Tools like the maximum ad content rating provide you with greater control over the content of ads shown to your users. You can set a maximum content rating to ensure adherence to platform policies.
+Apps can specify a maximum ad content rating for their ad requests using the max_ad_content_rating
property. AdMob ads returned with this configuration will have a content rating that matches or falls below the specified level. The available values for this network extra are based on digital content label classifications and must be one of the following strings:
RequestConfiguration.MAX_AD_CONTENT_RATING_G
RequestConfiguration.MAX_AD_CONTENT_RATING_PG
RequestConfiguration.MAX_AD_CONTENT_RATING_T
RequestConfiguration.MAX_AD_CONTENT_RATING_MA
The following code demonstrates how to configure a RequestConfiguration
object to specify that ad content returned should not exceed a digital content label designation of G
:
var request_configuration := RequestConfiguration.new()
+request_configuration.max_ad_content_rating = RequestConfiguration.MAX_AD_CONTENT_RATING_G
+MobileAds.set_request_configuration(request_configuration)
+
Learn more about:
+ + + + + + + + + + + + + + +