О опыт, сын ошибок трудных....
Знакомство с клиентом Х
Познакомились мы в 2016 году через upwork, клиент попросил сделать смесь adnetwork - marketplace.
У клиента большой опыт в традиционной рекламе, есть понимание перспектив онлайн рекламного рынка.
Цель системы была упростить работу паблишерам и адвертайзерам, собрать их под свое крыло и монетизировать.
Первая версия системы
Клиент решил, что адвертайзерам нужна единая панель по управлению кампаниями, информация об эффективности паблишеров, доступ к аудиториям.
Паблишерам нужна простота установки тега, рилтайм статистика, простой биллинг.
Согласились с видением клиента.
Сделали MVP показали клиенту, получили оплату, система не используется.
Вторая начальная версия системы
Клиент Х впечатлен технологией Header bidding, рассказываем ему о преимуществах и недостатках.
Решили делать s2s интеграцию с 12-ю ssp.
Тут надо отвлечься на особенности технологии header bidding.
Она возникла как ответ на привязанность паблишеров к ssp.
Суть проблемы в том, что, однажды выбрав ssp, паблишеру приходится работать именно с этой ssp, чем ssp и злоупотребляли, занижая цены и прибыль паблишера.
Технология header bidding позволяет посылать запрос в несколько ssp/exchanges и затем откручивать рекламу предложившему более выгодную цену.
Многие крупные игроки Appnexus, например, попробовали отжать рынок у гугла и всячески поддерживали prebid.js продвигали свои adservers для открутки.
Гуглу пришлось немного извернуться и изменить оригинальную концепцию DFP, и подвинуть его все таки не удалось.
Итак, отправляя запрос с сайта в несколько ssp паблишер в идеале получает более высокий филлрейт и больше прибыли.
Есть ключевой недостаток - сайт замедляется, при отправке более 7 запросов одновременно работать с сайтом не возможно.
Ключевой становится метрика insertion time время от начала работы тега до вставки рекламы.
Решить эту проблему призвана s2s header bidding
В этом случае запрос паблишера отправляется одной ссп, а та уже торгует с другими ssp.
Никаких задержек - торги идут на серверной стороне.
Есть ряд дополнительных технических проблем, например, доступ к кукам, но они решаемы.
Начинаем работы
Итак, мы начинаем работы, делаем интерфейс и одну s2s интеграцию и в определенный момент платежеспособность клиента резко ухудшается.
Сделав определенный объем работ, стопим проект.
Напоминаем клиенту о задолженности. Получаем “завтраки”.
Вторая промежуточная или футбол объединяет
За полтора месяца до чемпионата мира 2018 узнаем, что причиной задержек оплаты послужила реорганизации и релокации бизнеса клиента в другую страну для участия в стартап-инкубаторе от крупного exchange.
Договариваемся встретиться на чемпионате мира в Москве и обсудить дальнейшие планы.
Встречаемся на чемпионате мира, обсуждаем перспективы рынка, договариваемся о графике платежей.
Получаем оговоренные платежи, начинаем работы, делаем s2s интеграции, ругаясь на несоответствие документации и реальности и отсутствию обратной связи с саппортом ssp.
Делаем 3 интеграции, к которым есть доступ и документация из 10 и активность затихает - никто не из SSP не спешит интегрироваться со стартапом по S2S, несмотря на все старания.
Клиент приезжает к нам в Рязань, знакомится с командой.
Говорит, что ссп не хотят с ним работать.
Предлагаем клиенту просто прикрутить аналитику сверху prebid.js, работать пока так, но в этом случае он ничем не будет отличаться от других агрегаторов статистики prebid.
Спрашивает, что будет если вместо использования s2s мы будем обращаться через интерфейс для пребида для простых паблишеров, а затем проводить аукцион на сервере.
Отвечаем что будет очень медленно, но кое-как работать будет, приходим к решению что для бизнес целей и альфа версии пойдет.
Вторая версия - тестовый запуск
Делаем большую часть интеграций, по части интеграции ссп саппорт молчит.
Делаем адаптер для prebid.js для использования системы из стандартного prebid.js.
Развертываем альфа версию системы на нескольких десятках сайтов.
Видим низкий филлрейт и низкий ECPM, начинаем разбираться.
Обвешиваем всю систему ивентами видим insertion time - 3-6 секунд при норме 1-2.
DFP - как adserver, отдает рекламу 800 ms вместо 300 ms ссп отвечают по секунде-две, наш код отъедает 250-400 мс
Предлагаем клиенту просто прикрутить аналитику сверху prebid.js, работать пока так, а в это время договариваться с ссп про s2s
Клиент начинает паниковать и во всем винить нас.
Ссора
Готовим свой отчет со следующими выводами
- быстрые сайты с отсутствием ошибок в коде и не загруженные фоновыми скриптами работают нормально и укладываются в 1 секунду
- s2s интеграции работают очень быстро примерно 200-300 мс
- медленные сайты агрегаторы с сотнями скриптов внутри показывают отвратительные результаты
- показываем пример на таком сайте новостей где setTimeout(1 ms) выполняется 7 секунд
То есть, сайты настолько загружены скриптами, что скрипт не получает шанс выполниться, а повторный вызов скрипта почти не возможен.
Клиент проводит встречный аудит
- adtech аудитор из США говорит: "какие плохие результаты" это из-за скорости и предлагает переписать все на простой клиентский prebid, хм.
- ребята из россии смотрят как мы настраиваем clickhouse и предлагают переписать запросы написанные собственными разработчиками клиента и серверов докупить.
Никто причину именно низкого fillrate не объясняет
Клиент говорит, что он не будет платить так как не получил работающий продукт, говорит что он только заказчик, за решения не отвечает и хочет рабочий продукт.
Понимаем, что клиент переваливает свои риски на нас, о чем мы не договаривались.
Принимаем решение постепенно завершать работы с клиентом.
Завершение проекта, или третья версия системы
Договариваемся с клиентом об оплате уже подтвержденной части работ, неподтвержденной приходится жертвовать.
После оплаты передаем ему код.
Все задачи на проекте переводятся на детальную формализацию и письменное подтверждение клиентом.
За дополнительную плату переписываем ему все на клиентский prebid.js - изначальное решение и вешаем существующую систему как просто аналитику.
Передаем все решение в ответственность американского adtech консультанта
Так как нашего кода больше на клиенте нет, никаких претензий к нам быть не может.
Чтобы не остановить стартап 3 месяца по доброй воле бесплатно консультируем и поддерживаем код.
Опыт
Итак 20 мая заканчивается срок нашей добровольной и бесплатной поддержки клиента X.
Мы много узнали о header bidding
- то что он может и не запуститься на загруженном или кривом сайте или запуститься с задержкой
- то что ссп не горят желанием делиться s2s интеграциями с каждым встречным и поперечным
- ссп не любят общаться с мелкими и начинающими клиентами, обновлять документацию, и решать интеграционные проблемы
- то что при работе в асинхронном режиме статистика с ssp точно не будет сходится потому что пиксел ссп не отработает
- то что для коррекции статистики на глаз есть специальный параметр в пребид, т.е если мы знаем что теряется 15% пикселов ссп то можем зашить это в статистику.
- то что написать адаптер для prebid.js - совсем не сложно
- то что решения с эмуляцией s2s через prebid.js, будут показывать худшие результаты чем просто prebid и s2s
проект жив, клиент х работает с несколькими независимыми подрядчиками, проект набирает подписчиков и инвесторов.
Alexander Eriomenko
CEO IAGE ENGINEERING
skype: alexander.eriomenko
phone: +7 (910) 644-08-00