Dynamic QR कोड को हर स्कैनर को एक ही URL पर भेजने की जरूरत नहीं है। Conditional routing — जिसे scan routing या rule-based redirects भी कहते हैं — आपको एक ही प्रिंटेड कोड से अलग-अलग दर्शकों को अलग-अलग गंतव्यों पर भेजने देता है। अगर आपने कभी चाहा है कि आपका दोपहर का फ्लायर मेनू की ओर रीडायरेक्ट हो, शाम की भीड़ बुकिंग फॉर्म की ओर जाए, और अंतरराष्ट्रीय आगंतुक स्थानीयकृत पेज पर पहुंचें, तो यह बिल्कुल वही सुविधा है।
यहाँ सबसे उपयोगी routing परिदृश्य कैसे काम करते हैं, पहले क्या सेट अप करना है, और लोग आमतौर पर कहाँ गलती करते हैं।
Dynamic QR संदर्भ में "Routing" का वास्तविक अर्थ
जब कोई स्कैनर एक dynamic QR कोड को स्कैन करता है, तो कोड का गंतव्य URL सर्वर पर संग्रहीत होता है — यह कोड में खुद नहीं होता। वह सर्वर-साइड रीडायरेक्ट है जहाँ routing logic रहता है। सपाट रीडायरेक्ट ("सभी स्कैन → URL A") के बजाय, आप conditional rules जोड़ते हैं:
- अगर शर्त पूरी हो → URL A पर भेजें
- अन्यथा → URL B पर भेजें (fallback)
अधिकांश प्लेटफॉर्म जो इसका समर्थन करते हैं (कभी-कभी "multi-URL QR codes" या "smart redirect QR codes" कहा जाता है) आपको दो या तीन rules जोड़ने देते हैं। Fallback URL हमेशा आवश्यक है। Static और dynamic के बीच का अंतर समझना यहाँ मौलिक है — static vs dynamic QR codes की संपूर्ण व्याख्या बताती है कि रीडायरेक्ट सर्वर पर क्यों रहता है और routing के लिए यह क्यों महत्वपूर्ण है।
परिदृश्य 1: समय-आधारित Routing
उपयोग: एक कैफे टेबल टेंट पर एक QR कोड प्रिंट करता है। सुबह के स्कैनर नाश्ते का मेनू देखते हैं; दोपहर के स्कैनर लंच मेनू देखते हैं; शाम के स्कैनर ड्रिंक्स की सूची देखते हैं।
कैसे सेट अप करें:
- प्रत्येक मेनू अवधि के लिए तीन गंतव्य URL (या पेज सेक्शन) बनाएं।
- UTC में समय rules जोड़ें — अपने स्थानीय timezone offset के लिए खाता बनाना न भूलें।
- सबसे सामान्य उपयोग case को fallback के रूप में सेट करें, अगर कोई स्कैनर परिभाषित घंटों के बाहर स्कैन करे।
यह कहाँ गलत होता है: टीम भूल जाते हैं कि स्कैन का समय डिफ़ॉल्ट रूप से सर्वर द्वारा UTC में रिकॉर्ड किया जाता है। "11:00–14:00" के लिए timezone setting के बिना सेट किया गया rule आपके शहर में स्कैनर के लिए गलत घंटों पर फायर होगा। प्रिंट करने से पहले हमेशा अपने प्लेटफॉर्म की timezone हैंडलिंग की पुष्टि करें।
अन्य व्यावहारिक उदाहरण:
- इवेंट वेन्यू शो से पहले 7 बजे तक प्रोग्राम की ओर रूट करते हैं, फिर 9 बजे के बाद merchandise की ओर
- खुदरा विक्रेता केवल परिभाषित प्रचारणात्मक खिड़कियों के दौरान flash-sale landing page दिखाते हैं
- जिम सप्ताह के दिनों में क्लास शेड्यूल भेजते हैं और शनिवार/रविवार को सप्ताहांत का समय सारणी
परिदृश्य 2: देश या भाषा Routing
उपयोग: एक उत्पाद बॉक्स 12 देशों को भेजा जाता है। एक QR कोड अंग्रेजी-बोलने वाले बाजारों को अंग्रेजी support पेज पर रूट करता है, फ्रांसीसी-बोलने वाले बाजारों को फ्रेंच संस्करण पर, और बाकी सभी को language selector पर।
कैसे सेट अप करें:
- Routing engine स्कैनर के देश को IP geolocation के माध्यम से पहचानता है।
- विशिष्ट देश कोड मैप करें (US, GB, CA → अंग्रेजी पेज; FR, BE, CH → फ्रेंच पेज; DE → जर्मन पेज)।
- Language-selector पेज को global fallback के रूप में सेट करें।
आंतरिक रूप से दस्तावेज़ करने की सावधानियां:
- IP geolocation देश स्तर पर लगभग 95–99% सटीक है, लेकिन VPN उपयोगकर्ता गलत रूट होंगे। यह अधिकांश उपयोग cases के लिए स्वीकार्य है।
- ब्राउजर से पहचाने गए भाषा वरीयता द्वारा रूट न करें — QR स्कैन requests सभी ऐप्स के माध्यम से reliably Accept-Language headers पास नहीं करते।
- यदि आपका प्लेटफॉर्म प्रति गंतव्य URL या प्रति rule के लिए शुल्क लेता है, तो 40 अलग-अलग देशों को सूचीबद्ध करने के बजाय देश समूहों को एक साथ मैप करें।
परिदृश्य 3: डिवाइस-प्रकार Routing
उपयोग: एक software company का प्रिंट विज्ञापन trade magazine और developer newsletter दोनों में चलता है। iOS उपयोगकर्ता App Store listing पर जाते हैं; Android उपयोगकर्ता Google Play पर; desktop स्कैनर (कोई व्यक्ति अपने लैपटॉप कैमरे से विज्ञापन की तस्वीर ले रहा है) web app पर जाते हैं।
कैसे सेट अप करें:
- प्लेटफॉर्म स्कैन request से User-Agent string पढ़ता है।
iOS→ App Store URL रूट करें;Android→ Play Store URL;Other/Desktop→ web app।
यह क्यों महत्वपूर्ण है: App Store redirect pages platform को auto-detect करने में बदनाम हैं। Android उपयोगकर्ताओं को App Store link पर भेजना एक त्रुटि पैदा करता है और conversions को मारता है। Device routing बिना custom smart-banner implementation की आवश्यकता के इसे स्वच्छ रूप से हल करता है।
परिदृश्य 4: Rules को जोड़ना (Multi-Condition Routing)
कुछ प्लेटफॉर्म rules को stack करने देते हैं — उदाहरण के लिए, country AND device। एक सामान्य real-world सेटअप:
| प्राथमिकता | शर्त | गंतव्य |
|---|---|---|
| 1 | देश = US + डिवाइस = iOS | US App Store |
| 2 | देश = US + डिवाइस = Android | US Play Store |
| 3 | देश = DE | जर्मन landing page |
| 4 | Fallback | Global landing page |
Rules को top-to-bottom मूल्यांकित किया जाता है, इसलिए क्रम महत्वपूर्ण है। सबसे विशिष्ट शर्तों को पहले रखें, बीच में व्यापक geographic rules, और आखिरी में fallback। यह mis-sequence करना आसान है — प्रिंट करने से पहले हमेशा प्रत्येक शर्त को एक real device से test करें और, यदि संभव हो, एक VPN को relevant देश पर सेट करके।
आप प्रत्येक Route के लिए क्या ट्रैक कर सकते हैं
Routing केवल आधी तस्वीर है। प्रत्येक गंतव्य URL को UTM parameters ले जाने चाहिए ताकि आप अपने analytics platform में audience segment द्वारा performance को अलग कर सकें। एक scan जो फ्रेंच पेज पर रूट किया गया है, ?utm_source=qr&utm_medium=print&utm_content=fr fire करना चाहिए ताकि आप इसे generic scan से अलग कर सकें।
QR analytics के बारे में अधिक गहन जानकारी के लिए, QR कोड analytics गाइड जो वाकई निर्णय लेने में मदद करता है scan-to-conversion tracking को विस्तार से कवर करता है।
आप unexpected traffic patterns की पहचान करने के लिए routing logs का भी उपयोग कर सकते हैं — यदि एक UK-only print run पर 40% scans "non-UK fallback" को ट्रिगर कर रहे हैं, तो आपकी geolocation सेटअप को scale spend से पहले checking की जरूरत है।
Platform Checklist Routing पर Commit करने से पहले
हर dynamic QR platform conditional routing को support नहीं करता। एक चुनने से पहले, पुष्टि करें:
- Timezone चयन के साथ time-of-day rules (केवल UTC नहीं)
- Country/region-level geolocation routing
- डिवाइस-type detection (iOS / Android / Other न्यूनतम)
- Rule stacking या multi-condition support
- Per-rule scan analytics, केवल aggregate totals नहीं
- Fallback URL हमेशा आवश्यक और editable है
यदि आपका मौजूदा tool इनमें से कुछ नहीं है, तो सुपर QR कोड जेनरेटर समय, देश, और डिवाइस में conditional routing को per-rule analytics के साथ support करता है।
मुख्य बातें
- Routing एक ही प्रिंटेड QR कोड से अलग-अलग स्कैनर को अलग-अलग URL पर भेजता है, server-side redirect logic का उपयोग करके।
- Time-of-day routing के लिए सही timezone configuration की आवश्यकता होती है — UTC defaults अधिकांश markets में misfire करेंगे।
- Country routing IP geolocation का उपयोग करता है, जो country level पर reliable है लेकिन VPN उपयोगकर्ताओं के लिए विफल होता है।
- Device routing app download campaigns के लिए सबसे स्वच्छ fix है जिन्हें iOS और Android destinations को अलग करने की जरूरत है।
- हमेशा प्रत्येक routed URL को UTM parameters जोड़ें ताकि downstream analytics segmented रहे।
- Scale पर प्रिंट करने से पहले हमेशा एक real device (और आदर्श रूप से एक VPN) से प्रत्येक routing rule को test करें।