গেস্ট WiFi প্রোভাইডার পরিবর্তন করা: একাধিক সাইটযুক্ত ভেন্যুর জন্য একটি মাইগ্রেশন চেকলিস্ট

মাল্টি-সাইট ভেন্যু জুড়ে গেস্ট WiFi প্রোভাইডার পরিবর্তন করার জন্য গেস্ট ডেটা এক্সপোর্ট করা, RFC 2865 এবং RFC 2866-এর অধীনে ক্লাউড RADIUS কনফিগার করা এবং পর্যায়ক্রমে রোল আউট করার আগে একটি 14 দিনের পাইলট চালানো প্রয়োজন। Cisco Meraki বা HPE Aruba-এর মতো ভেন্ডরদের বিদ্যমান হার্ডওয়্যার ইকুইপমেন্ট প্রতিস্থাপন না করেই ইন্টিগ্রেট করে, পাশাপাশি একটি 30 দিনের ওভারল্যাপে সমান্তরাল রিপোর্টিং বজায় রাখা নিরবচ্ছিন্ন পরিষেবা নিশ্চিত করে।

গেস্ট WiFi প্রোভাইডার পরিবর্তনের ক্ষেত্রে আসলে কী কী জড়িত?

একটি গেস্ট WiFi প্রোভাইডার পরিবর্তন তিনটি জিনিস স্থানান্তর করে: আপনার গেস্ট ডেটা, আপনার নেটওয়ার্ক সেটিংস এবং আপনার রিপোর্টিং। আপনার অ্যাক্সেস পয়েন্টগুলি যেখানে আছে সেখানেই থাকে। Purple-এর Guest WiFi-এর মতো একটি ক্লাউড ওভারলে-সহ, নতুন প্রোভাইডারটি আপনার আগে থেকেই থাকা হার্ডওয়্যারের উপরেই কাজ করে। সেই হার্ডওয়্যারের মধ্যে রয়েছে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet। এর পেছনের কারণ Why your next WiFi upgrade doesn't need new hardware-এ বিশদ আলোচনা করা হয়েছে।

একটি গেস্ট WiFi মাইগ্রেশনের বেশিরভাগ কাজ তিনটি পরিভাষার অন্তর্ভুক্ত:

• ক্যাপটিভ পোর্টাল: অনলাইনে যাওয়ার আগে একজন ভিজিটর যে সাইন-ইন পেজটি দেখতে পান।
• ওয়ালড গার্ডেন: সাইন-ইন করার আগে কোনও ডিভাইস যে ডোমেনগুলিতে পৌঁছাতে পারে তার তালিকা, যাতে পোর্টাল এবং যেকোনো সোশ্যাল লগইন পেজ লোড হতে পারে।
• RADIUS: RFC 2865-এ সংজ্ঞায়িত প্রোটোকল যা অ্যাক্সেস পয়েন্টগুলি একটি ডিভাইসকে অনুমতি দেওয়া হবে কিনা তা সার্ভারকে জিজ্ঞাসা করতে ব্যবহার করে। এর অ্যাকাউন্টিং এক্সটেনশন, RFC 2866, সেশনের শুরু, শেষ এবং সময়কাল সার্ভারে রিপোর্ট করে।

যে দুটি ব্যর্থতা সবচেয়ে গুরুত্বপূর্ণ তা হলো একটি ডার্ক ডে এবং একটি হারিয়ে যাওয়া তালিকা। ডার্ক ডে হলো এমন একটি সাইট যেখানে কোনো সেটিং মিস হওয়ার কারণে গেস্টরা অনলাইনে যেতে পারেন না। একটি হারিয়ে যাওয়া তালিকা হলো একটি মার্কেটিং ডেটাবেস যা আপনি আর ইমেল করতে পারবেন না কারণ সম্মতির প্রমাণ পুরানো প্রোভাইডারের কাছেই রয়ে গেছে। নিচের কাজের ক্রমটি এই দুটিই প্রতিরোধ করার জন্য তৈরি করা হয়েছে।

গেস্ট WiFi প্রোভাইডার পরিবর্তন করার আগে আপনার কী কী প্রয়োজন?

আপনার চুক্তির তারিখ এবং ডেটা ক্লজ

নেটওয়ার্ক নয়, পুরানো চুক্তি দিয়ে শুরু করুন। তিনটি তারিখ খুঁজুন: নোটিশের শেষ সময়সীমা, পরিষেবা সমাপ্তির তারিখ এবং যেকোনো ডেটা ফেরতের শেষ সময়সীমা। GDPR Article 28(3)(g)-এর অধীনে, একজন প্রসেসরকে পরিষেবা শেষে ব্যক্তিগত ডেটা মুছে ফেলতে হবে বা ফেরত দিতে হবে, নিয়ন্ত্রক হিসাবে এটি আপনার পছন্দের ওপর নির্ভর করে। নোটিশ পাঠানোর আগে পুরানো প্রোভাইডারকে লিখিতভাবে জানান এবং "ফেরত" বিকল্পটি বেছে নিন।

