Apple और Google push notifications के साथ क्या कर रहे हैं

 (jacquescorbytuech.com)
11 पॉइंट द्वारा GN⁺ 6 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पुश notifications अब सिर्फ़ एक डिलीवरी लेयर नहीं रह गए हैं, बल्कि एक platform editorial channel में बदल रहे हैं जहाँ Apple और Google parsing, ranking, summarization और rewriting करते हैं
  • APNs और FCM की शुरुआत battery बचाने के लिए central brokerage structure के रूप में हुई थी, और iPhone·Android के सभी notifications शुरू से ही platform servers से होकर गुज़रते रहे हैं
  • Android channels, iOS Focus·Summary, और Android 13 permission बदलावों ने sender के control को कम किया है और user attention की रक्षा platform द्वारा किए जाने वाली संरचना बनाई है
  • on-device models display layer पर notifications को summarize, group और demote करते हैं, लेकिन sender के पास यह जानने के लिए लगभग कोई API नहीं है कि summary, Focus suppression, या priority downgrade हुआ या नहीं
  • व्यावहारिक रूप से push को निष्क्रिय users को फिर जगाने और समय-संवेदनशील transactional alerts तक सीमित करना चाहिए, और ज़ोर segmentation·personalization तथा in-app जैसी owned surfaces पर ले जाना चाहिए

पुश notifications के platform editorial channel में बदलने की दिशा

  • पुश notifications email जैसी simple delivery layer नहीं हैं, बल्कि ऐसे channel की ओर बढ़ रहे हैं जहाँ Apple और Google बीच में parsing, ranking, summarization और rewriting करते हैं
  • Apple और Google iPhone और Android के मुख्य push paths को संचालित करते हैं, और पिछले 5 वर्षों में device के अंदर के models delivery और lock screen के बीच आकर notifications को summarize, reorder, और कुछ screens पर rewrite कर रहे हैं
  • email में Google, Yahoo, Microsoft, और Apple ये चार operator brand और customer के बीच active intermediary बन चुके हैं, लेकिन push में Apple और Google ये दो operator वही भूमिका निभाते हैं

battery समस्या से शुरू हुई push architecture

  • push को शुरुआत से ही battery समस्या के कारण central brokerage structure के रूप में design किया गया था
  • 2009 WWDC में Scott Forstall ने समझाया था कि अगर install किए गए सभी apps अपने-अपने remote servers को background polling करें तो iPhone इसे संभाल नहीं सकता, और Apple ने यह प्रस्ताव रखा कि हर device Apple के साथ एक persistent TLS connection बनाए रखे, फिर third party उसी connection के ज़रिए notifications भेजे, यानी Apple Push Notification Service
  • APNs की शुरुआती 2008 सितंबर घोषणा के बाद scalability समस्याओं के कारण देरी हुई, और इसे 17 जून 2009 को iPhone OS 3 के साथ जारी किया गया
  • Google ने 2010 में Cloud to Device Messaging, 2012 में Google Cloud Messaging, और 2016 में Firebase Cloud Messaging तक पहुँचने वाला रास्ता अपनाया
  • iPhone पर भेजे जाने वाले सभी notifications Apple servers से होकर जाते हैं, और Android पर भेजे जाने वाले सभी notifications Google servers से होकर जाते हैं
  • platform हमेशा से notifications को limit, delete, log, low-priority treat, या reject कर सकता था; बदला सिर्फ़ इतना है कि Apple और Google अब पहले जितना संयम नहीं दिखा रहे हैं

15 साल में बढ़ता platform हस्तक्षेप

  • शुरुआती consumer push दौर में APNs और Google services सिर्फ़ user द्वारा install किए गए apps तक notifications पहुँचाते थे, और platform-level filtering सीमित थी
  • user control भी ज़्यादातर app-स्तरीय on/off toggle तक ही सीमित था
  • Android का पहला महत्वपूर्ण on-device हस्तक्षेप अगस्त 2017 में Android 8 Oreo के notification channels थे
    • Android 8 से पहले individual notifications पर sender द्वारा तय priority लगती थी, लेकिन उसके बाद developers channel स्तर पर define करते हैं और users channel स्तर पर control करते हैं
    • developers app-प्रति downloads, messages, promotions जैसे channels घोषित करते हैं और हर channel को IMPORTANCE_NONE से IMPORTANCE_HIGH तक importance देते हैं
    • users हर channel के लिए mute, importance कम करना, badge बंद करना, या पूरी तरह block करना सेट कर सकते हैं, बिना दूसरे channels को प्रभावित किए
    • developer द्वारा एक बार सेट की गई channel importance बाद में बढ़ाई नहीं जा सकती, और Android 8 को target करने वाले apps अगर channels declare नहीं करते तो notifications दिखाए ही नहीं जाते
  • Apple ने सितंबर 2021 में iOS 15 के साथ Focus, Scheduled Summary, और 4-स्तरीय interruption taxonomy पेश की
    • ये 4 स्तर passive, active, time-sensitive, और critical हैं, और व्यवहार में developers के लिए उपयोगी स्तर time-sensitive ही था
    • Apple ने स्पष्ट किया कि time-sensitive का इस्तेमाल marketing के लिए नहीं किया जाना चाहिए, और यह नीति अब भी जारी है
  • Android ने अगस्त 2022 में Android 13 के साथ POST_NOTIFICATIONS को runtime permission बना दिया, जिससे implicit opt-in की जगह user की explicit permission ज़रूरी हो गई
    • Pushwoosh के 1.6 करोड़ device sample में game apps ने opt-in base का लगभग एक-तिहाई खो दिया, जबकि news apps में 19% गिरावट आई
    • Batch के 2025 benchmark के अनुसार, 10,000 apps के 80,000 करोड़ से अधिक messages के आधार पर Android opt-in एक साल में 85% से 67% पर आ गया, और cross-platform average 61% पर रुका रहा
  • हर चरण ने sender के control को कम किया और push channel को इस दिशा में फिर से गढ़ा कि recipient का attention एक scarce resource है जिसकी रक्षा platform को करनी चाहिए
  • साफ़ और कम थकाने वाली notification surface platform के retention और ecosystem की रक्षा करती है, deletes कम करती है, और AI features दिखाने का साधन भी बनती है, इसलिए platform editing सिर्फ़ user advocacy भर नहीं है

