Native Ads - Impression Tracking Clarification
366 views
Skip to first unread message
K Shota
Sep 7, 2023, 11:05:30 PM9/7/23
to Google Mobile Ads SDK Developers
Dear AdMob Development Team,
I hope this message finds you well. I am currently implementing AdMob native ads in a mobile application, and I recently came across information related to impression tracking in AdMob's documentation. To ensure accurate impression tracking, I would like to seek clarification on this matter.
The documentation states the following:
"The GADNativeAdView class provides IBOutlets for registering views used for each individual asset and a method for registering the GADNativeAd object itself. Registering views in this manner allows the SDK to automatically handle tasks such as:
- Recording clicks.
- Recording impressions (when the first pixel is visible on the screen).
- Displaying the AdChoices overlay."
Based on this information, I would like to confirm that by registering the GADNativeAd object and associated views, the SDK automatically processes impression tracking when the first pixel of the ad is visible on the screen.
In our app, we implement native ads in the following scenario:
1. At the app's startup, we load and cache native ads. This process runs periodically and pauses when the app is in the background. It resumes caching when the app returns to the foreground.
2. When a user displays a screen containing native ads, we retrieve the ads from the cache and display them on the screen.
3. The screen objects persist until the app is closed.
Specific questions:
1. Does impression tracking automatically occur as described in the documentation when the GADNativeAd object and views are registered?
2. In the implementation scenario mentioned above, will impressions be counted correctly?
3. If a user is viewing a screen that does not contain native ads, does this affect the impression count?
4. Are there additional best practices or considerations to ensure accurate impression tracking for AdMob native ads?
5. Are there any specific scenarios or edge cases to be aware of regarding impression tracking?
We kindly request your guidance and clarification on this matter. We aim to implement AdMob native ads accurately and optimize ad performance by ensuring precise impression tracking.
We appreciate your time and cooperation.
Sincerely,
I hope this message finds you well. I am currently implementing AdMob native ads in a mobile application, and I recently came across information related to impression tracking in AdMob's documentation. To ensure accurate impression tracking, I would like to seek clarification on this matter.
The documentation states the following:
"The GADNativeAdView class provides IBOutlets for registering views used for each individual asset and a method for registering the GADNativeAd object itself. Registering views in this manner allows the SDK to automatically handle tasks such as:
- Recording clicks.
- Recording impressions (when the first pixel is visible on the screen).
- Displaying the AdChoices overlay."
Based on this information, I would like to confirm that by registering the GADNativeAd object and associated views, the SDK automatically processes impression tracking when the first pixel of the ad is visible on the screen.
In our app, we implement native ads in the following scenario:
1. At the app's startup, we load and cache native ads. This process runs periodically and pauses when the app is in the background. It resumes caching when the app returns to the foreground.
2. When a user displays a screen containing native ads, we retrieve the ads from the cache and display them on the screen.
3. The screen objects persist until the app is closed.
Specific questions:
1. Does impression tracking automatically occur as described in the documentation when the GADNativeAd object and views are registered?
2. In the implementation scenario mentioned above, will impressions be counted correctly?
3. If a user is viewing a screen that does not contain native ads, does this affect the impression count?
4. Are there additional best practices or considerations to ensure accurate impression tracking for AdMob native ads?
5. Are there any specific scenarios or edge cases to be aware of regarding impression tracking?
We kindly request your guidance and clarification on this matter. We aim to implement AdMob native ads accurately and optimize ad performance by ensuring precise impression tracking.
We appreciate your time and cooperation.
Sincerely,
K Shota
Mobile Ads SDK Forum Advisor
Sep 8, 2023, 5:57:06 AM9/8/23
to kin...@quadsystem.co.jp, google-adm...@googlegroups.com
Hi,
Thank you for reaching out to the Mobile Ads SDK Support Team. Kindly see my insights below regarding your concerns:
1. Does impression tracking automatically occur as described in the documentation when the GADNativeAd object and views are registered?
- Yes.
2. In the implementation scenario mentioned above, will impressions be counted correctly?
- Yes.
3. If a user is viewing a screen that does not contain native ads, does this affect the impression count?
- No, an impression is only counted when one or more pixels of the ad creative is visible on a device's screen.
4. Are there additional best practices or considerations to ensure accurate impression tracking for AdMob native ads?
- As long as you've followed our detailed guide (which you can find here: https://developers.google.com/admob/android/native/start), then we recommend no further action on your end and your implementation should be fine.
5. Are there any specific scenarios or edge cases to be aware of regarding impression tracking?
- I'm afraid we didn't receive any issues from other publishers regarding to the edge case. As mentioned, as long as our publishers followed our developer guide, then there should be no issues.
This message is in relation to case "ref:_00D1U1174p._5004Q2ojPd4:ref"
Thanks,
Thanks,
 |
