Как отправить событие просмотра экрана, чтобы помочь прогнозу Firebase сделать более точный прогноз

Question

У меня есть один Activityс несколькими Fragmentв ViewPager,

В настоящее время это мой способ отправить событие просмотра экрана как в Google Analytics, так и в Firebase.

---

public static void trackView(Activity activity, String view) {
    trackFBView(activity, view);
    trackGAView(view);
}

private static void trackFBView(Activity activity, String view) {
    if (activity == null) {
        return;
    }

    FirebaseAnalytics firebaseAnalytics = getFirebaseAnalytics();
    if (firebaseAnalytics == null) {
        return;
    }

    firebaseAnalytics.setCurrentScreen(activity, view, null);
}

private static void trackGAView(String view) {
    Tracker tracker = Utils.getTracker();
    if (tracker == null) {
        return;
    }
    tracker.setScreenName(view);
    tracker.send(new HitBuilders.ScreenViewBuilder().build());
}

public static FirebaseAnalytics getFirebaseAnalytics() {
    if (false == isGooglePlayServicesAvailable()) {
        return null;
    }

    return FirebaseAnalytics.getInstance(JStockApplication.instance());
}

---

В моем ViewPagerСлушатель, вот как я отправляю событие просмотра экрана.

private ViewPager.OnPageChangeListener getOnPageChangeListener() {
    return new ViewPager.OnPageChangeListener() {

        @Override
        public void onPageSelected(int position) {

            if (position == 0) {
                Utils.trackView(DetailedStockFragmentActivity.this, "InfoFragment");

---

После некоторого тестирования я понимаю, что получаю событие просмотра экрана в GA, но не в Firebase.

Позже я понимаю, firebaseAnalytics.setCurrentScreen фактически не отправляет событие просмотра экрана в Firebase. firebaseAnalytics.setCurrentScreen просто подготовить неявный параметр. Он будет отправлен только на базу, во время следующего события.

В настоящее время в своих фрагментах я не запускал явных событий.

Мне было интересно, чтобы помочь Firebase сделать лучший прогноз (Помогите Firebase идентифицировать пользователя при просмотре того, на каком экране), мне было интересно, должен ли я явным образом отправлять событие "Просмотр экрана" следующим образом?

private static void trackFBView(Activity activity, String view) {
    if (activity == null) {
        return;
    }

    FirebaseAnalytics firebaseAnalytics = getFirebaseAnalytics();
    if (firebaseAnalytics == null) {
        return;
    }

    firebaseAnalytics.setCurrentScreen(activity, view, null);

    // Question: Should I do this to help Firebase makes better prediction?
    firebaseAnalytics.logEvent(view + "_ScreenView", null);
}

Answer 1

Я думаю, что здесь есть несколько недоразумений.

Во-первых, как вы заметили, setCurrentScreen создает параметр, который автоматически присоединяется к будущим событиям. События - это единственные вещи, которые отправляются в Firebase и имеют прикрепленные параметры - параметр может существовать только в отношении события. "Параметры экрана" немного более специфичны, чем обычные параметры, так как они появляются в журналах отчетов о сбоях, и их проще использовать для создания аудиторий. Этот ответ подводит итог тому, что я только что сказал.

Второе недоразумение о том, как работает Firebase Predictions. Прогнозы на сегодняшний день могут действовать только на события. То есть, если вы создадите пользовательский прогноз, он не будет использовать никаких параметров и может только прогнозировать, будет ли пользователь выполнять действие (событие).

В вашем случае мне нужно знать больше о том, что вы пытаетесь сделать. Если вы ищете вовлечение пользователей, это уже связано с прогнозом "оттока". (И нет, регистрация события аналитики не повлияет на прогноз, поскольку он основан на глобальной идее "пользователь использует это приложение".) Теперь, с другой стороны, если вы пытаетесь узнать, действительно ли пользователь использует часть вашего приложения, тогда вы должны создать собственное событие, как select_stock и используйте Прогнозы, чтобы угадать, собирается ли пользователь просматривать акции. Мне нравится думать о прогнозах или A/B-тестировании как об используемых для измерения либо вовлеченности, либо увеличения конкретного выполняемого действия.

Как правило, вы должны перетекать свое приложение действиями пользователя вместо пассивного просмотра. Например, у вас может быть действие, когда пользователь выбирает акцию, добавляет ее в избранное, делится ею, ищет ее и т. Д. Затем в прогнозах или A/B-тестировании вы можете увидеть, как внесенные изменения влияют на определенная часть общего вовлечения пользователя - "Пользователь делает больше или меньше X?"

TL; DR: Нет, регистрация событий не влияет на прогнозирование оттока, поскольку они являются общими: "Предусматривается ли использование этого приложения в ближайшие 7 дней или нет?" Тем не менее, вы можете попытаться выяснить, собирается ли пользователь выполнять более или менее определенное действие, а затем записать событие, которое будет использоваться в прогнозах или A/B-тестировании.

Информация о предопределенных предсказаниях, обзор использования функции предсказаний и подробный пример того, как можно использовать предсказания.

Редактировать, отвечая на комментарий:

Я хотел бы предвосхитить это, сказав, что я не инженер Firebase и сомневаюсь, что гуглеры поделятся с вами своими коммерческими секретами, поэтому я в основном догадываюсь здесь. Я собираюсь использовать пример оформления заказа, так как это самый простой пример, который я мог придумать.

Хорошо, чтобы попытаться понять прогнозы, нам нужно сначала немного понять машинное обучение. Модели ML довольно глупы, если подумать: они просто пытаются сопоставить набор входных данных с некоторыми выходными числами (вероятностями). Так как Predictions не принимает параметры событий, я бы предположил, что Google вводит последовательность аналитических событий, которые произошли во время данной пользовательской сессии. AFAIK, порядок, в котором вводятся входные данные для модели ML, не имеет значения, поэтому порядок, в котором происходят события, не будет учитываться (Google, возможно, нашел способ обойти это, не знаю).

С нашими предположениями о модели ML мы можем вернуться к нашему примеру оформления заказа. По сути, я думаю, что вы на самом деле будете плохо или по крайней мере регистрировать бессмысленные события, просто отслеживая, какие экраны посещает пользователь. Допустим, пользователь проходит через экраны "Корзина", "Введите свой адрес" и "Оформить заказ". В этом случае модель будет обучаться, чтобы увидеть, что эти наборы событий тесно связаны с покупкой.

Вы можете подумать: "Ну, это здорово!" Не так быстро, такой прогноз бесполезен, поскольку на самом деле он ничего не предсказывает. Это просто говорит: "О, смотри, пользователь, который делает это на экране оформления заказа, обычно покупает вещи". Я бы подумал, что в этом случае на экране регистрации событий ваши прогнозы будут хуже: скажем, пользователь заходит на экран оформления заказа, но затем уходит, потому что боится выдать вам свою кредитную карту или что-то в этом роде. Модель подумает: "Они побывали на этом экране, поэтому они все купят", но это неправильно.

Нет, с другой стороны, для меня имеет смысл, что регистрация действий пользователя, как я упоминал ранее, была бы гораздо полезнее. Например, более точное предсказание, которое фактически предсказывало бы материал, можно обучить, используя число item_added_to_card События. Чем больше товаров пользователь добавляет в свою корзину, тем больше он склонен покупать товары.

Опять же, я мало что знаю о вашем приложении, но регистрация событий кликов, чтобы увидеть детальную панель статьи, лайк статьи или обмен ею, кажется, что они могут дать больше информации, чем просто просмотр панели статей. Тем не менее, я думаю, что это зависит от того, какое у вас поведение пользователя. Если большинство ваших пользователей, которые приобрели материал, также проводят много времени на экране статьи, то да, я не понимаю, как это может повредить записи события.

Главное, что я пытаюсь донести, - это то, что я думаю, что прогнозы будут лучше с событиями, которые измеряют вовлеченность пользователей. Так что пассивная аудитория может работать, но что, если некоторым пользователям нравится просто держать этот экран открытым, или, может быть, просмотр статей - это даже ваша вкладка по умолчанию? Тогда это не дает модели никакой новой информации, так как почти все ваши пользователи пройдут через этот экран. Мое эмпирическое правило гласит: "Если пользователь нажимает на него, зарегистрируйте его". Тогда вы наверняка получите массу аналитических событий для модели ML, в которых можно найти шаблоны, например, пользователи, кликающие для просмотра статей, с большей вероятностью будут покупать вещи.

PS: реверс-инжиниринг такой модели сложен, и я могу ошибаться в своих предположениях.