email ने यह मध्यस्थता पहले झेली

  • email push से पहले intermediary-driven बन चुका था, और push में भी वही प्रवाह एक चरण पीछे चलते हुए दिखाई दे रहा है
  • push, email की तुलना में और भी कमज़ोर channel है
    • email में Postmaster Tools और deliverability dashboards जैसे measurement tools होते हैं, लेकिन push में लगभग कुछ नहीं है
    • email inbox में बना रहता है, इसलिए user scroll, search और revisit कर सकता है, लेकिन notifications notification center में मिट जाते हैं, नीचे खिसक जाते हैं, summarize हो जाते हैं, और भरोसेमंद तरीके से संग्रहित नहीं रहते
  • Gmail ने 2013 में tabbed inbox के साथ वैध mail को Primary, Promotions, Social, और Updates में classify किया था, और Apple Mail ने 2024 में अपनी classification जोड़ी
  • Mail Privacy Protection सितंबर 2021 में iOS 15 में शामिल किया गया, जिससे Apple Mail user ने वास्तव में mail खोला हो या नहीं, इससे अलग Apple-controlled proxy के ज़रिए remote content को पहले ही fetch करने लगा
    • यह तरीका IP address छिपाता है और marketers के भरोसे वाले open pixel mechanism को तोड़ देता है
    • Omeda ने देखा कि Apple के कारण open rate 6 महीनों में 22.6% से 40.5% तक बढ़ा, लेकिन यह reader growth नहीं बल्कि prefetching का असर था
    • पारंपरिक रूप का open rate अब अपरिवर्तनीय रूप से टूट चुका है, और click rate तथा downstream conversions engagement signals की जगह ले रहे हैं
  • Yahoo और Google ने 2024 की शुरुआत से ऐसे senders के लिए, जो personal inboxes में वास्तविक मात्रा में mail भेजते हैं, SPF और DKIM authentication, DMARC alignment, one-click unsubscribe, और low spam complaint rate बनाए रखना अनिवार्य किया
  • email खुले और federated protocol पर चलता है, लेकिन push subscription किसी खास device की किसी खास install, native app, या iOS 16.4 के बाद home screen web app के भीतर मौजूद permission के रूप में रहती है
  • push APNs या FCM token से बँधा होता है, Apple या Google उस token को अपनी मर्ज़ी से invalidate कर सकते हैं, और sender के पास ऐसी कोई list नहीं होती जिसे वह कहीं और ले जा सके
  • web push App Store download के बिना भेजा जा सकता है, जिससे senders का दायरा बढ़ता है, लेकिन वही notification tray और वही on-device editing लागू होने के कारण यह editor से बाहर नहीं निकलता
  • push में भी sender के लिए यह जानना कठिन होता जा रहा है कि उसका notification summarize हुआ, Focus mode के पीछे छिप गया, on-device model द्वारा low-priority कर दिया गया, या किसी quiet folder में डाल दिया गया

डिवाइस-पर एडिटर

  • ईमेल एडिटिंग ज़्यादातर ट्रांज़िट के दौरान होती है, लेकिन push एडिटिंग display layer में होती है
  • notification दिखाना है, summary बनानी है, low priority पर रखना है, या group करना है—यह डिवाइस की display layer में तय होता है
  • मुख्य चीज़ network नहीं बल्कि डिवाइस-पर मॉडल है, और उसके weights तथा signals सार्वजनिक नहीं हैं
  • Apple Intelligence 3 अरब parameters वाले डिवाइस-पर foundation language model और Private Cloud Compute में उपलब्ध बड़े Parallel-Track Mixture-of-Experts server model का उपयोग करता है
    • जुलाई 2025 की technical report में Apple silicon के लिए अनुकूलित KV-cache sharing और 2-bit quantization-aware training पर चर्चा की गई है
    • Apple Intelligence features आम तौर पर base model को सीधे इस्तेमाल करने के बजाय, operating system द्वारा dynamically load किए गए कुछ दर्जन MB आकार के छोटे LoRA-style adapters चलाते हैं, जो summary, entity extraction, sentence polishing और notification prioritization जैसे कामों के लिए विशेषीकृत होते हैं
    • BBC द्वारा यह शिकायत करने के बाद कि summaries गलत headlines बना रही थीं, Apple ने iOS 18.3 में News and Entertainment apps के लिए summaries disable कर दीं, AI summaries को italics में दिखाना शुरू किया, और lock screen पर app-wise off switch तथा error की संभावना की warning जोड़ दी
  • Google का Gemini Nano Android 14 में पेश की गई system service AICore के भीतर चलता है
    • AICore models को system partition में रखता है, privileged apps को weights share करने देता है, हर inference request को isolate करता है, और input-output data को store नहीं करता
    • AICore Android Private Compute Core principles का पालन करता है, जिसमें restricted package binding, direct internet access block, और Google Play System Updates के ज़रिए model updates शामिल हैं
    • Gemini Nano डिवाइस के NPU, GPU और CPU पर automatically route होता है, और Low-Rank Adaptation के ज़रिए Pixel Recorder summaries, notification organization और smart reply जैसी features को base model को retrain किए बिना विशेषीकृत कर सकता है
  • notification-by-notification एडिटिंग flow में app payload बनाता है और उसे APNs या FCM में submit करता है, फिर operating system पहले Focus modes, Do Not Disturb schedules, channel mutings और per-app blocks जैसे user-control rules लागू करता है
  • इसके बाद notifications platform की ranking और display logic में जाती हैं, और अगर iOS की Notification Summaries on हों, तो operating system merged text को summary adapter लगे डिवाइस-पर मॉडल में भेजता है और original title व body को generated sentences से बदल सकता है
  • अगर Priority Notifications on हों, तो iOS 18.4 के बाद default रूप से off स्थिति में भी system learned app-wise ranking लागू कर सकता है, कुछ notifications को pin कर सकता है और बाकी को नीचे कर सकता है
  • जब Reduce Interruptions Focus सक्रिय होता है, तो model यह आकलन करता है कि हर notification user द्वारा customized importance threshold से ऊपर है या नहीं
  • Microsoft Technology Licensing LLC के US 11,340,963, Google LLC के US 11,609,806 और US 8,707,201 यह दिखाते हैं कि learning models के ज़रिए notification rewriting, delivery timing और prioritization को संभालने की दिशा iOS 18 विवाद से बहुत पहले से मौजूद थी

प्रेषक के नियंत्रण के सीमित साधन

  • iOS का UNNotificationServiceExtension app code को display से पहले delivered notifications को थोड़े समय के लिए modify करने देता है, और इसे payload decryption, image fetch करने और text editing के लिए इस्तेमाल किया जा सकता है
  • UNNotificationContentExtension extension view के लिए custom UI define करने देता है
  • दोनों extensions platform के summary या prioritization चरण के बाद नहीं चलते
  • apns-priority header 5 और 10 में से एक मान देता है; 5 non-urgent notifications को power-saving timing पर deliver करता है, जबकि 10 वास्तव में interactive notifications को तुरंत deliver करने के लिए होता है
  • Android में developers NotificationManager में लिखते हैं और channel importance declare करते हैं, लेकिन वे system classification से बाहर नहीं निकल सकते
  • NotificationListenerService एक system-level API है, जिसका उपयोग OEMs और accessibility apps incoming notifications पढ़ने के लिए करते हैं
  • यह पता लगाने के लिए कोई API नहीं है कि notification summarize हुई है, Notification Organiser के Promotions section में गई है, Focus द्वारा suppress की गई है, या Priority Notifications द्वारा quietly low priority कर दी गई है

wearables फोन notification stream का subset हैं

  • Apple Watch default रूप से iPhone notifications को mirror करती है, लेकिन iPhone के Focus और Summary state का पालन करती है
  • watchOS 11 से Smart Stack location, time और calendar जैसे डिवाइस-पर signals का उपयोग करके relevant widgets दिखाता है
  • Wear OS default रूप से phone notifications को paired watch तक bridge करता है, और अगर companion watch app installed हो, तो duplicate रोकने के लिए BridgingConfig, setBridgeTag, setDismissalId जैसे developer controls देता है
  • low priority notifications की watch delivery को suppress किया जा सकता है, लेकिन जिन notifications को user ने phone पर mute किया है उन्हें watch पर force-deliver नहीं किया जा सकता
  • wearables फोन notification stream का सख्त subset हैं, जो upstream में वही platform editing पाते हैं और downstream में bridging behavior तथा watch-side complication जैसे अतिरिक्त filters से गुजरते हैं