Mobile Ads SDK Team |
K Shota
Sep 8, 2023, 10:30:24 AM9/8/23
to Google Mobile Ads SDK Developers
Dear AdMob Development Team,
Thank you very much for your prompt response to our previous inquiry. The insights regarding AdMob Native Ad impression tracking were highly valuable. Based on the previous response, we have some additional questions and considerations.
1. **Observation and Implementation:** Our app has implemented AdMob Native Ads and has been released to users. We are currently closely monitoring its performance.
2. **Impression Tracking:** Impression tracking appears to be functioning correctly, and impressions are being accurately counted, as indicated in the previous response.
3. **Low Show Rate:** We are concerned about the consistently low show rate, which remains below 10%. Considering that users may frequently view screens without Native Ads, as mentioned in the previous response, this might be a contributing factor.
4. **Improving Show Rate:** The goal of improving the show rate is to make sure that more users see screens containing ads through proactive efforts. However, we believe that an effective means to achieve this goal immediately is by reducing the number of ad requests. We want to reduce unnecessary ad requests and approach optimization of the entire system. To achieve this, we need a mechanism for fetching ads appropriately from the cache and determining whether to display them.
5. **Ad Display Mechanism:** If impressions are invalid and registering views would be futile, we are considering suppressing view registration in such cases. We would like to confirm whether AdMob provides a mechanism to detect such situations.
6. **Custom Implementation:** If AdMob does not provide such a mechanism, would it be appropriate for us to implement a custom mechanism within our app? This might involve monitoring the visibility of screens containing Native Ads and adjusting the caching strategy, among other things.
We would greatly appreciate your guidance on these additional questions. Our goal is to optimize the performance of AdMob Native Ads while providing a smooth and engaging user experience, ultimately maximizing revenue through AdMob Native Ads.
Once again, we express our gratitude for your cooperation and support.
Sincerely,
K Shota
Thank you very much for your prompt response to our previous inquiry. The insights regarding AdMob Native Ad impression tracking were highly valuable. Based on the previous response, we have some additional questions and considerations.
1. **Observation and Implementation:** Our app has implemented AdMob Native Ads and has been released to users. We are currently closely monitoring its performance.
2. **Impression Tracking:** Impression tracking appears to be functioning correctly, and impressions are being accurately counted, as indicated in the previous response.
3. **Low Show Rate:** We are concerned about the consistently low show rate, which remains below 10%. Considering that users may frequently view screens without Native Ads, as mentioned in the previous response, this might be a contributing factor.
4. **Improving Show Rate:** The goal of improving the show rate is to make sure that more users see screens containing ads through proactive efforts. However, we believe that an effective means to achieve this goal immediately is by reducing the number of ad requests. We want to reduce unnecessary ad requests and approach optimization of the entire system. To achieve this, we need a mechanism for fetching ads appropriately from the cache and determining whether to display them.
5. **Ad Display Mechanism:** If impressions are invalid and registering views would be futile, we are considering suppressing view registration in such cases. We would like to confirm whether AdMob provides a mechanism to detect such situations.
6. **Custom Implementation:** If AdMob does not provide such a mechanism, would it be appropriate for us to implement a custom mechanism within our app? This might involve monitoring the visibility of screens containing Native Ads and adjusting the caching strategy, among other things.
We would greatly appreciate your guidance on these additional questions. Our goal is to optimize the performance of AdMob Native Ads while providing a smooth and engaging user experience, ultimately maximizing revenue through AdMob Native Ads.
Once again, we express our gratitude for your cooperation and support.
Sincerely,
K Shota
2023年9月8日金曜日 18:57:06 UTC+9 Mobile Ads SDK Forum Advisor:
Mobile Ads SDK Forum Advisor
Sep 8, 2023, 4:07:35 PM9/8/23
to kin...@quadsystem.co.jp, google-adm...@googlegroups.com
Hi,
Thank you for your response.
With regard to the show rate, you may check this article (https://support.google.com/admob/answer/3436475?hl=en&sjid=4502838654567068863-AP) for more information about it. Then, for the native ads custom implementation, you may try to check this documentation guide (https://developers.google.com/ad-manager/mobile-ads-sdk/android/custom-native-omid) available for Ad Manager SDK. Let us know if you have any other question.
K Shota
Sep 13, 2023, 2:58:48 AM9/13/23
to Google Mobile Ads SDK Developers
Dear AdMob Development Team,
I would like to express my sincere appreciation for your previous response and the resources provided. The information has proven to be extremely valuable in our efforts to enhance the performance of AdMob Native Ads.
Here is a summary of our follow-up actions and inquiries:
- **Gratitude for Provided Information:** Firstly, I would like to extend my heartfelt gratitude for the information and resources you shared. These have greatly assisted us in our evaluation process.
- **Show Rate:** To address the issue of low show rates, we have decided to take proactive measures. We firmly believe this will not only enhance the user experience but also maximize revenue from AdMob Native Ads.
- **Custom Implementation:** As part of our strategy to optimize ad performance, we have chosen to implement custom mechanisms within our app. This custom implementation involves monitoring the visibility of screens containing native ads and adjusting caching strategies accordingly.
Furthermore, I have specific questions regarding the caching process:
- **Clarification of the Caching Process:** Currently, we cache native ads as follows: We request ads using GADRequest, then cache them until the `func adLoader(_ adLoader: GADAdLoader, didReceive nativeAd: GADNativeAd)` method receives the ad, and until `func adLoaderDidFinishLoading(_ adLoader: GADAdLoader)` is triggered.
- **Challenges with Multiple Ad Units:** We are facing challenges when dealing with multiple ad units in our testing environment. The caching process does not distinguish between them, making the management of ad units difficult.
- **Request for Configuration of Test Ads:** To support our efforts in the testing environment, we kindly request an increase in the number of demo ad units available for each ad format in test ads.
Additionally, we would greatly appreciate your insights on alternative approaches to the caching process. If there are methods different from what we are currently employing, we would be eager to learn from your expertise.
We deeply appreciate your ongoing support and guidance as we continue to work towards optimizing AdMob Native Ads. Your expertise is instrumental to our success, and we eagerly anticipate your valuable insights on these matters.
Once again, we express our gratitude for your cooperation, and we eagerly await your response.
Best regards,
K Shota
I would like to express my sincere appreciation for your previous response and the resources provided. The information has proven to be extremely valuable in our efforts to enhance the performance of AdMob Native Ads.
Here is a summary of our follow-up actions and inquiries:
- **Gratitude for Provided Information:** Firstly, I would like to extend my heartfelt gratitude for the information and resources you shared. These have greatly assisted us in our evaluation process.
- **Show Rate:** To address the issue of low show rates, we have decided to take proactive measures. We firmly believe this will not only enhance the user experience but also maximize revenue from AdMob Native Ads.
- **Custom Implementation:** As part of our strategy to optimize ad performance, we have chosen to implement custom mechanisms within our app. This custom implementation involves monitoring the visibility of screens containing native ads and adjusting caching strategies accordingly.
Furthermore, I have specific questions regarding the caching process:
- **Clarification of the Caching Process:** Currently, we cache native ads as follows: We request ads using GADRequest, then cache them until the `func adLoader(_ adLoader: GADAdLoader, didReceive nativeAd: GADNativeAd)` method receives the ad, and until `func adLoaderDidFinishLoading(_ adLoader: GADAdLoader)` is triggered.
- **Challenges with Multiple Ad Units:** We are facing challenges when dealing with multiple ad units in our testing environment. The caching process does not distinguish between them, making the management of ad units difficult.
- **Request for Configuration of Test Ads:** To support our efforts in the testing environment, we kindly request an increase in the number of demo ad units available for each ad format in test ads.
Additionally, we would greatly appreciate your insights on alternative approaches to the caching process. If there are methods different from what we are currently employing, we would be eager to learn from your expertise.
We deeply appreciate your ongoing support and guidance as we continue to work towards optimizing AdMob Native Ads. Your expertise is instrumental to our success, and we eagerly anticipate your valuable insights on these matters.
Once again, we express our gratitude for your cooperation, and we eagerly await your response.
Best regards,
K Shota
2023年9月9日土曜日 5:07:35 UTC+9 Mobile Ads SDK Forum Advisor:
Mobile Ads SDK Forum Advisor
Sep 13, 2023, 6:58:19 AM9/13/23
to kin...@quadsystem.co.jp, google-adm...@googlegroups.com
Hi K Shota,
Let me do my best to answer your inquiries. Please see our responses below.
Let me do my best to answer your inquiries. Please see our responses below.
- **Clarification of the Caching Process:** Currently, we cache native ads as follows: We request ads using GADRequest, then cache them until the `func adLoader(_ adLoader: GADAdLoader, didReceive nativeAd: GADNativeAd)` method receives the ad, and until `func adLoaderDidFinishLoading(_ adLoader: GADAdLoader)` is triggered.
- We can confirm that this approach is fine
- **Challenges with Multiple Ad Units:** We are facing challenges when dealing with multiple ad units in our testing environment. The caching process does not distinguish between them, making the management of ad units difficult.
- For this use case, you can have your app to preload/cache the natives ands and keep them in a list. However, we would recommend keeping a reference to the ad that's showing to ensure you receive important event or callback
- **Request for Configuration of Test Ads:** To support our efforts in the testing environment, we kindly request an increase in the number of demo ad units available for each ad format in test ads.
- Our demo ad unit is created for the purpose of testing only and for publishers want to experience ads to their app, so it is indeed that the only available ad unit for a specific ad format is one. What I can do at this point is to submit your request as a feature request to the team. Before I can proceed, could you kindly share your business use case (or benefit) to the said request?
K Shota
Sep 13, 2023, 8:24:38 PM9/13/23
to Google Mobile Ads SDK Developers
Dear AdMob Development Team,
I would like to express my sincere appreciation for your previous response and the valuable information provided. Here is a detailed explanation of our understanding and requests:
1. **Regarding the Cache Process**: First and foremost, we understand that there are no issues with the cache process, and we are reassured by this.
2. **Maintaining References to Displayed Ads**: We also comprehend that maintaining references to displayed ads can resolve the issue effectively.
3. **Concerns in the Testing Environment**: However, we are keen to avoid implementing a different approach in our testing environment. This is primarily because there are no issues in the actual environment, and we wish to conduct smooth testing in the test environment.
Our use case is straightforward. We have two screens that utilize native ads, with separate ad units created for each screen. However, as an ongoing challenge, we cannot convert AdUnitIDs into ad objects, which means we can only bind one ad unit, resulting in ads being displayed on only one screen.
A crucial point to note is that we have interactions triggered by ad clicks, assuming ads are displayed on both screens. Unfortunately, testing this behavior is not feasible in our testing environment.
To address this issue, we have a potential solution in mind. Specifically, if there were two demo ad unit IDs available for the ad format within demo ad units, it would allow us to confirm the functionality of our interaction logic. This additional flexibility in the demo ad units would greatly assist us in testing and validating our setup.
We look forward to your continued support and cooperation as we strive to optimize AdMob Native Ads. Your expertise is vital to our success, and we appreciate your insights on these matters.
Once again, we express our gratitude for your cooperation, and we eagerly await your response.
Best regards,
K Shota
I would like to express my sincere appreciation for your previous response and the valuable information provided. Here is a detailed explanation of our understanding and requests:
1. **Regarding the Cache Process**: First and foremost, we understand that there are no issues with the cache process, and we are reassured by this.
2. **Maintaining References to Displayed Ads**: We also comprehend that maintaining references to displayed ads can resolve the issue effectively.
3. **Concerns in the Testing Environment**: However, we are keen to avoid implementing a different approach in our testing environment. This is primarily because there are no issues in the actual environment, and we wish to conduct smooth testing in the test environment.
Our use case is straightforward. We have two screens that utilize native ads, with separate ad units created for each screen. However, as an ongoing challenge, we cannot convert AdUnitIDs into ad objects, which means we can only bind one ad unit, resulting in ads being displayed on only one screen.
A crucial point to note is that we have interactions triggered by ad clicks, assuming ads are displayed on both screens. Unfortunately, testing this behavior is not feasible in our testing environment.
To address this issue, we have a potential solution in mind. Specifically, if there were two demo ad unit IDs available for the ad format within demo ad units, it would allow us to confirm the functionality of our interaction logic. This additional flexibility in the demo ad units would greatly assist us in testing and validating our setup.
We look forward to your continued support and cooperation as we strive to optimize AdMob Native Ads. Your expertise is vital to our success, and we appreciate your insights on these matters.
Once again, we express our gratitude for your cooperation, and we eagerly await your response.
Best regards,
K Shota
2023年9月13日水曜日 19:58:19 UTC+9 Mobile Ads SDK Forum Advisor:
Mobile Ads SDK Forum Advisor
Sep 14, 2023, 5:18:01 AM9/14/23
to kin...@quadsystem.co.jp, google-adm...@googlegroups.com
Hi K Shota,
Thank you for responding back with the detailed context of your use case. We now fully understand what you want to achieve here.
For you use case, you may opt-in to create a live ad units ID instead for testing, then you will need to enabled test device for testing. This is to avoid your account being flag for invalid activity. More information and guide can be found here: https://developers.google.com/admob/android/test-ads#enable_test_devices.
Thank you for responding back with the detailed context of your use case. We now fully understand what you want to achieve here.
For you use case, you may opt-in to create a live ad units ID instead for testing, then you will need to enabled test device for testing. This is to avoid your account being flag for invalid activity. More information and guide can be found here: https://developers.google.com/admob/android/test-ads#enable_test_devices.
K Shota
Sep 21, 2023, 8:26:01 PM9/21/23
to Google Mobile Ads SDK Developers
Hello AdMob Development Team,
We appreciate your swift response and the guidance you have provided. Thank you for assisting us in addressing our concerns.
Below are specific points related to our testing setup:
1. **Test Device Registration:** Our team has already registered test devices as test devices, and we have confirmed that test ads are active on these devices.
2. **Confirmation of Test Ad Functionality:** We have verified that test ads are functioning correctly on our registered test devices.
3. **Avoidance of Live Ad Units:** It is worth noting that our team prefers not to use live ad units during development and testing.
4. **Reason for Avoidance:** The reason behind this preference is to reduce the risk of unintended clicks or interactions with live ads during the development phase, which could potentially lead to ad penalties or disruptions in ad delivery.
5. **Concern About Mediation Adapters:** We would like to emphasize our concerns regarding mediation ad network adapters. Specifically, the documentation advises caution: "If it's unclear whether a mediation ad network adapter supports test ads, it's safest not to click on ads from that network during development." This caution is rooted in our desire to prevent any unintentional interactions that might occur due to human error.
6. **Inclusion of Banner Ads:** Our application includes banner ads, and these ad units are registered within mediation group.
7. **Request for Demo Ad Units:** Based on these considerations, we would like to use demo ad units for testing. This would allow us to conduct testing smoothly while avoiding potential risks associated with live ad units.
We appreciate your understanding of our testing approach and any further guidance or support you can provide to help us achieve our testing goals while maintaining the integrity of our AdMob account.
Once again, thank you for your assistance.
Best regards,
K Shota
We appreciate your swift response and the guidance you have provided. Thank you for assisting us in addressing our concerns.
Below are specific points related to our testing setup:
1. **Test Device Registration:** Our team has already registered test devices as test devices, and we have confirmed that test ads are active on these devices.
2. **Confirmation of Test Ad Functionality:** We have verified that test ads are functioning correctly on our registered test devices.
3. **Avoidance of Live Ad Units:** It is worth noting that our team prefers not to use live ad units during development and testing.
4. **Reason for Avoidance:** The reason behind this preference is to reduce the risk of unintended clicks or interactions with live ads during the development phase, which could potentially lead to ad penalties or disruptions in ad delivery.
5. **Concern About Mediation Adapters:** We would like to emphasize our concerns regarding mediation ad network adapters. Specifically, the documentation advises caution: "If it's unclear whether a mediation ad network adapter supports test ads, it's safest not to click on ads from that network during development." This caution is rooted in our desire to prevent any unintentional interactions that might occur due to human error.
6. **Inclusion of Banner Ads:** Our application includes banner ads, and these ad units are registered within mediation group.
7. **Request for Demo Ad Units:** Based on these considerations, we would like to use demo ad units for testing. This would allow us to conduct testing smoothly while avoiding potential risks associated with live ad units.
We appreciate your understanding of our testing approach and any further guidance or support you can provide to help us achieve our testing goals while maintaining the integrity of our AdMob account.
Once again, thank you for your assistance.
Best regards,
K Shota
2023年9月14日木曜日 18:18:01 UTC+9 Mobile Ads SDK Forum Advisor:
Mobile Ads SDK Forum Advisor
Sep 26, 2023, 2:09:26 AM9/26/23
to kin...@quadsystem.co.jp, google-adm...@googlegroups.com
Hi Shota
Thank you for contacting the Mobile Ads SDK Support team.
The quickest way to enable testing is to use Google-provided demo ad units. These ad units are not associated with your Ad Manager account, so there's no risk of your account generating invalid traffic when using these ad units.
Ads with this Test mode label are safe to click. Requests, impressions, and clicks on ads in test mode will not show up in your account's reports.
Mediated ads do not render a Test mode label. You are responsible for ensuring that test mode is enabled for each of your mediation networks so that these networks don't flag your account for invalid activity. See each network's respective mediation guide for more information.
Please refer to this document for testing with mediation
K Shota
Nov 30, 2023, 1:30:02 AM11/30/23
to Google Mobile Ads SDK Developers
Hello AdMob Development Team,
Thank you so much for your prompt and helpful response! I appreciate the clear instructions and guidance provided regarding testing with mediation using Google-provided demo ad units. It's reassuring to know that using these ad units won't impact our account with invalid traffic.
I will make sure to follow the recommendations and refer to the documentation for testing with mediation as suggested. If any further questions arise, I'll be sure to reach out.
Once again, thank you for your excellent support!
Best regards,
K Shota
Thank you so much for your prompt and helpful response! I appreciate the clear instructions and guidance provided regarding testing with mediation using Google-provided demo ad units. It's reassuring to know that using these ad units won't impact our account with invalid traffic.
I will make sure to follow the recommendations and refer to the documentation for testing with mediation as suggested. If any further questions arise, I'll be sure to reach out.
Once again, thank you for your excellent support!
Best regards,
K Shota
2023年9月26日火曜日 15:09:26 UTC+9 Mobile Ads SDK Forum Advisor:
Reply all
Reply to author
Forward
0 new messages