কুয়েরিকে পেজ ব্রিফে পরিণত করুন
একটি সুনির্দিষ্ট ইনটেন্ট ক্লাস্টার দিয়ে শুরু করুন। কুয়েরি থিম, বিজ্ঞাপন প্রতিশ্রুতি, সম্ভাব্য প্রশ্ন, ডেস্টিনেশন URL, এবং একটি প্রাথমিক অ্যাকশন নথিভুক্ত করুন। একটি ইমার্জেন্সি-প্লাম্বার সার্চ-এ সার্ভিস এরিয়া, অ্যাভেইলেবিলিটি, যোগাযোগ পদ্ধতি, এবং যোগ্যতা দরকার; একটি প্রোডাক্ট-ক্যাটাগরি সার্চে দাম, ফিট, এবং তুলনা তথ্য দরকার হতে পারে।
মেসেজ-ম্যাচ মানে হলো অর্থ সংরক্ষণ করা; এটি কীওয়ার্ড পুনরাবৃত্তি নয়। হিরো অংশে উত্তর থাকা উচিত—এটি কি এবং ভিজিটর কেন ক্লিক করেছে সেই একই অফার বা ফলাফল দিয়ে বোঝানো। যখন ব্যাখ্যামূলক শর্ত সিদ্ধান্তে প্রভাব ফেলে তখন ক্লেইমের পাশে বাদ-ছাড়া, মূল্য নির্ধারণ ভিত্তি, যোগ্যতা, বা ভৌগোলিক সীমাবদ্ধতা রাখুন।
ডিজাইনের আগে কুয়েরি থিম, অফার, শ্রোতা, অ্যাকশন, এবং প্রমাণ কী লাগবে তা লিখে রাখুন।
সঠিক শব্দবিন্যাস এমন একটি অফার মেরামত করতে পারে না যা ব্যবসাটি দিতে সক্ষম নয়।
প্রথম স্ক্রিনকে পরবর্তী অ্যাকশন উপযুক্ত করে তুলুন
একটি পরিষ্কার শিরোনাম, সংক্ষিপ্ত ব্যাখ্যা, দৃশ্যমান অ্যাকশন, এবং সেই অ্যাকশনকে বিশ্বাসযোগ্য করার জন্য প্রয়োজনীয় প্রমাণ ব্যবহার করুন: সঠিক দাম, স্পেসিফিকেশন, ডেলিভারি বিবরণ, যোগ্যতার নিয়ম, রিটার্ন পলিসি, বা উৎসাহজনক ফিডব্যাক। সম্পূর্ণ বিবরণ লুকোনো না করে লিংক করুন।
একটি উল্লিখিত অ্যাকশন ইনটেন্টের সাথে মেলে — “কোটা পান”, “উপলব্ধতা পরীক্ষা করুন”, এবং “এখনই কিনুন” ভিন্ন প্রতিশ্রুতি। যদি প্রথমে তথ্য প্রয়োজন হয়, তাহলে পৌঁছানো সহজ করুন। পপ-আপ, অটো-ডাউনলোড, এবং অপ্রাসঙ্গিক নেভিগেশন এড়িয়ে চলুন যা টাস্ক বিঘ্নিত করে; Google এমন ডেস্টিনেশন নিষেধ করে যা অপ্রয়োজনীয়ভাবে কঠিন বা হতাশাজনক নেভিগেশন সৃষ্টি করে।
মান, অ্যাকশন, এবং গুরুত্বপূর্ণ শর্ত টপ-এ রাখুন; তাদের নিচে সমর্থন দিন।
অযোগ্য সাধারণ দাবির বদলে নির্দিষ্ট, যাচাইযোগ্য ব্যবসায়িক তথ্য ব্যবহার করুন।
মোবাইল ফর্মটি সম্পূর্ণতার জন্য ডিজাইন করুন
ফোনে পথটি চেক করুন: ল্যান্ডিং ভিউ, সম্মতি, ফর্ম, ভ্যালিডেশন, কনফার্মেশন, ফোন লিংক, এবং হ্যান্ডঅফ। সংকীর্ণ ভিউপোর্টে টেক্সট ও কন্ট্রোল ক্লিপ বা ওভারল্যাপ করা যাবে না। WCAG 2.2 বলে যে সাধারণ উল্লম্ব কন্টেন্ট 320 CSS pixels-এ তথ্য অথবা কার্যক্ষমতা হেরে যাওয়া ছাড়াই পুনঃপ্রবাহিত হতে চাই, যেখানে দুই-মাত্রিক লেআউট অপরিহার্য নয়।
প্রতিটি ইনপুটকে দৃশ্যমান, সংশ্লিষ্ট লেবেল দিন এবং অপ্রচলিত ফরম্যাট গুলো উল্লেখ করুন। W3C ব্যাখ্যা করে যে লেবেল ও নির্দেশিকা মানুষকে কি ডেটা প্রত্যাশিত তা বলে এবং ত্রুটি প্রতিরোধ করতে সাহায্য করে। অস্থায়ী ফিল্ড হিন্ট, রঙ, বা কেবল একটি আইকন উপর নির্ভর করবেন না। কীবোর্ড অর্ডার, ফোকাস, এরর, জুম, এবং সাইটের জন্য উপযুক্ত সহায়ক-প্রযুক্তি পর্যালোচনা টেস্ট করুন।
সম্ভব হলে আরামদায়ক আকারের কন্ট্রোল ব্যবহার করুন। WCAG-এর 44 by 44 CSS-pixel টার্গেটটি Level AAA-এ উন্নত মান, আইনগত সার্বজনীন নিয়ম নয়।
শুধু সেই ডেটা চাহুন যা ঘোষিত পরবর্তী ধাপের জন্য প্রয়োজন।
গতির জন্য বাজেট বরাদ্দ করুন এবং পথ রক্ষা করুন
রিলিজের আগে ল্যাব ডায়াগনস্টিক ব্যবহার করুন এবং রিলিজের পরে ফিল্ড ডেটা পর্যালোচনা করুন। Web Vitals LCP-কে গ্রহণযোগ্য লোডিং, INP-কে প্রতিক্রিয়াশীলতা, এবং CLS-কে ভিজ্যুয়াল স্থিরতা হিসেবে সংজ্ঞায়িত করে। ভাল থ্রেশহোল্ডগুলোর সুপারিশ হল LCP 2.5 সেকেন্ডের মধ্যে, INP 200 মিলিসেকেন্ড বা তার কম, এবং CLS 0.1 বা তার কম 75th পার্সেন্টাইল-এ, মোবাইল এবং ডেক্সটপ আলাদা করে। এগুলো বেঞ্চমার্ক; কনভার্শনের নিশ্চয়তা নয়।
প্রথম স্ক্রিনকে অগ্রাধিকার দিন: ইমেজ ডাইমেনশন সেট করুন, সাইজকৃত ইমেজ সরবরাহ করুন, অপ্রয়োজনীয় কোড ডিফার করুন, এবং ধীর রেসপন্স, রেন্ডার-ব্লকিং রিসোর্স, লং টাস্ক, এবং শিফটগুলো তদন্ত করুন। ফাইনাল URL, রিডাইরেক্ট, ক্যাম্পেইন প্যারামিটার, সম্মতি, সাবমিট, কনফার্মেশন, এবং ক্রিটিকাল ডিপেনডেন্সিগুলো পরীক্ষা করুন। কম-ট্রাফিক পেজে ফিল্ড ডেটা নাও থাকতে পারে; ল্যাব চেক ব্যবহার করুন এবং ট্রাফিক বাড়ার সঙ্গে সঙ্গে বাস্তব-ইউজার ডেটা সংগ্রহ করুন।
প্রকাশের আগে প্রতিনিধিত্বমূলক মোবাইল ও ডেক্সটপ কন্ডিশনে পেজ, অ্যাকশন, ও কনফার্মেশন পরীক্ষা করুন।
প্রিভ্লাইট এবং রিমিডিয়েশন অনুশীলন ব্যবহার করে প্রচারণা বাড়ার আগে প্রতিরোধযোগ্য ল্যান্ডিং-পাথ রিগ্রেশন কমান; এখানে SIU পদ্ধতিগুলি কাজে আসে।
বিশ্বাস, ডেটা সংগ্রহ, এবং পেমেন্টকে পরিধিতে রাখুন
ব্যবসায়িক পরিচয়, অফার শর্তাবলী, প্রাইভেসি পছন্দ, এবং যোগাযোগ-রুট বিজ্ঞাপন অনুযায়ী এবং সংবেদনশীল কর্মপূরণের আগে দৃশ্যমান রাখুন। কেবল ঘোষিত উদ্দেশ্যের জন্য প্রয়োজনীয় ডেটাই সংগ্রহ করুন। ভ্যালিডেশন, সম্মতি, এবং রিটেনশন পণ্য ও আইনগত সিদ্ধান্ত; এই প্রবন্ধটি শিক্ষামূলক, আইনগত পরামর্শ নয়।
যদি পথ কার্ড নেয় বা পেমেন্ট ফ্রেম এমবেড করে, স্ক্রিপ্ট ও HTTP-হেডার পরিবর্তনগুলো পেমেন্ট-পেজের সুরক্ষায় প্রভাব ফেলতে পারে। PCI SSC বলে PCI DSS v4.x প্রয়োজনীয়তা 6.4.3 এবং 11.6.1 স্ক্রিপ্ট কর্তৃপক্ষীকরণ ও অখণ্ডতা এবং ট্যামপার মনিটরিং-কে কভার করে, যেখানে সিকিউরিটি-ইমপ্যাক্টিং হেডারও অন্তর্ভুক্ত। অনুমোদিত পেমেন্ট আর্কিটেকচার ব্যবহার করুন এবং বাস্তবায়ন ও অ্যাকুইরার বাধ্যবাধকতা মূল্যায়নের জন্য যোগ্য সিকিউরিটি, কমপ্লায়েন্স, ও লিগ্যাল রিভিউয়ার রাখুন।
পেমেন্ট-অ্যাসফেক্টিং পেজ পরিবর্তনের আগে স্ক্রিপ্ট, মালিক, উদ্দেশ্য, এবং পেজের তালিকা তৈরি করুন।
এই চেকলিস্ট থেকে PCI DSS অনুপালন নিয়োগ করে ধরে নেবেন না; PCI SSC কোনো সত্তার কমপ্লায়েন্স নির্ধারণ করে না।
ফলাফল বিভ্রান্ত না করে পরীক্ষা চালান
একটি হাইপোথিসিস, একটি প্রাথমিক ফলাফল, এবং পেজ এরর, অবৈধ লিড, গতি, এবং বাতিলকরণ মতো গার্ডরেইল নির্দিষ্ট করুন। তুলনার ব্যাখ্যা করার জন্য কুয়েরি থিম, অফার শর্ত, ট্রাফিক সোর্স, মেজারমেন্ট ডেফিনিশন, এবং পেজ পরিবর্তনগুলো যথেষ্ট স্থিতিশীল রাখুন।
Google Ads কর্তৃক একটি ক্যাম্পেইন এক্সপেরিমেন্টকে মূলের বিরুদ্ধে পরীক্ষিত খসড়া হিসেবে সংজ্ঞায়িত করা হয় যা তার ট্রাফিক এবং বাজেটের অংশ ব্যবহার করে একটি নির্দিষ্ট সময়ের জন্য। এটি স্বয়ংক্রিয়ভাবে প্রতিটি ল্যান্ডিং-পেজ URL টেস্ট ভ্যালিড করে না। ভ্যারিয়েন্টগুলো ন্যায্যভাবে তুলনা করার পদ্ধতি ব্যবহার করুন, এক্সপোজার ও তারিখ নথিভুক্ত করুন, এবং গার্ডরেইল ক্ষতিগ্রস্ত করলে ভ্যারিয়েন্ট রোলব্যাক করুন।
যখন জানতে চান কি কারণে ফলাফল এসেছে, তখন শিরোনাম, অফার, ফর্ম দৈর্ঘ্য, ও শ্রোতাকে একসাথে বদলাবেন না।
হাইপোথেসিস, ভ্যারিয়্যান্ট, নিয়ম, মেট্রিক, সীমাবদ্ধতা, ফলাফল, মালিক, ও রোলব্যাক সিদ্ধান্ত সংরক্ষণ করুন।