מעורבות בהנחיות לפרסום של אשכול SDK

המדריך הזה כולל סדרת הנחיות לפרסום אשכולות, שמפתחים יכול לשמש בשילוב עם Engage SDK.

אשכולות של המלצות

שם האשכול

מומלץ לספק כותרת אשכול ייחודית ורלוונטית שתיתן למשתמשים לקבל תובנות נוספות לגבי תוכן האשכול.

הנה כמה דוגמאות לכותרות טובות של אשכולות על סמך התוכן שלהן:

• אשכולות שקשורים לשופינג
  • מבצעים על ברק
  • קניות שבועיות שחייבים לקנות
  • קשורה לרכישת Pixel Buds
  • מגפי גשם לנשים
• אשכולות של ספרים בנושא בריאות
  • בריאות, נפש ו גוף
  • מומלצות עבורך בתחום הבריאות
  • המוצרים הכי נמכרים בכושר

תוכן של אשכול

כשמפרסמים אשכולות של המלצות, המפתחים צריכים לשקול אם המשתמש מחובר לאפליקציה של המפתח.

כשהמשתמש מחובר לחשבון

אם המשתמש מחובר לאפליקציה למפתחים, מומלץ לפרסם אשכולות של תוכן מותאמים אישית או שנוצרו על ידי משתמשים. מכיוון שההתאמה אישית תוכן שנוצר על ידי משתמשים רלוונטי יותר למשתמש, יש לו יותר מוטיבציה להיכנס לאפליקציה למפתחים מהפלטפורמה של Google.

• אפשר לפרסם המלצות בהתאמה אישית.
  • ריכזנו כאן כמה דוגמאות להמלצות בהתאמה אישית:
    • המלצות מובילות על סמך היסטוריית הצפייה של המשתמש.
    • ספרים שדומים לספרים בהיסטוריית הקריאה של המשתמש.
    • שירים של האומנים האהובים על המשתמש.
• ניתן לפרסם ספריות תוכן שנוצרו על ידי משתמשים.
  • לפניכם כמה דוגמאות לספריות תוכן שנוצרו על ידי המשתמשים:
    • רשימת הצפייה של המשתמש מהאפליקציה למפתחים.
    • רשימה שדווחה באופן עצמי של האומנים המועדפים על המשתמש מהמפתח אפליקציה.

כשהמשתמש לא מחובר

גם אם המשתמש לא מחובר לאפליקציה למפתחים, עדיין מומלץ לפרסם אשכולות כדי לעודד את המשתמשים לבקר באפליקציה למפתחים פלטפורמה.

• צריך לפרסם אשכולות של המלצות ללא התאמה אישית.
  • הנה כמה דוגמאות להמלצות ללא התאמה אישית:
    • 10 הספרים המובילים שנקראו השנה.
    • סרטים חדשים.
    • פודקאסטים פופולריים.
• מפרסמים כרטיס כניסה.
  • כדי לעודד את המשתמשים להיכנס לאפליקציה למפתחים, מפתחים לבחור לפרסם כרטיס כניסה יחד עם המודעה אשכול המלצות. אפשר לעיין בקטע שלמטה כדי לקבל פרטים נוספים על איך לפרסם כרטיס כניסה.

אשכולות המשך

כשמפרסמים אשכולות המשך, על המפתחים לשקול אם המשתמש מחובר לאפליקציה של המפתח.

כשהמשתמש מחובר לחשבון

• יש לפרסם אשכולות המשך שנוצרו על ידי משתמשים.
  • לפניכם כמה דוגמאות אשכולות המשך שנוצרו על ידי משתמשים:
    • אפשר להמשיך את הצפייה מהמקום שבו המשתמש הפסיק.
    • אפשר להמשיך לקרוא מהמקום שבו המשתמש הפסיק.

כשהמשתמש לא מחובר

מסלולי המשך מיועדים בעיקר למשתמשים שמחוברים לחשבון. עם זאת, אפשר גם לפרסם אשכולות המשך למשתמשים שלא מחוברים לחשבון אם האפליקציה תומכת בגלישה כאורח.

אשכול ניהול משתמשים

המטרה העיקרית של אשכול ניהול המשתמשים היא לעודד משתמשים לבצע פעולות באפליקציה של הספק. פעולת הכניסה מפנה את המשתמשים לחתימה של האפליקציה בדף כדי שהאפליקציה תוכל לפרסם תוכן (או לספק יותר תוכן תוכן)

כרטיס כניסה

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

