প্রতিটি monetization দল এই অনুভূতি জানে: আপনি নিশ্চিত যে একটি waterfall পরিবর্তন রাজস্ব বাড়াবে, কিন্তু যে মুহূর্তে আপনি সেটি লাইভ করেন, তখন আপনি শ্বাস আটকে রাখেন। যদি এটি উল্টো ফল দেয়? যদি fill rate কমে যায়? যদি ভুলটি লক্ষ্য করে তা ফিরিয়ে আনতে যে সময় লাগে, সেই সময়ের মধ্যেই আপনি কোম্পানিকে হাজার হাজার ডলারের ক্ষতি করান?
এই ভয় অযৌক্তিক নয় — এটিই কারণ যে বেশিরভাগ প্রকাশক তাঁদের waterfall কনফিগারেশনগুলি মাসের পর মাস অপরিবর্তিত রাখেন, টেবিলের উপর উল্লেখযোগ্য রাজস্ব ফেলে। সমাধান হল পরিবর্তন করা বন্ধ না করা। সমাধান হল পরিবর্তনগুলি চূড়ান্তভাবে গ্রহণ করার আগে সেগুলি সঠিকভাবে পরীক্ষা করা।
Waterfall টেস্টিং কেন আলাদা
একটি waterfall-এর A/B test একটি বোতামের রঙ বা onboarding flow পরীক্ষা করার মতো নয়। বিজ্ঞাপন রাজস্ব প্রকৃতিগতভাবেই শোরগোলপূর্ণ — এটি ঘণ্টা, সপ্তাহের দিন, ঋতু এবং আরও কয়েক ডজন কারণে ওঠানামা করে। সোমবার যে পরিবর্তনটি 10 শতাংশ উন্নতির মতো দেখায়, তা সম্পূর্ণভাবে স্বাভাবিক সাপ্তাহিক পরিবর্তন দিয়েই ব্যাখ্যা করা যেতে পারে। এবং পণ্যের A/B test-এর বিপরীতে, যেখানে একটি খারাপ variant সামান্য খারাপ ব্যবহারকারী অভিজ্ঞতা তৈরি করে, একটি খারাপ waterfall variant মানে প্রতিদিন হাজার হাজার ডলার হারানো রাজস্ব।
Traffic split পদ্ধতি
Waterfall পরিবর্তনগুলি পরীক্ষা করার সবচেয়ে নিরাপদ উপায় হল আপনার ট্রাফিককে বর্তমান কনফিগারেশন (control) এবং প্রস্তাবিত পরিবর্তনের (variant) মধ্যে ভাগ করা। বেশিরভাগ mediation প্ল্যাটফর্ম — AppLovin MAX এবং Unity LevelPlay সহ — traffic segmentation সমর্থন করে যা আপনাকে ব্যবহারকারীদের একটি শতাংশকে একটি ভিন্ন waterfall কনফিগারেশনে পাঠাতে দেয়।
একটি পরিষ্কার টেস্ট কীভাবে সেট আপ করবেন
90/10 split দিয়ে শুরু করুন: 90 শতাংশ ট্রাফিক আপনার বর্তমান waterfall-এ থাকে, এবং 10 শতাংশ নতুন কনফিগারেশন পায়। এটি আপনার ঝুঁকি ট্রাফিকের 10 শতাংশে সীমাবদ্ধ রাখে এবং একই সঙ্গে অর্থপূর্ণ পার্থক্য শনাক্ত করার জন্য পর্যাপ্ত তথ্য দেয়। বিজ্ঞাপন চাহিদার সাপ্তাহিক চক্র ধরতে অন্তত সাত দিন টেস্ট চালান।
কী পরিমাপ করবেন
শুধু eCPM পরিমাপ করবেন না। উভয় দলের জন্য এই মেট্রিকগুলি ট্র্যাক করুন: প্রতি হাজার দৈনিক সক্রিয় ব্যবহারকারীতে মোট রাজস্ব (revenue per mille DAU), fill rate, গড় eCPM, সেশন প্রতি impression এবং — সবচেয়ে গুরুত্বপূর্ণ — ব্যবহারকারী retention। একটি waterfall পরিবর্তন যা eCPM 15 শতাংশ বাড়ায় কিন্তু বিজ্ঞাপন লোড টাইম বৃদ্ধি করে এবং 7-দিনের retention 2 শতাংশ কমিয়ে দেয়, তা নিট ক্ষতি।
Holdout group পদ্ধতি
আরও উল্লেখযোগ্য পরিবর্তনের জন্য — যেমন একটি demand source যোগ বা সরানো, বা আপনার পুরো waterfall পুনর্গঠন — একটি holdout group ব্যবহার করুন। আপনার ট্রাফিকের 20 শতাংশ স্থায়ীভাবে (বা টেস্টের সময়কালের জন্য) পুরানো কনফিগারেশনে রাখুন এবং অবশিষ্ট 80 শতাংশে নতুন কনফিগারেশন রোল আউট করুন। এটি আপনাকে তুলনার জন্য একটি স্থায়ী বেসলাইন দেয়, যা বিশেষভাবে সেই পরিবর্তনগুলির জন্য মূল্যবান যেগুলির প্রভাব সম্পূর্ণভাবে প্রকাশ পেতে কয়েক সপ্তাহ সময় নিতে পারে।
ধাপে ধাপে রোলআউট
একবার কোনো টেস্ট 10 শতাংশে ইতিবাচক ফলাফল দেখালে, অবিলম্বে 100 শতাংশে পাঠাবেন না। আরও কয়েক দিনের জন্য 25 শতাংশে বাড়ান, তারপর 50, তারপর 75, তারপর 100। প্রতিটি ধাপ আপনাকে একটি চেকপয়েন্ট দেয় যাতে নিশ্চিত হওয়া যায় যে উন্নতি বেশি ট্রাফিক ভলিউমে টিকে থাকে এবং সেই সমস্যাগুলি ধরা পড়ে যা শুধুমাত্র স্কেলে প্রকাশ পায় — যেমন একটি demand partner যা কম ভলিউমে ভাল পারফর্ম করে কিন্তু বেশি ট্রাফিক পেলে fill rate বজায় রাখতে পারে না।
যে প্রকাশকরা ধারাবাহিকভাবে তাঁদের বিজ্ঞাপন রাজস্ব বাড়ান তাঁরা সবচেয়ে সাহসী পরিবর্তন করেন না — তাঁরা প্রতিটি পরিবর্তন পদ্ধতিগতভাবে পরীক্ষা করেন এবং কেবলমাত্র বিজয়ীদের চূড়ান্ত করেন। ছোট, যাচাইকৃত উন্নতিগুলি সময়ের সাথে বিশাল অর্জনে পরিণত হয়।
সাধারণ টেস্টিং ভুল
একবারে অনেক পরিবর্তনশীল পরীক্ষা করা
প্রতি টেস্টে একটি জিনিস পরিবর্তন করুন। আপনি যদি একই সঙ্গে floor price সামঞ্জস্য করেন, একটি নতুন demand source যোগ করেন এবং waterfall অগ্রাধিকার পুনর্বিন্যাস করেন, তবে আপনি ফলাফলকে কোনও একটি পরিবর্তনের জন্য দায়ী করতে পারবেন না। পরিবর্তনশীলগুলি আলাদা করুন।
টেস্ট খুব তাড়াতাড়ি শেষ করা
বিজ্ঞাপন রাজস্বে সপ্তাহের দিনের উল্লেখযোগ্য প্রভাব রয়েছে। সোমবার থেকে বুধবার পর্যন্ত চলা একটি টেস্ট আপনাকে পূর্ণ সপ্তাহান্ত অন্তর্ভুক্ত টেস্টের তুলনায় ভিন্ন চিত্র দেবে। সর্বদা অন্তত সাত পূর্ণ দিন, আদর্শভাবে চৌদ্দ দিন টেস্ট চালান।
Statistical significance উপেক্ষা করা
একটি ছোট ট্রাফিক সেগমেন্টে 5 শতাংশ রাজস্ব উন্নতি শব্দমাত্র হতে পারে। একজন বিজয়ী ঘোষণা করার আগে, নিশ্চিত করুন যে পার্থক্যটি statistically significant — বেশিরভাগ mediation প্ল্যাটফর্ম confidence interval সরবরাহ করে, অথবা আপনি যাচাই করতে স্ট্যান্ডার্ড পরিসংখ্যানমূলক সরঞ্জাম ব্যবহার করতে পারেন।
প্রক্রিয়াটি স্বয়ংক্রিয় করা
একটি managed monetization পার্টনার আপনার পক্ষ থেকে ধারাবাহিক waterfall test চালাতে পারে, স্বয়ংক্রিয় সিস্টেম ব্যবহার করে যা ট্রাফিক ভাগ করে, ফলাফল পরিমাপ করে এবং বিজয়ী কনফিগারেশনগুলিকে প্রচার করে — এ সমস্ত কিছু আপনার প্রকৌশল দলকে টেস্ট অবকাঠামো সেট আপ এবং পরিচালনা করতে বাধ্য না করে। এটি waterfall অপ্টিমাইজেশনকে একটি মাঝে মাঝের ম্যানুয়াল প্রক্রিয়া থেকে একটি ধারাবাহিক উন্নতি ইঞ্জিনে রূপান্তরিত করে।