High-volume address validation guide

উদ্দেশ্য

ডেভেলপার হিসেবে, আপনাকে প্রায়ই এমন ডেটাসেট নিয়ে কাজ করতে হয় যাতে গ্রাহকের ঠিকানা থাকে, যেগুলি হয়ত ভাল কোয়ালিটির নয়। আপনাকে নিশ্চিত করতে হবে যে ঠিকানাগুলি সঠিক গ্রাহক আইডি যাচাইকরণ থেকে শুরু করে ডেলিভারি এবং আরও অনেক কিছু ব্যবহারের ক্ষেত্রে।

Address Validation API হল Google Maps Platform-এর একটি প্রোডাক্ট যা আপনি ঠিকানা যাচাই করার জন্য ব্যবহার করতে পারেন। তবে, এটি একবারে শুধুমাত্র একটি ঠিকানা প্রসেস করে। এই ডকুমেন্টে, আমরা দেখব কীভাবে API টেস্টিং থেকে শুরু করে এককালীন এবং বারবার ঠিকানা যাচাইকরণ পর্যন্ত বিভিন্ন পরিস্থিতিতে High Volume Address Validation ব্যবহার করা যায়।

যেসব ক্ষেত্রে ব্যবহার করা যাবে

এখন আমরা সেইসব ব্যবহারের ক্ষেত্র বুঝব যেখানে High Volume Address Validation উপযোগী।

পরীক্ষা করা

আপনি প্রায়ই হাজার হাজার ঠিকানা রান করিয়ে Address Validation API পরীক্ষা করতে চান। আপনার কাছে কমা দিয়ে আলাদা করা ভ্যালু ফাইলে ঠিকানা থাকতে পারে এবং আপনি ঠিকানার কোয়ালিটি যাচাই করতে চাইতে পারেন।

ঠিকানার এককালীন যাচাইকরণ

Address Validation API-তে অনবোর্ড করার সময়, আপনি ব্যবহারকারীর ডেটাবেসের সাথে আপনার বর্তমান ঠিকানা ডেটাবেস যাচাই করতে চান।

ঠিকানার রেকারিং যাচাইকরণ

বিভিন্ন পরিস্থিতিতে বারবার ঠিকানা যাচাই করার প্রয়োজন হয়:

  • আপনি হয়ত সারাদিনে ক্যাপচার করা বিবরণের জন্য ঠিকানা যাচাই করতে শিডিউল করা কাজ সেট করেছেন, যেমন, গ্রাহকের সাইন-আপ, অর্ডারের বিবরণ, ডেলিভারির শিডিউল।
  • আপনি বিভিন্ন বিভাগ থেকে ঠিকানা সহ ডেটা ডাম্প পেতে পারেন, যেমন, সেলস থেকে মার্কেটিং। নতুন বিভাগ যারা ঠিকানাগুলি গ্রহণ করছে, তারা প্রায়শই সেগুলি ব্যবহার করার আগে যাচাই করতে চায়।
  • আপনি সমীক্ষা বা বিভিন্ন প্রোমোশন চলাকালীন ঠিকানা সংগ্রহ করতে পারেন এবং পরে অনলাইন সিস্টেমে আপডেট করতে পারেন। সিস্টেমে ঠিকানা ইনপুট করার সময় আপনি যাচাই করতে চান যে সেগুলি সঠিক কিনা।

প্রযুক্তিগত ডিপ ডাইভ

এই ডকুমেন্টের উদ্দেশ্যে, আমরা ধরে নিচ্ছি যে:

  • আপনি গ্রাহকের ডেটাবেস (অর্থাৎ, গ্রাহকের বিবরণ সহ ডেটাবেস) থেকে ঠিকানা সহ Address Validation API কল করছেন
  • আপনার ডেটাবেসে আলাদা আলাদা ঠিকানার জন্য আপনি বৈধতা ফ্ল্যাগ ক্যাশে করতে পারবেন।
  • কোনও স্বতন্ত্র গ্রাহক লগ-ইন করলে, Address Validation API থেকে বৈধতা ফ্ল্যাগ উদ্ধার করা হয়।

