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
- Estos son algunos ejemplos de recomendaciones personalizadas:
- 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
- Estos son algunos ejemplos de bibliotecas de contenido generado por usuarios:
Tipo de recomendación | Estrategia de actualización del contenido | Lineamientos de actualización del contenido |
---|---|---|
Recomendaciones personalizadas | Tolerante Te recomendamos que actualices las recomendaciones una vez al día para que los usuarios puedan ver recomendaciones nuevas todos los días. |
Como los usuarios no tienen una expectativa exacta de cuál será el contenido de la recomendación, la estrategia de actualización del contenido puede ser tolerante. |
Bibliotecas de contenido generado por usuarios | Estricto Te recomendamos que actualices la biblioteca de contenido a medida que los usuarios salgan de la app del desarrollador. |
Es importante que este contenido se sincronice con los datos que se muestran en las plataformas de Google. Esto se debe a que, a diferencia de las recomendaciones personalizadas, el usuario espera un conjunto exacto de contenido. Cualquier retraso significativo en la publicación confundirá a los usuarios. Por lo tanto, la estrategia de actualización de contenido debe ser estricta. |
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
- Estos son algunos ejemplos de recomendaciones no personalizadas:
- 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.
Tipo de recomendación | Estrategia de actualización del contenido | Lineamientos de actualización del contenido |
---|---|---|
Recomendaciones no personalizadas | Tolerante Te recomendamos que actualices las recomendaciones una vez al día. |
Como los usuarios no tienen una expectativa exacta de cuál será el contenido de la recomendación, la estrategia de actualización del contenido puede ser tolerante. |
Tarjeta de acceso en las recomendaciones | Estricto Recomendamos actualizar el estado de la tarjeta de acceso a medida que los usuarios salgan la app del desarrollador. Después de que los usuarios acceden, los desarrolladores deben borrar la tarjeta llamando
API de |
Es importante que el estado de acceso esté sincronizado con la plataforma de Google. Resulta confuso para un usuario ver una tarjeta de acceso en la plataforma de Google cuando este ya accedió. Por lo tanto, la estrategia de actualización de contenido debe ser estricta. |
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
- Estos son algunos ejemplos de clústeres de Continuation generados por el usuario:
Tipo de continuación | Estrategia de actualización del contenido | Lineamientos de actualización del contenido |
---|---|---|
Clústeres de continuación generados por el usuario | Estricto Te recomendamos que actualices la biblioteca de contenido a medida que los usuarios salgan de la app del desarrollador. |
Es importante que este contenido se sincronice con los datos que se muestran en las plataformas de Google. Esto se debe a que, a diferencia de las recomendaciones personalizadas, el usuario espera un conjunto exacto de contenido. Cualquier retraso significativo en la publicación confundirá a los usuarios. Por lo tanto, la estrategia de actualización de contenido debe ser estricta. |
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
Atributo | Requisito | Descripción |
---|---|---|
URI de acción | Obligatorio | Vínculo directo a la acción (p. ej., navega a la página de acceso de la app) |
Imagen | Opcional: En caso de que no se proporcione el título, debes brindar uno. |
Imagen que se muestra en la tarjeta Imágenes con una relación de aspecto de 16 × 9, con una resolución de 1264 × 712 |
Título | Opcional: En caso de que no se proporcione la imagen, debes brindar una. | Título en la tarjeta |
Texto de acción | Opcional | Texto que se muestra en la CTA (p. ej., Acceder) |
Subtítulo | Opcional | Subtítulo opcional en la tarjeta |
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());
Después de que los usuarios acceden, los desarrolladores deben borrar la tarjeta llamando
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.
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());
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
conContext.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 archivoAndroidManifest.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.