নতুন পরিষেবা চালু হওয়া এবং পুরানো পরিষেবা শেষ হওয়ার মধ্যে অন্তত 30 দিনের একটি ওভারল্যাপের পরিকল্পনা করুন। পরবর্তীতে বর্ণিত সমান্তরাল রিপোর্টিং চালানোর জন্য আপনার সেই ওভারল্যাপ প্রয়োজন। নোটিশের মেয়াদ 90 দিন হলে, উল্টো গণনা করুন: প্রথম পক্ষে এক্সপোর্ট, 45 তম দিনে পাইলট, 75 তম দিনে চূড়ান্ত পর্যায়।

প্রতিটি সাইটের একটি ইনভেন্টরি

যে কাটওভারটি আপনি দেখতে পাচ্ছেন না তার ক্রম আপনি নির্ধারণ করতে পারবেন না। প্রতি সাইটের জন্য একটি করে সারি এবং এই কলামগুলি দিয়ে একটি শিট তৈরি করুন:

• অ্যাক্সেস পয়েন্ট ভেন্ডর এবং কন্ট্রোলার বা ড্যাশবোর্ড (উদাহরণস্বরূপ, Cisco Meraki dashboard, HPE Aruba Central, Ruckus SmartZone)।
• গেস্ট SSID-এর নাম এবং গেস্ট ট্র্যাফিক যে VLAN (ভার্চুয়াল LAN, একটি পৃথক নেটওয়ার্ক সেগমেন্ট)-তে রয়েছে।
• সেই সাইটের ফায়ারওয়াল এবং ব্রডব্যান্ড লাইনের মালিক কে।
• একজন নির্দিষ্ট স্থানীয় পরিচিতি ব্যক্তি যিনি নিশ্চিত করতে পারেন যে পোর্টালটি ফোনে লোড হচ্ছে।
• ব্যবসার শীর্ষ সময় (Trading peaks) এবং ব্ল্যাকআউট তারিখ।

পুরানো প্রদানকারীর থেকে একটি পরিষ্কার এক্সপোর্ট

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

ফিল্ড	কেন এটি আপনার প্রয়োজন	যে ফর্ম্যাটে অনুরোধ করবেন
ইমেল ঠিকানা	মার্কেটিং এবং ডুপ্লিকেশন দূরীকরণের প্রাথমিক চাবিকাঠি	UTF-8 CSV, প্রতি সারিতে একটি রেকর্ড
মোবাইল নম্বর	SMS মার্কেটিং এবং ম্যাচিং	ITU-T E.164 আন্তর্জাতিক ফর্ম্যাট
চ্যানেল প্রতি সম্মতির ফ্ল্যাগ	PECR-এর অধীনে ইমেল এবং SMS-এর সম্মতি পৃথক	প্রতি চ্যানেলে একটি true/false কলাম
সম্মতির টাইমস্ট্যাম্প	সম্মতি কখন দেওয়া হয়েছিল তা প্রমাণ করে (GDPR আর্টিকেল 7(1))	UTC অফসেট সহ ISO 8601
সম্মতির শব্দচয়ন বা সংস্করণ	ভিজিটরকে কী বলা হয়েছিল তা প্রমাণ করে	আর্কাইভ করা পোর্টাল কপির সাথে ম্যাপ করা সংস্করণ ID
Capture সাইট	সম্মতিটিকে সংগ্রহকারী ভেন্যুর সাথে সংযুক্ত করে	আপনার ইনভেনটরির সাথে মিলে যাওয়া সাইট ID
প্রত্যাহার এবং আনসাবস্ক্রাইব	যারা অপ্ট আউট করেছেন তাদের ইমেল পাঠানো বন্ধ করে	তারিখ সহ পৃথক সাপ্রেশন ফাইল
পরিদর্শনের ইতিহাস	রিপোর্ট মেলানোর জন্য ভিত্তিপ্রস্তর	প্রতি সাইটে মাসিক মোট সংখ্যা, বিগত 13 মাস

ফাইল এলে সারির সংখ্যা যাচাই করুন। পুরানো ড্যাশবোর্ড যদি 200,000 প্রোফাইল দেখায় এবং ফাইলে 160,000 থাকে, তবে কোনো কিছুতে সই করার আগেই এর কারণ জানতে চান।

সম্মতির প্রমাণ যা স্থানান্তরের পরেও কার্যকর থাকে

GDPR আর্টিকেল 7(1) বলে যে যেখানে ডেটা প্রক্রিয়াকরণ সম্মতির ওপর নির্ভর করে, সেখানে নিয়ন্ত্রককে তা প্রমাণ করতে সক্ষম হতে হবে। ICO-এর সম্মতির নির্দেশিকায় সেই রেকর্ডে কী কী থাকতে হবে তা উল্লেখ করা হয়েছে: কে সম্মতি দিয়েছেন, কখন, কীভাবে, তাদের কী বলা হয়েছিল এবং তারা তা প্রত্যাহার করেছেন কিনা। "marketing = yes" কলাম সহ ইমেল ঠিকানার একটি স্প্রেডশীট এর কোনো শর্তই পূরণ করে না।

