Bear ने CSS से analytics कैसे लागू किया

 (herman.bearblog.dev)
4 पॉइंट द्वारा GN⁺ 2023-11-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Bear Blog ने गति, दक्षता और स्थिरता की सीमाओं के कारण client-side JavaScript के बिना चलने वाला अपना analytics system लागू किया
  • आम analytics scripts ad blockers से ब्लॉक हो सकती हैं, और केवल server logs से crawler, scraper और GPT-based parsers भी मिल जाने पर visit stats विकृत हो सकते हैं
  • हर page के CSS में body:hover होने पर border-image के जरिए /hit/{{ post.id }}/ endpoint को call किया जाता है, जिससे hover या mobile scroll को read signal के रूप में इस्तेमाल किया जाता है
  • server user-agent से bot होने/न होने, browser और platform की जांच करता है, और IP address को केवल country पहचानने के लिए इस्तेमाल करने के बाद IP+date hash से duplicate reads हटाता है
  • एक ही IP से उसी दिन कई devices पर पढ़ने पर उसे एक बार गिना जाता है, लेकिन identifying information store किए बिना हर page के unique read count को सरलता से aggregate किया जा सकता है

CSS hover से read event बनाना

  • Bear Blog का analytics system client-side JavaScript इस्तेमाल न करने की constraint का पालन करता है
  • सामान्य analytics tools client JavaScript से traffic की authenticity या bot होने/न होने का कुछ हद तक आकलन कर सकते हैं, लेकिन कई ad blockers Google Analytics के साथ-साथ Fathom, Plausible जैसे analytics scripts को भी block कर देते हैं
  • केवल server logs parse करने से search engine crawlers, scrapers और GPT-based parsers सामान्य traffic की तरह मिलकर विकृत नजरिया पैदा कर सकते हैं
  • Bear हर page में नीचे दिया CSS डालता है, ताकि user जब page पर cursor ले जाए या mobile पर scroll करे, तब body:hover हो
body:hover {
  border-image: url("/hit/{{ post.id }}/?ref={{ request.META.HTTP_REFERER }}");
}
  • body:hover trigger होने पर उस post का hit URL call होता है
  • इस request में explicit रूप से फिर जोड़ी जाने वाली जानकारी referrer है, और HTTP_REFERER की spelling गलत spelling के standard जैसी रह गई form है
  • bots hover नहीं करते—इस बात का इस्तेमाल करके, body:hover-based call को human readers का signal माना जाता है
  • इसके बाद server पर user-agent के bot होने की जांच की जाती है, और user-agent string से browser और platform निकाले जाते हैं

identifying information के बिना duplicate reads हटाना

  • दूसरी constraint यह है कि reader को identify कर सकने वाली जानकारी browser cookie या server पर store नहीं की जाती
  • IP address का इस्तेमाल केवल country तय करने के लिए होता है, और store करने से पहले IP address और date को साथ में hash किया जाता है
  • उसी page के लिए बाद की requests को IP address + date hash से compare किया जाता है और duplicate होने पर छोड़ दिया जाता है
  • इस तरीके में एक दिन के दौरान एक IP address को एक page के लिए एक read के रूप में गिना जाता है
  • मूल IP address store नहीं किया जाता, और date शामिल करने वाला hash day-level expiry जैसा असर देता है
user_agent = httpagentparser.detect(self.request.META.get('HTTP_USER_AGENT', None))
if user_agent.get('bot', False):
    print('Bot traffic')
    return

ip_hash = hashlib.md5(f"{client_ip(self.request)}-{timezone.now().date()}".encode('utf-8')).hexdigest()
country = get_user_location(client_ip(self.request)).get('country_name', '')
device = user_agent.get('platform', {}).get('name', '')
browser = user_agent.get('browser', {}).get('name', '')
referrer = self.request.GET.get('ref', '')

if referrer:
    referrer = urlparse(referrer)
    referrer = '{uri.scheme}://{uri.netloc}/'.format(uri=referrer)

