Сервисы
Evgeny Guryanov
3994

А не фигню ли я придумал: «поиск» в продукте, часть третья

Привет! Я Женя Гурьянов, Chief Product Officer в компании DocDoc. В своих статьях я рассказываю, как внедрять и развивать «поиск» в продуктах. В этой статье я расскажу о метриках поисковой выдачи, а также о том, как можно проверить, что вы не придумали ерунды: офлайн- и онлайн-оценки поисковой выдачи.

В закладки
Аудио

В первой статье я рассказывал про то, как наполнять бэклог развития «поиска» в продукте и как приоритизировать поисковые задачи.

Во второй статье я даю ответы на вопросы:

  • Что такое релевантность?
  • Как построить поиск книг в электронной библиотеке?
  • Как построить поиск объявлений в онлайн-классифайде?

Итак, теперь к статье.

Метрики поисковой выдачи

Допустим, у вас уже есть поисковая выдача. Вы хотите понимать, ведут ли изменения алгоритма ранжирования к успеху или только ухудшают ситуацию?

Давайте разобьём метрики на две группы: поисковые и бизнесовые (разделение больше формальное).

Поисковые, кликовые метрики

CTR@5, CTR@10

CTR@N — это отношениеколичества выдач, в которых был хотя бы один клик в первые N позиций в выдаче, к количеству всех выдач. Измеряется в процентах.

Давайте поясню формулой для CTR@10.

Чем выше CTR, тем лучше

Average Highest Click (AHC)

Средняя позиция клика в выдаче (если пользователь сделал несколько кликов в конкретной выдаче, то выбирается наивысший клик).

Пример: у вас три кликнутых выдачи, клики были на второй, шестой и первой позициях. Подсчёт: AHC = (2 + 6 + 1) / 3 = 3.

То есть средняя позиция наивысшего клика в нашем примере — третья. Очевидно, что кейс идеальной выдачи, это когда пользователи кликают на первую позицию в выдаче (AHC = 1).

Важно: чем меньше Average Highest Click, тем лучше.

Доля кликнутых выдач

Отношение количества всех выдач, в которых был хотя бы один клик на сниппет, к количеству всех выдач.

Также важно учитывать две следующие метрики:

  1. Доля нулевых выдач: отношение количества выдач, в которых не было ни одного найденного документа, к количеству всех выдач.
  2. Доля малых выдач: если вам важно давать пользователю большой ассортимент товаров, услуг или предоставлять большой выбор поставщиков, полезно будет смотреть на данную метрику. Для различных продуктов малая выдача может определяться по-разному. Давайте для примера определим её как выдачу, в которой найдено не более пяти документов.
Формула расчёта доли

Бизнес-метрики

Скорее всего, вы работаете над поисковой выдачей не просто в отрыве от бизнеса, а для достижения конкретных целей. Понятно, что финальной целью функционирования бизнеса будут деньги. Но не всегда можно напрямую завязаться на деньги. Рассмотрим пару примеров бизнес-метрик.

Классифайды: «Юла», Avito

Если не принимать в расчёт рекламу на сайтах, то основные деньги приносят продавцы (они платят за поднятия объявлений, премиум-размещения), но поисковая выдача напрямую влияет на покупателей.

Поэтому сложно привязать рост выручки непосредственно к изменению алгоритма работы поисковой выдачи (особенно в A/B- тесте). И поэтому вполне нормальным было бы привязать успех к количеству контактов или количеству покупателей в продукте.

Логика следующая: становится больше покупателей (можно проверять в разрезах: все объявления, платные объявления) → становится больше сделок → продавцы более мотивированы размещать товары и платить за рекламу.

Социальные сети: Facebook, «ВКонтакте», Linkedin и другие

Обычно на вершине иерархии метрик для соцсетей стоит время, в среднем проводимое пользователем в соцсети за день (timespent).

Далее метрики каскадируются. Давайте поговорим, например, про поиск людей или друзей. Как оценивать работу поисковой выдачи? Вполне резонный ответ — по количеству добавленных в друзья.

Логика следующая: чем больше у пользователя друзей в соцсети, тем больше он зависит от неё и больше проводит там времени. Рост количества друзей → рост timespent-показателя.