তিনটি ধাপ সম্মতিকে অক্ষত রেখে স্থানান্তর করে:

1. পুরানো পোর্টালের শব্দচয়ন আর্কাইভ করুন। সাইন-ইন পৃষ্ঠা এবং গোপনীয়তা বিজ্ঞপ্তির প্রতিটি সংস্করণের তারিখ সহ স্ক্রিনশট নিন এবং প্রতিটিকে সম্মতির সংস্করণ ফিল্ডের সাথে ম্যাপ করুন।
2. সম্মতি কার নামে রয়েছে তা যাচাই করুন। GDPR রেসাইটাল 42 বলে যে ডেটা সাবজেক্টের অন্তত নিয়ন্ত্রকের পরিচয় জানা উচিত। আপনার ভেন্যু ব্র্যান্ডকে দেওয়া সম্মতি স্থানান্তরিত হয়। পুরানো প্রদানকারীর নিজস্ব মার্কেটিংয়ের জন্য দেওয়া সম্মতি স্থানান্তরিত হয় না।
3. প্রথমে সাপ্রেশন তালিকা ইমপোর্ট করুন। যারা আনসাবস্ক্রাইব করেছেন তাদের প্রথম দিন থেকেই নতুন সিস্টেমে আনসাবস্ক্রাইবড থাকতে হবে।

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

কীভাবে আপনি সাইট ধরে ধরে গেস্ট WiFi মাইগ্রেশন পরিচালনা করবেন?

ধাপ 1: কোনো অ্যাক্সেস পয়েন্ট স্পর্শ করার আগেই তালিকাটি ইমপোর্ট করুন

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

Purple Engage CRM এবং মার্কেটিং প্ল্যাটফর্মগুলির সাথে সংহত হয়। আপনার ইমেল প্ল্যাটফর্মটি যদি আনসাবস্ক্রাইব সংক্রান্ত রেকর্ডের প্রধান মাধ্যম হয়, তবে প্রথম প্রচারণার পরে নয়, আগেই সেটিকে সংযুক্ত করুন।

ধাপ ২: ক্যাপটিভ পোর্টাল, ওয়াল্ড গার্ডেন এবং RADIUS সেটিংস তৈরি করুন

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

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

ধাপ ৩: একটি পাইলট সাইটের কাটওভার সম্পন্ন করুন

এমন একটি পাইলট বেছে নিন যা সাধারণ মানের, সহজ নয়। এটিতে আপনার সর্বাধিক ব্যবহৃত হার্ডওয়্যার থাকা উচিত, স্বাভাবিক সংখ্যক দর্শকের উপস্থিতি থাকা উচিত এবং এটি আপনার IT টিমের নাগালের মধ্যে থাকা উচিত। সবচেয়ে কম ব্যস্ততার সময়ে কাটওভার করুন, যেখানে পুরনো SSID কনফিগারেশনটি সেভ করা থাকবে যাতে আপনি কয়েক মিনিটের মধ্যে পূর্বাবস্থায় ফিরে যেতে পারেন।

কমপক্ষে চারটি ডিভাইসে পরীক্ষা করুন: একটি সাম্প্রতিক iPhone, একটি সাম্প্রতিক Android ফোন, একটি Windows ল্যাপটপ এবং একটি macOS ল্যাপটপ। আপনার দেওয়া প্রতিটি সাইন-ইন পদ্ধতি পরীক্ষা করুন। এরপর প্রথম ওয়েভের আগে পাইলটটিকে ১৪ দিনের জন্য চালু রাখুন, কারণ কিছু ত্রুটি কেবল বাস্তব লোডের সময়েই দেখা দেয়।

ধাপ ৪: ওয়েভ বা পর্যায়ক্রমে কাটওভার করুন

সাইটগুলিকে এমনভাবে গ্রুপ করুন যাতে প্রতিটি ওয়েভে আপনার ইতিমধ্যে প্রমাণিত কোনো কনফিগারেশন পুনরায় ব্যবহার করা যায়। এই ডিসিশন ম্যাট্রিক্সটি ক্রম নির্ধারণ করে।

