این راهنما شامل مجموعه‌ای از دستورالعمل‌ها برای انتشار خوشه است که توسعه‌دهندگان می‌توانند هنگام ادغام با Engage SDK از آن‌ها استفاده کنند.
خوشه‌های توصیه
عنوان خوشه
توصیه می‌کنیم عنوان خوشه غیرتکراری و مرتبطی ارائه دهید که به کاربران اطلاعات بیشتری درباره محتوای خوشه بدهد.
در اینجا چند نمونه از عنوان‌های خوشه‌ای خوب براساس محتوا آورده شده است:
- خوشه‌های مرتبط با خرید
- معامله‌های برق‌آسا
- خریدنی‌های هفتگی
- مربوط به خرید Pixel Buds
- چکمه بارانی زنانه
- خوشه‌های کتاب درباره سلامت
- بهداشت، روان، و بدن
- توصیه‌شده برای شما در «سلامت»
- پرفروش‌ترین‌ها در تناسب اندام
خوشه‌بندی کردن محتوا
هنگام انتشار خوشه‌های توصیه، توسعه‌دهندگان باید درنظر بگیرند که آیا کاربر به سیستم برنامه توسعه‌دهنده وارد شده است یا نه.
وقتی کاربر به سیستم وارد شده باشد
اگر کاربر به سیستم برنامه توسعه‌دهنده وارد شده است، توصیه می‌کنیم خوشه‌های محتوای شخصی‌سازی‌شده یا تولیدشده توسط کاربر را منتشر کنید. چون محتوای شخصی‌سازی‌شده و تولیدشده توسط کاربر برای کاربر مرتبط‌تر است، او انگیزه بیشتری برای بازدید از برنامه توسعه‌دهنده ازطریق سطح Google دارد.
- توصیه‌های شخصی‌سازی‌شده را می‌توان منتشر کرد.
- چند نمونه از توصیه‌های شخصی‌سازی‌شده در اینجا آورده شده است:
- انتخاب‌های برتر براساس سابقه تماشای کاربر.
- کتاب‌های مشابه با کتاب‌هایی که در سابقه خواندن کاربر وجود دارد.
- آهنگ‌های هنرمندان دلخواه کاربر.
- چند نمونه از توصیه‌های شخصی‌سازی‌شده در اینجا آورده شده است:
- کتابخانه‌های محتوای تولیدشده توسط کاربر را می‌توان منتشر کرد.
- در اینجا چند نمونه از کتابخانه‌های محتوای تولیدشده توسط کاربر آورده شده است:
- فهرست تماشای کاربر از برنامه توسعه‌دهنده.
- فهرستی از هنرمندان موردعلاقه کاربر که خود کاربر در برنامه توسعه‌دهنده گزارش کرده است.
- در اینجا چند نمونه از کتابخانه‌های محتوای تولیدشده توسط کاربر آورده شده است:
| نوع پیشنهاد | راهبرد تازگی محتوا | رهنمود تازگی محتوا |
|---|---|---|
| توصیه‌های شخصی‌سازی‌شده | ملایم توصیه می‌کنیم توصیه‌ها را یک‌بار در روز به‌روز کنید تا کاربران بتوانند توصیه‌های جدید را روزانه ببینند. |
چون کاربران انتظار دقیقی از محتوای توصیه‌شده ندارند، استراتژی تازگی محتوا می‌تواند ملایم باشد. |
| کتابخانه‌های محتوای تولیدشده توسط کاربر | سخت‌گیرانه توصیه می‌کنیم وقتی کاربران از برنامه توسعه‌دهنده خارج می‌شوند، کتابخانه محتوا را به‌روز کنید. |
مهم است که این محتوا با داده‌های نمایش‌داده‌شده در سطوح Google همگام‌سازی شود. دلیل این امر این است که برخلاف توصیه‌های شخصی‌سازی‌شده، کاربر انتظار مجموعه دقیقی از محتوا را دارد. هرگونه تأخیر قابل‌توجه در انتشار باعث سردرگمی کاربران خواهد شد. بنابراین، استراتژی تازگی محتوا باید سخت‌گیرانه باشد. |
وقتی کاربر به سیستم وارد نشده است
اگر کاربری به سیستم برنامه توسعه‌دهنده وارد نشده باشد، همچنان توصیه می‌کنیم خوشه‌ها را منتشر کنید تا کاربران تشویق شوند از سطح Google به برنامه توسعه‌دهنده مراجعه کنند.
- خوشه‌های توصیه‌های شخصی‌سازی‌نشده باید منتشر شوند.
- چند نمونه از توصیه‌های شخصی‌سازی‌نشده در اینجا آورده شده است:
- ۱۰ کتاب برتر خوانده‌شده در سال جاری.
- فیلم‌های تازه منتشرشده.
- پادکست‌های پرطرفدار.
- چند نمونه از توصیه‌های شخصی‌سازی‌نشده در اینجا آورده شده است:
- کارت ورود به سیستم منتشر کنید.
- برای تشویق کاربران به ورود به سیستم برنامه توسعه‌دهنده، توسعه‌دهندگان می‌توانند کارت ورود به سیستم را همراه با خوشه توصیه‌های غیرشخصی‌سازی‌شده منتشر کنند. برای جزئیات بیشتر درباره نحوه انتشار کارت ورود به سیستم، بخش زیر را بررسی کنید.
| نوع پیشنهاد | راهبرد تازگی محتوا | رهنمود تازگی محتوا |
|---|---|---|
| توصیه‌های شخصی‌سازی‌نشده | ملایم توصیه می‌کنیم توصیه‌ها را یک‌بار در روز به‌روز کنید. |
چون کاربران انتظار دقیقی از محتوای توصیه‌شده ندارند، استراتژی تازگی محتوا می‌تواند ملایم باشد. |
| کارت ورود به سیستم در توصیه‌ها | سخت‌گیرانه توصیه می‌کنیم وقتی کاربران از برنامه توسعه‌دهنده خارج می‌شوند، وضعیت کارت ورود به سیستم را به‌روز کنید. پس‌از اینکه کاربران به سیستم وارد شدند، توسعه‌دهندگان باید با فراخوانی
|
مهم است که وضعیت ورود به سیستم با سطح Google همگام‌سازی شود. دیدن کارت ورود به سیستم در سطح Google وقتی کاربر قبلاً به سیستم وارد شده است، باعث سردرگمی او می‌شود. بنابراین، استراتژی تازگی محتوا باید سخت‌گیرانه باشد. |
دسته‌های ادامه‌دار
هنگام انتشار خوشه‌های ادامه، توسعه‌دهندگان باید درنظر بگیرند که آیا کاربر به سیستم برنامه توسعه‌دهنده وارد شده است یا نه.
وقتی کاربر به سیستم وارد شده باشد
- خوشه‌های ادامه تولیدشده توسط کاربر باید منتشر شوند.
- چند نمونه از خوشه‌های ادامه تولیدشده توسط کاربر در زیر آمده است:
- ادامه تماشا از جایی که کاربر متوقف کرده است.
- ادامه خواندن از جایی که کاربر متوقف شده است.
- چند نمونه از خوشه‌های ادامه تولیدشده توسط کاربر در زیر آمده است:
| نوع ادامه | راهبرد تازگی محتوا | رهنمود تازگی محتوا |
|---|---|---|
| خوشه‌های ادامه تولیدشده توسط کاربر | سخت‌گیرانه توصیه می‌کنیم وقتی کاربران از برنامه توسعه‌دهنده خارج می‌شوند، کتابخانه محتوا را به‌روز کنید. |
مهم است که این محتوا با داده‌های نمایش‌داده‌شده در سطوح Google همگام‌سازی شود. دلیل این امر این است که برخلاف توصیه‌های شخصی‌سازی‌شده، کاربر انتظار مجموعه دقیقی از محتوا را دارد. هرگونه تأخیر قابل‌توجه در انتشار باعث سردرگمی کاربران خواهد شد. بنابراین، استراتژی تازگی محتوا باید سخت‌گیرانه باشد. |
وقتی کاربر به سیستم وارد نشده است
سفرهای ادامه در درجه اول برای کاربران واردشده به سیستم درنظر گرفته شده است؛ بااین‌حال، اگر برنامه‌تان از جلسه‌های مهمان پشتیبانی می‌کند، می‌توانید خوشه‌های ادامه را برای کاربران خارج‌شده از سیستم نیز منتشر کنید.
خوشه مدیریت کاربر
هدف اصلی «خوشه مدیریت کاربر» این است که کاربران را به انجام کنش‌های خاصی در برنامه ارائه‌دهنده ترغیب کند. کنش ورود به سیستم کاربران را به صفحه ورود به سیستم برنامه هدایت می‌کند تا برنامه بتواند محتوا منتشر کند (یا محتوای شخصی‌سازی‌شده‌تری ارائه دهد)
کارت ورود به سیستم
| مشخصه | الزام | شرح |
|---|---|---|
| شناسه منبع یکسان کنش | الزامی | پیوند عمیق به کنش (یعنی پیمایش به صفحه ورود به سیستم برنامه) |
| تصویر | اختیاری - اگر ارائه نشود، عنوان باید ارائه شود |
تصویر نشان‌داده‌شده در کارت تصاویر با نسبت ابعادی ۱۶×۹ و وضوح ۱۲۶۴×۷۱۲ |
| عنوان | اختیاری - اگر ارائه نشود، تصویر باید ارائه شود | عنوان روی کارت |
| متن کنش | اختیاری | نوشتار نشان‌داده‌شده در «دعوت به اقدام» (یعنی ورود به سیستم) |
| زیرنویس | اختیاری | زیرنویس اختیاری روی کارت |
کاتلین
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());
پس‌از اینکه کاربران وارد سیستم شدند، توسعه‌دهندگان باید با فراخوانی
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
اگر محتوا به‌دلیل وارد نشدن کاربر به سیستم منتشر نشود، توصیه می‌کنیم «کارت ورود به سیستم» را منتشر کنید. اگر ارائه‌دهندگان به هر دلیلی نتوانند «کارت ورود به سیستم» را منتشر کنند، توصیه می‌کنیم با کد وضعیت NOT_PUBLISHED_REQUIRES_SIGN_IN با میانای برنامه‌سازی کاربردی updatePublishStatus تماس بگیرید
کاتلین
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
برای زمان‌بندی کار تکرارشونده‌ای که هر ۲۴ ساعت خوشه‌ها را منتشر می‌کند استفاده کنید. بااستفاده از خط‌مشی
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);
}
مدیریت هدف‌های همه‌فرستی
علاوه‌بر برقراری تماس‌های میانای برنامه‌سازی کاربردی محتوای انتشار ازطریق کار،
لازم است
BroadcastReceiver راه‌اندازی شود تا
درخواست انتشار محتوا دریافت شود.
بااین‌حال، توسعه‌دهندگان باید مراقب باشند که صرفاً به همه‌فرستی‌ها تکیه نکنند، زیرا آن‌ها فقط در سناریوهای خاصی راه‌اندازی می‌شوند—عمدتاً برای فعال‌سازی مجدد برنامه و اجبار به همگام‌سازی داده‌ها. این رویدادها فقط زمانی راه‌اندازی می‌شوند که «سرویس تعامل» تشخیص دهد محتوا ممکن است قدیمی باشد. به‌این‌ترتیب، اطمینان بیشتری وجود دارد که کاربر تجربه محتوای جدیدی خواهد داشت، حتی اگر برنامه برای مدت طولانی باز نشده باشد.
BroadcastReceiver باید به دو روش زیر راه‌اندازی شود:
- نمونه‌ای از کلاس
BroadcastReceiverرا بااستفاده ازContext.registerReceiver()به‌صورت پویا ثبت کنید. این گزینه ارتباط از برنامه‌هایی را که هنوز در حافظه فعال هستند فعال می‌کند. - پیاده‌سازی را با برچسب
<receiver>در فایلAndroidManifest.xmlبه‌صورت ایستا اعلام کنید. این به برنامه اجازه می‌دهد تا زمانی که درحال اجرا نیست، اهداف پخش را دریافت کند و همچنین به برنامه اجازه می‌دهد تا محتوا را منتشر کند.