Notification

Get personalized optimization tips, understand your account health and set up completion on the improved "My AdMob page".

Reports

Automatically collected events

Automatically collected events are triggered by basic interactions with your app.

If you use the Google Mobile Ads SDK, you don't have to write any extra code to collect these events. Although some of these events may not be available in AdMob reporting, they will be available once you link to Firebase.

To review event reports in Firebase, click the Events tab in the Analytics dashboard of the Firebase console.

Note: Unless stated, the Google Mobile Ads SDK collects these events for Android and iOS apps.

The following table lists the collected events, their triggers and parameters.

Event name Automatically triggered when Parameters
ad_click a user clicks an ad
 
ad_event_id
ad_exposure at least one ad served by the Mobile Ads SDK is on screen firebase_screen, firebase_screen_id, firebase_screen_class, exposure_time
ad_impression a user has an ad impression
 
ad_event_id
ad_query an ad request is made by the Mobile Ads SDK ad_event_id
ad_reward a reward is granted by a rewarded ad served by the Mobile Ads SDK ad_unit_id, reward_type, reward_value
adunit_exposure an ad unit served by the Mobile Ads SDK is on screen firebase_screen, firebase_screen_id, firebase_screen_class, exposure_time
app_clear_data the user resets/clears the app data, removing all settings and sign-in data  
app_exception the app crashes or throws an exception fatal, timestamp
app_remove

an application package is removed or "uninstalled" from an Android device

Note: Android only

This event is different from the Daily uninstalls by device and Daily uninstalls by user metrics, which are both reported by Google Play Developer Console.

The app_remove event counts the removal of application packages, regardless of the installation source, and the count changes depending on the date range you are using for the report.

The Daily uninstalls by device and Daily uninstalls by user metrics count the removal of application packages only when they were installed from Google Play, and are reported on a daily basis.

 
app_update

the app is updated to a new version and launched again 

The previous app version id is passed as a parameter.

This event is conceptually different from the Daily upgrades by device metric, which is reported by Google Play Developer Console.  

An upgrade refers to the updating of the application binary, whereas an app_update event is triggered upon the subsequent launch of the upgraded app.

previous_app_version
first_open

a user launches an app the first time after installing or re-installing it

This event is not triggered when a user downloads the app onto a device, but instead when a user first uses it.

To review raw download numbers, check in Google Play Developer Console or in iTunesConnect.

previous_gmp_app_id, updated_with_analytics, previous_first_open_count, system_app, system_app_update, deferred_analytics_collection, reset_analytics_cause
in_app_purchase

a user completes an in-app purchase, including an initial subscription, that is processed by the App Store on iTunes or by Google Play

The product ID, product name, currency, and quantity are passed as parameters.

For Android in_app_purchase events, link your app to Firebase and connect your app to Play

Note: Paid-app purchase revenue and refunds (iOS only) are not automatically tracked.

product_id, price, value, currency, quantity, subscription, free_trial, introductory_price
os_update

the device operating system is updated to a new version.

The previous operating system version id is passed as a parameter.

previous_os_version
screen_view a screen transition occurs and any of the following criteria are met:
  • The new screen-class name differs from the previous screen-class name
  • The new screen id differs from the previous screen id
firebase_screen, firebase_screen_class, firebase_screen_id, firebase_previous_screen, firebase_previous_class, firebase_previous_id
session_start a user engages the app for more than the minimum session duration after a period of inactivity that exceeds the session timeout duration.  
user_engagement periodically, while the app is in the foreground. engagement_time_msec

Was this helpful?

How can we improve it?
true
Show your support to promote DEI in Gaming by turning intentions into action!

Check out the newly launched Diversity in Gaming website, where you can find video stories and written pledges from global gaming developers. This campaign centers on 3 pillars: diverse teams, diverse games and diverse audiences showing how diversity is not just good for gamers, but for business as well. Show your support by taking the pledge to promote DEI in Gaming and share it on social!

Learn More

Search
Clear search
Close search
Main menu
10449217719248053382
true
Search Help Center
true
true
true
true
true
73175
false
false