সাইটের বিবরণ	ওয়েভ	কারণ
সাধারণ সাইট, প্রচলিত হার্ডওয়্যার, IT টিমের কাছাকাছি	পাইলট	৩০টি সাইটের বদলে একটি সাইটেই কনফিগারেশনের ত্রুটি ধরা পড়ে
পাইলটের মতোই একই কন্ট্রোলার বা ড্যাশবোর্ড	ওয়েভ ১	প্রমাণিত টেমপ্লেট, সবচেয়ে কম ঝুঁকি
ভিন্ন হার্ডওয়্যার ভেন্ডার	নিজস্ব পাইলট, তারপর পরবর্তী ওয়েভ	ভেন্ডার অনুযায়ী ওয়াল্ড গার্ডেন এবং RADIUS সিনট্যাক্স আলাদা হয়
সিজনাল বা কম ব্যবসার সাইটগুলি	ওয়েভ ১ বা ২	কোনো ত্রুটি থেকে গেলেও কম সংখ্যক দর্শক প্রভাবিত হন
ফ্ল্যাগশিপ বা সর্বাধিক রাজস্ব অর্জনকারী সাইটগুলি	চূড়ান্ত ওয়েভ	সর্বাধিক প্রমাণিত কনফিগারেশন পায়
পরিকল্পনার মধ্যে ইভেন্ট বা ব্যস্ততম দিন রয়েছে এমন সাইটগুলি	ব্যস্ততম সময়ের আগে ও পরে ৭ দিনের বাফারের বাইরে	আপনার ব্যস্ততম সময়ে কোনো চেঞ্জ ফ্রিজ নীতি লঙ্ঘিত হয় না

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

অনুশীলিত পরিস্থিতি: ৩০টি হোটেলের একটি গ্রুপ

নিচের পরিসংখ্যানগুলো একটি কার্যকর উদাহরণ, কোনো নির্দিষ্ট স্থাপনা নয়। একটি 30টি হোটেলের গ্রুপ তাদের 22টি সম্পত্তিতে Cisco Meraki-এ এবং আটটিতে HPE Aruba-এ গেস্ট WiFi পরিচালনা করে। এদের চুক্তিতে 90 দিনের নোটিশের শর্ত রয়েছে। আপনি আমাদের Hotels পেজে গিয়ে এই ক্ষেত্র সম্পর্কে আরও পড়তে পারেন।

যা করা হয়েছিল। গ্রুপটি Article 28-এর অধীনে "রিটার্ন" বেছে নেয় এবং প্রথম দিনেই নোটিশ জারি করে। দ্বিতীয় সপ্তাহে 210,000 রেকর্ডের এক্সপোর্ট ফাইলটি এসে পৌঁছায়। সেগুলির মধ্যে 31,000 রেকর্ডে সম্মতির কোনো টাইমস্ট্যাম্প ছিল না এবং সেগুলি নন-মার্কেটেবল হিসেবে Purple Engage-এ ইম্পোর্ট করা হয়। পাইলট প্রকল্পটি একটি 120-রুমের Meraki হোটেলে 14 দিনের জন্য চালানো হয়েছিল। বাকি Meraki হোটেলগুলি ড্যাশবোর্ড টেমপ্লেট ব্যবহার করে 10 ও 11টির দুটি পর্যায়ে স্থানান্তরিত করা হয়। Aruba এস্টেটের নিজস্ব পাইলট ছিল, এরপর সেগুলিকে একযোগে সাতটি পর্যায়ে স্থানান্তরিত করা হয়।

ফলাফল। সপ্তম সপ্তাহের মধ্যে সমস্ত 30টি হোটেল নতুন পোর্টালে যুক্ত হয়ে যায়। রাতারাতি পরিবর্তনের সময়সীমার মধ্যে যেকোনো সাইটে দীর্ঘতম বাধা ছিল মাত্র 12 মিনিট। পাইলট প্রজেক্টের দৈনিক সাইন-ইন পুরনো প্রোভাইডারের পরিসংখ্যানের সাথে 3%-এর ব্যবধানে মিলে গিয়েছিল। পুরনো চুক্তিটি 40 দিন অতিরিক্ত সময় হাতে রেখেই সমাপ্ত হয়েছিল।

নতুন রিপোর্টগুলো যে পুরনো রিপোর্টগুলোর সাথে মিলছে, তা আপনি কীভাবে প্রমাণ করবেন?

পাইলট প্রজেক্টে উভয় সিস্টেম সমান্তরালভাবে চালান

আপনি এমন দুটি সিস্টেমের রিপোর্টের তুলনা করতে পারেন না যা কখনই একই ভিজিটরদের পরিমাপ করেনি। পাইলট পক্ষকাল চলাকালীন, এক্সপোর্ট সক্ষম রেখে পুরনো প্রোভাইডারের ড্যাশবোর্ড লাইভ রাখুন। একই তারিখ এবং সাইটের জন্য উভয় সিস্টেম থেকে একই পাঁচটি পরিমাপ বের করুন:

• দৈনিক সাইন-ইন।
• ইউনিক ভিজিটর।
• নতুন বনাম পুনরায় আগত ভিজিটর।
• সেশনের গড় সময়কাল।
• মার্কেটিং অপ্ট-ইন রেট।

Purple-এর WiFi Analytics এই তথ্যগুলি প্রতিটি সাইট এবং সমগ্র এস্টেট জুড়ে রিপোর্ট করে। সেশনের সময়কাল RADIUS অ্যাকাউন্টিংয়ের ওপর নির্ভর করে, তাই এই সংখ্যাটির ওপর নির্ভর করার আগে অ্যাকাউন্টিং রেকর্ডগুলো আসছে কিনা তা যাচাই করে নিন।

