Рекомендации по публикации кластеров в Engage SDK

В этом руководстве приведены рекомендации по публикации кластеров, которые разработчики могут использовать при интеграции с Engage SDK.

Кластеры рекомендаций

Название кластера

Рекомендуем указывать уникальные и релевантные названия, которые дают пользователям представление о контенте в кластере.

Вот несколько примеров хороших названий кластеров, основанных на контенте:

  • Кластеры, связанные с покупками
    • Lightning Deals
    • Еженедельные покупки
    • Покупка Pixel Buds
    • Женские резиновые сапоги
  • Кластеры книг о здоровье
    • Для души и тела
    • Рекомендации для вас в категории "Здоровье"
    • Бестселлеры в категории "Фитнес"

Кластеризация контента

При публикации кластеров рекомендаций разработчики должны учитывать, вошел ли пользователь в приложение.

Если пользователь вошел в аккаунт

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

  • Персональные рекомендации можно публиковать.
    • Вот несколько примеров персональных рекомендаций:
      • Лучшие рекомендации на основе истории просмотра пользователя.
      • Книги, похожие на те, которые пользователь уже читал.
      • Треки любимых исполнителей пользователя.
  • Можно публиковать библиотеки контента, созданного пользователями.
    • Вот несколько примеров библиотек пользовательского контента:
      • Список просмотра пользователя из приложения разработчика.
      • Список любимых исполнителей пользователя, составленный им самим в приложении разработчика.
Тип рекомендации Стратегия обновления контента Рекомендации по актуальности контента
Персональные рекомендации

Lenient

Рекомендуем обновлять рекомендации раз в день, чтобы пользователи ежедневно видели новые.

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

Строгое значение

Рекомендуем обновлять библиотеку контента, когда пользователи выходят из приложения разработчика.

Важно, чтобы этот контент был синхронизирован с данными, которые показываются на платформах Google. Это связано с тем, что в отличие от персональных рекомендаций, пользователь ожидает точный набор контента. Значительная задержка в публикации может запутать пользователей. Поэтому стратегия обновления контента должна быть строгой.

Если пользователь не вошел в аккаунт

Если пользователь не вошел в приложение разработчика, мы все равно рекомендуем публиковать кластеры, чтобы побудить его перейти в приложение с платформы Google.

  • Неперсонализированные кластеры рекомендаций должны быть опубликованы.
    • Вот несколько примеров неперсонализированных рекомендаций:
      • Топ-10 книг, прочитанных в этом году.
      • Новые фильмы.
      • Популярные подкасты.
  • Опубликуйте карточку входа.
    • Чтобы побудить пользователей войти в приложение, разработчики могут опубликовать карточку входа вместе с кластером неперсонализированных рекомендаций. Подробнее о том, как опубликовать карточку входа, рассказывается в разделе ниже.
Тип рекомендации Стратегия обновления контента Рекомендации по актуальности контента
Неперсонализированные рекомендации

Lenient

Рекомендуем обновлять рекомендации раз в день.

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

Строгое значение

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

После входа пользователя в систему разработчики должны удалить карту, вызвав API deleteUserManagementCluster().

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

Кластеры продолжения

При публикации кластеров продолжения действий разработчики должны учитывать, вошел ли пользователь в аккаунт в приложении.

Если пользователь вошел в аккаунт

  • Кластеры продолжения действий, созданные пользователями, должны быть опубликованы.
    • Вот несколько примеров кластеров продолжения, созданных пользователями:
      • Продолжить просмотр с того места, где пользователь остановился.
      • Продолжить чтение с того места, где пользователь остановился.
Тип продолжения Стратегия обновления контента Рекомендации по актуальности контента
Блоки продолжения действий, созданные пользователями

Строгое значение

Рекомендуем обновлять библиотеку контента, когда пользователи выходят из приложения разработчика.

Важно, чтобы этот контент был синхронизирован с данными, которые показываются на платформах Google. Это связано с тем, что в отличие от персональных рекомендаций, пользователь ожидает точный набор контента. Значительная задержка в публикации может запутать пользователей. Поэтому стратегия обновления контента должна быть строгой.

