[Question] Firebase or specific Android versions trigger app_clear_data on first_open, disrupting our funnel

[fatihforgemaster]

What is your question?

We observe approximately 50% abandonment at the first_open event.

Through investigation, we found that certain devices (e.g., Samsung S23 Ultra and S24 Ultra on Android 13 and 14) only log first_open and app_clear_data in the initial session, with no further events recorded.

• Local Test Findings: Testing locally on these devices shows that Firebase initializes correctly, and events are sent to the server without any exceptions or errors.
• App Clear Data: We have verified that these devices are not manually triggering app_clear_data

Example User at Firebase User Explorer:

We don’t have specific reproduction steps, but during DebugView, events are being sent correctly, and there is no app_clear_data event.

it might be related with androidManifest file so i will share some of them;
we are using firebase activity:

<application android:theme="@style/UnityThemeSelector" android:icon="@mipmap/app_icon" android:label="@string/app_name" tools:replace="android:allowBackup" android:allowBackup="false" android:isGame="true">
    <activity android:name="com.google.firebase.MessagingUnityPlayerActivity" android:configChanges="fontScale|keyboard|keyboardHidden|locale|mnc|mcc|navigation|orientation|screenLayout|screenSize|smallestScreenSize|uiMode|touchscreen" android:exported="true">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
      <meta-data android:name="unityplayer.UnityActivity" android:value="true" />
    </activity>
    <service android:name="com.google.firebase.messaging.MessageForwardingService" android:permission="android.permission.BIND_JOB_SERVICE" android:exported="true"></service>
</application>

Some Permissions in use:

"android.permission.WRITE_EXTERNAL_STORAGE"
"android.permission.READ_EXTERNAL_STORAGE"

Initialization Code: Firebase initializes upon checking dependencies
After initialization we start sending events

FirebaseApp.CheckAndFixDependenciesAsync().ContinueWith(task =>
{
  var dependencyStatus = task.Result;
  if (dependencyStatus == DependencyStatus.Available)
  {
    IsInitialized = true;
  }
  else
  {
    IsInitialized = false;
  }
}, TaskScheduler.FromCurrentSynchronizationContext());

Firebase Unity SDK Version

12.3.0

Unity editor version

2021.3.44

Installation Method

.unitypackage

Problematic Firebase Component(s)

Analytics

Other Firebase Component(s) in use

Analytics, Crashlytics, Messaging

Additional SDKs you are using

Facebook, GameAnalytics, Appmetrica, Appsflyer, Google play games, Play Plugins

Targeted Platform(s)

Android

Unity editor platform

Windows

Scripting Runtime

IL2CPP

Release Distribution Type

Pre-built SDK from https://firebase.google.com/download/unity

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[argzdev]

Hey @fatihforgemaster, thanks for reaching out. While this does look like there's an odd behavior happening, I don't see anyway for us to investigate this, especially since the issue doesn't seem reproducible. I've tried testing this on Android 14 emulators, but so far, no issues come up.

In the SDK perspective, we are only sending the events for the manual/automatic actions performed by the app. In this case, this Stack Overflow thread explains app_clear_data very well:

app_clear_data and app_remove work only on devices with Google Play Services (most Android devices). The Firebase Service that record the state on disk runs inside Google Play Services so when the app runs there is code in the app that tells the Google Play Services if its shared preference file stored in the app data was deleted. Google Play Services then check if this app has run in the past and if it has run it then assumes the app data was cleared and logs app_clear_data.

Several factors could contribute to this behavior. It's possible that the issue stems from the app being under testing, running in an emulated environment that can clears data after each session, or encountering faulty devices that may trigger unexpected behavior. However, the available information is limited, making it difficult to pinpoint the exact cause.

Based on the current evidence, there's no indication that the SDK is directly responsible. Without a reliable method to identify the root cause, I'm not sure how we can proceed investigating this further.

For now, let's keep this open in case anyone else has an idea about the issue.

[google-oss-bot]

Hey @fatihforgemaster. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!