মোট সংখ্যার ওপর নয়, সংজ্ঞার ভিত্তিতে সমাধান করুন

প্রথম দিনে মোট সংখ্যা কদাচিৎ মেলে, এবং সেটি কোনো ত্রুটি নয়। বেশিরভাগ পার্থক্য আসে ভিন্ন ভিন্ন সংজ্ঞার কারণে। একজন প্রোভাইডার প্রতিটি ডিভাইস অ্যাসোসিয়েশনকে একটি ভিজিট হিসেবে গণনা করতে পারেন। অন্যজন শুধুমাত্র অথেনটিকেটেড সেশন গণনা করতে পারেন। একজন হয়তো 30 মিনিটের ভেতরের সেশনগুলোকে একত্রিত করতে পারেন, অন্যজন তা নাও করতে পারেন।

প্রতিটি প্রোভাইডারের সংজ্ঞা লিখে রাখুন, তারপর তুলনামূলক বিষয়ের সাথে তুলনা করুন। ডিভাইসের গোপনীয়তা সংক্রান্ত ফিচারগুলোও পুনরায় আগত ভিজিটরদের সংখ্যাকে প্রভাবিত করে। Apple iOS 14-এ প্রাইভেট অ্যাড্রেস চালু করেছে, এবং Android Android 10 থেকে ডিফল্টভাবে অ্যাড্রেস এলোমেলো করে দেয়। যে প্রোভাইডার শুধুমাত্র MAC অ্যাড্রেস দ্বারা পুনরায় আগত ভিজিটরদের শনাক্ত করে, সে সাইন-ইন আইডেন্টিটির সাথে মেলানো প্রোভাইডারের চেয়ে কম রিটার্ন রিপোর্ট করবে।

শুরু করার আগে একটি সহনশীলতার সীমা ঠিক করে নিন, উদাহরণস্বরূপ দৈনিক সাইন-ইনের ক্ষেত্রে 5%। আগে থেকে কোনো সংখ্যা নির্ধারিত না থাকলে, প্রতিটি ব্যবধানই একটি তর্কের বিষয়ে পরিণত হয়।

নোটিশের মেয়াদ শেষ হওয়ার আগেই সাইন অফ করুন

এক পৃষ্ঠার একটি সাইন-অফ তৈরি করুন: যে পরিমাপগুলোর তুলনা করা হয়েছে, প্রতিটি প্রোভাইডারের সংজ্ঞা, ব্যবধান এবং তার ব্যাখ্যা। এতে IT, মার্কেটিং এবং প্রকিউরমেন্ট টিমের স্বাক্ষর নিন। তারপর পুরনো প্রোভাইডারের কাছ থেকে ঐতিহাসিক রিপোর্টগুলির একটি চূড়ান্ত এক্সপোর্ট সংগ্রহ করে রাখুন, যাতে বছরভিত্তিক তুলনা করার বিষয়টি পরিবর্তনের পরেও বজায় থাকে।

বাস্তব প্রয়োগের দৃশ্যপট: একটি 120-স্টোরের রিটেল চেইন

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

যা করা হয়েছিল। পাইলট স্টোরটিতে দেখা গিয়েছিল যে Android ডিভাইসে সোশ্যাল লগইন ব্যর্থ হয়েছে। ওয়াল্ড গার্ডেনে পোর্টাল ডোমেনগুলি ছিল কিন্তু আইডেন্টিটি প্রোভাইডারের সাইন-ইন ডোমেনগুলি ছিল না। IT বিভাগ ওয়েভ 1-এর আগেই এটি ঠিক করে দেয়। প্যারালাল রিপোর্টিং-এ পুরানো প্রোভাইডার Purple-এর তুলনায় 18% বেশি দৈনিক ভিজিট দেখিয়েছে। পুরানো প্রোভাইডার প্রতিটি অ্যাসোসিয়েশন গণনা করেছিল। Purple প্রমাণীকৃত সেশনগুলি গণনা করেছিল। কেবলমাত্র প্রমাণীকৃত সেশনগুলিতে পুরানো এক্সপোর্ট পুনরায় চালানোর ফলে ব্যবধানটি কমে 2%-এ নেমে আসে।

ফলাফল। সমস্ত 120টি স্টোর চারটি সাপ্তাহিক ওয়েভে স্থানান্তরিত করা হয়েছিল। ব্যবসার সময় কোনও স্টোরই গেস্ট WiFi হারায়নি। পুরানো চুক্তি শেষ হওয়ার তিন সপ্তাহ আগে, সম্মত 5% টলারেন্সের বিপরীতে 2% ব্যবধানে সমন্বয়টি অনুমোদিত হয়েছিল।

একটি ক্যাপটিভ পোর্টাল মাইগ্রেশনের সময় অ্যাক্সেস পয়েন্টের কোন সেটিংসগুলি সবচেয়ে বেশি সমস্যার সৃষ্টি করে?