उपयोगकर्ता वास्तव में notifications को कैसे संभालते हैं

  • ज़्यादातर notifications तुरंत app switch नहीं कराते, बल्कि cognitive signal की तरह काम करते हैं जिन्हें उपयोगकर्ता नोटिस करके अपना चल रहा काम जारी रखते हैं
  • Sahami Shirazi, Henze, Dingler, Pielot, Weber, Schmidt के CHI 2014 अध्ययन “Large-Scale Assessment of Mobile Notifications” ने Android launcher instrumentation के ज़रिए 40,000 से अधिक उपयोगकर्ताओं से लगभग 20 करोड़ notifications एकत्र किए
    • messaging notifications को लगातार सबसे अधिक मूल्यवान और promotional notifications को लगातार सबसे कम मूल्यवान माना गया
    • यह इस बात का प्रायोगिक आधार बना कि लोगों से आए संदेशों और brands से आए संदेशों को अलग surfaces पर संभालना चाहिए
  • Pielot, Church, de Oliveira के MobileHCI 2014 अध्ययन “An In-Situ Study of Mobile Phone Notifications” ने पाया कि उपयोगकर्ताओं को औसतन प्रतिदिन 63.5 notifications मिलते हैं, जिनमें अधिकांश messenger और email से आते हैं, और फोन silent होने पर भी वे कुछ ही मिनटों में उन पर ध्यान देते हैं
  • Okoshi आदि द्वारा बनाया गया Attelia एक middleware था जो उपयोगकर्ता के फोन activity में रुकावट के बिंदु पहचानकर तब तक notifications रोकता था, और controlled study में cognitive load को 46%, तथा वास्तविक वातावरण में 33% तक कम किया
  • इसके बाद Yahoo! Japan app के भीतर बड़े पैमाने पर deployment में केवल send timing समायोजित करने से click-through rate अधिकतम 60.7% तक बढ़ा
  • Localytics ने बताया कि push notifications बंद करने वाले 52% उपयोगकर्ता अंततः app को पूरी तरह छोड़ देते हैं, अधिकांश apps में प्रति सप्ताह 2~5 notifications इष्टतम सीमा है, और segmented audiences ने broad sends की तुलना में लगभग दोगुनी open rate दिखाई
  • CleverTap में शामिल Leanplum ने बताया कि personalized notifications की open rate सामान्य broad sends की तुलना में लगभग 800% अधिक है, और खुले हुए push notifications में से 90% 1 घंटे के भीतर किसी action तक ले जाते हैं
  • CleverTap की 2025 fintech report में segmented campaigns की औसत open rate 16.3% और non-targeted campaigns की 4.7% बताई गई है
  • vendor की अपनी reported numbers को कुछ छूट के साथ देखना चाहिए, लेकिन दिशा लगातार एक जैसी है
    • send volume permissions को खत्म कर देता है, और relevance ही नियंत्रण में रहने वाला एकमात्र स्थिर lever है
    • send timing भी महत्वपूर्ण है, लेकिन relevance से कम महत्वपूर्ण
    • जो चीज़ promotional लगती है, उसे आम तौर पर promotion ही वर्गीकृत किया जाता है, और अक्सर यह आकलन सही होता है
    • उपयोगकर्ता promotional notifications की तुलना में transactional और conversational notifications को कहीं अधिक आवृत्ति पर सहन करते हैं
  • platform editing broad sends और promotional push पर सबसे अधिक सख़्ती से काम करती है, जबकि वे notifications जिन्हें उपयोगकर्ता वास्तव में चाहते हैं, वे या तो वैसे ही पार हो जाते हैं या और अधिक प्रमुखता पाते हैं
  • Live Activities सबसे स्पष्ट bypass route है
    • ActivityKit sessions notification tray से अलग surface, यानी lock screen और Dynamic Island, पर render होते हैं, इसलिए summarizer और grouping उन्हें नहीं छूते
    • Android के Live Updates और ongoing notifications भी यही भूमिका निभाते हैं
    • ride-hailing, delivery, sports, timers जैसी वास्तव में चल रही transactional content के लिए यह platform editor से बचने का सबसे साफ़ रास्ता है
    • इन्हें केवल वास्तविक ongoing events के लिए ही इस्तेमाल किया जा सकता है; promotion को Live Activity की तरह पैक नहीं किया जा सकता
  • Dekker, Baumgartner, Sumter, Ohme के 2024 Media Psychology अध्ययन “Beyond the Buzz” ने 1 सप्ताह के randomized experiment में बताया कि notifications बंद करने से phone-checking frequency या screen time कम नहीं हुआ, क्योंकि उपयोगकर्ताओं ने सीधे apps में जाकर compensatory behavior दिखाया

