जुड़ाव वाले SDK टूल के क्लस्टर पब्लिश करने से जुड़े दिशा-निर्देश

इस गाइड में, क्लस्टर पब्लिश करने के लिए दिशा-निर्देशों का एक सेट शामिल है. Engage SDK टूल के साथ इंटिग्रेट करते समय, डेवलपर इनका इस्तेमाल कर सकते हैं.

सुझाव वाले क्लस्टर

क्लस्टर का टाइटल

हमारा सुझाव है कि क्लस्टर का टाइटल यूनीक और काम का हो. इससे उपयोगकर्ताओं को क्लस्टर के कॉन्टेंट के बारे में ज़्यादा जानकारी मिलती है.

कॉन्टेंट के आधार पर, क्लस्टर के अच्छे टाइटल के कुछ उदाहरण यहां दिए गए हैं:

• शॉपिंग से जुड़े क्लस्टर
  • Lightning Deals
  • हर हफ़्ते खरीदे जाने वाले ज़रूरी प्रॉडक्ट
  • Pixel Buds की खरीदारी से जुड़ी जानकारी
  • महिलाओं के लिए रेन बूट
• स्वास्थ्य से जुड़ी किताबों के क्लस्टर
  • सेहत, तन और मन
  • सेहत से जुड़े आपके लिए सुझाव
  • फ़िटनेस कैटगरी में सबसे ज़्यादा बिकने वाले प्रॉडक्ट

क्लस्टर कॉन्टेंट

सुझावों के क्लस्टर पब्लिश करते समय, डेवलपर को यह देखना होगा कि उपयोगकर्ता ने डेवलपर के ऐप्लिकेशन में साइन इन किया है या नहीं.

जब उपयोगकर्ता ने साइन इन किया हो

अगर उपयोगकर्ता ने डेवलपर के ऐप्लिकेशन में साइन इन किया है, तो हमारा सुझाव है कि आप उपयोगकर्ता के हिसाब से बनाए गए या यूज़र जनरेटेड कॉन्टेंट के क्लस्टर पब्लिश करें. लोगों की दिलचस्पी के हिसाब से बनाया गया कॉन्टेंट और यूज़र जनरेटेड कॉन्टेंट, उपयोगकर्ताओं के लिए ज़्यादा काम का होता है. इसलिए, वे Google के प्लैटफ़ॉर्म से डेवलपर के ऐप्लिकेशन पर जाने के लिए ज़्यादा प्रेरित होते हैं.

• दिलचस्पी के हिसाब से सुझाव पब्लिश किए जा सकते हैं.
  • यहां दिलचस्पी के हिसाब से मिलने वाले सुझावों के कुछ उदाहरण दिए गए हैं:
    • उपयोगकर्ता के वीडियो देखने के इतिहास के आधार पर, सबसे अच्छे सुझाव.
    • उपयोगकर्ता के पढ़ने के इतिहास में मौजूद किताबों से मिलती-जुलती किताबें.
    • उपयोगकर्ता के पसंदीदा कलाकारों के गाने.
• यूज़र जनरेटेड कॉन्टेंट की लाइब्रेरी पब्लिश की जा सकती हैं.
  • यूज़र जनरेटेड कॉन्टेंट की लाइब्रेरी के कुछ उदाहरण यहां दिए गए हैं:
    • डेवलपर के ऐप्लिकेशन से उपयोगकर्ता की वॉचलिस्ट.
    • डेवलपर के ऐप्लिकेशन से, उपयोगकर्ता के पसंदीदा कलाकारों की सूची. यह सूची, उपयोगकर्ता की ओर से दी गई जानकारी के आधार पर तैयार की जाती है.

सुझाव का टाइप	कॉन्टेंट को अप-टू-डेट रखने की रणनीति	कॉन्टेंट को अप-टू-डेट रखने से जुड़ा दिशा-निर्देश
आपके हिसाब से सुझाव	Lenient हमारा सुझाव है कि सुझावों को दिन में एक बार अपडेट करें, ताकि उपयोगकर्ताओं को रोज़ नए सुझाव दिखें.	उपयोगकर्ताओं को यह नहीं पता होता कि उन्हें किस तरह के कॉन्टेंट के सुझाव मिलेंगे. इसलिए, कॉन्टेंट को अपडेट करने की रणनीति में थोड़ी छूट दी जा सकती है.
यूज़र जनरेटेड कॉन्टेंट की लाइब्रेरी	सटीक मिलान अनिवार्य है हमारा सुझाव है कि जब उपयोगकर्ता डेवलपर के ऐप्लिकेशन से बाहर निकलें, तब कॉन्टेंट लाइब्रेरी को अपडेट करें.	यह ज़रूरी है कि यह कॉन्टेंट, Google के प्लैटफ़ॉर्म पर दिखाए जाने वाले डेटा के साथ सिंक हो. ऐसा इसलिए है, क्योंकि उपयोगकर्ता को अपनी पसंद के हिसाब से सुझाव पाने के बजाय, कॉन्टेंट का एक सटीक सेट चाहिए होता है. कॉन्टेंट पब्लिश करने में ज़्यादा देरी होने से, उपयोगकर्ताओं को भ्रम हो सकता है. इसलिए, कॉन्टेंट को अपडेट करने की रणनीति सख्त होनी चाहिए.