বেশিরভাগ ব্যর্থতাই মূলত কয়েকটি সেটিংসের কারণে ঘটে। এই সারণীতে প্রতিটির তালিকা, ভুল হলে কী লক্ষণ দেখা যায় এবং তার সমাধান দেওয়া হয়েছে।

Setting	Symptom when wrong	Fix
Walled garden missing new portal domains	ফোন কানেক্ট হয়, কিন্তু পোর্টাল কখনই লোড হয় না	Purple-এর ভেন্ডর গাইডের প্রতিটি ডোমেন যোগ করুন, তারপর পুরানো প্রোভাইডারের ডোমেনগুলি সরিয়ে ফেলুন
Walled garden missing social login domains	ইমেল সাইন-ইন কাজ করে, কিন্তু সোশ্যাল লগইন ব্যর্থ হয়	ভেন্ডর গাইডে তালিকাভুক্ত আইডেন্টিটি প্রোভাইডার ডোমেনগুলি যোগ করুন
RADIUS shared secret mismatch	সাইন-ইন গৃহীত হয়, কিন্তু ডিভাইস কখনই অনলাইন হয় না	কন্ট্রোলার এবং নতুন সার্ভার উভয়েই সিক্রেট পুনরায় লিখুন
RADIUS accounting disabled	সাইন-ইন দেখা যায়, সেশনের দৈর্ঘ্য শূন্য দেখায়	অন্তর্বর্তীকালীন আপডেট সহ অ্যাকাউন্টিং (RFC 2866) সক্ষম করুন
Firewall blocking RADIUS ports	সাইন-ইন শুধুমাত্র একটি সাইটেই টাইম আউট হয়	আউটবাউন্ড UDP 1812 এবং 1813 পোর্টগুলির অনুমতি দিন, যেগুলি RFC 2865 এবং RFC 2866-এ নির্ধারিত পোর্ট
Site identifier mapped wrongly	ভুল ভেন্যুতে সেশনগুলি দেখা যায়	কন্ট্রোলারের সাইট আইডেন্টিফায়ারের সাথে Purple সাইট ID মেলান
Old redirect left on one access point group	একটি সাইটের অর্ধেকাংশে পুরানো পোর্টাল দেখা যায়	কেবল ডিফল্ট নয়, প্রতিটি SSID এবং অ্যাক্সেস পয়েন্ট গ্রুপ অডিট করুন
Session timeout copied from the old provider	ভিজিটের মাঝপথেই অতিথিদের পুনরায় অনুরোধ জানানো হয়	আপনার ভিজিটের দৈর্ঘ্য অনুযায়ী টাইমআউট সেট করুন; দেখুন How to Implement Time and Bandwidth Restrictions on Guest WiFi

যে পলিসিগুলি পুরানো প্রোভাইডারের মধ্যে ছিল

কিছু প্রোভাইডার আপনার হার্ডওয়্যারে নয়, তাদের নিজস্ব ক্লাউডে কন্টেন্ট ফিল্টারিং বা ব্যান্ডউইথের সীমাবদ্ধতা প্রয়োগ করে। আপনি পরিবর্তন করার সাথে সাথেই সেই পলিসিগুলি নিঃশব্দে অদৃশ্য হয়ে যায়। পুরানো প্রোভাইডার প্রয়োগ করেছিল এমন প্রতিটি পলিসির তালিকা তৈরি করুন এবং কাটওভারের আগে সেগুলি পুনর্নির্মাণ করুন। দেরিতে চলা নাইট ভেন্যুগুলি প্রায়শই এই সমস্যার মুখোমুখি হয়, যেমনটি Nightclub and late-night venue WiFi providers: content filtering, peak capacity and staff access-এ ব্যাখ্যা করা হয়েছে।

ঘড়ি এবং সার্টিফিকেট সংক্রান্ত সমস্যা

RADIUS অ্যাকাউন্টিং এবং পোর্টাল সার্টিফিকেট - উভয়ই সঠিক সময়ের উপর নির্ভরশীল। ভুল সময়যুক্ত কন্ট্রোলার এমন সেশন রেকর্ড তৈরি করে যা ভুল দিনের অন্তর্ভুক্ত হয়। পাইলট শুরুর আগে প্রতিটি কন্ট্রোলারকে একটি নির্ভরযোগ্য NTP (Network Time Protocol) উৎসের সাথে সংযুক্ত করুন।

পরিবর্তনের খরচ কত, এবং আপনি বিনিময়ে কী পাবেন?

বাজেটের জন্য খরচের খাতসমূহ

বিদ্যমান হার্ডওয়্যারে পরিবর্তনের জন্য চারটি খরচের খাত রয়েছে, যার কোনোটিই হার্ডওয়্যার সংক্রান্ত নয়:

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