প্রোডাকশন ব্যবহারের জন্য ক্যাশে

Address Validation API ব্যবহার করার সময়, আপনি প্রায়ই API কল থেকে পাওয়া উত্তরের কিছু অংশ ক্যাশে করতে চান। আমাদের পরিষেবার শর্তাবলী কোন ডেটা ক্যাশে করা যেতে পারে তা সীমিত করে, Address Validation API থেকে ক্যাশে করা যেতে পারে এমন যেকোনও ডেটা অবশ্যই ব্যবহারকারীর অ্যাকাউন্টের বিপরীতে ক্যাশে করতে হবে। এর অর্থ হল, ডেটাবেসে, ঠিকানা বা ঠিকানা মেটাডেটা অবশ্যই ব্যবহারকারীর ইমেল ঠিকানা বা অন্যান্য প্রাথমিক আইডির বিপরীতে ক্যাশে করা থাকতে হবে।

High Volume Address Validation ব্যবহারের ক্ষেত্রে, ডেটা ক্যাশিং অবশ্যই Address Validation API পরিষেবা সংক্রান্ত নির্দিষ্ট শর্তাবলী মেনে চলতে হবে, যা ১১.৩ বিভাগে উল্লেখ করা আছে। এই তথ্যের ভিত্তিতে, আপনি নির্ধারণ করতে পারবেন যে কোনও ব্যবহারকারীর ঠিকানা ভুল কিনা। ভুল হলে, আপনার অ্যাপ্লিকেশনের সাথে পরবর্তী ইন্টার‍্যাকশনের সময় আপনি ব্যবহারকারীকে সঠিক ঠিকানা দেওয়ার জন্য প্রম্পট করতে পারবেন।

  • AddressComponent অবজেক্ট থেকে পাওয়া ডেটা
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

আপনি যদি আসল ঠিকানা সম্পর্কে কোনও তথ্য ক্যাশে করতে চান, তাহলে সেই ডেটা শুধুমাত্র ব্যবহারকারীর সম্মতি নিয়েই ক্যাশে করতে হবে। এটি নিশ্চিত করে যে ব্যবহারকারী ভালভাবে জানেন যে কেন একটি নির্দিষ্ট পরিষেবা তার ঠিকানা স্টোর করছে এবং তিনি তার ঠিকানা শেয়ার করার শর্তাবলীতে সম্মতি দিয়েছেন।

ব্যবহারকারীর সম্মতির একটি উদাহরণ হল চেক-আউট পৃষ্ঠায় ই-কমার্স ঠিকানা ফর্মের সাথে সরাসরি ইন্টার‍্যাক্ট করা। এটি ধরে নেওয়া হয় যে আপনি প্যাকেজ শিপিং করার উদ্দেশ্যে ঠিকানা ক্যাশে ও প্রসেস করবেন।

ব্যবহারকারীর সম্মতি নিয়ে, আপনি উত্তর থেকে formattedAddress এবং অন্যান্য গুরুত্বপূর্ণ কম্পোনেন্ট ক্যাশে করতে পারবেন। তবে, হেডলেস পরিস্থিতিতে, ব্যবহারকারী সম্মতি দিতে পারবেন না কারণ ব্যাকএন্ড থেকে ঠিকানা যাচাইকরণ করা হচ্ছে। তাই, এই হেডলেস পরিস্থিতিতে আপনি খুব সীমিত তথ্য ক্যাশে করতে পারবেন।

উত্তরটি বুঝুন

