दस्तावेज़ पर जाएँ
नॉलेज बेस

देखें कि आपकी भेजी मेल कब खोली गई

आपका भेजा संदेश खोला गया या नहीं, कब, कितनी बार और उसके कौन-से लिंक खोले गए। जब तक आप बंद न करें चालू, और उन रीडिंग्स के बारे में साफ़ जो उसे नहीं मिल सकतीं।

विवरण

  • एक नहीं बल्कि दो स्विच, और जब तक mailbox उन्हें बंद न करे दोनों चालू हैं। Opens और clicks मेल पाने वाले व्यक्ति के साथ दो अलग सौदे हैं। pixel बताता है कि संदेश दिखाया गया और कुछ नहीं, जबकि फिर से लिखा गया लिंक असली मुलाक़ात हमारे रास्ते भेजता है, और बहुत से प्रेषक पहला चाहते हैं और दूसरे से इनकार करते हैं। दोनों बंद करके भेजा गया संदेश न pixel ले जाता है, न फिर से लिखा गया लिंक, और न ही यह दावा करती कोई पंक्ति कि उसे ट्रैक किया गया। API से भेजते समय tracking: { opens, clicks } बताकर उस एक संदेश के लिए तय किया जाता है, mailbox के लिए नहीं, और यह दोनों दिशाओं में तय करता है: जो प्रोग्राम कुछ भी दर्ज नहीं कराना चाहता वह प्रति संदेश यह कह देता है और वैसा ही पाता है, mailbox चाहे जैसा भी सेट हो।
  • कोई भी स्विच केवल यह तय करता है कि आपका अगला संदेश क्या ले जाएगा, और कुछ नहीं। पहले भेजी जा चुकी मेल अपना pixel और फिर से लिखे गए लिंक रखती है, और स्विच बंद होने के बाद भी रिपोर्ट करती रहती है, और उसे रोकने का अकेला तरीक़ा उन संदेशों के लिंक तोड़ना होता जो लोग पहले से रखे हैं, जो पाठक के साथ गिनती जारी रखने से भी बुरा बर्ताव है। tracking बंद करना इस बारे में निर्णय है कि अब से क्या बाहर जाएगा; वापस बुलाना नहीं होता।
  • किसी open या click के लिए कोई IP address संग्रहित नहीं होता, और उसे रखने के लिए कोई column ही नहीं है। जो रखा जाता है वह वही है जो edge को अनुरोध हम तक पहुँचने से पहले ही पता था (एक देश, एक क्षेत्र, एक शहर, एक time zone, जिनमें से कोई भी पाने के लिए खोजा नहीं गया), साथ ही address और user agent का SHA-256 fingerprint, जिसे आधी रात UTC पर बदलने वाले मान से salt किया जाता है। यही hash रिपोर्ट को दो opens के बजाय दो उपकरण कहने देता है, और एक दिन बाद उसे किसी address से कोई मिला नहीं सकता, हम भी नहीं। स्थान को व्यक्ति के बारे में नहीं, नेटवर्क के बारे में तथ्य की तरह पढ़ें: VPN या कॉर्पोरेट proxy के पीछे बैठा कोई भी ऐसी जगह दिखाया जाता है जहाँ वह कभी गया ही नहीं।
  • संख्याओं के पीछे दो तरह के रिकॉर्ड बैठते हैं। hit पंक्ति ऐसे व्यक्ति के बारे में user agent, शहर और fingerprint रखती है जिसने मापे जाने की सहमति कभी नहीं दी, और वह भेजने के बाद के दिनों में पूछे जाने वाले सवालों का उत्तर देने के लिए है: क्या वह scanner था, कौन-सा उपकरण था, क्या वह वाक़ई वही थे। दूसरी तरह पठन स्वयं है (पहला, आख़िरी और गिनती, प्रति संदेश और प्रति लिंक), जो खोलने वाले व्यक्ति के बारे में नहीं, आपकी अपनी मेल के बारे में तथ्य है।
  • स्वचालित fetch दर्ज किए जाते हैं और फिर गिने नहीं जाते, जो फेंक दिए जाने से अलग बात है। Apple की Mail Privacy Protection डिलीवरी पर हर संदेश की हर दूरस्थ छवि डाउनलोड कर लेती है, चाहे कोई उसे देखे या न देखे। वह डिफ़ॉल्ट रूप से चालू है, और उसे गिनने से हर प्रेषक को 100% के क़रीब open दर मिल जाती है जिसका कोई अर्थ नहीं, इसलिए उसे user agent से और उस नेटवर्क से पहचाना जाता है जहाँ से अनुरोध आया, और मशीन के रूप में चिह्नित किया जाता है। कॉर्पोरेट scanners, link checkers, headless browsers और भेजे जाने के दस सेकंड के भीतर आने वाली हर चीज़ उसी तरह चिह्नित होती है, क्योंकि कोई व्यक्ति कुछ भी इतनी तेज़ी से नहीं करता। user agent ठीक वैसा ही रखा जाता है जैसा आया, साथ में यह भी कि उसमें से क्या पढ़ा गया, क्योंकि वह स्ट्रिंग ही वह है जिससे कॉल बना, और जिस कॉल को उसके input के विरुद्ध कोई जाँच न सके उसे कोई सुधार भी नहीं सकता। client वहाँ कुछ भी लिख सकता है और उनमें से कई लगभग कुछ नहीं कहते, इसलिए वह तथ्य नहीं, दावा है। रिपोर्ट लॉग और कुल के बीच अस्पष्ट खाई छोड़ने के बजाय छापती है कि कितने छाँट दिए गए।
  • Gmail तीसरा मामला है और उसे वैसा ही बताया जाता है। उसका image proxy इसलिए लाता है क्योंकि किसी ने संदेश दिखाया, इसलिए open असली है जबकि उपकरण, स्थान और client बस जाने नहीं जा सकते, और proxy cache करता है, इसलिए दूसरा और तीसरा पठन शायद हम तक कभी पहुँचे ही नहीं। Gmail से होकर आई open गिनती एक न्यूनतम है, कुल नहीं।
  • कोई open दर्ज न होना इसका सबूत नहीं कि संदेश पढ़ा नहीं गया। दूरस्थ छवियाँ रोकना सामान्य बात है, क्योंकि बहुत से clients उसे चालू रखकर आते हैं और बाक़ी सब उसका विकल्प देते हैं, और वह इसे पूरी तरह दबा देता है, इसलिए यहाँ की ख़ामोशी किसी भी दिशा में सबूत नहीं है, और यही वह उत्तर है जो आपको सबसे अधिक मिलेगा। उत्पाद में कुछ भी न-ट्रैक किए या न-रिपोर्ट किए संदेश को “नहीं खोला गया” के रूप में नहीं दिखाता, क्योंकि वह अनुपस्थिति में इनकार पढ़ना होता।
  • click, open से मज़बूत सबूत है, इसलिए दोनों को कभी एक संख्या में नहीं मिलाया जाता। छवियाँ रोकी जाना लिंक न क्लिक होने से कहीं अधिक आम है, जिससे वह संदेश जिस पर clicks हैं और opens नहीं, निश्चित रूप से पढ़ा गया संदेश बनता है। प्रति संदेश अधिकतम 100 गंतव्य फिर से लिखे जाते हैं, हर एक एक बार। किसी header छवि, बटन और footer से जुड़ा वही campaign पेज अपनी गिनती वाली एक ही पंक्ति है, क्योंकि वह तीन बार पूछा गया एक ही सवाल है, और रिपोर्ट बता सकती है कि कौन-सा लिंक अनुसरण के लायक़ था, न कि यह कि कहीं कुछ अनुसरण हुआ। उस सीमा के आगे बचे लिंक हटाने के बजाय ठीक वैसे ही छोड़ दिए जाते हैं जैसे लिखे गए थे, क्योंकि बिना ट्रैक वाला लिंक भी काम करता है जबकि ऐसा संदेश जो चुपचाप उनमें से दो सौ खो दे, नहीं करता।
  • फिर से लिखे गए लिंक को कहीं और नहीं मोड़ा जा सकता, सिवाय उसके जो हमने खुद संदेश में डाला। गंतव्य एक पंक्ति में रखा जाता है और URL केवल उसकी id ले जाता है, इसलिए छेड़ने को कोई query parameter है ही नहीं और यहाँ कुछ भी किसी मेल provider के domain पर open redirect नहीं बनाया जा सकता, जो phishing अभियानों का कच्चा माल है। redirect 301 नहीं बल्कि 302 है, क्योंकि स्थायी redirect को browser और बीच का हर proxy cache कर लेता है और गिनती एक पर रुककर वहीं रह जाती। जिस लिंक का संदेश बाद में हटा दिया गया हो, वह कोरा 404 देने के बजाय कहता है कि यह पता अब कहीं इशारा नहीं करता।
  • उत्तर का केवल नया हिस्सा फिर से लिखा जाता है; उसके नीचे का उद्धृत इतिहास किसी और का संदेश है और उनके लिंक उन्हीं के रहते हैं। Sent में रखी प्रति से pixel निकाल दिया जाता है और हर लिंक वैसा ही वापस रख दिया जाता है जैसा आपने टाइप किया था। इसके बिना, अपनी ही भेजी मेल अग्रेषित करना किसी प्राप्तकर्ता का token किसी अजनबी तक पहुँचा देता, अपने ही outbox में लिंक क्लिक करना प्राप्तकर्ता का क्लिक दर्ज करा देता, और जो प्रति आप रखते हैं वह वह नहीं होती जो आपने लिखी थी।
  • एक प्राप्तकर्ता वाला संदेश हमेशा उनका नाम बताता है: और कोई हो ही नहीं सकता था। एक से अधिक होने पर यह बताना कि किस प्राप्तकर्ता ने उसे खोला, हर व्यक्ति को body की अपनी प्रति देने की माँग करता है, जो केवल उसी संदेश पर किया जाता है जो इतना छोटा हो कि प्रति व्यक्ति उसे दोबारा बनाना सस्ता पड़े: अनुमानित आकार को प्राप्तकर्ताओं की संख्या से गुणा करने पर वह 8MB से कम आना चाहिए। उस बजट के आगे, और ऐसे सीलबंद संदेश पर जिसके ciphertext का एक ब्लॉक प्रति व्यक्ति बदल नहीं सकता, सबको एक ही body जाता है, और open को सूची से नाम चुनने के बजाय “इस संदेश पर कोई” के रूप में दर्ज किया जाता है। एक-दूसरे के तीस सेकंड के भीतर दो लोगों का खोलना वहाँ एक ही पठन गिना जाता है, जो वही सीमा दूसरे शब्दों में कही गई है। तीस सेकंड हर हाल में खिड़की है: preview pane का दोबारा बनना, या संदेश का दोबारा दृश्य में आना, छवि फिर से लाता है और वह दूसरा पठन नहीं है।
  • एक OpenEmail mailbox से दूसरे को भेजी मेल अपने opens reader से ही रिपोर्ट करती है। यहाँ का reader हर संदेश से हर 1×1 छवि आपकी स्क्रीन तक पहुँचने से पहले हटा देता है, हमारी अपनी सहित, इसलिए pixel कभी लाया ही नहीं जाता। जब संदेश दूरस्थ छवियाँ दिखाते हुए प्रस्तुत होता है, तो reader उस प्रति के विरुद्ध open दर्ज करता है जो उस mailbox को मिली और client का नाम OpenEmail बताता है। जो पाठक छवियाँ छिपाए रखता है, वह कुछ दर्ज नहीं कराता, ठीक वैसे ही जैसे कोई भी दूसरा client जो उन्हें रोकता है। लिंक किसी से भी नहीं हटाए जाते, इसलिए एक OpenEmail mailbox से दूसरे को किया गया click सामान्य तरीक़े से वापस आता है।
  • पूरी रिपोर्ट REST API पर उसी emails:read scope के अंतर्गत है जो पहले से भेजी गई मेल को ढकता है: एक सूची, किसी खिड़की में ट्रैक किए गए संदेशों पर open और click दरें, और अलग-अलग hits, यदि आप कहें तो स्वचालित वाले भी शामिल। प्रति-hit लॉग प्रति प्रति 2,000 पंक्तियों पर रुक जाता है जबकि गिनती चलती रहती है, ताकि लूप में लाया गया pixel ऐसी तालिका न बढ़ा सके जिसे कोई देख ही नहीं रहा।
  • tracking बंद करके भेजा गया संदेश शून्य opens के बजाय कुछ भी नहीं दिखाता। “किसी ने नहीं खोला” और “हम दर्ज नहीं कर रहे थे” अलग उत्तर हैं, और उत्पाद में कुछ भी उन्हें एक जैसा नहीं दिखाता।