marketer क्या देख सकते हैं

  • marketer की visibility जानबूझकर कम रखी गई है, और यह और भी खराब हो रही है
  • measurement metrics विश्वसनीयता के उच्च से निम्न क्रम में send, platform acceptance, device delivery, device display, open, और attributed conversion तक जाते हैं
  • APNs और FCM server submit पर response codes देते हैं, इसलिए platform acceptance भरोसेमंद रूप से दिखाई देता है, लेकिन APNs SMTP जैसी delivery confirmation नहीं देता; केवल इतना पता चलता है कि Apple ने payload स्वीकार कर queue में डाल दिया
  • FCM message ID और कुछ मामलों में delivery callbacks देता है, लेकिन “device तक deliver हुआ” और “उपयोगकर्ता को दिखाया गया” के बीच की सीमा अब भी अस्पष्ट है
  • iOS offline स्थिति में app-विशिष्ट केवल सबसे हालिया notifications ही store करता है, इसलिए पुराने notifications उपयोगकर्ता तक पहुँचने से पहले चुपचाप हटाए जा सकते हैं
  • Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io, Batch जैसे lifecycle platforms app SDK-आधारित measurement जोड़ते हैं
    • SDK notification display, user tap, और tap से session शुरू हुआ या नहीं, यह record करता है
    • granularity इस पर निर्भर करती है कि iOS पर NotificationServiceExtension या Android पर उसके समकक्ष broadcast receiver घोषित है या नहीं
    • extension न होने पर “delivered” फिर से “APNs/FCM accepted” तक सिमट जाता है, जिससे उपयोगकर्ता ने वास्तव में जो देखा उससे अधिक दिखाई देने वाली delivery rate फूल जाती है
  • OneSignal की अपनी guide के अनुसार click rate परंपरागत रूप से taps की संख्या को deliveries से विभाजित करके निकाली जाती है, और delivery का अर्थ आमतौर पर “FCM या APNs से होकर गुज़रा” होता है
    • इस पद्धति में वे notifications भी शामिल होते हैं जो दिखाए ही नहीं गए, बिना पढ़े swipe कर दिए गए, चुपचाप dismiss कर दिए गए, या Focus और Reduce Interruptions filters के पीछे छिपे रहे
    • कुछ platforms में “confirmed delivery” ज़्यादा वास्तविकता के करीब होती है क्योंकि SDK render देखी गई notification को गिनता है, लेकिन यह फिर भी नहीं बता सकती कि dismiss होने से पहले render हुई notification उपयोगकर्ता ने वास्तव में देखी या नहीं
  • AppsFlyer, Adjust, Branch, Singular, Kochava जैसे mobile measurement partners payload में tracking links डालते हैं और बाद के SDK events से match करके downstream sessions को किसी खास push campaign से attribute करते हैं
  • Amplitude, Mixpanel, Heap, PostHog जैसे in-app analytics tools downstream sessions तो देखते हैं, लेकिन अपने बल पर upstream notifications नहीं देख पाते
  • अगर push platform के send और open events को shared user identifier के साथ analytics tools में भेजा जाए, तो notification, session, और conversion को जोड़ा जा सकता है, लेकिन funnel के बीच का हिस्सा—जैसे “delivered notifications कितनी बार दिखाए गए, summarize हुए, demote हुए, Focus द्वारा suppress हुए, या unacknowledged रहे”—वापस नहीं पाया जा सकता
  • platform कई ऐसे signals देता ही नहीं है
    • iOS में notification Notification Summary में bundled हुई या नहीं
    • Pixel पर वह Notification Organiser के Promotions section में गई या नहीं
    • Reduce Interruptions ने उसे silent बनाया या नहीं
    • Priority Notifications ने उसे demote किया या नहीं
    • iOS पर उपयोगकर्ता ने lock screen से उसे पढ़े बिना swipe किया या नहीं
    • उपयोगकर्ता notification suppress करने वाले Focus mode में था या नहीं
    • iOS storage limits के कारण display से पहले delete हुई या नहीं
    • Samsung One UI 8.5 ने उसे summarize किया या नहीं
  • एक जगह जहाँ push email से बेहतर है, वह है Android का delete-intent
    • जब उपयोगकर्ता दिखाई गई notification को swipe करके हटाता है, तो event trigger होता है, जिससे intentional dismissal record की जा सकती है
    • यह केवल Android पर है, केवल displayed notifications पर trigger होता है, और सोच-समझकर किए गए swipe तथा clear-all के बीच फ़र्क नहीं कर सकता
  • 2026 में push measurement, Mail Privacy Protection के बाद email measurement की तरह, invisible editing layers के नीचे मौजूद metrics को केवल वास्तव में action लेने वाले उपयोगकर्ताओं के conversion data से calibrate करने वाला रूप ले लेगा

पाइप के अंदर के मॉडल के लिए लिखने का तरीका

  • पूरा भेजा गया संदेश अब पहले की तरह जस का तस नहीं बचता
  • on-device summarizer नोटिफिकेशन को सार में संक्षिप्त कर देता है, इसलिए जो पहुँचता है वह brand tone नहीं बल्कि ठोस तथ्य होते हैं
  • राशि, नाम, समय, कार्रवाई जैसे मुख्य payload को शुरुआत में रखने से summarizer के पास संरक्षित रखने योग्य सामग्री रहती है
  • अगर brand-style भूमिका, विस्मयादिबोधक, emoji, या शब्दों के खेल के पीछे मुख्य बात छिपा दी जाए, तो summarizer केवल emoji छोड़ सकता है और अर्थ हटा सकता है, या गलत आधी जानकारी बचा सकता है
  • शीर्षक को प्राकृतिक भाषा में लिखे गए structured data field की तरह संभालना चाहिए
    • “Your delivery is 15 minutes away” सारांश में स्थिर रहता है
    • “We've got great news!” में कोई तथ्य नहीं होता, इसलिए यह स्थिर नहीं है
    • यह जाँचना कि शीर्षक के शुरुआती कुछ शब्द ही बचे रहें तब भी क्या वे उपयोगकर्ता को उपयोगी जानकारी देते हैं, एक मोटा self-check हो सकता है
    • इसे गारंटी नहीं, बल्कि एक आदत की तरह देखना चाहिए
  • यही सिद्धांत Live Activities और Live Updates पर भी लागू होते हैं, और मुख्य प्रस्ताव brand packaging नहीं बल्कि ETA, score, step count जैसे field होते हैं
  • time-sensitive interruption level का दुरुपयोग नहीं करना चाहिए, इसका आधार Batch की developer guide में साफ़ लिखा है
    • “If your time-sensitive notifications are not often interacted with, iOS will prompt your users from the lock screen to let them disable time-sensitive alerts for your app”
    • उपयोगकर्ता lock screen से एक टैप में app-specific time-sensitive notifications बंद कर सकते हैं, और sender के पास इसके बराबर की कोई अपील प्रक्रिया नहीं होती

स्वामित्व वाले surface की ओर केंद्र का स्थानांतरण

  • lifecycle program में push को अब छोटी भूमिका निभानी चाहिए
  • app के भीतर स्वामित्व वाले surface को कम intrusive से अधिक intrusive क्रम में बाँटा जा सकता है
    • feed के अंदर passive in-product card, जहाँ उपयोगकर्ता जानबूझकर पहुँचता है
    • स्थायी in-app message center या inbox, जहाँ उपयोगकर्ता बाद में फिर लौट सकता है
    • session event पर आधारित targeted in-app message, जो केवल active session के दौरान दिखता है
    • product flow के भीतर embedded messaging element, जिन्हें उन screens पर रखा जाता है जहाँ उपयोगकर्ता पहले से कोई काम पूरा करने आया होता है
  • ये owned surface APNs या FCM से नहीं गुजरते, और Apple Intelligence या Gemini Nano इन्हें छूते नहीं हैं
  • बिना summary या Focus suppression के, SDK rendering, dismissal, और interaction events को रिकॉर्ड करता है, इसलिए platform-mediated gap के बिना observability मिलती है
  • सीमा यह है कि owned surface केवल active users तक ही पहुँचते हैं
    • जिसने 14 दिनों तक app नहीं खोला, उसे in-app message से नहीं बल्कि केवल push से पहुँचा जा सकता है
    • push, dormant users की re-engagement और active users के लिए transactional व time-sensitive alerts का channel बनता है
    • cross-sell, upsell, content discovery, education, और value-add का काम in-product surface करते हैं
  • Batch के 2025 data में promotional code campaign के लिए in-app message click-through rate Android पर 16.1% और iOS पर 17.9% था, जो push CTR से अधिक था
  • उसी data में, क्योंकि in-app के लिए session चाहिए, इसलिए उसका reachable audience push से छोटा होता है
  • push का काम उपयोगकर्ता को फिर से product में लाना है, और उसके अंदर आने के बाद owned surface आगे की भूमिका संभालते हैं

