Linee guida sulla pubblicazione dei cluster di SDK Engage

Questa guida include una serie di linee guida per la pubblicazione dei cluster che gli sviluppatori durante l'integrazione con l'SDK Engage.

Cluster di suggerimenti

Titolo del cluster

Ti consigliamo di fornire un titolo del cluster univoco e pertinente che dia agli utenti più insight sui contenuti del cluster.

Ecco alcuni esempi di titoli dei cluster efficaci basati sui contenuti:

  • Cluster correlati a Shopping
    • Offerte Lightning
    • Acquisti settimanali da non perdere
    • Contenuti correlati all'acquisto di Pixel Buds
    • Stivali da pioggia da donna
  • Cluster di libri sullo stato di integrità
    • Salute, mente e corpo
    • Consigliati per te in Salute
    • Best-seller per il fitness

Contenuti del cluster

Quando pubblicano cluster di suggerimenti, gli sviluppatori devono valutare se l'utente abbia eseguito l'accesso all'applicazione dello sviluppatore.

Quando l'utente ha eseguito l'accesso

Se l'utente ha eseguito l'accesso all'app sviluppatore, ti consigliamo di pubblicare ad esempio con cluster di contenuti personalizzati o generati dagli utenti. Poiché i servizi personalizzati i contenuti generati dagli utenti sono più pertinenti per l'utente, sono più motivati a visitare l'app per sviluppatori dalla piattaforma Google.

  • È possibile pubblicare consigli personalizzati.
    • Ecco alcuni esempi di consigli personalizzati:
      • Scelti per te in base alla cronologia delle visualizzazioni dell'utente.
      • Libri simili ai libri presenti nella cronologia di lettura dell'utente.
      • Brani degli artisti preferiti dell'utente.
  • Le raccolte di contenuti generate dagli utenti possono essere pubblicate.
    • Ecco alcuni esempi di librerie di contenuti generati dagli utenti:
      • La lista di titoli dell'utente dall'app sviluppatore.
      • Un elenco autodichiarato degli artisti preferiti dell'utente dello sviluppatore dell'app.
Tipo di suggerimento Strategia per l'aggiornamento dei contenuti Linee guida per l'aggiornamento dei contenuti
Consigli personalizzati

Indulto

Consigliamo di aggiornare i consigli una volta al giorno gli utenti possono vedere nuovi consigli ogni giorno.

 Perché gli utenti non hanno un'aspettativa esatta di quanto contenuti consigliati, la strategia di aggiornamento dei contenuti può permissiva.
Raccolte di contenuti generate dagli utenti

Rigorosa

Consigliamo di aggiornare la raccolta di contenuti quando gli utenti escono dalla come app per sviluppatori.

 È importante che questi contenuti siano sincronizzati con i dati visualizzati Piattaforme Google. Questo perché, a differenza dei consigli personalizzati, l'utente si aspetta un insieme esatto di contenuti. Qualsiasi ritardo significativo nella la pubblicazione confonde gli utenti. La strategia di aggiornamento dei contenuti devono essere rigide.

Se l'utente non ha eseguito l'accesso

Se un utente non ha eseguito l'accesso all'app sviluppatore, consigliamo comunque di pubblicare in modo che gli utenti siano incoraggiati a visitare l'app per sviluppatori dal superficie.

  • I cluster di suggerimenti non personalizzati devono essere pubblicati.
    • Ecco alcuni esempi di consigli non personalizzati:
      • I 10 libri più letti quest'anno.
      • Film appena usciti.
      • Podcast di tendenza.
  • Pubblica una scheda di accesso.
    • Per incoraggiare gli utenti ad accedere all'app sviluppatore, gli sviluppatori puoi scegliere di pubblicare una scheda di accesso insieme ai file non personalizzati di suggerimenti. Consulta la sezione di seguito per ulteriori dettagli su come pubblicare una scheda di accesso.
Tipo di suggerimento Strategia per l'aggiornamento dei contenuti Linee guida per l'aggiornamento dei contenuti
Consigli non personalizzati

Indulto

Consigliamo di aggiornare i consigli una volta ogni giorno.

 Perché gli utenti non hanno un'aspettativa esatta di quanto contenuti consigliati, la strategia di aggiornamento dei contenuti può permissiva.
Scheda di accesso nei consigli

Rigorosa

Ti consigliamo di aggiornare lo stato della scheda di accesso quando gli utenti escono l'app per sviluppatori.

Dopo che gli utenti hanno eseguito l'accesso, gli sviluppatori devono eliminare la carta chiamando API deleteUserManagementCluster().

È importante che lo stato di accesso sia sincronizzato con Google superficie. È poco chiaro per un utente vedere una scheda di accesso sulla vengono visualizzate quando l'utente ha già eseguito l'accesso. Pertanto, l'aggiornamento dei contenuti strategia deve essere rigorosa.

Cluster di continuazione

Quando pubblicano cluster di continuazione, gli sviluppatori devono valutare se l'utente abbia eseguito l'accesso all'applicazione dello sviluppatore.

Quando l'utente ha eseguito l'accesso

  • I cluster di continuazione generati dall'utente dovrebbero essere pubblicati.
    • Ecco alcuni esempi di cluster di continuazione generati dall'utente:
      • Continua a guardare dal punto in cui l'utente l'aveva interrotto.
      • Continua a leggere dal punto in cui l'utente si era interrotto.
Tipo di continuazione Strategia per l'aggiornamento dei contenuti Linee guida per l'aggiornamento dei contenuti
Cluster di continuazione generati dall'utente

Rigorosa