Purple তিনটি প্ল্যানের মাধ্যমে লাইসেন্স প্রদান করে: Connect, Capture এবং Engage। প্রকিউরমেন্ট দলের উচিত পরিবর্তনের দিন থেকে পুরো বছরের পরিবর্তে ওভারল্যাপ মেয়াদের ভিত্তিতে প্রয়োজনীয় প্ল্যানের মূল্য নির্ধারণ করা।

বিনিময়ে আপনি কী পাবেন

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

এছাড়াও আপনি বৃহৎ পরিসরে পরীক্ষিত একটি প্ল্যাটফর্মে যুক্ত হবেন। Purple ৯০ টিরও বেশি দেশে ৮০,০০০+ ভেন্যুতে পরিচালিত হয় এবং প্রতি বছর ৫০ কোটি ব্যবহারকারী ও লগইন পরিচালনা করে। Purple ৯৯.৯৯৯% আপটাইম প্রদান করে, ISO 27001 সার্টিফিকেশন ধারণ করে এবং এটি GDPR সম্মত।

সাধারণ জিজ্ঞাসাসমূহ

গেস্ট WiFi প্রদানকারী পরিবর্তন করে Purple-এ যেতে কি আমাদের নতুন অ্যাক্সেস পয়েন্টের প্রয়োজন?

না, Purple আপনার ইতিমধ্যে থাকা অ্যাক্সেস পয়েন্টগুলিতেই চলে। Purple হার্ডওয়্যার-অজ্ঞেয়বাদী এবং এটি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-এর সাথে কাজ করে। এই পরিবর্তনের ফলে আপনার কন্ট্রোলার বা ড্যাশবোর্ডে ক্যাপটিভ পোর্টাল, ওয়াল্ড গার্ডেন এবং RADIUS সেটিংস পরিবর্তিত হয়। আপনার অ্যাক্সেস পয়েন্ট, কেব্লিং এবং সুইচগুলি যথাস্থানেই থাকে, তাই প্রদানকারী পরিবর্তন একটি কনফিগারেশন প্রকল্প, কোনো হার্ডওয়্যার রিফ্রেশ নয়।

পরিবর্তনের পরেও কি আমরা আমাদের বিদ্যমান গেস্ট তালিকায় ইমেল পাঠানো চালিয়ে যেতে পারি?

হ্যাঁ, যদি তালিকার সাথে সম্মতির প্রমাণও স্থানান্তরিত হয়। GDPR-এর অনুচ্ছেদ ৭(১) অনুযায়ী আপনাকে সম্মতি প্রদর্শন করতে হবে, তাই প্রতিটি রেকর্ডে টাইমস্ট্যাম্প, চ্যানেল, ক্যাপচার সাইট এবং ভিজিটর যে বয়ান দেখেছিলেন তা থাকা প্রয়োজন। Purple Engage এই ইতিহাস সংযুক্ত রেখেই সম্মতিপ্রাপ্ত রেকর্ডগুলি আমদানি করে। প্রমাণবিহীন রেকর্ডগুলিকে নন-মার্কেটেবল হিসেবে আমদানি করা উচিত। আপনার ব্র্যান্ডের পরিবর্তে পুরানো প্রদানকারীর নিজস্ব নামে দেওয়া সম্মতি হস্তান্তরযোগ্য নয়।

একটি মাল্টি-সাইট গেস্ট WiFi মাইগ্রেশনে কত সময় লাগে?

২০ থেকে ১৫০টি সাইট বিশিষ্ট অধিকাংশ এস্টেটের জন্য ছয় থেকে আট সপ্তাহের পরিকল্পনা করুন। এতে দুই সপ্তাহের এক্সপোর্ট, ১৪ দিনের পাইলট এবং আপনার টিম এক শিফটে যাচাই করতে পারে এমন আকারের কাটওভার ওয়েভ অন্তর্ভুক্ত থাকে। যে সাইটগুলি ক্লাউড ড্যাশবোর্ড শেয়ার করে সেগুলির কাজ দ্রুত সম্পন্ন হয়, কারণ একটি প্রমাণিত টেমপ্লেট অনেকের ক্ষেত্রে প্রযোজ্য হয়। আপনার পুরোনো চুক্তির নোটিশের তারিখ থেকে পরিকল্পনা শুরু করুন, সমান্তরাল রিপোর্টিংয়ের জন্য কমপক্ষে ৩০ দিনের ওভারল্যাপ রাখুন।

কাটওভারের সময় কি আমাদের সাইটগুলি অফলাইন হয়ে যাবে?

না, আপনি যদি পাইলট-তারপর-ওয়েভ পদ্ধতি অনুসরণ করেন তবে তা হবে না। প্রতিটি সাইট তার সবচেয়ে শান্ত ট্রেডিংয়ের সময়ে পরিবর্তিত হয় এবং পুরোনো কনফিগারেশনটি সেভ রাখা হয় যাতে কয়েক মিনিটের মধ্যে রোলব্যাক করা যায়। বেশিরভাগ বিঘ্ন কেবল কন্ট্রোলারের নতুন সেটিংস পুশ করার সময়টুকু পর্যন্তই স্থায়ী হয়। যেসব ত্রুটির কারণে দীর্ঘ বিভ্রাট ঘটে, যেমন মিসিং ওয়াল্ড গার্ডেন ডোমেন বা ব্লক করা RADIUS পোর্ট, সেগুলি সমগ্র এস্টেটের পরিবর্তে পাইলট সাইটেই ধরা পড়ে।