अगला बदलाव: नोटिफिकेशन को संभालने वाले agent

  • on-device language model एक बार शामिल हो जाने पर summary से आगे कई कामों में इस्तेमाल होते हैं
  • Apple का Foundation Models framework iOS 18.4 से developers को वही model इस्तेमाल करने देता है जिन्हें operating system summary, entity extraction, text understanding, refinement, और छोटे conversation के लिए उपयोग करता है
  • Google के ML Kit GenAI APIs AICore के ऊपर summary, correction, rewriting, और image description उपलब्ध कराते हैं
  • अगला चरण यह है कि model नोटिफिकेशन पर प्रतिक्रिया देकर उपयोगकर्ता की ओर से कार्रवाई करें
    • संभावित कार्रवाई में app खोलना, booking पूरी करना, notification dismiss करना, reply draft लिखना आदि शामिल हैं
    • अधिक भारी reasoning केवल device के अंदर चलने के बजाय Apple Private Cloud Compute या Google cloud model जैसे server-side पर चलने की अधिक संभावना है
  • Apple का App Intents framework developers को Siri और Apple Intelligence के सामने typed app actions expose करने देता है
  • Android में App Actions और Gemini, third-party app के भीतर कार्रवाई करने की उभरती क्षमता के रूप में समान भूमिका निभाते हैं
  • sender को केवल ऐसे notification लिखने तक सीमित नहीं रहना चाहिए जिन्हें summarizer खराब न करे, बल्कि notification के पीछे की action भी expose करनी चाहिए ताकि agent उपयोगकर्ता के app खोले बिना भी booking पूरी कर सके या alert हटा सके
  • notification अब destination नहीं, बल्कि agent द्वारा consume किया जाने वाला trigger बन जाता है, और click-through rate metric, जो 10 साल से push measurement का केंद्र था, अपना बहुत सा अर्थ खो देगा

push notifications को संभालने के व्यावहारिक सिद्धांत

  • push का इस्तेमाल सिर्फ वहीं करें जहाँ दूसरे channels काम नहीं करते

    • push ऐसा channel है जो उन users तक भी पहुँच सकता है जिन्होंने कई हफ्तों से app नहीं खोला है, इसलिए यह निष्क्रिय users को फिर से सक्रिय करने और वास्तव में समय-संवेदनशील transactional alerts के लिए सबसे उपयुक्त है
    • cross-sell, up-sell, education और discovery उद्देश्य वाले alerts भी तब संभव हैं जब उनमें पर्याप्त timeliness और personalization हो, लेकिन मूल रूप से वे promotional माने जाते हैं और user के interruption budget के लिए सबसे प्रतिकूल प्रतिस्पर्धा में उतरते हैं
    • promotional messages, user द्वारा जानबूझकर खोली गई स्क्रीन पर अधिक प्रभावी होते हैं और उनका जोखिम भी कम होता है

  • design का केंद्र user की activity और request हो

    • जिन alerts के platform की बीच की editorial filtering से गुजरने की संभावना अधिक होती है, वे हैं user द्वारा सीधे सेट किए गए signals और product द्वारा user की state से generated events
    • price drop, restock, wishlist, threshold trigger और जिस item का user इंतज़ार कर रहा है उसकी status notification, user द्वारा सीधे सेट किए गए signals हैं
    • shared documents, काम पर आए comments या replies, completed tasks, exceeded limits और चल रहे task के next step, product द्वारा user की state से generated events हैं
    • दोनों ही प्रकार की notifications recipient की “अपनी चीज़” के बारे में होती हैं, इसलिए वे relevance के मानदंड को स्वाभाविक रूप से पार कर जाती हैं, और उन्हें product के भीतर ऐसी जगह पर deep link करना चाहिए जहाँ user तुरंत action ले सके

  • permission request first launch पर नहीं, context के भीतर करें

    • Android 13 ने notification permission को explicit runtime approval में बदलने के बाद opt-in rate में बड़ी गिरावट आई
    • first launch के तुरंत बाद system prompt दिखाने के बजाय, पहले उस feature से जुड़ी value दिखानी चाहिए जिसके लिए user notifications पाना चाहेगा, फिर request करनी चाहिए
    • notification permission पूरे channel पर लागू होती है, इसलिए इसे ठंडी पहली request पर बर्बाद नहीं करना चाहिए

  • segmentation और personalization default होने चाहिए

    • vendor data दिशासूचक material है, लेकिन 10 साल से वही निष्कर्ष दिखा रहा है, और segmented·personalized notifications का open rate broadcast की तुलना में लगभग दोगुना होता है
    • generic bulk sending का performance कम होता है, और यह ऐसी permission खर्च करती है जिसे वापस नहीं लाया जा सकता
    • अगर कोई message किसी खास वजह से किसी खास व्यक्ति को नहीं भेजा जा सकता, तो बेहतर है कि उसे सबको भी न भेजा जाए

  • जो interruption right हासिल नहीं हुआ, उसका इस्तेमाल न करें

    • marketing messages को time-sensitive alerts की तरह सजाकर नहीं भेजना चाहिए
    • iOS में user lock screen पर app-वार time-sensitive alerts बंद कर सकता है, और sender इसके खिलाफ कोई आपत्ति नहीं कर सकता
    • sending volume बढ़ाना permission को खत्म करता है; sender के पास बचा रहने वाला एकमात्र lever relevance है

  • engagement ही deliverability तय करती है

    • platform ranking यह सीखती है कि user notifications पर action लेता है या नहीं, इसलिए ऐसा बड़ा recipient base जो tap नहीं करता, model को app का कम मूल्यांकन करना सिखाता है और user को notifications बंद करने की ओर धकेलता है
    • push में email के sender reputation system जितनी व्यवस्थित व्यवस्था नहीं है और इसका प्रभाव app·OS के हिसाब से अलग हो सकता है, लेकिन दिशा वही है
    • निष्क्रिय subscriptions को साफ करना चाहिए; अनदेखा किए जाने वाले बड़े base की तुलना में engaged छोटा base अधिक व्यापक reach बनाए रखता है

  • style से पहले facts रखें

    • title की शुरुआत में brand tone वाले intro के बजाय specific payload होना चाहिए: राशि, नाम, समय और action जैसी जानकारी पहले आनी चाहिए
    • summarizers बात को मुख्य बिंदु तक संक्षेपित करते हैं और machine-readable content को बचाकर रखते हैं, इसलिए fact-centered titles, tone-centered titles की तुलना में rewrite होने के बाद भी ज़्यादा टिकते हैं
    • यह कोई measured rule नहीं, बल्कि एक reasonable default है; कोई public test नहीं है और evidence भी indirect है

  • push dashboard पर आँख बंद करके भरोसा न करें

    • opens और clicks, एक अदृश्य editorial layer के पीछे होते हैं, और measurable conversions उन notifications का biased sample होते हैं जिन्हें platform ने पहले से तरजीह देने का फैसला किया है
    • downstream conversion सबसे कम खराब signal है, लेकिन push conversion events दुर्लभ होते हैं, इसलिए सामान्य sending volume पर campaign-वार statistical significance तक पहुँचना कठिन होता है
    • अगर SDK के ज़रिए rendering verify की जा सकती है, तो करें; campaigns को समूहित करें, observation window बढ़ाएँ, फिर numbers पर भरोसा करें
    • engagement में बढ़ोतरी को सिर्फ “copy बेहतर हुई” नहीं, बल्कि “platform मुझ पर ज़्यादा भरोसा करता है” के रूप में भी पढ़ा जा सकता है

  • weight को owned surfaces की ओर shift करें

    • in-app inbox, logged-in product screens, physical mail और सीधे संचालित loyalty surfaces में pipeline के भीतर कोई model नहीं होता
    • इन surfaces पर summarization, ranking या silent treatment नहीं होता, और इन्हें end-to-end मापा जा सकता है
    • push और owned surfaces को प्रतिस्पर्धी channels की तरह नहीं, बल्कि एक ही portfolio की तरह चलाना चाहिए

  • lock screen नहीं, agents के लिए design करें

    • जब Siri और Gemini notifications पर कार्रवाई करना शुरू करेंगे, तो agent जिस चीज़ को execute कर सकेगा वह साफ, machine-readable proposal होगी
    • notification के पीछे का action UI में तीन taps के पीछे छिपा नहीं होना चाहिए, बल्कि iOS के App Intents या Android के App Actions के माध्यम से callable रूप में exposed होना चाहिए
    • message को इस तरह लिखना चाहिए कि model उसे इंसान के पढ़े बिना भी execute कर सके

