دستورالعمل های انتشار SDK Cluster را درگیر کنید

این راهنما شامل مجموعه‌ای از دستورالعمل‌ها برای انتشار خوشه‌ای است که توسعه‌دهندگان می‌توانند هنگام ادغام با Engage SDK از آن‌ها استفاده کنند.

خوشه های توصیه

عنوان خوشه

توصیه می کنیم یک عنوان خوشه منحصر به فرد و مرتبط ارائه کنید که به کاربران بینش بیشتری در مورد محتوای خوشه بدهد.

در اینجا چند نمونه از عناوین خوشه ای خوب بر اساس محتوا آورده شده است:

• خوشه های مرتبط با خرید
  • معاملات لایتنینگ
  • باید هفتگی خرید
  • مربوط به خرید شما از Pixel Buds
  • چکمه های بارانی زنانه
• مجموعه ای از کتاب های سلامت
  • سلامتی، ذهن و بدن
  • در Health به شما توصیه می شود
  • پرفروش ترین ها در تناسب اندام

محتوای خوشه ای

هنگام انتشار خوشه‌های توصیه، توسعه‌دهندگان باید در نظر بگیرند که آیا کاربر به برنامه برنامه‌نویس وارد شده است یا خیر.

وقتی کاربر وارد سیستم شده است

اگر کاربر به برنامه برنامه‌نویس وارد شده است، توصیه می‌کنیم مجموعه‌های محتوای شخصی‌شده یا تولید شده توسط کاربر را منتشر کنید. از آنجایی که محتوای شخصی سازی شده و تولید شده توسط کاربر بیشتر به کاربر مربوط است، آنها انگیزه بیشتری برای بازدید از برنامه توسعه دهنده از سطح Google دارند.

• توصیه های شخصی را می توان منتشر کرد.
  • در اینجا چند نمونه از توصیه های شخصی آورده شده است:
    • برترین ها بر اساس سابقه تماشای کاربر.
    • کتاب‌هایی شبیه به کتاب‌هایی که در تاریخچه خواندن کاربر هستند.
    • آهنگ های هنرمندان مورد علاقه کاربر.
• کتابخانه های محتوای تولید شده توسط کاربر می توانند منتشر شوند.
  • در اینجا چند نمونه از کتابخانه های محتوای تولید شده توسط کاربر آورده شده است:
    • فهرست تماشای کاربر از برنامه توسعه دهنده.
    • لیستی از هنرمندان مورد علاقه کاربر که توسط برنامه توسعه دهنده گزارش شده است.

وقتی کاربر وارد نشده است

اگر کاربری وارد برنامه برنامه‌نویس نشده باشد، همچنان توصیه می‌کنیم خوشه‌ها را منتشر کنید تا کاربران تشویق شوند از برنامه برنامه‌نویس از سطح 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() حذف کنند.

به روز رسانی وضعیت انتشار

اگر به دلایل تجاری داخلی، هیچ یک از خوشه‌ها منتشر نشد، اکیداً توصیه می‌کنیم وضعیت انتشار را با استفاده از updatePublishStatus API به‌روزرسانی کنید. این مهم است زیرا:

• ارائه وضعیت در همه سناریوها، حتی زمانی که محتوا منتشر می شود (وضعیت == منتشر شده)، برای پر کردن داشبوردهایی که از این وضعیت صریح برای انتقال سلامت و سایر معیارهای ادغام شما استفاده می کنند، بسیار مهم است.
• اگر محتوایی منتشر نشود اما وضعیت ادغام خراب نباشد (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

اگر محتوا به دلیل عدم ورود کاربر منتشر نشده است، انتشار کارت ورود به سیستم را توصیه می کنیم. اگر به هر دلیلی ارائه دهندگان قادر به انتشار کارت ورود به سیستم نیستند، توصیه می کنیم با کد وضعیت NOT_PUBLISHED_REQUIRES_SIGN_IN با updatePublishStatus API تماس بگیرید.

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

}

اهداف پخش را مدیریت کنید

علاوه بر برقراری تماس‌های API محتوای انتشار از طریق یک کار، برای دریافت درخواست انتشار محتوا نیز باید یک BroadcastReceiver راه‌اندازی کرد.

با این حال، توسعه‌دهندگان باید مراقب باشند که صرفاً به پخش‌ها اتکا نکنند ، زیرا آنها فقط در سناریوهای خاصی فعال می‌شوند - عمدتاً برای فعال‌سازی مجدد برنامه و همگام‌سازی داده‌ها. آنها فقط زمانی فعال می شوند که سرویس Engage تشخیص دهد که ممکن است محتوا قدیمی باشد. به این ترتیب، اطمینان بیشتری وجود دارد که کاربر یک تجربه محتوای تازه خواهد داشت، حتی اگر برنامه برای مدت طولانی باز نشده باشد.

BroadcastReceiver باید به دو روش زیر راه اندازی شود:

• به صورت پویا یک نمونه از کلاس BroadcastReceiver را با استفاده از Context.registerReceiver() ثبت کنید. این امکان برقراری ارتباط از برنامه هایی را که هنوز در حافظه هستند را امکان پذیر می کند.
• به صورت ایستا یک پیاده سازی را با تگ <receiver> در فایل AndroidManifest.xml خود اعلام کنید. این اجازه می دهد تا برنامه زمانی که در حال اجرا نیست، اهداف پخش را دریافت کند و همچنین به برنامه اجازه می دهد محتوا را منتشر کند.