উচ্চ ভলিউমে ঠিকানাগুলি প্রক্রিয়া করতে ঠিকানা যাচাইকরণ API ব্যবহার করুন

উদ্দেশ্য

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

ঠিকানা যাচাইকরণ API হল Google মানচিত্র প্ল্যাটফর্মের একটি পণ্য যা আপনি একটি ঠিকানা যাচাই করতে ব্যবহার করতে পারেন। যাইহোক, এটি একবারে শুধুমাত্র একটি ঠিকানা প্রক্রিয়া করে। এই নথিতে, আমরা এপিআই পরীক্ষা থেকে এককালীন এবং পুনরাবৃত্ত ঠিকানা যাচাইকরণ পর্যন্ত বিভিন্ন পরিস্থিতিতে কীভাবে উচ্চ ভলিউম ঠিকানা বৈধতা ব্যবহার করতে হয় তা দেখব।

কেস ব্যবহার করুন

এখন আমরা বুঝতে পারব যে উচ্চ ভলিউম অ্যাড্রেস ভ্যালিডেশন দরকারী।

টেস্টিং

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

ঠিকানাগুলির এককালীন বৈধতা

ঠিকানা যাচাইকরণ API এ অনবোর্ডিং করার সময়, আপনি ব্যবহারকারী ডাটাবেসের বিপরীতে আপনার বিদ্যমান ঠিকানা ডাটাবেসকে যাচাই করতে চান।

ঠিকানার পুনরাবৃত্তি বৈধতা

পুনরাবৃত্ত ভিত্তিতে ঠিকানা যাচাই করার জন্য বেশ কয়েকটি পরিস্থিতিতে আহ্বান করে:

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

প্রযুক্তিগত গভীর ডুব

এই নথির উদ্দেশ্যে, আমরা অনুমান করি যে:

  • আপনি একটি গ্রাহক ডাটাবেস থেকে ঠিকানা সহ ঠিকানা যাচাইকরণ API কল করছেন (যেমন গ্রাহকের বিবরণ সহ একটি ডাটাবেস)
  • আপনি আপনার ডাটাবেসে পৃথক ঠিকানার বিরুদ্ধে বৈধতা পতাকা ক্যাশে করতে পারেন।
  • বৈধতা ফ্ল্যাগগুলি ঠিকানা যাচাইকরণ API থেকে পুনরুদ্ধার করা হয় যখন একজন পৃথক গ্রাহক লগ ইন করেন।

উৎপাদন ব্যবহারের জন্য ক্যাশে

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

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

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

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

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

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

প্রতিক্রিয়া বুঝুন

যদি ঠিকানা যাচাইকরণ API প্রতিক্রিয়াতে নিম্নলিখিত মার্কারগুলি থাকে, তাহলে আপনি নিশ্চিত হতে পারেন যে ইনপুট ঠিকানাটি বিতরণযোগ্য মানের:

  • Verdict অবজেক্টে addressComplete মার্কার true ,
  • রায় বস্তুর validationGranularity হল PREMISE বা SUB_PREMISE
  • Address Component এর কোনোটিই এইভাবে চিহ্নিত করা হয়নি:
    • Inferred (দ্রষ্টব্য : inferred=true ঘটতে পারে যখন addressComplete=true )
    • spellCorrected
    • replaced
    • unexpected , এবং
  • confirmationLevel : ঠিকানা উপাদানের নিশ্চিতকরণ স্তরটি CONFIRMED বা UNCONFIRMED_BUT_PLAUSIBLE এ সেট করা হয়েছে

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

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

একটি শিরোনামহীন ঠিকানা বৈধতা প্রয়োগ করুন

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

  • ব্যবসায়িক কারণে অ্যাড্রেস ভ্যালিডেশন API থেকে প্রতিক্রিয়ার কিছু অংশ ক্যাশে করা প্রায়ই প্রয়োজন হয়।
  • তবে Google মানচিত্র প্ল্যাটফর্মে পরিষেবার শর্তাবলী কী ডেটা ক্যাশে করা যেতে পারে তা সীমাবদ্ধ করে।

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

ধাপ 1:

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

ডায়াগ্রাম A: নিম্নোক্ত চিত্রটি দেখায় যে কীভাবে একটি উচ্চ ভলিউম ঠিকানা যাচাইকরণ যুক্তি দিয়ে একটি ডেটা পাইপলাইন উন্নত করা যায়।

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

এইভাবে বাস্তবায়নের এই ধাপে আমরা UserID এর বিপরীতে উল্লিখিত ক্ষেত্রগুলিকে ক্যাশে করব।

আরও তথ্যের জন্য প্রকৃত ডেটা কাঠামোর বিশদ বিবরণ দেখুন।

ধাপ 2:

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

ডায়াগ্রাম B : এই চিত্রটি দেখায় যে ব্যবহারকারীর সম্মতি প্রবাহের শেষ থেকে শেষ একীকরণ কেমন হতে পারে:

alt_text

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

উপসংহার

উচ্চ ভলিউম ঠিকানা যাচাইকরণ হল একটি সাধারণ ব্যবহারের ক্ষেত্রে যা আপনি অনেক অ্যাপ্লিকেশনে সম্মুখীন হতে পারেন। এই দস্তাবেজটি Google Maps প্ল্যাটফর্ম পরিষেবার শর্তাবলীর সাথে সামঞ্জস্যপূর্ণ এই জাতীয় সমাধান কীভাবে বাস্তবায়ন করা যায় সে সম্পর্কে কিছু পরিস্থিতি এবং একটি নকশা প্যাটার্ন প্রদর্শন করার চেষ্টা করে।

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

পরবর্তী পদক্ষেপ

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

আরও পড়ার পরামর্শ দেওয়া হয়েছে:

অবদানকারী

Google এই নিবন্ধটি বজায় রাখে। নিম্নলিখিত অবদানকারীরা মূলত এটি লিখেছেন।
প্রধান লেখক:

হেনরিক ভালভ | সমাধান প্রকৌশলী
টমাস অ্যাংলারেট | সমাধান প্রকৌশলী
সার্থক গাঙ্গুলি | সমাধান প্রকৌশলী