DocDoc

Деньги DocDoc приносит запись к врачу. До записи есть ещё заявка на запись. Поэтому, казалось бы, для измерения «хорошести» алгоритма поисковой выдачи можно использовать метрику «количество заявок или записей». Но не тут то было.

В реальности всё сложнее: разные клиники могут предоставлять разный чек для записи к разным врачам. Соответственно, даже при увеличении количества записей выручка может уменьшиться. В этом случае завязывать успех надо на выручку.

Ловушки метрик ускорения поиска пользователя

Почему бы не попытаться помочь пользователю быстрее находить то, что он ищет? Для этого надо работать над следующими метриками поиска:

  • Количество шагов до целевого действия.
  • Время до целевого действия.

Кажется, что при уменьшении этих метрик счастье пользователя должно расти. На самом деле не всегда. Рассмотрим это на примере классифайда.

Целевым действием пользователя считаем первый контакт в день в конкретной категории (собственно, тогда можно считать пользователя покупателем в конкретной категории). Мы пытаемся сократить время или количество действий до первого контакта.

В одной из статей, написанной ранее, я предлагал потенциальную доработку в Avito и «Юле» — пробрасывать пользователя при конкретном запросе марки и модели авто в нужную ему категорию. В примере был запрос «шевроле траверс».

Теперь представим себе, как это может повлиять на поведение пользователя и выбранные метрики поиска. Для этого рассмотрим варианты с пробросом в нужную категорию и без проброса.

  • Если проброса нет, пользователь после текстового поиска видит объявления, выданные ему по всем категориям. Он не провалился в категорию «Автомобили», соответственно не видит фильтры (цена, тип автомобиля, год выпуска). Пользователь вынужден выбирать из предложенных объявлений и, чтобы уточнить информацию, входит внутрь объявлений и по некоторым из них делает контакты.

Если пользователя пробрасывать в нужную ему категорию, он сразу же видит, что ему доступна куча фильтров, которые помогут уточнить его выбор. Пользователь начинает сужать искомое множество.

Время до первого контакта растёт, число действий также растёт (пользователь прокликивает фильтры). Итого: пользователь ищет дольше. Но больше пользователей делают контакт, и контактов на пользователя становится больше.

То есть в примере замедление совершения первого целевого действия не снижает счастье пользователя, а напротив, увеличивает его.

Ну и не забываем про скорость работы поисковой выдачи

Придумывая новый супералгоритм поисковой выдачи, вы можете нечаянно реализовать что-то, что будет работать в разы медленнее чем то, что было ранее.

Важно следить не только за метриками, которые были описаны выше, но и за скоростью работы выдачи.

Почему это важно? Потому что скорость отображения выдачи может влиять на продуктовые метрики вашего продукта: если пользователь огорчён скоростью работы поиска или не дождался результатов, он может покинуть ваш продукт.

Вы можете проверить, насколько скорость отображения выдачи влияет на метрики продукта, просто проведя ухудшающий А/B-тест (искусственно замедлив выдачу в тестовой группе). При этом важно понимать, что функция влияния скорости отображения выдачи на продуктовые метрики может отличаться в различных диапазонах скорости выдачи.

Как понять, что вы не придумали ерунду

Теперь перейдём к более подробному ответу на вопрос, как оценивать эффективность работы алгоритма поисковой выдачи и как сравнивать два алгоритма между собой.

Есть офлайн- и онлайн-оценка работы алгоритмов.

Подходы, приведённые ниже, можно использовать как при составлении формулы ранжирования вручную, так и при машинном обучении с учителем.

Офлайн-оценка поисковой выдачи

Документы

Вы фиксируете набор документов(слепок документов), на которых будете обучать и оценивать ваш алгоритм ранжирования.

  • В задаче поиска книг в электронной библиотеке — список книг в конкретный момент времени (со всей доступной по ним информацией).
  • В задаче для классифайда (Avito, «Юла») — набор объявлений на конкретную дату.
  • В задаче ранжирования докторов на сайте DocDoc — данные об анкетах врачей.

Запросы

На каких запросах оценивать качество работы поиска. Очевидно, что не на всех, которые вбивали пользователи за последние два года.