जब उपयोगकर्ता ने साइन इन न किया हो

अगर किसी उपयोगकर्ता ने डेवलपर के ऐप्लिकेशन में साइन इन नहीं किया है, तो भी हमारा सुझाव है कि क्लस्टर पब्लिश किए जाएं. इससे उपयोगकर्ताओं को Google के प्लैटफ़ॉर्म से, डेवलपर के ऐप्लिकेशन पर जाने के लिए बढ़ावा मिलता है.

• दिलचस्पी के हिसाब से न दिए जाने वाले सुझावों के क्लस्टर पब्लिश किए जाने चाहिए.
  • यहां ऐसे सुझावों के कुछ उदाहरण दिए गए हैं जो आपकी दिलचस्पी के हिसाब से नहीं दिखाए जाते:
    • इस साल पढ़ी गई टॉप 10 किताबें.
    • नई रिलीज़ हुई फ़िल्में.
    • ट्रेंडिंग पॉडकास्ट.
• साइन-इन कार्ड पब्लिश करना.
  • उपयोगकर्ताओं को डेवलपर के ऐप्लिकेशन में साइन इन करने के लिए बढ़ावा देने के लिए, डेवलपर, लोगों के हिसाब से न दिखाए जाने वाले सुझावों के क्लस्टर के साथ-साथ, साइन-इन कार्ड पब्लिश करने का विकल्प चुन सकते हैं. साइन इन कार्ड पब्लिश करने के तरीके के बारे में ज़्यादा जानने के लिए, यहां दिया गया सेक्शन देखें.

सुझाव का टाइप	कॉन्टेंट को अप-टू-डेट रखने की रणनीति	कॉन्टेंट को अप-टू-डेट रखने से जुड़ा दिशा-निर्देश
लोगों की दिलचस्पी के हिसाब से न दिए जाने वाले सुझाव	Lenient हमारा सुझाव है कि सुझावों को दिन में एक बार अपडेट करें.	उपयोगकर्ताओं को यह नहीं पता होता कि उन्हें किस तरह के कॉन्टेंट के सुझाव मिलेंगे. इसलिए, कॉन्टेंट को अपडेट करने की रणनीति में थोड़ी छूट दी जा सकती है.
सुझावों में साइन-इन कार्ड	सटीक मिलान अनिवार्य है हमारा सुझाव है कि जब उपयोगकर्ता डेवलपर ऐप्लिकेशन से बाहर निकलें, तो साइन-इन कार्ड की स्थिति को अपडेट करें. उपयोगकर्ताओं के साइन इन करने के बाद, डेवलपर को deleteUserManagementCluster() एपीआई को कॉल करके कार्ड को मिटाना होगा.	यह ज़रूरी है कि साइन-इन की स्थिति, Google के प्लैटफ़ॉर्म के साथ सिंक हो. अगर किसी उपयोगकर्ता ने पहले से साइन इन किया हुआ है, तो उसे Google के प्लैटफ़ॉर्म पर साइन-इन कार्ड दिखने से भ्रम हो सकता है. इसलिए, कॉन्टेंट को अप-टू-डेट रखने की रणनीति सख्त होनी चाहिए.

जारी रखने वाले क्लस्टर

कंटिन्यूएशन क्लस्टर पब्लिश करते समय, डेवलपर को यह देखना होगा कि उपयोगकर्ता ने डेवलपर के ऐप्लिकेशन में साइन इन किया है या नहीं.

जब उपयोगकर्ता ने साइन इन किया हो

• यूज़र जनरेटेड कॉन्टेंट वाले कंटिन्यूएशन क्लस्टर पब्लिश किए जाने चाहिए.
  • यहां उपयोगकर्ताओं के बनाए गए कॉन्टेंट के क्लस्टर के कुछ उदाहरण दिए गए हैं:
    • उपयोगकर्ता को वहीं से वीडियो देखने की सुविधा देना जहां उसने पिछली बार छोड़ा था.
    • उपयोगकर्ता ने जहां से पढ़ना छोड़ा था वहीं से पढ़ना जारी रखें.

जारी रखने का टाइप	कॉन्टेंट को अप-टू-डेट रखने की रणनीति	कॉन्टेंट को अप-टू-डेट रखने से जुड़ा दिशा-निर्देश
उपयोगकर्ता के बनाए गए कॉन्टिन्यूएशन क्लस्टर	सटीक मिलान अनिवार्य है हमारा सुझाव है कि जब उपयोगकर्ता डेवलपर के ऐप्लिकेशन से बाहर निकलें, तब कॉन्टेंट लाइब्रेरी को अपडेट करें.	यह ज़रूरी है कि यह कॉन्टेंट, Google के प्लैटफ़ॉर्म पर दिखाए गए डेटा के साथ सिंक हो. ऐसा इसलिए है, क्योंकि उपयोगकर्ता को अपनी पसंद के हिसाब से सुझाव पाने के बजाय, कॉन्टेंट का एक सटीक सेट चाहिए होता है. कॉन्टेंट पब्लिश करने में ज़्यादा देरी होने से, उपयोगकर्ताओं को भ्रम हो सकता है. इसलिए, कॉन्टेंट को अपडेट करने की रणनीति सख्त होनी चाहिए.