निष्कर्ष

  • push कभी email जैसा पूरी तरह owned channel नहीं था; यह social की तुलना में कम rented channel के अधिक करीब था
  • platform हर release के साथ rental terms को अपने पक्ष में फिर से तय कर रहे हैं
  • अगले 10 साल तक टिकने वाला sender वह नहीं होगा जो सबसे ज़्यादा भेजता है या सबसे चालाकी से इस्तेमाल करता है, बल्कि वह होगा जो ऐसे messages भेजता है जिन्हें platform के editors इसलिए defend कर सकें क्योंकि recipient उन्हें वैसे भी चाहता था
  • सबसे अच्छा काम उस पक्ष के पास रहेगा जिसने पहले से ही अपना वजन उन surfaces पर शिफ्ट कर दिया है जहाँ कोई editor सामने खड़ा नहीं है
  • अदृश्य models के लिए लिखें, और उन channels के लिए बनाएं जहाँ वे models पहुँच नहीं सकते

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 일 전
Hacker News की राय

  • अगर मेरा फ़ोन मुझे बाधित करे, तो उसका मतलब यही होना चाहिए कि अभी किसी को सच में मेरा ध्यान चाहिए; नहीं तो उसे मुझे बिल्कुल बाधित नहीं करना चाहिए। मेरी notification settings में calls, messages, WhatsApp, Apple Health, banking apps जैसी चीज़ों को ही push notifications की अनुमति है
    इसके अलावा किसी app के पास मुझे तुरंत बुलाने की कोई वजह नहीं है। ज़्यादातर apps notification इसलिए भेजते हैं क्योंकि कुछ महत्वपूर्ण हुआ है ऐसा नहीं, बल्कि क्योंकि उन्हें मेरा ध्यान चाहिए
    streaks, discounts, recommendations, delivery updates जैसी notifications की ज़रूरत नहीं है; वे तब तक इंतज़ार कर सकती हैं जब तक मैं खुद app खोलने का फैसला न करूँ

    • यह लेख काफ़ी खुलकर भेजने वाले के नज़रिए से लिखा गया है, और इसे इस बात की चिंता है कि platform “sender control” अपने हाथ में ले रहे हैं
      लेकिन ज़्यादातर apps पहले ही यह साबित कर चुके हैं कि वे users के attention का सम्मान नहीं कर सकते। बेकार notifications और मेरे फ़ोन के बीच platform जितनी ज़्यादा रुकावटें डालें, उतना बेहतर है। मैं Apple या Google को हीरो नहीं मानता, लेकिन वे कम-से-कम उस marketing department से तो बेहतर मेरी तरफ़ हैं, जो किसी ticket के साथ ज़बरदस्ती install कराई गई app में बैठी है
    • सबसे बड़ी समस्या वे apps हैं जो दोनों काम करती हैं। उदाहरण के लिए, मैं चाहता हूँ कि Uber बताए जब driver पहुँच जाए, लेकिन अगली 5 rides पर 10% discount जैसे संदेश नहीं चाहिए
      ज़रूरी notifications और विज्ञापन notifications को अलग-अलग block करना आसान नहीं है
    • यह बात याद आती है: “marketing ने ऐसा कोई communication system नहीं देखा जिसे वह अपने क़ब्ज़े में न लेना चाहे”
      जब भी मैं किसी ग्राहक को commercial app में WhatsApp support जोड़ना चाहते देखता हूँ ताकि वे “customers से communicate” कर सकें, यही सोचता हूँ
      साथ ही, हर user के लिए notifications चाहने वाले app के हिस्से अलग होते हैं। shift workers को assigned shifts या अचानक खुली shifts के बारे में पता होना चाहिए, और जो एक user के लिए सच में महत्वपूर्ण है, वही दूसरे के लिए spam हो सकता है
      उपयोगी notifications आसानी से marketing notifications में बदल जाती हैं। मैं यह जानना चाहता हूँ कि delivery driver बाहर खड़ा है, लेकिन इस हफ़्ते के special offers नहीं जानना चाहता
      यह ऐसा मसला नहीं है जिसे तकनीकी तौर पर पूरी तरह हल किया जा सके। बुरे actor सच में बुरा व्यवहार करते हैं। फिर भी system ऐसा होना चाहिए कि अच्छे apps ठीक से काम कर सकें, और आख़िर में user ही तय करे कि उसे क्या देखना है — Google या Apple नहीं
      अगर समाज को सबसे निचले common denominator पर बनाया जाएगा, तो वह सबके लिए खराब होगा। बुरे व्यवहार को punish कर सकना चाहिए और अच्छे व्यवहार को actively encourage करना चाहिए; सिर्फ़ “यह बुरा हो सकता है” कहकर सब कुछ ban नहीं कर देना चाहिए
    • यहाँ “push notifications” और “push notifications से बाधित होना” दोनों को एक ही चीज़ मान लिया गया है। मेरे फ़ोन में कई ऐसे apps हैं जो महत्वपूर्ण हैं लेकिन urgent नहीं, और उन्हें iOS Notification Center में silently add होने के लिए सेट किया हुआ है
      इस तरह सेट किए गए apps की notification आने पर banner नहीं दिखता और वह lock screen पर भी नहीं आती। वे तभी दिखती हैं जब मैं खुद नीचे scroll करके समय-संवेदी lock-screen alerts के बाद सभी notifications देखता हूँ
      असल में यह “email inbox” जैसा बन जाता है — चाहो तो देखो, नहीं तो छोड़ दो। email से अलग, notifications app workflow का अनिवार्य हिस्सा नहीं बन सकतीं, इसलिए notification inbox को कभी भी बिना झिझक खाली किया जा सकता है
    • Apple और Google पिछले 10 सालों में push notifications को वाकई उपयोगी बनाने में नाकाम रहे हैं। महत्वपूर्ण notifications पूरी तरह असंबंधित कचरा notifications के समुद्र में दब जाती हैं
      यह एक बहुत ही आदिम ढाँचा है जिसमें कई apps बहुत छोटी screen space के लिए लड़ती हैं, और ज़्यादातर push notifications “कुछ हुआ!” से ज़्यादा कुछ नहीं बतातीं। इनमें actionable information भी कम होती है और असल में क्या हुआ यह भी अस्पष्ट रहता है
      नतीजा यह हुआ कि notification के पूरे विचार की value कम हो गई, और कभी-कभी कुछ दिलचस्प निकल भी जाए तो वह छूट जाता है या बाद में ढूँढना मुश्किल हो जाता है
      push notification user experience बहुत खराब है, और app developers ने users को मनमाने ढंग से बाधित करने की अपनी superpower का दुरुपयोग किया है, जिससे समय के साथ यह और बदतर हुआ है। Apple और Google ने इसे काबू करने की कोशिश की, लेकिन जो बचा है वह कुछ गिने-चुने वैध उपयोगों के लिए भी बस औसत दर्जे का है
      bank approvals, 2FA जैसी चीज़ें app में deep links के रूप में उपयोगी हैं, लेकिन उसके अलावा वे आम तौर पर इतना महत्वपूर्ण नहीं कि मैं अपना काम रोककर फ़ोन देखूँ
      मेरे Android फ़ोन पर सबसे ज़्यादा इस्तेमाल होने वाले apps Firefox, Gmail और कुछ ही दूसरे हैं। notification channel के रूप में email inbox mobile push से कहीं ज़्यादा उपयोगी है। यह ज़्यादा actionable है, ज़्यादा जानकारी देता है, और individual unsubscribe, filtering और दोबारा search करना भी आसान है। ज़्यादातर apps दोनों कर सकती हैं, इसलिए push notifications inferior और duplicate हैं

  • यह लेख ऐसे पढ़ा जाता है जैसे लेखक Apple और Google के कुछ खास तरह की notifications, यानी spam notifications, को रोकने या नियंत्रित करने पर नाराज़ हो
    “cross-sell, upsell, education, discovery भी push पर काम कर सकते हैं,” लेकिन push notifications सिर्फ़ transactional notifications के लिए होनी चाहिए। मुझे junk के लिए एक और inbox नहीं चाहिए

    • hospital appointment app की reminders की वजह से मैं उसकी notifications चालू रखना चाहता हूँ। लेकिन हाल में उसने उसी channel से marketing messages भेजना शुरू कर दिया है
      शायद सिर्फ़ marketing messages बंद करने का कोई तरीका हो, लेकिन ज़्यादातर लोगों को यह पता नहीं होगा और वे इसे बदलेंगे भी नहीं। यह सच में चिढ़ाने वाला है
    • काश Apple app developers को promotional notifications और transactional notifications को अलग-अलग notification channels में implement करने के लिए मजबूर करता। तब users अपनी पसंद की चीज़ें चुन पाते
    • शीर्षक में “your push notifications” का “your” user नहीं बल्कि marketer है। सिर्फ़ यही बात इस लेख की अहमियत समझाने के लिए काफ़ी है
    • नाराज़गी नहीं है, चिंता इस बात की है कि हर channel धीरे-धीरे Big Tech की मध्यस्थता से होकर गुजरने लगा है
    • यह स्थिति पर निर्भर करता है। BlackBerry 10 Hub, iOS या Android की ढीली-ढाली notification व्यवस्था की तरह नहीं, बल्कि एक shared inbox के रूप में मज़बूती से डिज़ाइन किया गया था, और वह वाकई बहुत अच्छा था

  • Uber, Bolt, Airbnb जैसी services परेशान करती हैं। core service के लिए push चाहिए, लेकिन provider उसी मौके का इस्तेमाल करके spam घुसेड़ देता है

    • Uber ख़ास तौर पर बहुत बुरा है। मैं गाँव में रहता हूँ इसलिए सामान्य दिनों में इसे इस्तेमाल नहीं करता, लेकिन यात्रा के समय Uber या कभी-कभी Uber Eats का इस्तेमाल करता हूँ
      अब marketing junk इतना intrusive हो गया है कि मैं app सिर्फ़ तब install करता हूँ जब सच में ज़रूरत लगे, वरना हटा देता हूँ। burger delivery अच्छी है, लेकिन यह बात और भी खलती है कि service हमारे घर तक जो ला सकती है, वह सचमुच कुछ भी नहीं है
    • Apple और Google ने services को notifications का दुरुपयोग करने दिया, जिससे notifications लगभग बेकार हो गई हैं। काश वे मेरे समय और ध्यान का ज़्यादा सम्मान करते

  • लोग उन चीज़ों के प्रति बहुत ज़्यादा निष्क्रिय हैं जो उनका ध्यान चुरा लेती हैं, यह बात हमेशा चौंकाती है
    मेरा फ़ोन 24x7 Do Not Disturb mode में रहता है। अगर कोई ऐप बेकार की चीज़ें notify करे तो मैं उसे delete कर देता हूँ और website इस्तेमाल करता हूँ
    मेरे पास एक mail rule भी है जो inbox से “unsubscribe” शब्द वाले emails को निकालकर अलग tag वाले section में भेज देता है। हर कुछ दिनों में वहाँ जाकर पहुँची हुई सभी चीज़ों को unsubscribe कर देता हूँ
    अगर किसी retail store के checkout पर personal info या phone number माँगा जाए, या किसी club में जुड़ने को कहा जाए, तो मैं पूछता हूँ कि क्या उसके बदले discount मिलेगा। अगर discount नहीं, तो info भी नहीं। अगर मेरी info के लिए उसका उचित मूल्य दिया जाए तो सोच सकता हूँ, लेकिन अब तक किसी भी retailer ने मेरे समय और info की कीमत के बराबर कुछ नहीं दिया

    • जब retail store में phone number माँगा जाता है, तो वह शुरू से ही विचार करने लायक नहीं लगता। वे एक बार discount देकर सालों तक info रखकर उसका दुरुपयोग कर सकते हैं
    • email की अनावश्यक notifications को पूरी तरह खत्म करने के लिए मैंने unsubscribe rule का एक और उन्नत version बनाया और उसे open source में जारी किया
      https://unfuck.email
    • “निष्क्रिय” वाली बात का आशय समझ में आता है और वह उचित भी लगता है, लेकिन सख़्ती से कहें तो ज़्यादातर लोगों को लगता है कि उनके पास विकल्प ही नहीं है
      फ़ोन न उठाना या message का जवाब न देना बहुत से लोगों के लिए वर्जित जैसा है, इसलिए वे spammers और social apps के हर दिशा से आने वाली arms race में फँसे रहते हैं। ऐसे लोगों को यह बात खलती है कि हम 24x7 Do Not Disturb की दुनिया में रहते हैं
      इसका हल क्या हो सकता है, पता नहीं, लेकिन उनका नज़रिया भी समझ में आता है

  • message notifications को छोड़कर बाकी सब बंद करके एक दिन गुज़ार कर देखो। तुम मरोगे नहीं। जिन चीज़ों की सच में परवाह होती है, उन्हें समय-समय पर check करने की आदत जल्दी पड़ जाती है, और बाकी सबको जब तक मुझे परवाह हो तब तक इंतज़ार करना चाहिए
    मैं कई सालों से ऐसे ही जी रहा हूँ, और मेरे दोस्तों या सहकर्मियों को यह पता नहीं है, न ही उन्हें पता होना चाहिए। notifications मुझे जल्दी जवाब देने में मदद नहीं करतीं, वे बस मेरा ध्यान उस काम से हटा देती हैं जो मैं करने वाला था
    आज मैंने अभी तक न Discord देखा है न email। जब मुझे जानना होगा कि दोस्तों ने कुछ लिखा है, कोई नया bill आया है, या किसी चीज़ पर follow-up चाहिए, तब मैं वह app खोलकर निपटा लूँगा
    फ़ोन को कई घंटों तक पास रखकर भी बिना distracted हुए रहा जा सकता है

    • “जिन चीज़ों की सच में परवाह है उन्हें समय-समय पर check करने की आदत पड़ जाती है” — मेरे लिए यही सबसे बड़ा बदलाव था। पहले notifications बंद करने पर यह चिंता रहती थी कि कहीं कुछ important miss न हो जाए, लेकिन सच तो यह है कि notifications होने पर भी मैं चीज़ें miss कर देता था
      important चीज़ों को समय-समय पर check करने की आदत का एक अच्छा side effect भी था। फ़ोन पर निर्भरता कम हुई कि वह मेरी जगह सब कर दे, और मेरा mental notification system बेहतर हो गया। साथ ही यह भी और साफ़ दिखने लगा कि जिन apps और services को मैं कम-से-कम check करता जा रहा था, वे वास्तव में कितनी कम महत्वपूर्ण थीं
      अब मेरे पास apps और accounts कहीं कम हैं, और कुल मिलाकर मैं समय का बेहतर पालन करता हूँ

  • यह हिस्सा तथ्यात्मक रूप से सही नहीं है: “notifications सिर्फ notification center में मौजूद होती हैं, और notification center गुजरती हुई चीज़ों को साफ़ करता है, फेंक देता है, summarize करता है, और कुछ भी reliably store नहीं करता”
    notification center जानकारी को reliably store करता है। inbox जैसी कोई चीज़ user space में नहीं दिखती, लेकिन वास्तव में वह मौजूद है: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...

  • “15 सालों में इस channel को एक ही premise के इर्द-गिर्द फिर से बनाया गया। recipient का attention एक scarce resource है, और platform पर उसे defend करने की ज़िम्मेदारी है. … sender के रूप में, control चाहे जिस तरफ़ भी जाए, आप उस premise के opposite side पर खड़े हैं”
    यह दिलचस्प है कि लेखक इस स्थिति को खुलकर sender और recipient के हितों के टकराव के रूप में frame करता है

    • यह ज़रूरी नहीं कि हमेशा टकराव ही हो; इसे tension कहना ज़्यादा ठीक होगा
      user के attention को बहुत आक्रामक तरीके से बचाने वाला device कभी-कभी ऐसी चीज़ भी रोक सकता है जिसे user वास्तव में देखना चाहता था
      फिर भी ज़्यादातर notifications कचरा हैं और उन्हें block किया जाना चाहिए
    • मुझे लगता है यह काफ़ी कठोर reading है। मेरे हिसाब से वह वाक्य यह कहने के ज़्यादा करीब है कि platform, user के हित में नहीं बल्कि platform के अपने हित के अनुसार काम करता है

  • “ये सारे प्रभाव एक जैसे नहीं पड़ते। filtering, broadcast-type और promotional push पर सबसे ज़्यादा सख़्ती से गिरती है, जबकि वे notifications जिन्हें लोग सच में चाहते हैं, अक्सर वैसे ही गुजर जाती हैं या amplify हो जाती हैं”
    मुझे तो यह ठीक लगता है

  • “इस channel के इतिहास के ज़्यादातर समय में platform ने दिखने लायक लगभग कोई हस्तक्षेप नहीं किया। संरचनात्मक रूप से हस्तक्षेप संभव था, लेकिन उन्होंने बस ज़्यादा हस्तक्षेप न करने का चुनाव किया। वह restraint अब खत्म हो गया है”
    यह हमेशा दिखाई नहीं देता था, लेकिन शुरू से ही किसी न किसी रूप में हस्तक्षेप मौजूद था। WhatsApp में हम हमेशा push delay, suppression, merging को monitor करते थे, और मेरी याद के मुताबिक यह कम-से-कम 2011 से, जब मैं जुड़ा था, system का हिस्सा था
    अगर वह system के अंदर ठीक से काम न करे, तो user messages समय पर deliver नहीं होते

    • दिलचस्प। सोच रहा हूँ कि क्या आप इससे जुड़ा और context बता सकते हैं। मैंने इतनी बड़ी scale वाले product पर कभी काम नहीं किया, इसलिए monitoring हमेशा commercial push platforms से मिलने वाली चीज़ों तक ही सीमित रही

  • USA PATRIOT Act की Section 215 के फोन metadata के बड़े पैमाने पर संग्रह की जगह लेने वाली किसी चीज़ का असर Apple Push Notification, Firebase Cloud Messaging जैसी संरचनाओं पर पड़ता है, ऐसा लगता है
    Apple सभी iPhone के लिए persistent connection का मालिक है, और सिर्फ APNs ही apps को जगा सकता है। यहाँ “self-hosting” का मतलब है कि Firebase Cloud Messaging, OneSignal, Pusher जैसे third party को सौंपने के बजाय क्या भेजना है यह तय करके APNs को सौंपने वाला अपना provider backend चलाना। लेकिन आख़िरी हिस्सा कभी भी मेरा नहीं होता
    सभी लोगों के ट्रैफ़िक को कुछ गिने-चुने identity-aware brokers से गुज़रने देने वाली संरचना, डिज़ाइन के हिसाब से, सिर्फ कानूनी औज़ारों का इंतज़ार करती हुई एक mass metadata collection system है
    दिसंबर 2023 में Senator Ron Wyden ने खुलासा किया कि अमेरिकी सरकार और विदेशी सरकारों ने Google और Apple को push notification जानकारी, communication metadata, और कभी-कभी content तक को गुप्त रूप से सौंपने के लिए मजबूर किया था। डेवलपर्स के लिए चिंता की बात यह है कि iPhone और Android जिस platform पर निर्भर हैं, वहाँ notifications भेजने के लिए इस प्रथा को रोकने का कोई तरीका नहीं है
    Apple इस प्रोग्राम के सार्वजनिक होने से पहले तक gag order के तहत था, और बाद में उसने कहा कि वह ऐसी requests को transparency reports में विस्तार से दिखाएगा। इसलिए यह structural hypothesis अटकल नहीं बल्कि एक confirmed mechanism है, और Section 215 से इसका फ़र्क बस इतना है कि इसका क्षेत्र calls नहीं बल्कि apps हैं, और कानूनी साधन §215 की specific business records theory नहीं बल्कि सामान्य subpoena, FISA orders, और NSL हैं
    “वह तो सिर्फ metadata है” जैसी बात आख़िरकार ऐसे ही संदर्भ से आती है। बेशक यह मज़ाक है, और ऐसे काम के लिए कोई एक व्यक्ति अकेला ज़िम्मेदार नहीं है; यह सामूहिक राजनीतिक इच्छा का नतीजा है, और दुर्भाग्य से शायद यही हमारे बस का सबसे अच्छा विकल्प हो सकता है
    https://www.youtube.com/watch?v=9iUdm0QMDM0
    https://epic.org/sen-wyden-reveals-government-surveillance-o...