Нужна выборка запросов для оценки. Для начала я советую не париться и выбрать запросы для оценки из базы случайно. Например, вынуть из всей базы с запросами пользователей 1000 запросов для оценки. В них будет представлена голова и хвост.

Хороший вопрос — за какой период выбирать запросы?

Ответ зависит от продукта:

  • С одной стороны, для получения самых актуальных данных надо выбирать запросы за последнее время (например, за месяц).
  • С другой стороны, для учёта сезонности хорошо бы выбрать запросы за весь год: люди ищут разные вещи, например, зимой и летом (тогда и слепок базы надо будет подгонять под сезонность).

Поэтому если в поиске продукта нет сезонности или она слабая, можно брать наиболее актуальные данные — за месяц.

Если в продукте есть сезонность (например, классифайд), то в идеале её стоит учитывать. В выборку могут попасть такие сезонные запросы, как «дома под ключ», «лыжи», «детские самокаты».

Оценщики или асессоры

Как вы уже догадались из названия подхода («офлайн...»), оценка работы алгоритма производится не реальными пользователями на бою. Оценка происходит специально подобранными экспертами — асессорами. Асессор — это оценщик качества работы поискового алгоритма.

Откуда взять этих асессоров?

Во-первых, те люди, которые работают над улучшением поиска, должны понимать, как и что ищут пользователи (в первую очередь понимание должно быть у продакт-менеджера).

Во-вторых, при работе над поисковыми алгоритмами вам понадобится оценить огромное количество документов по различным запросам, поэтому на помощь приходит «Яндекс.Толока». В неё вы сможете загрузить свои задания и подобрать асессоров, которые быстро дадут вам столь необходимые данные.

Далее я хочу рассмотреть два подхода к офлайн-оценке: поточечный (pointwise approach) и попарный (pairwise approach).

Поточечный подход

Оценки

В данном подходе каждой паре «запрос пользователя — выданный документ» поставлена в соответствие числовая оценка. Один из подходов к варианту оценки:

  • 0 — этот документ для меня не релевантен (это не то, чего я хотел).
  • 1 — релевантный документ (более-менее ОК).
  • 2 — очень релевантный документ (прямо в точку!).

Как только мы определились с оценками, запросами и корпусом документов, на котором будем оценивать релевантность, можно делать первые подходы к получению оценок.

Чтобы стало ещё понятнее, давайте разберём на примере «Юлы». Пользователь ищет услуги ремонта для смартфона. Есть вероятность, что у него что-то с экраном телефона (но это не точно).

Вводим запрос «ремонт samsung galaxy s5»

Предположим, наш алгоритм выбрал и отранжировал из базы объявлений следующие:

Привожу пример объявлений с прода

Я немного поработал асессором и проставил оценки (красным цветом). К сожалению, я посчитал, что в выдаче не было ни одной «двойки», но и такое бывает.

Надеюсь, стало понятнее, что означают оценки и как они расставляются. Допустим, вы получили оценки для всех пар «запрос — документы». Идём дальше.

Офлайн — метрики качества ранжирования

Есть несколько метрик качества ранжирования. Перечислю для наиболее пытливых читателей: DCG, NDCG, MAP, precision@N, NDCG@N, pFound (подробнее в статье на «Википедии»).

Для общего понимания я бы остановился на NDCG (Normalized Discounted Cumulative Gain.). Да и то с целью качественно пояснить, как работает и рассчитывается данная метрика.

Допустим, что на запрос X алгоритм вернул выдачу, результаты которой оценены асессорами следующим образом:

  • Первый документ — 0 (не релевантен).
  • Второй документ — 2 (прямо в точку).
  • Третий документ — 0 (не релевантен).
  • Четвёртый документ — 1 (более-менее релевантен).
  • Пятый документ — 1 (более-менее релевантен).
  • Шестой документ — 2 (прямо в точку).
  • Седьмой документ — 0 (не релевантен).
  • Восьмой документ — 0 (не релевантен).
  • Девятый документ — 1 (более-менее релевантен).
  • Десятый документ — 0 (не релевантен).

Для примера рассмотрим десять первых результатов. Будем рассчитывать NDCG@10.

