Richtlinien für die Veröffentlichung von Engage SDK-Clustern

Dieses Handbuch enthält eine Reihe von Richtlinien für die Cluster-Veröffentlichung, die Entwickler die bei der Integration mit dem Engage SDK verwendet werden können.

Empfehlungscluster

Clustertitel

Wir empfehlen, einen eindeutigen und relevanten Clustertitel anzugeben, der Nutzern und erhalten mehr Einblick in den Inhalt des Clusters.

Hier sind einige Beispiele für gute, inhaltsbezogene Clustertitel:

• Cluster für Shopping <ph type="x-smartling-placeholder">
  </ph>
  • Blitzangebote
  • Wöchentliche Must-Käufe
  • Zum Kauf von Pixel Buds
  • regenstiefel für damen
• Cluster von Büchern zum Thema Gesundheit <ph type="x-smartling-placeholder">
  </ph>
  • Gesundheit, Geist und Text
  • Für Sie im Bereich „Gesundheit“ empfohlen
  • Bestseller im Bereich Fitness

Clusterinhalte

Bei der Veröffentlichung von Empfehlungsclustern müssen Entwickler überlegen, ob sie wenn der Nutzer in der App des Entwicklers angemeldet ist.

Wenn der Nutzer angemeldet ist

Wenn der Nutzer in der Entwickler-App angemeldet ist, empfehlen wir, die App zu veröffentlichen. oder nutzergenerierten Content-Clustern. Denn personalisierte und sind für die Nutzer relevanter und sie haben mehr die Entwickler-App über die Google-Oberfläche aufrufen.

• Personalisierte Empfehlungen können veröffentlicht werden.
  • Hier einige Beispiele für personalisierte Empfehlungen: <ph type="x-smartling-placeholder">
    </ph>
    • Empfehlungen basierend auf dem Wiedergabeverlauf des Nutzers.
    • Bücher, die mit Büchern vergleichbar sind, die sich im Leseverlauf des Nutzers befinden.
    • Songs von den Lieblingskünstlern des Nutzers
• Bibliotheken mit von Nutzern erstellten Inhalten können veröffentlicht werden.
  • Hier einige Beispiele für Bibliotheken mit von Nutzern erstellten Inhalten: <ph type="x-smartling-placeholder">
    </ph>
    • Die Beobachtungsliste des Nutzers aus der Entwickler-App.
    • Eine eigene Liste der Lieblingskünstler des Nutzers vom Entwickler

Wenn der Nutzer nicht angemeldet ist

Auch wenn ein Nutzer nicht in der Entwickler-App angemeldet ist, empfehlen wir, die App zu veröffentlichen. erstellen, damit Nutzer aufgefordert werden, die Entwickler-App über die Google Oberfläche.

• Nicht personalisierte Empfehlungscluster sollten veröffentlicht werden.
  • Hier einige Beispiele für nicht personalisierte Empfehlungen: <ph type="x-smartling-placeholder">
    </ph>
    • Die 10 beliebtesten Bücher dieses Jahres.
    • Neu veröffentlichte Filme
    • Angesagte Podcasts.
• Veröffentlichen Sie eine Anmeldekarte.
  • Um Nutzer zu ermutigen, sich in der Entwickler-App anzumelden, kann eine Anmeldekarte zusammen mit den nicht personalisierten Empfehlungs-Cluster. Weitere Informationen finden Sie im So veröffentlichst du eine Anmeldekarte

Fortsetzungscluster

Bei der Veröffentlichung von Fortsetzungsclustern müssen Entwickler überlegen, ob sie wenn der Nutzer in der App des Entwicklers angemeldet ist.

Wenn der Nutzer angemeldet ist

• Nutzergenerierte Fortsetzungscluster sollten veröffentlicht werden.
  • Hier einige Beispiele für nutzergenerierte Continuation-Cluster: <ph type="x-smartling-placeholder">
    </ph>
    • Wiedergabe dort fortsetzen, wo der Nutzer aufgehört hat
    • Weiterlesen, wo der Nutzer aufgehört hat

Wenn der Nutzer nicht angemeldet ist

Fortsetzungspfade sind in erster Linie für angemeldete Nutzer gedacht. Allerdings können Sie auch Fortsetzungscluster für abgemeldete Nutzer veröffentlichen, sofern Ihre App Gastsitzungen unterstützt.

Cluster zur Nutzerverwaltung

Das Hauptziel des Nutzerverwaltungs-Clusters besteht darin, Nutzende dazu zu bewegen, Aktionen in der Anbieter-App. Bei der Anmeldung werden Nutzer zum App-Zeichen weitergeleitet. damit die App Inhalte veröffentlichen oder personalisierte Inhalt)