אחרי שהמשתמשים נכנסים, המפתחים צריכים למחוק את הכרטיס באמצעות התקשרות API של deleteUserManagementCluster().

עדכון סטטוס הפרסום

אם מסיבה עסקית פנימית כלשהי, אף אחד מהאשכולות לא מתפרסם, מומלץ מאוד לעדכן את סטטוס הפרסום באמצעות ממשק API של updatePublishStatus. זה חשוב מהסיבות הבאות :

• הצגת הסטטוס בכל התרחישים, גם כשהתוכן פורסם (STATUS == PUBLISHED) הוא קריטי לאכלוס מרכזי בקרה שמשתמשים בכך סטטוס מפורש כדי להעביר את התקינות ומדדים אחרים של השילוב שלך.
• אם לא מתפרסם תוכן, אבל סטטוס השילוב לא פגום (STATUS == NOT_PUBLISHED), Google יכולה להימנע מהפעלת התראות באפליקציה לוחות בקרה בנושאי בריאות. היא מאשרת שהתוכן לא פורסם עקב הצפוי מבחינת הספק.
• הם עוזרים למפתחים להבין מתי הנתונים מתפרסמים ומתי לא.
• Google עשויה להשתמש בקודי הסטטוס כדי לעודד את המשתמש לבצע פעולות מסוימות כדי שיוכלו לראות את התוכן של האפליקציה או להתגבר עליו.

רשימת קודי הסטטוסים הכשירים לפרסום היא :

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

אם התוכן לא פורסם כי משתמש לא מחובר, אנחנו ממליצים לפרסם את כרטיס הכניסה. אם מסיבה כלשהי ספקים לא יכולים לפרסם את כרטיס הכניסה לאחר מכן מומלץ לקרוא ל-API updatePublishStatus עם קוד הסטטוס 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 לפרסום אשכולות

מומלץ להשתמש ב-WorkManager כדי לפרסם אשכולות, כי זה הפתרון המומלץ לעבודה ברקע שבהם הביצוע חייב להיות גם הזדמנותי וגם מובטח.

• WorkManager מבצע את העבודה ברקע בהקדם האפשרי.
• WorkManager מטפל בלוגיקה בהתחלת העבודה במגוון של תנאים, גם אם המשתמש מנווט אל מחוץ לאפליקציה.

כשהמשתמש מנווט אל מחוץ לאפליקציה, מומלץ להפעיל רקע. שמפרסמת אשכולות המשך יחד עם אשכולות של המלצות. א' הטיפול בהיגיון הזה הוא מקום טוב Activity.onStop(), שנקרא כשהמשתמש מנווט אל מחוץ לאפליקציה.

מומלץ להשתמש PeriodicWorkRequest כדי לתזמן משימה חוזרת שמפרסמת אשכולות כל 24 שעות. באמצעות CANCEL_AND_REENQUEUE להפעלת העבודה, המפתחים יכולים לוודא ש-WorkManager שולח נתונים מעודכנים בכל פעם שמשתמש מנווט אל מחוץ לאפליקציה. זה עוזר למנוע למשתמשים לראות נתונים לא פעילים.

הדוגמה הבאה ממחישה את זה:

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

}

טיפול בכוונות שידור

בנוסף לביצוע קריאות לפרסום Content API באמצעות משימה, מדובר גם נדרשות כדי להגדיר BroadcastReceiver כדי לקבל את הבקשה לפרסום תוכן.

עם זאת, מפתחים צריכים להיזהר לא להסתמך רק על שידורים, כי הן מופעלות רק בתרחישים מסוימים – בעיקר בשביל אפליקציות הפעלה מחדש ואילוץ סנכרון נתונים. הן מופעלות רק כאשר השירות קובע שייתכן שהתוכן מיושן. כך יש אפשרות להיות בטוחים שלמשתמש תהיה חוויית תוכן חדשה, גם אם לא נפתח במשך זמן רב.

צריך להגדיר את BroadcastReceiver בשתי הדרכים הבאות:

• רישום באופן דינמי של מופע של המחלקה BroadcastReceiver באמצעות Context.registerReceiver(). כך מתאפשרת תקשורת מאפליקציות שעדיין קיימים בזיכרון.
• הצהרה סטטית על יישום עם התג <receiver> ב- קובץ AndroidManifest.xml. ההרשאה הזו מאפשרת לאפליקציה לקבל שידור את ה-Intent כאשר הוא לא פועל, וגם מאפשרת לאפליקציה לפרסם את התוכן.