Если пользователь не вошел в аккаунт

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

Кластер управления пользователями

Основная цель кластера управления пользователями – побудить пользователей выполнить определенные действия в приложении поставщика. Действие входа направляет пользователей на страницу входа в приложение, чтобы приложение могло публиковать контент (или предоставлять более персонализированный контент).

Карточка входа

Атрибут Требования Описание
URI действия Обязательно Ссылка на контент для действия (например, переход на страницу входа в приложение)
Изображение Необязательно. Если не указано, необходимо указать название.

Изображение на карточке

Изображения с соотношением сторон 16:9 и разрешением 1264 x 712.

Название Необязательно. Если не указано, необходимо добавить изображение. Название на карточке
Текст действия Необязательно Текст, который будет показываться в призыве к действию (например, "Войти")
Подзаголовок Необязательно Необязательный подзаголовок на карточке

Kotlin

var SIGN_IN_CARD_ENTITY =
      SignInCardEntity.Builder()
          .addPosterImage(
              Image.Builder()
                  .setImageUri(Uri.parse("http://www.x.com/image.png"))
                  .setImageHeightInPixel(500)
                  .setImageWidthInPixel(500)
                  .build())
          .setActionText("Sign In")
          .setActionUri(Uri.parse("http://xx.com/signin"))
          .build()

appEngagePublishClient.publishUserAccountManagementRequest(
            PublishUserAccountManagementRequest.Builder()
                .setSignInCardEntity(SIGN_IN_CARD_ENTITY)
                .build());

Java

SignInCardEntity SIGN_IN_CARD_ENTITY =
      new SignInCardEntity.Builder()
          .addPosterImage(
              new Image.Builder()
                  .setImageUri(Uri.parse("http://www.x.com/image.png"))
                  .setImageHeightInPixel(500)
                  .setImageWidthInPixel(500)
                  .build())
          .setActionText("Sign In")
          .setActionUri(Uri.parse("http://xx.com/signin"))
          .build();

appEngagePublishClient.publishUserAccountManagementRequest(
            new PublishUserAccountManagementRequest.Builder()
                .setSignInCardEntity(SIGN_IN_CARD_ENTITY)
                .build());

После входа пользователя разработчик должен удалить карту, вызвав API deleteUserManagementCluster().

Обновить статус публикации

Если по какой-либо внутренней причине ни один из кластеров не опубликован, мы настоятельно рекомендуем обновить статус публикации с помощью API updatePublishStatus. Это важно по следующим причинам :

  • Указывать статус нужно во всех случаях, даже когда контент опубликован (STATUS == PUBLISHED). Это необходимо для заполнения панелей управления, на которых статус используется для передачи данных о работоспособности и других показателей интеграции.
  • Если контент не опубликован, но статус интеграции не нарушен (STATUS == NOT_PUBLISHED), Google может не запускать оповещения на панелях мониторинга работоспособности приложения. Она подтверждает, что контент не опубликован по ожидаемой причине с точки зрения поставщика.
  • Это помогает разработчикам понять, когда данные публикуются, а когда нет.
  • Google может использовать коды статуса, чтобы подсказать пользователю, как получить доступ к контенту приложения.

Список допустимых кодов статуса публикации :

// Content is published
AppEngagePublishStatusCode.PUBLISHED,

// Content is not published as user is not signed in
AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN,

// Content is not published as user is not subscribed
AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SUBSCRIPTION,

// Content is not published as user location is ineligible
AppEngagePublishStatusCode.NOT_PUBLISHED_INELIGIBLE_LOCATION,

// Content is not published as there is no eligible content
AppEngagePublishStatusCode.NOT_PUBLISHED_NO_ELIGIBLE_CONTENT,

// Content is not published as the feature is disabled by the client
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_FEATURE_DISABLED_BY_CLIENT,

// Content is not published as the feature due to a client error
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_CLIENT_ERROR,

// Content is not published as the feature due to a service error
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_SERVICE_ERROR,

