Lineamientos sobre la publicación de clústeres del SDK de Engage

En esta guía, se incluye un conjunto de lineamientos para la publicación de clústeres que los desarrolladores pueden usar durante la integración al SDK de Engage.

Clústeres de Recommendation

Título del clúster

Recomendamos que proporciones un título de clúster único y relevante que les brinde a los usuarios más indicios sobre el contenido del clúster.

Estos son algunos ejemplos de buenos títulos de clústeres basados en el contenido:

• Clústeres relacionados con compras
  • Ofertas relámpago
  • Compras imperdibles semanales
  • Relacionado con tu compra de Pixel Buds
  • Botas de lluvia para mujer
• Clústeres de libros sobre la salud
  • Salud, cuerpo y mente
  • Recomendaciones para ti en Salud
  • Más vendidos en Entrenamiento

Contenido del clúster

Al momento de publicar clústeres de Recommendation, los desarrolladores deben considerar si el usuario accedió a la aplicación del desarrollador.

Si el usuario accedió

Si el usuario accedió a la app del desarrollador, te recomendamos que publiques clústeres de contenido personalizado o generado por usuarios. Como el contenido personalizado y generado por usuarios resulta más relevante para el usuario, este estará más motivado a visitar la app del desarrollador desde la plataforma de Google.

• Se pueden publicar recomendaciones personalizadas.
  • Estos son algunos ejemplos de recomendaciones personalizadas:
    • Principales recomendaciones según el historial de reproducciones del usuario
    • Libros similares a los que están en el historial de lectura del usuario
    • Canciones interpretadas por los artistas favoritos del usuario
• Bibliotecas de contenido generado por usuarios.
  • Estos son algunos ejemplos de bibliotecas de contenido generado por usuarios:
    • La lista para ver del usuario desde la app del desarrollador
    • Una lista autoinformada de los artistas favoritos del usuario desde la app del desarrollador

Si el usuario no accedió

Si un usuario no accedió a la app del desarrollador, te recomendamos que publiques clústeres, de modo que se anime a los usuarios a visitar la app del desarrollador desde la plataforma de Google.

• Se deben publicar los clústeres de Recommendation no personalizadas.
  • Estos son algunos ejemplos de recomendaciones no personalizadas:
    • Los 10 libros más leídos este año
    • Películas que se estrenaron recientemente
    • Podcasts del momento
• Publicar una tarjeta de acceso
  • Para alentar a los usuarios a que accedan a la app, los desarrolladores pueden elegir publicar una tarjeta de acceso junto con el clúster de recomendaciones no personalizadas. Consulta la siguiente sección para obtener más detalles sobre cómo publicar una tarjeta de acceso.

Clústeres de Continuation

Al momento de publicar clústeres de Continuation, los desarrolladores deben considerar si el usuario accedió a la aplicación del desarrollador.

Si el usuario accedió

• Se deben publicar los clústeres de Continuation generados por el usuario.
  • Estos son algunos ejemplos de clústeres de Continuation generados por el usuario:
    • Continuar mirando desde donde dejó el usuario
    • Continuar leyendo desde donde dejó el usuario

Si el usuario no accedió

Las exploraciones de continuación están destinadas principalmente a los usuarios que accedieron a sus cuentas. Sin embargo, también puedes publicar clústeres de continuación para usuarios que salieron de sus cuentas si tu app admite sesiones de invitado.

Clúster de administración de usuarios

El objetivo principal del clúster de User Management es motivar a los usuarios para que realicen determinadas acciones en la app del proveedor. La acción de acceso dirige a los usuarios a la página de acceso de la app para que esta pueda publicar contenido (o brindar contenido más personalizado).

Tarjeta de acceso

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());

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());

Después de que los usuarios acceden, los desarrolladores deben borrar la tarjeta llamando a la API de deleteUserManagementCluster().

Actualiza el estado de publicación

Si, por algún motivo empresarial interno, no se publica ninguno de los clústeres, te recomendamos que actualices el estado de publicación a través de la API de updatePublishStatus. A continuación, explicamos por qué es importante:

• Proporcionar el estado en todas las situaciones, incluso cuando el contenido está publicado (STATUS == PUBLISHED), es fundamental para propagar los paneles que usan este estado explícito para transmitir el estado y otras métricas de tu integración.
• Si no se publica contenido pero el estado de integración no está roto (STATUS == NOT_PUBLISHED), Google puede evitar activar alertas en los paneles de estado de la app. Confirma que el contenido no se publicó debido a una situación prevista desde el punto de vista del proveedor.
• Ayuda a los desarrolladores a proporcionar estadísticas sobre cuándo se publican los datos y cuándo no.
• Google puede usar los códigos de estado para sugerir al usuario que realice determinadas acciones en la app de modo que pueda ver el contenido de la app o superarlo.

La lista de códigos de estado de publicación aptos es la siguiente:

// 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

Si el contenido no se publica debido a que un usuario no accedió, te recomendamos que publiques la tarjeta de acceso. Si, por algún motivo, los proveedores no pueden publicar la tarjeta de acceso, recomendamos que llames a la API de updatePublishStatus con el código de estado NOT_PUBLISHED_REQUIRES_SIGN_IN.

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

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

Publicación de clústeres con WorkManager

Recomendamos que uses WorkManager para publicar clústeres, ya que es la solución recomendada para trabajos en segundo plano en los que la ejecución debe ser tanto oportunista como garantizada.

• WorkManager realiza el trabajo en segundo plano tan pronto como sea posible.
• WorkManager controla la lógica para iniciar tu trabajo en diferentes condiciones, incluso si un usuario sale de tu app.

Cuando el usuario salga de la app, recomendamos que inicies un trabajo en segundo plano que publique clústeres de Continuation y clústeres de Recommendation. Un buen lugar para controlar esta lógica es Activity.onStop(), que se llama cuando el usuario sale de la app.

Te recomendamos que uses PeriodicWorkRequest para programar un trabajo recurrente que publique clústeres cada 24 horas. Con el uso de una política CANCEL_AND_REENQUEUE para activar el trabajo, los desarrolladores pueden asegurarse de que WorkManager envíe los datos actualizados cada vez que un usuario salga de la app. Esto ayuda a evitar que los usuarios vean datos inactivos.

En el siguiente ejemplo se demuestra esto:

// 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);

}

Controla los intents de transmisión

Además de realizar llamadas a las APIs de publicación de contenido a través de un trabajo, también se requiere configurar un BroadcastReceiver para recibir la solicitud de publicación de contenido.

Sin embargo, los desarrolladores deben tener cuidado de no depender únicamente de las transmisiones, ya que estas solo se activan en ciertas situaciones, principalmente para la reactivación de una app y para forzar una sincronización de datos. Solo se activan cuando el servicio de Engage determina que el contenido podría estar inactivo. De esa manera, será más probable que el usuario tenga una experiencia de contenido actualizado, incluso si la aplicación no se abrió hace mucho tiempo.

El BroadcastReceiver debe configurarse de las siguientes dos maneras:

• Registra de forma dinámica una instancia de la clase BroadcastReceiver con Context.registerReceiver(). Esto permite la comunicación desde aplicaciones que aún están activas en la memoria.
• Declara de forma estática una implementación con la etiqueta <receiver> en tu archivo AndroidManifest.xml. Esto permite que la aplicación reciba intents de transmisión cuando no está en ejecución y que la aplicación publique el contenido.