Address Validation API রেসপন্সে নিম্নলিখিত মার্কার থাকলে, আপনি নিশ্চিত হতে পারেন যে ইনপুট করা ঠিকানা ডেলিভারি করার জন্য উপযুক্ত:

  • Verdict অবজেক্টে addressComplete মার্কার হল true,
  • Verdict অবজেক্টে validationGranularity হল PREMISE অথবা SUB_PREMISE
  • কোনও AddressComponent এইভাবে চিহ্নিত করা নেই:
    • Inferred(মনে রাখবেন: inferred=trueএটি হতে পারে যখন addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected, এবং
  • confirmationLevel: AddressComponent-এ কনফার্মেশন লেভেল CONFIRMEDবাUNCONFIRMED_BUT_PLAUSIBLEহিসেবে সেট করা আছে

API রেসপন্সে উপরের মার্কার না থাকলে, ইনপুট করা ঠিকানা সম্ভবত নিম্নমানের ছিল এবং আপনি নিজের ডেটাবেসে ফ্ল্যাগ ক্যাশে করতে পারেন যাতে সেটি বোঝা যায়। ক্যাশে করা ফ্ল্যাগ থেকে বোঝা যায় যে ঠিকানাটি সামগ্রিকভাবে খারাপ কোয়ালিটির, যদিও বানান সংশোধন করার মতো আরও বিস্তারিত ফ্ল্যাগ থেকে নির্দিষ্ট ধরনের ঠিকানার কোয়ালিটি সংক্রান্ত সমস্যা বোঝা যায়। খারাপ কোয়ালিটি হিসেবে ফ্ল্যাগ করা কোনও ঠিকানার সাথে পরবর্তী গ্রাহক ইন্টার‍্যাকশনের সময় আপনি আগে থেকে থাকা ঠিকানার সাথে Address Validation API কল করতে পারবেন। Address Validation API সঠিক ঠিকানা দেখাবে যা আপনি UI প্রম্পট ব্যবহার করে দেখাতে পারবেন। গ্রাহক ফর্ম্যাট করা ঠিকানা গ্রহণ করলে আপনি উত্তর থেকে নিম্নলিখিত তথ্য ক্যাশে করতে পারবেন:

  • formattedAddress
  • postalAddress
  • addressComponent componentNamesঅথবা
  • UspsData standardizedAddress

হেডলেস ঠিকানা যাচাইকরণ প্রয়োগ করুন

উপরের আলোচনার ভিত্তিতে:

  • Address Validation API থেকে পাওয়া উত্তরের কিছু অংশ ক্যাশে করা প্রায়শই ব্যবসায়িক কারণে প্রয়োজন হয়।
  • তবে, Google Maps Platform-এর পরিষেবার শর্তাবলী অনুযায়ী কোন ডেটা ক্যাশে করা যাবে তা সীমাবদ্ধ করা হয়েছে।

পরবর্তী বিভাগে, আমরা পরিষেবার শর্তাবলী মেনে চলা এবং উচ্চ ভলিউম ঠিকানা যাচাইকরণ বাস্তবায়ন করার বিষয়ে একটি দুই-ধাপের প্রক্রিয়া নিয়ে আলোচনা করব।

ধাপ ১:

প্রথম ধাপে আমরা দেখব কীভাবে একটি বিদ্যমান ডেটা পাইপলাইন থেকে একটি উচ্চ ভলিউম ঠিকানা যাচাইকরণ স্ক্রিপ্ট বাস্তবায়ন করা যায়। এই প্রসেস আপনাকে পরিষেবার শর্তাবলী মেনে Address Validation API রেসপন্স থেকে নির্দিষ্ট ফিল্ড সেভ করার অনুমতি দেবে।

ডায়াগ্রাম ক: নিম্নলিখিত ডায়াগ্রাম থেকে বোঝা যায় যে কীভাবে High Volume Address Validation লজিকের মাধ্যমে ডেটা পাইপলাইন উন্নত করা যায়।

alt_text

পরিষেবার শর্তাবলী অনুযায়ী, আপনি addressComponent থেকে নিম্নলিখিত ডেটা ক্যাশে করতে পারবেন:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

তাই, প্রয়োগ করার এই ধাপ চলাকালীন আমরা UserID-এর বিপরীতে উপরে উল্লেখ করা ফিল্ড ক্যাশে করব।

আরও তথ্যের জন্য আসল ডেটা স্ট্রাকচার সংক্রান্ত বিবরণ দেখুন।

ধাপ ২:

ধাপ ১-এ, আমরা মতামত সংগ্রহ করেছি যে ইনপুট ডেটাসেটের কিছু ঠিকানা উচ্চ মানের নাও হতে পারে। পরবর্তী ধাপে, আমরা এই ফ্ল্যাগ করা ঠিকানাগুলি নেব এবং সেগুলি ব্যবহারকারীর কাছে উপস্থাপন করব এবং সেভ করা ঠিকানা সংশোধন করার জন্য তাদের সম্মতি নেব।

ডায়াগ্রাম খ: এই ডায়াগ্রাম থেকে বোঝা যায় যে ব্যবহারকারীর সম্মতি সংক্রান্ত ফ্লোয়ের এন্ড-টু-এন্ড ইন্টিগ্রেশন কেমন দেখতে হতে পারে:

alt_text

  1. ব্যবহারকারী লগ-ইন করলে, আপনার সিস্টেমে কোনও যাচাইকরণ ফ্ল্যাগ ক্যাশে করা আছে কিনা তা প্রথমে চেক করুন।
  2. কোনও ফ্ল্যাগ থাকলে, ব্যবহারকারীকে তার ঠিকানা সংশোধন ও আপডেট করার জন্য একটি UI দেখানো উচিত।
  3. আপনি আপডেট করা বা ক্যাশে করা ঠিকানা সহ Address Validation API আবার কল করতে পারেন এবং ব্যবহারকারীকে কনফার্ম করার জন্য সঠিক ঠিকানা দেখাতে পারেন।
  4. ঠিকানাটি সঠিক হলে, Address Validation API একটি formattedAddress রিটার্ন করে।
  5. ঠিকানাটি সংশোধন করা হলে আপনি ব্যবহারকারীকে সেটি দেখাতে পারেন অথবা সংশোধন করা না হলে নীরবে গ্রহণ করতে পারেন।
  6. ব্যবহারকারী সম্মতি দিলে, আপনি ডেটাবেসে formattedAddress ক্যাশে করতে পারবেন।

উপসংহার

High Volume Address Validation হল একটি সাধারণ ব্যবহারের কেস যা আপনি অনেক অ্যাপ্লিকেশনে দেখতে পাবেন। এই ডকুমেন্টটি কিছু পরিস্থিতি এবং একটি ডিজাইন প্যাটার্ন দেখানোর চেষ্টা করে যে কীভাবে Google Maps Platform পরিষেবার শর্তাবলী মেনে এই ধরনের সমাধান বাস্তবায়ন করা যায়।

আমরা GitHub-এ ওপেন সোর্স লাইব্রেরি হিসেবে High Volume Address Validation-এর রেফারেন্স ইমপ্লিমেন্টেশন লিখেছি। High Volume Address Validation-এর মাধ্যমে দ্রুত বিল্ডিং শুরু করতে এটি চেক করে দেখুন। এছাড়াও, বিভিন্ন পরিস্থিতিতে কীভাবে লাইব্রেরি ব্যবহার করতে হয় তার ডিজাইন প্যাটার্নের উপর নিবন্ধটি দেখুন।

পরবর্তী ধাপ

নির্ভরযোগ্য ঠিকানার মাধ্যমে চেক-আউট, ডেলিভারি ও অপারেশন উন্নত করুন হোয়াইটপেপার ডাউনলোড করুন এবং Address Validation-এর মাধ্যমে চেক-আউট, ডেলিভারি ও অপারেশন উন্নত করা ওয়েবিনার দেখুন।

আরও পড়ার জন্য সাজেস্ট করা বই:

অবদানকারী

Google এই নিবন্ধটি রক্ষণাবেক্ষণ করে। নিম্নলিখিত কন্ট্রিবিউটররা এটি লিখেছেন।
প্রধান লেখক:

হেনরিক ভালভ | সলিউশন ইঞ্জিনিয়ার
থমাস অ্যাঙ্গলেরেট | সলিউশন ইঞ্জিনিয়ার
সার্থক গাঙ্গুলি | সলিউশন ইঞ্জিনিয়ার