// Content is not published due to some other reason
// Reach out to engage-developers@ before using this enum.
AppEngagePublishStatusCode.NOT_PUBLISHED_OTHER

Если контент не публикуется из-за того, что пользователь не вошел в аккаунт, рекомендуем опубликовать карточку входа. Если по какой-либо причине поставщики не могут опубликовать карточку входа, мы рекомендуем вызвать API updatePublishStatus с кодом статуса NOT_PUBLISHED_REQUIRES_SIGN_IN.

Kotlin

client.updatePublishStatus(
   PublishStatusRequest.Builder()
     .setStatusCode(AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN)
     .build())

Java

client.updatePublishStatus(
    new PublishStatusRequest.Builder()
        .setStatusCode(AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN)
        .build());

WorkManager для публикации кластеров

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

  • WorkManager выполняет фоновые задачи как можно быстрее.
  • WorkManager запускает работу при различных условиях, даже если пользователь закрыл приложение.

Когда пользователь выходит из приложения, рекомендуем запустить фоновое задание, которое публикует кластеры продолжения вместе с кластерами рекомендаций. Для этого хорошо подходит метод Activity.onStop(), который вызывается, когда пользователь выходит из приложения.

Рекомендуем использовать PeriodicWorkRequest, чтобы запланировать повторяющееся задание, которое будет публиковать кластеры каждые 24 часа. Используя правило CANCEL_AND_REENQUEUE для запуска задачи, разработчики могут гарантировать, что WorkManager будет отправлять обновленные данные каждый раз, когда пользователь выходит из приложения. Это помогает предотвратить показ устаревших данных.

Это показано в следующем примере:

// Define the PublishClusters Worker requiring input
public class PublishClusters extends Worker {

   public PublishClusters(Context appContext, WorkerParameters workerParams) {
       super(appContext, workerParams);
   }

   @NonNull
   @Override
   public Result doWork() {
       // publish clusters
   }
   ...
}

public static void schedulePublishClusters(Context appContext) {
// Create a PeriodicWorkRequest to schedule a recurring job to update
// clusters at a regular interval
PeriodicWorkRequest publishClustersEntertainmentSpace =
// Define the time for the periodic job
       new PeriodicWorkRequest.Builder(PublishClusters.class, 24, TimeUnit.HOURS)
// Set up a tag for the worker.
// Tags are Unique identifier, which can be used to identify that work
// later in order to cancel the work or observe its progress.
          .addTag("Publish Clusters to Entertainment Space")
          .build();

// Trigger Periodic Job, this will ensure that the periodic job is triggered
// only once since we have defined a uniqueWorkName
WorkManager.getInstance(appContext).enqueueUniquePeriodicWork(
// uniqueWorkName
     "publishClustersEntertainmentSpace",
// If a work with the uniqueWorkName is already running, it will cancel the
// existing running jobs and replace it with the new instance.
// ExistingPeriodicWorkPolicy#CANCEL_AND_REENQUEUE
     ExistingPeriodicWorkPolicy.CANCEL_AND_REENQUEUE,
// Recurring Work Request
publishClustersEntertainmentSpace);

}

Обработка намерений широковещательной рассылки

Помимо вызовов API для публикации контента через задание, также необходимо настроить BroadcastReceiver для получения запроса на публикацию контента.

Однако разработчикам не следует полагаться только на широковещательные сообщения, поскольку они запускаются только в определенных сценариях, в основном для повторной активации приложения и принудительной синхронизации данных. Они запускаются, только когда сервис Google Play Объекты определяет, что контент может быть устаревшим. Это позволяет гарантировать, что пользователь увидит актуальный контент, даже если приложение не открывалось в течение долгого времени.

BroadcastReceiver необходимо настроить двумя способами:

  • Динамически зарегистрируйте экземпляр класса BroadcastReceiver с помощью Context.registerReceiver(). Это позволяет приложениям, которые все ещё находятся в памяти, обмениваться данными.
  • Статически объявите реализацию с помощью тега <receiver> в файле AndroidManifest.xml. Это позволяет приложению получать намерения широковещательной рассылки, когда оно не запущено, а также публиковать контент.