Anmeldekarte

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

Nachdem sich Nutzer angemeldet haben, müssen Entwickler die Karte löschen, indem sie deleteUserManagementCluster()-API.

Veröffentlichungsstatus aktualisieren

Wenn aus internen geschäftlichen Gründen keiner der Cluster veröffentlicht wird, empfehlen wir dringend, den Veröffentlichungsstatus über die updatePublishStatus verwenden. Dies ist aus folgenden Gründen wichtig :

• Angabe des Status in allen Szenarien, auch wenn die Inhalte veröffentlicht wurden (STATUS == VERÖFFENTLICHT) ist wichtig, um Dashboards mit diesem expliziten Status, um den Zustand und andere Messwerte deiner Integration zu vermitteln.
• Wenn keine Inhalte veröffentlicht werden, der Integrationsstatus aber nicht fehlerhaft ist (STATUS == NOT_PUBLISHED), Google kann verhindern, dass Benachrichtigungen in der App ausgelöst werden Gesundheits-Dashboards. Er bestätigt, dass Inhalte aufgrund eines erwartete Situation aus Sicht des Anbieters.
• Entwickler können so herausfinden, wann die Daten veröffentlicht werden und wann nicht.
• Google kann die Statuscodes verwenden, um Nutzer zu bestimmten Aktionen im damit sie den App-Inhalt sehen oder überwinden können.

Die Liste der zulässigen Veröffentlichungsstatuscodes sieht so aus :

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

Wenn der Inhalt nicht veröffentlicht wird, weil ein Nutzer nicht angemeldet ist, empfehlen wir, die Log-in-Karte zu veröffentlichen. Wenn Anbieter die Anmeldekarte aus irgendeinem Grund nicht veröffentlichen können sollten Sie die API updatePublishStatus aufrufen, mit dem Statuscode 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());

WorkManager für die Clusterveröffentlichung

Wir empfehlen die Verwendung von WorkManager, Cluster veröffentlichen, da dies die empfohlene Lösung für Hintergrundarbeiten ist bei der die Umsetzung sowohl opportunistisch als auch garantiert sein muss.

• WorkManager führt Ihre Hintergrundarbeit so schnell wie möglich aus.
• WorkManager übernimmt die Logik, um Ihre Arbeit unter verschiedenen selbst wenn der Nutzer die App verlässt.

Wenn der Nutzer die App verlässt, empfehlen wir, einen Hintergrund Job, der Fortsetzungscluster zusammen mit Empfehlungsclustern veröffentlicht. A um mit dieser Logik umzugehen, Activity.onStop() mit dem Namen wenn Nutzende die App verlassen.

Wir empfehlen die Verwendung von PeriodicWorkRequest um einen wiederkehrenden Job zu planen, der Cluster alle 24 Stunden veröffentlicht. Mit einem CANCEL_AND_REENQUEUE zum Auslösen der Arbeit, können Entwickler dafür sorgen, dass WorkManager die aktualisierte Daten, sobald ein Nutzer die App verlässt. So wird verhindert, dass Nutzer veraltete Daten sehen.

Das folgende Beispiel veranschaulicht dies:

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

}

Broadcast-Intents verarbeiten

Neben den Aufrufen der Content API zum Veröffentlichen über einen Job für die Einrichtung eines BroadcastReceiver zum Empfangen von um die Veröffentlichung von Inhalten zu beantragen.

Entwickler dürfen sich jedoch nicht ausschließlich auf Broadcasts verlassen, da sie nur in bestimmten Szenarien ausgelöst werden, vor allem für Apps, und eine Datensynchronisierung erzwingen. Sie werden nur ausgelöst, wenn die Schaltfläche Der Dienst stellt fest, dass der Inhalt möglicherweise veraltet ist. Auf diese Weise gibt es darauf vertrauen können, dass die Inhalte für den Nutzer ansprechend sind, auch wenn der Nutzer die App schon länger nicht mehr geöffnet hat.

BroadcastReceiver muss auf zwei Arten eingerichtet werden:

• Dynamisches Registrieren einer Instanz der BroadcastReceiver-Klasse mithilfe von Context.registerReceiver(). Dies ermöglicht die Kommunikation von Anwendungen die sich noch im Arbeitsspeicher befinden.
• Sie müssen eine Implementierung mit dem <receiver>-Tag in Ihrem AndroidManifest.xml-Datei. Dadurch kann die Anwendung Nachrichten an alle Intents erstellt, wenn sie nicht ausgeführt wird, und ermöglicht der App, für den Inhalt.