প্রোভাইডারদের মধ্যে গেস্ট ডেটা স্থানান্তর করা কি GDPR সম্মত?

হ্যাঁ, যখন আপনি কন্ট্রোলার হিসেবে কাজ করেন এবং উভয় প্রোভাইডার চুক্তির অধীনে প্রসেসর হিসেবে কাজ করে। GDPR Article 28(3)(g) অনুসারে, পরিষেবার শেষে আপনার পছন্দ অনুযায়ী পুরোনো প্রসেসরকে ব্যক্তিগত ডেটা ফেরত দিতে হবে বা মুছে ফেলতে হবে। নোটিশ দেওয়ার আগে লিখিতভাবে "ফেরত" দেওয়ার বিষয়টি বেছে নিন। সাপ্রেশন লিস্টটি প্রথমে স্থানান্তর করুন, যাতে যে কেউ অপ্ট-আউট করলে তিনি অপ্ট-আউট অবস্থাতেই থাকেন। Purple হলো GDPR সম্মত এবং ISO 27001 সার্টিফায়েড।

পুরোনো প্রোভাইডারের কাছে এখনও থাকা ডেটার কী হবে?

যদি আপনার চুক্তি GDPR Article 28 অনুসরণ করে, তবে পরিষেবা শেষ হয়ে গেলে পুরোনো প্রোভাইডারকে অবশ্যই তা মুছে ফেলতে হবে। আপনার এক্সপোর্ট যাচাই করার পর এবং রিপোর্টিং সাইন-অফ সম্পন্ন করার পর ডেটা মুছে ফেলার লিখিত নিশ্চয়তা চান। প্রথমে ঐতিহাসিক রিপোর্টগুলির একটি চূড়ান্ত এক্সপোর্ট নিন, কারণ বছর-ওয়ারি তুলনা সেই ইতিহাসের ওপর নির্ভর করে। কোনো নিয়ন্ত্রক বা ভিজিটর জিজ্ঞাসা করলে যাতে দেখাতে পারেন, সেজন্য আপনার প্রসেসিং রেকর্ডের সাথে ডেটা মুছে ফেলার নিশ্চিতকরণটি রাখুন।

আমরা কীভাবে প্রমাণ করব যে Purple-এর রিপোর্ট আমাদের পুরোনো প্রোভাইডারের সংখ্যার সাথে মেলে?

পাইলট সাইটে ১৪ দিনের জন্য উভয় সিস্টেম সমান্তরালভাবে চালান এবং পাঁচটি পরিমাপ তুলনা করুন: দৈনিক সাইন-ইন, ইউনিক ভিজিটর, নতুন বনাম প্রত্যাবর্তনকারী, সেশনের দৈর্ঘ্য এবং অপ্ট-ইন হার। বেশিরভাগ অসঙ্গতি ত্রুটিপূর্ণ ডেটার কারণে নয়, বরং ভিজিটের বিভিন্ন সংজ্ঞার কারণে হয়ে থাকে। প্রতিটি প্রোভাইডারের সংজ্ঞা নথিভুক্ত করুন, আগে থেকেই ৫%-এর মতো সহনশীলতার সীমা নির্ধারণ করুন এবং পুরোনো চুক্তি শেষ হওয়ার আগেই সাইন অফ করুন।

Purple কি আমাদের বিদ্যমান CRM এবং ইমেল প্ল্যাটফর্মের সাথে সংযোগ করতে পারে?

হ্যাঁ, Purple CRM এবং মার্কেটিং প্ল্যাটফর্মের সাথে ইন্টিগ্রেট করে। ইমপোর্ট করা গেস্ট প্রোফাইল, নতুন সাইন-ইন এবং সম্মতির পরিবর্তনগুলি আপনার মার্কেটিং টিমের ইতিমধ্যে ব্যবহৃত সিস্টেমে স্থানান্তরিত হতে পারে। আপনার প্রথম পোস্ট-মাইগ্রেশন ক্যাম্পেইনের আগে ইন্টিগ্রেশনটি সংযুক্ত করুন, যাতে যেকোনো এক দিক থেকে আনসাবস্ক্রাইব করা হলে প্রথম সেন্ড থেকেই তা কার্যকর হয়। এটি WiFi সাইন-ইন এবং ইমেল জুড়ে একটি একক সম্মতির রেকর্ড বজায় রাখে, যা ICO-এর সম্মতি নির্দেশিকা অনুযায়ী আপনার কাছে থাকা প্রত্যাশিত।