Всеки екип по монетизация познава усещането: сигурни сте, че промяна във waterfall ще увеличи приходите, но в мига, в който я пуснете в production, затаявате дъх. Ами ако се обърка? Ами ако fill rate спадне? Ами ако току-що струвате на компанията си хиляди долари за времето, необходимо да забележите и върнете промяната?
Този страх не е ирационален — това е причината повечето издатели да оставят конфигурациите на waterfall недокоснати с месеци, оставяйки значителни приходи на масата. Решението не е да спрете да правите промени. То е да ги тествате правилно, преди да ги потвърдите окончателно.
Защо тестването на waterfall е различно
A/B тестването на waterfall не е като тестване на цвят на бутон или onboarding поток. Приходите от реклами са присъщо шумни — те се колебаят по час, ден от седмицата, сезон и десетки други фактори. Промяна, която изглежда като 10 процента подобрение в понеделник, може изцяло да се обясни с нормална седмична вариация. И за разлика от продуктовите A/B тестове, при които лош вариант причинява леко по-лошо потребителско изживяване, лош waterfall вариант може да означава хиляди долари загубени приходи на ден.
Подходът с разделяне на трафика
Най-безопасният начин да тествате промени във waterfall е да разделите трафика между текущата конфигурация (control) и предложената промяна (variant). Повечето mediation платформи — включително AppLovin MAX и Unity LevelPlay — поддържат сегментиране на трафика, което ви позволява да насочите процент от потребителите към различна waterfall конфигурация.
Как да подготвите чист тест
Започнете със split 90/10: 90 процента от трафика продължава по текущия ви waterfall, а 10 процента получават новата конфигурация. Това ограничава риска ви до 10 процента от трафика, като същевременно ви дава достатъчно данни, за да откриете значими разлики. Пуснете теста за поне седем дни, за да уловите седмичната цикличност в търсенето на реклами.
Какво да измервате
Не измервайте само eCPM. Проследявайте тези показатели за двете групи: общи приходи на хиляда дневно активни потребители (revenue per mille DAU), fill rate, среден eCPM, impression-и на сесия и — критично важно — задържане на потребители. Промяна във waterfall, която вдига eCPM с 15 процента, но увеличава времето за зареждане на реклами и свежда 7-дневното задържане с 2 процента, е нетен минус.
Методът на holdout група
За по-значителни промени — като добавяне или премахване на demand source, или преструктуриране на целия ви waterfall — използвайте holdout група. Задръжте 20 процента от трафика на старата конфигурация постоянно (или за продължителността на теста) и пуснете новата конфигурация към останалите 80 процента. Това ви дава устойчива базова линия за сравнение, което е особено ценно за промени, чието въздействие може да отнеме седмици, за да се прояви напълно.
Постепенно внедряване
След като един тест показва положителни резултати при 10 процента, не бързайте веднага да го пускате на 100 процента. Увеличете до 25 процента за още няколко дни, после 50, после 75, после 100. Всяка стъпка ви дава контролна точка, за да потвърдите, че подобрението се запазва при по-голям обем трафик, и да уловите проблеми, които се проявяват само при мащаб — например demand партньор, който се представя добре при нисък обем, но не може да поддържа fill rate, когато получи повече трафик.
Издателите, които последователно увеличават приходите си от реклами, не са тези, които правят най-смелите промени — те са тези, които тестват всяка промяна методично и потвърждават само победителите. Малките, валидирани подобрения се натрупват в огромни печалби с течение на времето.
Често срещани грешки при тестване
Тестване на твърде много променливи наведнъж
Променяйте по едно нещо на тест. Ако едновременно коригирате floor price-овете, добавяте нов demand source и пренареждате приоритета на waterfall, не можете да припишете резултата на нито една промяна. Изолирайте променливите.
Прекратяване на тестовете твърде рано
Приходите от реклами имат значителни ефекти в зависимост от деня на седмицата. Тест, който върви от понеделник до сряда, ще ви даде различна картина от тест, който включва пълен уикенд. Винаги пускайте тестове за поне седем пълни дни, в идеалния случай четиринадесет.
Игнориране на статистическата значимост
Подобрение на приходите от 5 процента на малък сегмент трафик може да е шум. Преди да обявите победител, уверете се, че разликата е статистически значима — повечето mediation платформи предоставят confidence interval-и, или можете да използвате стандартни статистически инструменти за проверка.
Автоматизиране на процеса
Управляван monetization партньор може да провежда непрекъснати waterfall тестове от ваше име, използвайки автоматизирани системи, които разделят трафика, измерват резултатите и популяризират печелившите конфигурации — всичко това, без да изисква инженерният ви екип да настройва и управлява тестова инфраструктура. Това превръща оптимизацията на waterfall от случаен ръчен процес в непрекъснат двигател за подобрение.