Hit.objects.get_or_create(
    post_id=self.pk,
    ip_address=ip_hash,
    referrer=referrer,
    country=country,
    device=device,
    browser=browser)
  • IP hash का इस्तेमाल केवल एक दिन के दौरान duplicate hits रोकने के लिए होता है, और सभी page views को मूल रूप से unique माना जाता है
  • हर दिन के अंत में background job hit logs से hash हटा देती है, ताकि GDPR की अत्यधिक सख्त interpretation से टकराव न हो
  • इस तरीके की कमी यह है कि एक ही IP address से उसी दिन कई devices पर पढ़ने पर भी इसे सिर्फ एक read के रूप में दर्ज किया जाता है
  • Bear मानता है कि ऐसे मामले traffic का छोटा हिस्सा हैं, और CSS-based तरीका कई analytics collection तरीकों की तुलना में अधिक compact, simple और accurate read count देता है

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

1 टिप्पणियां

 
GN⁺ 2023-11-03
Hacker News टिप्पणियाँ

  • मैं लेखक हूँ। इस संदर्भ में IP address hash का उपयोग सिर्फ एक ही दिन के भीतर duplicate views को रोकने के लिए है
    इसका मकसद हर page view को डिफ़ॉल्ट रूप से unique बनाना है, और हर दिन के अंत में worker job view जानकारी को रखते हुए hash को खाली कर देता है। इसे लेख में और स्पष्ट करने के लिए मैंने एक update जोड़ा है

    • क्या आपने यह तरीका विचार किया कि एक छोटी transparent image वास्तव में serve की जाए, जिस पर midnight पर expire होने वाला private cache header लगा हो, और IP बिल्कुल भी store न किया जाए?
    • अगर दुनिया भर के किसी shared VPN पर 10 users एक ही IP से साइट पर आएँ, तो क्या उन्हें सिर्फ 1 user गिना जाएगा? कंपनी नेटवर्क में भी ऐसा हो सकता है, और IP एक खराब metric है

  • जब मैंने पहली बार analytics के लिए CSS से होने वाले requests का विचार देखा, तो यह मुझे सच में बहुत शानदार लगा
    Twitter पर किसी ने page के ऊपर अदृश्य चौकोरों की एक grid बिछाई थी, और हर cell पर hover करने पर एक unique background image load होती थी, जिसे mouse tracking के लिए इस्तेमाल किया गया। हर background image server को एक specific request भेजती थी, और server उसे interpret करता था
    मज़े के लिए मैंने एक गर्मियों में इस विचार को बढ़ाकर JavaScript के बिना “CSS-only asynchronous web chat” बनाया था: https://github.com/kkuchta/css-only-chat

  • सिर्फ date और IP को hash करके IP address को anonymize करना दरअसल security theater है
    Cryptographic hash को तेज़ी से compute होने के लिए design किया जाता है। hashcat से MacBook M1 Pro पर प्रति सेकंड 6 अरब MD5 hashes निकाले जा सकते हैं, और IPv4 addresses तो कुल 4 अरब ही हैं। पूरे range पर brute force चलाकर IP address निकाला जा सकता है, इसलिए यह व्यावहारिक रूप से hash को reverse करने जैसा ही है
    टूटा हुआ MD5 छोड़कर SHA-256 जैसा secure hash इस्तेमाल करें, तब भी बात वही रहती है

    • IP को hash से वापस निकालना तकनीकी रूप से मामूली बात है, लेकिन इससे अलग भी EU data protection authorities ने बहुत स्पष्ट कहा है कि personal data को hash करना anonymization नहीं है
      अगर आप किसी का पूरा नाम hash कर दें, तब भी बाद में इस सवाल का जवाब दिया जा सकता है कि “क्या यह hash इस खास पूरे नाम से मेल खाता है?”। इस सवाल का जवाब दे पाना ही दिखाता है कि anonymization प्रक्रिया reversible है
    • मैं लेखक हूँ। मैंने नीचे भी यही लिखा है, लेकिन यह इस thread में ज़्यादा प्रासंगिक लगता है
      IP address hash का उपयोग इस संदर्भ में सिर्फ एक दिन के भीतर duplicate views को रोकने के लिए है। इसका मकसद हर page view को डिफ़ॉल्ट रूप से unique बनाना है, और हर दिन के अंत में worker job उन IP hashes को हटा देता है जिनकी अब ज़रूरत नहीं रहती
    • जानकारी के लिए, Storybook की telemetry में ऐसा ही कुछ करने पर हुई चर्चा में भी यही समस्या उठी थी[0], और बिना किसी optimization के भी मेरे घर के laptop पर सभी IPv4 के लिए salted hashes निकालने में लगभग दो घंटे लगे
      [0] https://news.ycombinator.com/item?id=37596757
    • Hash में salt होना चाहिए। Salt हो तो बात ठीक है, न हो तो ठीक नहीं है
      Salt को स्थायी रूप से रखना है या नियमित रूप से rotate करना है, यह implementation detail भर है; analytics hash में salt का असली महत्व यह है कि salt कभी भी client से बाहर नहीं जाना चाहिए
      लेख के विवरण से लगता है कि salt नहीं है। या फिर शायद current date को salt की तरह इस्तेमाल किया जा रहा है, लेकिन वह random salt नहीं है, इसलिए जो भी यह जानना चाहे कि “क्या IP x.y.z.w ने yy-mm-dd तारीख़ को visit किया था?” वह इसे आसानी से guess कर सकता है
      Attacker के नज़रिये से ऐसी समस्या को समझना आसान है। दिए गए data से किसी खास व्यक्ति के बारे में कुछ पता करने के लिए मैं क्या करूँगा? अगर यह संभव नहीं है, तो शायद उस data को store करना आम तौर पर ठीक हो सकता है
    • क्या secret salt या rotating salt इस्तेमाल नहीं किया जा सकता? Example code में यह नहीं है, इसलिए यह आलोचना सही लगती है। फिर भी, सिर्फ एक चीज़ जोड़कर इसे काफ़ी हद तक वाजिब रूप से सुरक्षित बनाया जा सकता है
      लेकिन चिंता यह है कि कहीं सिर्फ ऐसा security theater ही privacy से जुड़े कई कानूनों और नियमों से निकल जाने के लिए काफ़ी न साबित हो जाए

  • यह चतुर तो लगता है, लेकिन body:hover शायद keyboard-only users और pointer device का उपयोग न करने वाले user agents, यानी assistive technology users, को लगभग पूरी तरह छोड़ देगा
    ऐसे समूह भले ही हाशिये पर माने जाएँ, लेकिन किसी भी रूप में उनका exclude होना हमेशा बहुत बुरा संकेत है
    मुझे नहीं पता, और संदेह भी है, कि सिर्फ basic CSS के सहारे सभी user agents में 100% भरोसेमंद तरीके से यह detect किया जा सकता है कि “कोई वास्तविक user यह लेख पढ़ रहा है” और उसके आधार पर HTTP request भेजी जा सकती है। कुछ user agents CSS को बिल्कुल support नहीं करते होंगे, या CSS की decorative image loading को बंद किए हुए होंगे
    एक आधुनिक selector जो मदद कर सकता है वह :root:focus-within है, लेकिन इसके लिए user को वास्तव में किसी interactive element पर focus करना होगा, और सभी user agents इसकी गारंटी भी नहीं देते। अत्याधुनिक scroll-linked animation @scroll-timeline भी संभव हो सकता है, लेकिन braille readers फिर भी शायद छूट जाएँगे

    • हाशिये पर? क्या :hover को support न करने वाले फोन और टैबलेट, यानी user agents के 50% से अधिक, इससे प्रभावित नहीं होंगे? बेशक, जब उनमें mouse connected न हो
    • जिस तरह यह लिखा गया है, उसके अनुसार pointer वाले devices पर यह pointer की position पर निर्भर करता है। अगर pointer बीच के 760px क्षेत्र के अंदर है तो यह active होगा, बाहर है तो नहीं
      यह क्षेत्र content column और दोनों ओर के 20px padding सहित उसकी चौड़ाई है। इसलिए कुछ keyboard users पकड़े जाएँगे, जबकि कुछ mouse users, खासकर बड़े viewport वाले, छूट जाएँगे

  • “यह कि Google Analytics जैसी बुरी चीज़ें ही नहीं, बल्कि Fathom और Plausible को भी ad-blocking browsers में activity record करने में मुश्किल होती है,” इसका कारण मुझे यह लगता है कि वे असल में ज़हरीली बंजर ज़मीन में जीने की कोशिश कर रहे हैं
    हमारे जैसे users इस पूरे concept से ऊब चुके हैं, इसलिए अगर CSS analytics लोकप्रिय हो भी जाए, तो उसे bypass करने की कोशिशें भी शुरू हो जाएँगी

    • ऐसा क्यों?
      मैंने uBlock में Piwik/Matomo, Plausible, और Fathom को manually unblock किया है। मुझे नहीं लगता कि वे क्या और कैसे track करते हैं, उससे कोई नुकसान होता है। और यह site operators को “service improvement” के लिए उपयोगी जानकारी देता है
      उदाहरण के लिए, Plausible मेरे बारे में सामान्य nginx या Apache logs की तुलना में कम जानकारी इकट्ठा करता है। एक blogger के नज़रिए से यह देखना महत्वपूर्ण है कि कोई post HN पर गई या नहीं, कहीं और link हुई या नहीं, कौन-सा content मूल्यवान माना जा रहा है और किसे नज़रअंदाज़ किया जा रहा है। तभी आप वह लिख सकते हैं जिसे लोग सच में पढ़ना चाहते हैं, और उसे उन channels में फैला सकते हैं जिन्हें वास्तव में जाना जा सकता है
    • web server के access.log को analytics service में डालने से कुछ भी नहीं रुकता
      बल्कि सिर्फ user agent देखकर सारे bot traffic को फ़िल्टर करना लगभग असंभव है, इसलिए आँकड़े फुल सकते हैं
    • वेब पर जो चीज़ मुझे ज़हरीली बंजर ज़मीन जैसी लगती है, वह हर तरह के ads हैं। tracking उससे कहीं ज़्यादा subtle समस्या है, लेकिन लंबे समय में इसका नुकसान यह हो सकता है कि मुझे manipulate करने का सबसे अच्छा तरीका खोजने के लिए एक प्रयोग-योग्य digital twin बनाया जाए
      वास्तव में कितने लोग इससे डरते हैं, पता नहीं। प्रतिक्रियाएँ शायद “हाँ, creepy है” से लेकर “बिलकुल नहीं, यह तो बस sci-fi है” तक जाएँगी
    • uMatrix याद आता है, जो CSS loading तक block कर सकता था
    • यह तरीका JavaScript वाले तरीके से block करना किसी भी तरह ज़्यादा कठिन नहीं है। आख़िर में करना तो बस इतना है कि खास URL patterns पर जाने वाली requests को रोकना है

  • यह तो कई दशकों से pixel tracker के नाम से जाना जाता है

    • email में भी इस्तेमाल होता है। 1x1 transparent image load करना hover event trigger करने से ज़्यादा भरोसेमंद है, लेकिन ad blockers ऐसी images को अक्सर block कर देते हैं
    • सही। लेकिन CSS के साथ इसमें कुछ दिलचस्प पहलू हैं। :hover का इस्तेमाल करें तो आप उन bots को पकड़ सकते हैं जो पूरा WebDriver इस्तेमाल नहीं करते, यानी ज़्यादातर bots
      कुछ मायनों में लगभग खाली .css file को supports के साथ @import करके लोड करना बेहतर हो सकता है। ad blockers 1px transparent tracking pixels को बहुत अच्छी तरह पकड़ लेते हैं, लेकिन layout न टूटे इसलिए वे .css files को कम block कर सकते हैं। हालाँकि इस स्थिति में :hover का clever फ़ायदा गायब हो जाता है

  • यह सचमुच जिज्ञासा वाला सवाल है, हालाँकि डर है कि कहीं यह dismissive opinion जैसा न लगे। Bearblog जैसे दिखने वाले non-commercial personal blog पर analytics data इकट्ठा करने का लक्ष्य क्या है?

    • 2000 के आसपास से लगातार blogging करने वाले और पूरे समय “stats” में बहुत रुचि रखने वाले लेखक के नज़रिए से मैं कह सकता हूँ
      analytics में रुचि रखने का मुख्य कारण यह देखना है कि लिखी हुई चीज़ पढ़ी जा रही है या नहीं। ऊपर से, और कुछ हद तक, यह vanity की बात लग सकती है, लेकिन असल में यह लेखक और पाठक के बीच जुड़ाव के बारे में है। मुझे सच में जानना होता है कि पाठक किस पर प्रतिक्रिया देते हैं, और मैं उन्हें वैसी चीज़ें और देना चाहता हूँ। वह “वैसी चीज़” topic हो सकती है, tone हो सकती है, या length हो सकती है। इससे मुझे अपने readers के हिसाब से सामग्री को सँवारने में मदद मिलती है। आखिरकार मैं बारह विषयों पर चौबीस तरीकों से लिख सकता हूँ। मैं वही लिखता हूँ जो मुझे पसंद है, लेकिन उसे इस तरह तराशता हूँ कि वह readers के साथ बेहतर resonate करे
      इस अर्थ में analytics readers को जानने का एक तरीका भी है। जिन blogs पर engagement ज़्यादा था, वहाँ analytics ने readers की एक धुँधली-सी profile दी। सिर्फ यह नहीं कि उन्हें क्या पसंद है, बल्कि यह भी कि कब पसंद है। यह जानना संभव था कि वे सुबह सबसे पहले पढ़ते हैं, lunch break में पढ़ते हैं, या देर रात पढ़ते हैं, और इससे यह तय करने या उस फ़ैसले पर भरोसा रखने में मदद मिलती थी कि किस समय publish किया जाए। बेशक यह सब धुँधली जानकारी थी, लेकिन readers से अधिक सक्रिय रूप से जुड़ने में यह सचमुच मददगार थी
    • feedback loop की वजह से। बहुत से लोगों की सोच के विपरीत, analytics सिर्फ ads या data बेचने के लिए नहीं होती, बल्कि site और content performance का analysis करने के लिए होती है
      बेशक इसका इस्तेमाल ads में हो सकता है और इसका दुरुपयोग भी हो सकता है, लेकिन अगर मुझे अपने काम के बारे में feedback चाहिए, तो यह ज़रूरी है
      site को 12 लोग पढ़ें या 12,000, उसकी कोई monetary value न भी हो सकती है। लेकिन व्यक्तिगत नज़रिए से यह जानना अच्छा है कि लोग मुझसे क्या पढ़ना चाहते हैं, इससे लगता है कि लिखने में लगाया गया समय सार्थक था, और अगर चाहें तो आप चीज़ों को अधिक लोकप्रिय दिशा में adjust भी कर सकते हैं
    • शायद जिज्ञासा? मैं जानना चाहता हूँ कि जो मैंने लिखा है, उसे कोई पढ़ भी रहा है या नहीं। लोगों की दिलचस्पी किसमें है, यह जानना भी उपयोगी है
      व्यक्तिगत blogger भी readers के हिसाब से content adjust करना चाह सकता है। यह जानना अच्छा है कि किसी एक topic पर 500 लोगों ने पढ़ा, जबकि किसी दूसरे topic पर सिर्फ 3 लोगों ने

  • मैंने इस साल की शुरुआत में ऐसा कुछ करने की कोशिश की थी, लेकिन web UI बनाते समय motivation खो दी। मेरा तरीका CSS नहीं था, बस tags से fake image load करना था
    https://github.com/nolytics

  • यह जानकारी सीधे HTTP server से क्यों नहीं ली जाती?

    • blog post में इसे इस तरह समझाया गया है
      “server logs को parse करने का विकल्प हमेशा होता है, और इससे server तक पहुँचने वाले traffic के प्रकार का मोटा अंदाज़ा लगाया जा सकता है। लेकिन आम तौर पर सारा server traffic एक जैसा दिखता है। तकनीकी रूप से bots के पास ऐसा user agent होना चाहिए जो खुद को bot के रूप में identify करे, लेकिन वे browser इस्तेमाल करने वाले ‘इंसान’ की तरह जानकारी scrape करना चाहते हैं, इसलिए वे शायद ही कभी इस तरह पहचान देते हैं। मूल रूप से अगर analytics के लिए सिर्फ server logs का इस्तेमाल किया जाए, तो search engine crawlers, scrapers, और अब GPT-आधारित parsers की वजह से traffic विकृत दिखेगा”
    • bots सब मिल जाते हैं
    • serverless में चलाएँ तो यह मुश्किल है

  • एनालिटिक्स डेटा कैसे स्टोर किया जाता है?
    मान लीजिए एक e-commerce साइट है और उस पर बेचने के लिए प्रोडक्ट हैं। एनालिटिक्स के अलावा, लॉग-इन स्थिति में प्रोडक्ट डिटेल पेज विज़िट जैसी कुछ गतिविधियों को सीधे लॉग के रूप में दर्ज करने का फैसला किया गया। इसलिए user ID, product ID, timestamp जैसी चीज़ें स्टोर करनी हैं
    व्यवहार में इसे कैसे स्टोर करना चाहिए? भोलेपन में लगा कि बस इसे एक टेबल में डाल देंगे। DBA ने पूछा डेटा कितने समय तक चाहिए, और जवाब मिला कम से कम एक महीना। तब उन्होंने कहा ठीक है, और शायद उससे पुराना डेटा किसी दूसरी टेबल में शिफ्ट करने का कोई जॉब सेट कर दिया होगा
    वास्तव में ऐसे लॉग कैसे स्टोर किए जाते हैं, और कितने समय तक रखे जाते हैं?

    • अगर स्केल बहुत बड़ा नहीं है, तो Postgres टेबल में डालना भी पूरी तरह ठीक है। स्केल बड़ा हो तब भी तारीख या किसी अन्य उपयुक्त प्रॉपर्टी के आधार पर टेबल partitioning करके बहुत बड़े indexes संभालने से बचा जा सकता है
      पहले ऐसा किया है, और लगभग 1 अरब rows तक पहुँचने से पहले partitioning के बारे में सोचने की भी ज़रूरत नहीं पड़ी। फिर भी, इससे पहले partitioning कर लेना बेहतर है। वह अनुभव सुखद नहीं था
    • एनालिटिक्स के लिए डेटाबेस बेहतर है। जैसे ClickHouse या BigQuery
      ये aggregations बहुत तेज़ी से कर सकते हैं, और ऐसे बहुत सारे sparse columns भी अच्छी तरह संभालते हैं। उदाहरण के लिए paid event में amount प्रॉपर्टी होती है, जबकि page_view event में url प्रॉपर्टी होती है
    • MySQL में 13 साल का डेटा स्टोर करके रखा है। स्केल सालाना 50 लाख visitors का है। वहाँ query करना कष्टदायक है, इसलिए ClickHouse में भी उसकी एक कॉपी रखी जाती है। ClickHouse में query करना वाकई बहुत आसान है
    • Postgres और TimescaleDB का उपयोग करते हैं। अगर e-commerce साइट amazon.com के स्केल की नहीं है, तो यह अच्छी तरह काम करता है
      TimescaleDB की अच्छी बात यह है कि यह प्रति घंटा product views जैसे रुचिकर aggregations के लिए materialized views बनाना खुद संभाल लेता है। अगर events बहुत ज़्यादा हों और database बहुत बड़ा हो जाने से बचना हो, तो events को खुद “फेंककर” सिर्फ aggregations रखने का विकल्प भी चुना जा सकता है
    • ClickHouse