Очевидно, что идеальный порядок тех же документов в выдаче выглядит следующим образом (чем релевантнее, тем выше). Это идеальная выдача:

  • Второй документ — 2 (прямо в точку).
  • Шестой документ — 2 (прямо в точку).
  • Четвёртый документ — 1 (более-менее релевантен).
  • Пятый документ — 1 (более-менее релевантен).
  • Девятый документ — 1 (более-менее релевантен).
  • Оставшиеся пять нерелевантных документов.

Представим, что можно посчитать некоторое число для измерения того, насколько текущая выдача хуже идеальной.

Для этого я вас проведу по вычислениям cumulative gain (CG), discounted cumulative gain (DCG) и nDCG@10.

Первый показатель — просто сумма всех десяти оценок (CG@10 = 0 + 2 + 0 + 1 + 1 + 2 + 0 + 0 + 1 + 0 = 7)

При последующем подсчёте учитывается принцип «пользователи просматривают документы сверху вниз».

Также пользователи зачастую нетерпеливые и могут не дойти до документов в нижней части выдачи. Поэтому вводятся веса для учёта положения документа в выдаче. Чем ниже релевантный документ в выдаче, тем ниже у него вес. Итак, чем выше сниппет, тем лучше.

Таким образом подсчитываем то, что называется DCG.

Для нашего примера DCG@10 равен 3,093
Для идеальной выдачи DCG равен 4,579

Тогда nDCG@10 равен 0,675 (3,093 ÷ 4,579).

Очевидно, что максимально достижимый nDCG равен единице (если бы наша выдача совпадала с идеальной). Поэтому тот nDCG, который мы получили, — некая мера того, насколько мы приблизились к идеальной выдаче.

На этом мы закончили рассмотрение поточечного подхода к оценке нашей выдачи. Перейдём к краткому рассмотрению попарного подхода.

Попарный подход

В поточечном подходе каждому документу в выдаче мы выставляли одну из трёх цифр для оценки (0, 1, 2). Но в таком подходе есть две проблемы:

  1. Сложно понять «правильную» позицию документа в выдаче по отношению к другим документам с той же оценкой (как должны располагаться два документа с «единичной» оценкой относительно друг друга?).
  2. Асессорам сложно проставлять какую-то абсолютную оценку (например, в некоторых случаях сложно выбрать между единицей и двойкой).

Для более точного оценивания и решения вышеописанных проблем используется попарный подход к оценке.

Пример задания для попарного сравнения сниппетов по запросу «дерматолог» в DocDoc. Сравнивается именно желание записаться на приём к конкретному дерматологу (правому или левому).

После достаточно большого количества попарных сравнений можно определить точнее идеальный порядок врачей в выдаче.

Нюансы работы с асессорами

В наш самый первый подход к «Толоке» мы не стали заморачиваться на долгой подготовке инструкции и контрольных заданий (golden dataset) для асессоров. Мы запустили небольшую порцию заданий на асессоров и затем руками проверили качество ответов (некое MVP). Результат оказался печальным. Зато задания были выполнены практически мгновенно :)

Почему это происходит? Мы сталкивались с двумя проблемами:

  1. Асессоры не понимают задание, которое необходимо выполнить.
  2. Некоторые асессоры могут обманывать, намеренно прокликивать случайные ответы в тесте.

Нам пришлось провести ещё пару итераций работы над системой контроля качества, чтобы добиться необходимого уровня качества ответов.

Над чем я рекомендую поработать:

  • Обязательно подготовьте инструкцию и обучающий пулзаданий. Для начала мы тестировали эти артефакты на коллегах (скажем, из бухгалтерии). Был создан некий цикл: прохождение обучения, сбор фидбэка, доработка, затем опять прохождение обучения и по кругу.
  • Разработайте пул контрольных заданий. Пример контрольного вопроса для выдачи классифайда — запрос «samsung galaxy s8», а на сниппете — iPhone 8. Если асессор отвечает, что объявление релевантно, тут явно что-то не то. Наличие подобных контрольных вопросов поможет вам сильно сократить асессорский фрод.
  • Запускайте выполнение заданий с перекрытием. Например, вы можете задать следующее условие: на каждое задание нужно получить ответ от пяти асессоров. Правильным можете считать, например, мнение большинства (то есть одинаковый ответ как минимум от трёх асессоров в случае с пятикратным перекрытием).