जब उपयोगकर्ता ने साइन इन न किया हो

जारी रखने की सुविधा, मुख्य रूप से साइन इन किए हुए उपयोगकर्ताओं के लिए है. हालांकि, अगर आपका ऐप्लिकेशन गेस्ट सेशन की सुविधा देता है, तो साइन आउट किए हुए उपयोगकर्ताओं के लिए भी, जारी रखने की सुविधा वाले क्लस्टर पब्लिश किए जा सकते हैं.

यूज़र मैनेजमेंट क्लस्टर

यूज़र मैनेजमेंट क्लस्टर का मुख्य मकसद, उपयोगकर्ताओं को सेवा देने वाले ऐप्लिकेशन पर कुछ कार्रवाइयां करने के लिए बढ़ावा देना है. साइन इन करने की कार्रवाई, उपयोगकर्ताओं को ऐप्लिकेशन के साइन इन पेज पर ले जाती है, ताकि ऐप्लिकेशन कॉन्टेंट पब्लिश कर सके या ज़्यादा से ज़्यादा लोगों की दिलचस्पी के हिसाब से कॉन्टेंट उपलब्ध करा सके

साइन इन कार्ड

एट्रिब्यूट	ज़रूरी शर्त	ब्यौरा
ऐक्शन यूआरआई	ज़रूरी है	कार्रवाई के लिए डीपलिंक (जैसे, ऐप्लिकेशन के साइन इन पेज पर ले जाता है)
इमेज	ज़रूरी नहीं - अगर यह एट्रिब्यूट नहीं दिया गया है, तो टाइटल एट्रिब्यूट देना ज़रूरी है	कार्ड पर दिखाई गई इमेज 16x9 आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) और 1264x712 रिज़ॉल्यूशन वाली इमेज
शीर्षक	ज़रूरी नहीं - अगर यह एट्रिब्यूट नहीं दिया गया है, तो इमेज एट्रिब्यूट देना ज़रूरी है	कार्ड पर मौजूद टाइटल
ऐक्शन टेक्स्ट	वैकल्पिक	सीटीए पर दिखने वाला टेक्स्ट (जैसे, साइन इन करें)
सबटाइटल	वैकल्पिक	कार्ड पर सबटाइटल (ज़रूरी नहीं)

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

उपयोगकर्ताओं के साइन इन करने के बाद, डेवलपर को deleteUserManagementCluster() एपीआई को कॉल करके कार्ड को मिटाना होगा.

पब्लिश करने की स्थिति अपडेट करना

अगर कारोबार से जुड़ी किसी अंदरूनी वजह से, कोई भी क्लस्टर पब्लिश नहीं किया जाता है, तो हमारा सुझाव है कि आप 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 एपीआई को कॉल करें

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

हमारा सुझाव है कि क्लस्टर पब्लिश करने के लिए, 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);

}

ब्रॉडकास्ट इंटेंट मैनेज करना

किसी जॉब के ज़रिए कॉन्टेंट पब्लिश करने वाले एपीआई को कॉल करने के अलावा, कॉन्टेंट पब्लिश करने का अनुरोध पाने के लिए, BroadcastReceiver सेट अप करना भी ज़रूरी है.

हालांकि, डेवलपर को सिर्फ़ ब्रॉडकास्ट पर निर्भर नहीं रहना चाहिए, क्योंकि ये सिर्फ़ कुछ मामलों में ट्रिगर होते हैं. जैसे, ऐप्लिकेशन को फिर से चालू करने और डेटा को सिंक करने के लिए. ये सिर्फ़ तब ट्रिगर होते हैं, जब Engage सेवा को लगता है कि कॉन्टेंट पुराना हो सकता है. इससे यह भरोसा बढ़ता है कि उपयोगकर्ता को नया कॉन्टेंट देखने को मिलेगा. भले ही, ऐप्लिकेशन को लंबे समय से न खोला गया हो.

BroadcastReceiver को इन दो तरीकों से सेट अप करना ज़रूरी है:

• Context.registerReceiver() का इस्तेमाल करके, BroadcastReceiver क्लास के इंस्टेंस को डाइनैमिक तरीके से रजिस्टर करें. इससे उन ऐप्लिकेशन से बातचीत की जा सकती है जो अब भी मेमोरी में लाइव हैं.
• अपनी AndroidManifest.xml फ़ाइल में, <receiver> टैग के साथ स्टैटिक तौर पर एलान करें कि आपने इस सुविधा को लागू किया है. इससे ऐप्लिकेशन को ब्रॉडकास्ट इंटेंट पाने की अनुमति मिलती है, भले ही वह चालू न हो. साथ ही, ऐप्लिकेशन को कॉन्टेंट पब्लिश करने की अनुमति भी मिलती है.