सीमा तक पहुँचने से पहले अपनी कुंजी के उपयोग पर नज़र रखें
काम के साथ-साथ अपने कोटा हेडर देखते रहने से पता चलता है कि कब सीमा करीब आ रही है, किसी अनुरोध के असल में अस्वीकार होने से काफ़ी पहले।
CRM एक्सपोर्ट से पतों को बल्क में जियोकोड करें
CRM एक्सपोर्ट आम तौर पर ग्राहक रिकॉर्ड की एक सपाट फ़ाइल होती है जिसमें एक पता फ़ील्ड होता है और लोकेशन से जुड़ा और कुछ नहीं, न निर्देशांक, न सत्यापित घटक। इसे ऐसी चीज़ में बदलने के लिए जिसे आप मैप कर सकें या क्षेत्र के हिसाब से बाँट सकें, पूरे एक्सपोर्ट को जियोकोड करना पड़ता है।
एक्सपोर्ट तैयार करना
अपने CRM एक्सपोर्ट से पते वाला कॉलम एक सादे ऐरे के रूप में निकालें, और स्थिति के आधार पर हर पते के साथ ग्राहक ID को जोड़े रखें, क्योंकि बाद में आपको परिणामों को वापस रिकॉर्ड से मिलाना होगा।
POST /v1/forward
Content-Type: application/json
["1600 Pennsylvania Avenue, Washington", "221B Baker Street, London"]{
"status": "ok",
"results": [
{"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500", "lat": 38.8977, "lon": -77.0365, "type": "address", "precision": "house", "confidence": 0.97, "place_id": "def456", "components": {}},
{"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}}
]
}परिणामों को वापस CRM में लिखना
हर परिणाम को उसके ग्राहक से उस स्थिति के आधार पर मिलाएँ जो आपने अनुरोध भेजने से पहले दर्ज की थी, फिर निर्देशांक और घटकों को अपने CRM में वापस लिखें, या तो उसके अपने API के ज़रिए या बल्क इम्पोर्ट से, इस पर निर्भर करते हुए कि आपका CRM क्या सपोर्ट करता है। confidence और precision फ़ील्ड भी सहेजें, ताकि कमज़ोर मिलान वाली किसी भी चीज़ को सत्यापित मानने के बजाय सफ़ाई के लिए चिह्नित किया जा सके।
दूसरा उदाहरण: अंतरराष्ट्रीय ग्राहक आधार
कई देशों में ग्राहकों वाले CRM को हर क्षेत्र के बैच के साथ countries पैरामीटर पास करने से फ़ायदा होता है, जो संभावित मिलानों को अपेक्षित देश तक सीमित करता है और उस दुर्लभ स्थिति को कम करता है जिसमें एक से ज़्यादा देशों में आम सड़क का नाम गलत देश में रिज़ॉल्व हो जाता है। एक्सपोर्ट को हर देश के अलग बैच में बाँटकर हर एक को उसके अपने बल्क अनुरोध के रूप में भेजना, वर्कफ़्लो में और कुछ बदले बिना इसे लागू करने का एक उचित तरीका है।
एक आम गलती जिससे बचना चाहिए
मूल ग्राहक ID तक वापस पहुँचने की अलग मैपिंग रखे बिना, भेजने से पहले पतों के ऐरे से डुप्लिकेट न हटाएँ और उसका क्रम न बदलें। परिणाम उसी क्रम में लौटते हैं जिसमें आपने ऐरे भेजा था, और सहेजे गए इंडेक्स के बिना एक बार वह क्रम आपके ग्राहक रिकॉर्ड से अलग हो गया, तो बाद में किसी निर्देशांक जोड़ी को सही ग्राहक से मिलाने का कोई भरोसेमंद तरीका नहीं बचता। जॉब की पूरी अवधि के लिए स्थिति से ID की मैपिंग को मेमोरी में या किसी अस्थायी कॉलम में रखें।
सिर्फ़ नए रिकॉर्ड पर दोबारा चलाना
एक बार शुरुआती एक्सपोर्ट जियोकोड हो जाने के बाद, बाद में पूरे ग्राहक आधार को फिर से प्रोसेस करने की ज़रूरत नहीं है। दर्ज रखें कि किन रिकॉर्ड के पास पहले से निर्देशांक हैं और आगे की बार सिर्फ़ नए या बदले हुए पते वाले रिकॉर्ड ही एंडपॉइंट पर भेजें, ताकि लगातार होने वाला अनुरोधों का उपयोग आपके कुल ग्राहकों की संख्या के बजाय नई गतिविधि के अनुपात में रहे।
ठीक से रिज़ॉल्व न होने वाले रिकॉर्ड को संभालना
कम कॉन्फ़िडेंस स्कोर वाले या कई अपेक्षित घटकों से रहित रिकॉर्ड को आपके पूरी तरह सत्यापित रिकॉर्ड के साथ चुपचाप लिखने के बजाय रिव्यू कतार में चिह्नित करना बेहतर है। इससे कोई खराब पता भरे गए डेटा से बनी किसी क्षेत्रीय रिपोर्ट या मैप व्यू को चुपचाप दूषित नहीं कर पाता।
इसकी लागत क्या है
किसी मौजूदा CRM को एक बार भरने में पते वाले हर ग्राहक रिकॉर्ड पर एक अनुरोध लगता है, जिसे एक ही बल्क कॉल या कुछ हिस्सों में चलाया जाता है। कुछ हज़ार ग्राहकों वाला CRM एक ही बार में 2,500 प्रतिदिन मुफ़्त अनुरोधों से ज़्यादा इस्तेमाल कर सकता है, और यह जॉब को कुछ दिनों में फैलाने या इस एक बार के काम के लिए प्रीपेड क्रेडिट पर जाने का उचित समय है।
एक बार भराई पूरी हो जाने के बाद, नए ग्राहकों के लिए लगातार होने वाली जियोकोडिंग किसी बार-बार होने वाले बल्क जॉब के बजाय कम और स्थिर रहती है। अनुरोध और रिस्पॉन्स की पूरी संरचना के लिए फ़ॉरवर्ड जियोकोडिंग दस्तावेज़ देखें।