Consigliamo di aggiornare la raccolta di contenuti quando gli utenti escono dalla come app per sviluppatori.

 È importante che questi contenuti siano sincronizzati con i dati visualizzati sulle piattaforme di Google. Questo perché, a differenza dei consigli personalizzati, l'utente si aspetta un insieme esatto di contenuti. Qualsiasi ritardo significativo nella la pubblicazione confonde gli utenti. La strategia di aggiornamento dei contenuti devono essere rigide.

Se l'utente non ha eseguito l'accesso

I percorsi di continuazione sono destinati principalmente agli utenti che hanno eseguito l'accesso. ma Puoi anche pubblicare cluster di continuazione per gli utenti che non hanno eseguito l'accesso se la tua app supporta le sessioni Ospite.

Cluster di gestione utenti

Lo scopo principale del cluster di gestione degli utenti è sollecitare gli utenti a eseguire determinate azioni sull'app del provider. L'azione di accesso indirizza gli utenti all'accesso all'app nella pagina in modo che l'app possa pubblicare contenuti (o fornire contenuti contenuti)

Scheda di accesso

Attributo Requisito Descrizione
URI azione Obbligatorio Link diretto all'azione (ad esempio, per passare alla pagina di accesso all'app)
Immagine Facoltativo: se non viene specificato, è necessario indicare il titolo

Immagine mostrata sulla scheda

Immagini con proporzioni 16:9 con una risoluzione di 1264 x 712
Titolo Facoltativo: se non viene fornita, è necessario fornire l'immagine Titolo sulla scheda
Testo dell'azione Facoltativo Testo mostrato sull'invito all'azione (ad es. Accedi)
Sottotitolo Facoltativo Sottotitolo facoltativo sulla scheda

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

Dopo che gli utenti hanno eseguito l'accesso, gli sviluppatori devono eliminare la carta chiamando API deleteUserManagementCluster().

Aggiorna stato pubblicazione

Se, per qualsiasi motivo di business interno, nessuno dei cluster viene pubblicato, ti consigliamo vivamente di aggiornare lo stato di pubblicazione utilizzando API updatePubblicaStatus. Questo è importante perché :

  • Indicare lo stato in tutti gli scenari, anche quando i contenuti vengono pubblicati (STATO == PUBBLICATO), è fondamentale per compilare le dashboard che utilizzano questo stato esplicito per comunicare lo stato di integrità e altre metriche della tua integrazione.
  • Se non sono stati pubblicati contenuti, ma lo stato dell'integrazione non funziona (STATUS == NOT_PUBLISHERED), Google può evitare di attivare avvisi nell'app dashboard dell'integrità. Conferma che i contenuti non sono stati pubblicati a causa di un situazione prevista dal punto di vista del provider.
  • Consente agli sviluppatori di capire quando i dati vengono pubblicati o meno.
  • Google può utilizzare i codici di stato per sollecitare l'utente a eseguire determinate azioni nel dell'app in modo da poter vedere o risolvere i contenuti dell'app.

Ecco un elenco di codici di stato idonei per la pubblicazione :

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

Se i contenuti non vengono pubblicati perché un utente non ha eseguito l'accesso, ti consigliamo di pubblicare la scheda di accesso. Se per qualsiasi motivo i fornitori non riescono a pubblicare la scheda di accesso ti consigliamo di chiamare l'API updatepublishStatus con il codice di stato NOT_PUBLISHERED_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 per la pubblicazione di cluster

Ti consigliamo di utilizzare WorkManager per pubblicare cluster, in quanto è la soluzione consigliata per il lavoro in background in cui l'esecuzione deve essere sia opportunistica che garantita.

  • WorkManager esegue il lavoro in background appena possibile.
  • WorkManager gestisce la logica per iniziare il lavoro in diverse anche se un utente esce dalla tua app.

Quando l'utente esce dall'app, è consigliabile iniziare uno sfondo un job che pubblica cluster di continuazione insieme a cluster di suggerimenti. R il modo migliore per gestire questa logica è Activity.onStop(), che prende il nome quando l'utente esce dall'app.

Ti consigliamo di usare PeriodicWorkRequest per pianificare un job ricorrente che pubblica cluster ogni 24 ore. Mediante un CANCEL_AND_REENQUEUE per attivare il lavoro, gli sviluppatori possono assicurarsi che WorkManager invii il messaggio dati aggiornati ogni volta che un utente esce dall'app. Ciò aiuta a prevenire la visualizzazione di dati inattivi per gli utenti.

L'esempio seguente dimostra che:

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

}

Gestire gli intent di trasmissione

Oltre a effettuare chiamate all'API Publication di contenuti tramite un job, è anche necessario per configurare BroadcastReceiver per ricevere la richiesta di pubblicazione di contenuti.

Tuttavia, gli sviluppatori devono fare attenzione a non fare affidamento esclusivamente sulle trasmissioni, perché vengono attivati solo in determinati scenari, principalmente per le app a riattivare e forzare una sincronizzazione dei dati. Vengono attivati solo quando il pulsante Il servizio stabilisce che i contenuti potrebbero essere obsoleti. In questo modo, c'è una maggiore quantità la certezza che l'utente vivrà un'esperienza nuova con i contenuti, anche se l'applicazione non viene aperta da molto tempo.

BroadcastReceiver deve essere configurato nei due modi seguenti:

  • Registra dinamicamente un'istanza della classe BroadcastReceiver utilizzando Context.registerReceiver(). Ciò consente la comunicazione dalle applicazioni ancora in memoria.
  • Dichiarare in modo statico un'implementazione con il tag <receiver> nel tuo AndroidManifest.xml file. Ciò consente all'applicazione di ricevere annunci quando non è in esecuzione e consente inoltre all'applicazione di pubblicare dei contenuti.