Если вы решите работать для оценки заданий с «Толокой», то подробнее про настройку работы с качеством можно почитать в разделе «Контроль качества».

Онлайн-оценка поисковой выдачи

Допустим, что мы протестировали наш новый алгоритм в офлайне и теперь готовы тестировать на реальных пользователях.

Как измерить результат вашей работы в онлайне? Тут нам помогут старые-добрые А/B-тесты. Разбиваем пользователей на две группы:

  1. Контрольная группа видит результаты работы старого алгоритма.
  2. Тестовая — нового (тестируемого).

В одном из предыдущих разделов я рассказывал про метрики поисковой выдачи.

При онлайн-оценке поиска прежде всего нужно смотреть на бизнес-метрики.

Они могут могут отличаться у разных продуктов.

Примеры:

  • Классифайды(«Юла», Avito) — количество контактов, сделок.
  • Социальные сети (поиск друзей) — количество пользователей, добавленных в друзья.
  • DocDoc(поиск врачей) — выручка, количество записей.

Далее смотрим на кликовые метрики: CTR@5, CTR@10, Average Highest Click, долю кликнутых выдач, долю нулевых выдач.

Вместе с аналитиками делаем выводы и не забываем про проверку статистической значимости результатов.

Бонус: пользователи не всегда знают, чего хотят

Есть нюанс, который сложно проверить при офлайн-оценке качества работы алгоритма: реальные люди часто не знают, чего именно хотят и на что готовы согласиться, если им предложат. Умение видеть такие моменты в выдаче приходит с опытом, а также выявляется на пользовательских интервью. Тестируется же на реальных пользователях.

Например. Пользователь ищет на «Юле» «чёрный iPhone 8». Вдруг среди чёрных iPhone в выдаче пользователь видит белый iPhone 8, но дешёвый, в хорошем состоянии да ещё и в соседнем доме. Пользователь заходит в объявление и покупает товар.

С одной стороны, объявление формально было нерелевантно запросу и асессоры бы отсекли его из выдачи, но в реальности такие вкрапления могут быть очень полезны для пользователей.

Как находить такие вкрапления

Смотрим на то, какие факторы влияют на выбор товара пользователем, смотрим на товары субституты. Например:

  • Тип, вид, марка, модель товара. Пользователь, который ищет одну марку и модель авто, потенциально готов рассмотреть марку или модель того же класса, но в том же диапазоне цен.
  • Цвет товара.
  • Состояние товара — новый или почти новый.
  • Геопозиция.
  • Стоимость товара.

Затем в онлайне экспериментируем с предложением товаров, незначительно отличающихся от искомого товара набором признаков, но сильно выигрывающего по ряду других ключевых факторов.

В своей следующей статье я опишу работу над формированием поисковой выдачи врачей в DocDoc. Мы пройдём весь продуктовый путь — от приоритизации доработки до проверки придуманного нами решения!

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Evgeny Guryanov", "author_type": "self", "tags": ["\u0432\u044b\u0434\u0430\u0447\u0430","docdoc"], "comments": 4, "likes": 25, "favorites": 148, "is_advertisement": false, "subsite_label": "services", "id": 81359, "is_wide": false, "is_ugc": true, "date": "Sun, 01 Sep 2019 19:45:09 +0300", "is_special": false }
0
{ "id": 81359, "author_id": 346502, "diff_limit": 1000, "urls": {"diff":"\/comments\/81359\/get","add":"\/comments\/81359\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/81359"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 200396, "last_count_and_date": null }
4 комментария
Популярные
По порядку
3

Спасибо за статью. Интересный способ оценки качества с помощью Яндекс.Толоки.
Не подскажете, как оценивали необходимое число асессоров? какое перекрытие брали?

Ответить
1

А вам на вашей работе за эту водяную воду платят?

Ответить
1

Вода овер 100, должны платить)

Ответить
0

Интересно было бы послушать со стороны технической.
Видимо индексы эластика придется перестраивать постоянно.

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }