Wskazówki dotyczące publikowania klastra SDK w Google Engage

Ten przewodnik zawiera zestaw wytycznych dotyczących publikowania klastrów, które deweloperzy których możesz użyć do integracji z pakietem SDK dla Agencji.

Klastry rekomendacji

Tytuł klastra

Zalecamy podanie unikalnej i trafnej nazwy klastra, która pokaże użytkownikom więcej informacji na temat zawartości klastra.

Oto kilka przykładów prawidłowych nazw klastrów na podstawie treści:

  • Klastry związane z zakupami
    • Wyjątkowe oferty
    • Cotygodniowe zakupy
    • Powiązane z zakupem słuchawek Pixel Buds
    • Kalosze damskie
  • Książki o zdrowiu
    • Zdrowie, umysł i treść
    • Polecane dla Ciebie w aplikacji Zdrowie
    • bestsellery z kategorii Fitness

Zawartość klastra

Przy publikowaniu klastrów rekomendacji deweloperzy muszą wziąć pod uwagę, użytkownik jest zalogowany w aplikacji dewelopera.

Gdy użytkownik jest zalogowany

Jeśli użytkownik jest zalogowany w aplikacji dewelopera, zalecamy opublikowanie jej spersonalizowanych lub generowanych przez użytkowników. Ponieważ spersonalizowane tworzone przez użytkowników są dla nich bardziej przydatne i motywujące otwórz aplikację dla deweloperów w Google.

  • Spersonalizowane rekomendacje można publikować.
    • Oto kilka przykładów spersonalizowanych rekomendacji:
      • Najczęściej wybierane na podstawie historii oglądania użytkownika.
      • książki podobne do tych, które znajdują się w historii czytania użytkownika;
      • Utwory ulubionych wykonawców użytkownika.
  • Można publikować biblioteki treści użytkowników.
    • Oto kilka przykładów bibliotek treści użytkowników:
      • Lista Do obejrzenia w aplikacji dewelopera
      • Wpisana przez siebie lista ulubionych wykonawców użytkownika tworzona przez dewelopera .
Typ rekomendacji Strategia dotycząca aktualności treści Wytyczne dotyczące aktualności treści
Spersonalizowane rekomendacje

Obiektyw

Zalecamy aktualizowanie rekomendacji raz dziennie, aby użytkownicy widzą nowe rekomendacje każdego dnia.

 Użytkownicy nie mają pewności co do tego, rekomendacji, strategia dotycząca aktualności treści może być wyrozumiały.
Biblioteki treści użytkowników

Ścisłe

Zalecamy aktualizowanie biblioteki treści, gdy użytkownicy wychodzą aplikację deweloperską.

 Ważne jest, aby te treści były zsynchronizowane z danymi wyświetlanymi na stronie Platformy Google. Dzieje się tak, ponieważ w odróżnieniu od spersonalizowanych rekomendacji oczekuje konkretnego zestawu treści. Wszelkie znaczące opóźnienia w publikowaniem treści wprowadza użytkowników w błąd. Dlatego strategia dotycząca aktualności treści muszą być rygorystyczne.

Gdy użytkownik nie jest zalogowany

Jeśli użytkownik nie jest zalogowany w aplikacji dewelopera, nadal zalecamy jej opublikowanie w klastrach, dzięki czemu użytkownicy są zachęcani do korzystania z aplikacji dla programistów na różnych powierzchniach.

  • Klastry rekomendacji niespersonalizowanych powinny zostać opublikowane.
    • Oto kilka przykładów niespersonalizowanych rekomendacji:
      • 10 najpopularniejszych książek w tym roku.
      • Nowo opublikowane filmy.
      • Podcasty zyskujące popularność.
  • Opublikuj kartę logowania.
    • Aby zachęcić użytkowników do logowania się w aplikacji, deweloperzy mogą opublikować kartę logowania wraz z niespersonalizowanymi klastra rekomendacji. Więcej informacji znajdziesz w sekcji poniżej. Jak opublikować kartę logowania.
Typ rekomendacji Strategia dotycząca aktualności treści Wytyczne dotyczące aktualności treści
Niespersonalizowane rekomendacje

Obiektyw

Zalecamy aktualizowanie rekomendacji raz na dzień.

 Użytkownicy nie mają pewności co do tego, rekomendacji, strategia dotycząca aktualności treści może być wyrozumiały.
Karta logowania w rekomendacjach

Ścisłe

Zalecamy aktualizowanie stanu karty logowania po wyjściu użytkownika z aplikacji dewelopera.

Gdy użytkownicy się zalogują, deweloperzy muszą usunąć kartę, wywołując Interfejs API deleteUserManagementCluster().

Ważne jest, aby stan logowania był zsynchronizowany z kontem Google, na różnych powierzchniach. Użytkownikom może się to dziwić, widząc kartę logowania na swojej stronie pojawiają się, gdy są już zalogowani. Dlatego też aktualność treści musi być rygorystyczna.

Klastry kontynuacji

Przy publikowaniu klastrów kontynuacji deweloperzy muszą wziąć pod uwagę, czy użytkownik jest zalogowany w aplikacji dewelopera.

Gdy użytkownik jest zalogowany

  • Klastry kontynuacji wygenerowane przez użytkowników powinny zostać opublikowane.
    • Oto kilka przykładów klastrów kontynuacji wygenerowanych przez użytkowników:
      • Kontynuuj oglądanie od miejsca, w którym widz przerwał.
      • Wznów czytanie od miejsca, w którym przerwał użytkownik.
Typ kontynuacji Strategia dotycząca aktualności treści Wytyczne dotyczące aktualności treści
Klastry kontynuacji wygenerowane przez użytkownika

Ścisłe

Zalecamy aktualizowanie biblioteki treści, gdy użytkownicy wychodzą aplikację deweloperską.

 Ważne jest, aby te treści były zsynchronizowane z danymi wyświetlanymi na stronie Platformy Google. Dzieje się tak, ponieważ w odróżnieniu od spersonalizowanych rekomendacji oczekuje konkretnego zestawu treści. Wszelkie znaczące opóźnienia w publikowaniem treści wprowadza użytkowników w błąd. Dlatego strategia dotycząca aktualności treści muszą być rygorystyczne.

Gdy użytkownik nie jest zalogowany

Kolejne ścieżki są przeznaczone głównie dla zalogowanych użytkowników. jednak możesz też publikować klastry kontynuacji dla niezalogowanych użytkowników jeśli aplikacja obsługuje sesje gościa.

Klaster zarządzania użytkownikami

Głównym celem klastra zarządzania użytkownikami jest zachęcanie użytkowników do wykonania określonych w aplikacji dostawcy. Czynność logowania kieruje użytkowników do znaku aplikacji na stronie, dzięki czemu aplikacja może publikować treści (lub zapewniać treści)

Karta logowania

Atrybut Wymaganie Opis
Identyfikator URI działania Wymagane Precyzyjny link do działania (np. otwiera stronę logowania w aplikacji)
Obraz Opcjonalnie – jeśli nie podano, musisz podać tytuł

Obraz widoczny na karcie

Obrazy o współczynniku proporcji 16 x 9 i rozdzielczości 1264 x 712
Tytuł Opcjonalnie – jeśli nie podano, należy przesłać zdjęcie Tytuł na karcie
Tekst działania Opcjonalnie Tekst widoczny w wezwaniu do działania (np. „Zaloguj się”)
Podtytuł Opcjonalnie Opcjonalny tytuł na karcie

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

Gdy użytkownicy się zalogują, deweloperzy muszą usunąć kartę, wywołując Interfejs API deleteUserManagementCluster().

Zaktualizuj stan publikacji

Jeśli z jakiegoś wewnętrznego powodu biznesowego żaden z klastrów nie zostanie opublikowany, zdecydowanie zalecamy zaktualizowanie stanu publikacji za pomocą interfejsu API updatePublishStatus. To ważne, ponieważ :

  • Podawanie stanu we wszystkich sytuacjach, nawet po opublikowaniu treści (STATUS == PUBLISHED) – ma kluczowe znaczenie przy wypełnianiu paneli, które używają jawny stan, który przekazuje informacje o stanie i inne wskaźniki integracji.
  • Jeśli treści nie zostały opublikowane, ale stan integracji nie jest nieprawidłowy (STATUS == NOT_PUBLISHED), Google może uniknąć wywoływania alertów w aplikacji paneli stanu. Potwierdza ono, że treść nie została opublikowana z powodu jest oczekiwana z punktu widzenia dostawcy.
  • Pomaga deweloperom określić, kiedy dane są publikowane, a kiedy nie.
  • Google może używać kodów stanu, aby skłonić użytkownika do wykonania określonych czynności aby wyświetlić jej zawartość lub ją pokonać.

Lista kodów stanu odpowiednich publikacji :

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

Jeśli treści nie zostały opublikowane z powodu niezalogowania się użytkownika, zalecamy opublikowanie karty logowania. Jeśli z jakiegoś powodu dostawcy nie mogą opublikować karty logowania zalecamy wywoływanie interfejsu API updatePublishStatus z kodem stanu 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 do publikowania klastrów

Zalecamy używanie WorkManagera do publikowanie klastrów, ponieważ jest to zalecane rozwiązanie do pracy w tle w których realizacja musi być jednocześnie oportunistyczna i gwarantowana.

  • WorkManager wykonuje Twoje działania w tle tak szybko, jak to możliwe.
  • WorkManager obsługuje logikę rozpoczynania pracy w różnych warunków, nawet wtedy, gdy użytkownik opuści aplikację.

Zalecamy uruchomienie tła, gdy użytkownik opuści aplikację zadanie publikowania klastrów kontynuacji wraz z klastrami rekomendacji. O Dobrze radzić sobie z tą logiką Activity.onStop() o nazwie gdy użytkownik opuści aplikację.

Zalecamy użycie PeriodicWorkRequest aby zaplanować zadanie cykliczne, które publikuje klastry co 24 godziny. Za pomocą CANCEL_AND_REENQUEUE zasady uruchamiania zadania, programiści mogą zapewnić, że WorkManager wysyła aktualizowanych danych za każdym razem, gdy użytkownik opuści aplikację. Dzięki temu zapobiegamy na wyświetlanie nieaktualnych danych.

Oto przykład:

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

}

Obsługa intencji transmisji

Oprócz wykonywania wywołań interfejsu Content API w zadaniu wymagane do skonfigurowania BroadcastReceiver do otrzymania z prośbą o opublikowanie treści.

Deweloperzy powinni jednak uważać, aby nie polegać wyłącznie na transmisjach, ponieważ są one aktywowane tylko w określonych sytuacjach – głównie w przypadku aplikacji ponowna aktywacja i wymuszenie synchronizacji danych. Są wywoływane tylko wtedy, gdy komponent Usługa wykrywa, że treści mogą być nieaktualne. W ten sposób że użytkownicy będą mieli dostęp do nowych treści, nawet jeśli aplikacja od dawna nie była otwierana.

BroadcastReceiver trzeba skonfigurować na 2 sposoby:

  • Dynamicznie zarejestruj instancję klasy BroadcastReceiver za pomocą Context.registerReceiver() Umożliwia to komunikację z aplikacji które wciąż są żywe w pamięci.
  • Statycznie deklaruj implementację z tagiem <receiver> w sekcji AndroidManifest.xml. Zezwala to aplikacji na odbieranie komunikatów intencje, gdy nie jest uruchomiona, oraz umożliwia publikowanie aplikacji treści.