Пишу сюда, потому что мое обращение #14235191 было просто закрыто сотрудником Ozon в одностороннем порядке даже без возможности переоткрыть его и даже без возможности поставить оценку (вообще впервые такое вижу), что продемонстрировав отсутствие интереса решать проблему, которая не столько мешает лично мне, сколько позорит вашу организацию и, возможно, доставляет неудобство другим селлерам.
А теперь к сути:
У Ozon, как известно, есть чудесный инструмент - Аналитика, в котором как-то появилась далеко не самая бесполезная по своей идее метрика - средние позиции товара по запросу.
И все бы в этой фиче было бы хорошо, если не одно "но": реализацией таковой занимался программист, который, по всей видимости, в гробу видал свою работу и от вашего лица плевал на всех партнеров, которые будут данную метрику использовать.
Так что же с этой частью аналитики не так?
Когда только Ozon добавил информацию о средних позициях товара, я начал ее изучать и думать: как это можно применить на практике. И мне хватило буквально несколько минут, чтобы не просто найти противоречия в этих данных, но и понять: от-куда они взялись.
А взялись они из того, что кому-то было лень написать несколько "лишних" строк кода, дабы учесть в аналитике ситуацию, когда товар по тем или иным причинам просто не показывается, а значит и не может иметь данных о своих позициях.
Да, в этом плане данная метрика уникальная: ведь по всем остальным нужно уметь только складывать, а вот в учете позиций попахивает более сложными вычислениями, за которые сотрудникам Ozon, возможно, просто не доплачивают.
Абстрагируемся для того, чтобы ситуация была понятна всем:
Допустим, в школьных соревнованиях должно было участвовать 10 учеников. Из них семеро заболело, а оставшиеся трое заняли 1, 2, 3 места соответственно.
Но какое место заняли ученики в среднем? Математика проста: складываем места, которые заняли ученики (1+2+3) и делим на общее количество участников, участвовавших в соревнованиях: на 3, получая 2, как среднее место.
А что с учениками, которые в соревнованиях не участвовали?
Очевидно, что их никак не "пришить" к расчету среднего места. От слова "совсем". Их просто нужно исключить из расчета. Это очевидно: НЕ участвовавшие в соревнованиях ученики не занимают никаких мест: ни первых, ни последних и нельзя их каким-то образом учитывать в итоговом отчете.
Конечно, если очень хочется все-таки учесть, то можно, например, поставив отсутствующих учеников на последние места - наверняка в каких-то соревнованиях так и поступают.
Но уж точно чего делать не стоит, так это ставить отсутствующих учеников на нулевые места, после чего без каких-либо угрызений совести пихать эти нули в итоговые расчеты.
Но сотрудник из Ozon именно так и поступает: присваивает товару место номер ноль, если он отсутствовал в показах, а потом без каких-либо проблем суммирует эти данные с остальными, деля их на общее число измерений.
Т.е. если бы этого сотрудника попросили предоставить отчет о школьных соревнованиях, то он бы посчитал так: (1+2+3+0*7)/10, заявив о том, что ученики заняли в среднем 0,6 место.
Еще бы интереснее был бы расчет среднего места ученика в разных соревнованиях:
В первом соревновании занял 10-е место, во втором не участвовал. Значит в среднем ученик занимает 5-е место. Здорово, правда?
Я уже молчу про то, что если наш условный сотрудник Ozon без всякого зазрения совести будет складывать и делить места для разных дисциплин вместе: например, соревнования по бегу и контрольные по литературе.
Места в категориях - в кучу, в поиске - в кучу. Запросы по рейтингу, популярности, по цене - все-все кидаем в одну кучу. И даже если это сам селлер искал свой товар по SKU - да тоже в кучу все закинем и на все поделим.
Чего заморачиваться, верно? Пусть "уважаемые партнеры" сами разбираются!
Спасибо за внимание!
P.S. Я не просто так столь детально описал данную проблему. Подобных экстравагантных решений у Ozon хватает (я сейчас именно про раздел аналитики). И причина вовсе не в каких-то ошибках или в неопытности сотрудников, а именно в наплевательском отношении к своей работе. Или же в преступной глупости - допускаю и такой вариант.
Здравствуйте! Я из Ozon Marketplace. Извините, что закрыли обращение без ответа – разберём этот момент с сотрудниками. Что же касается аналитики позиций товара в поиске и каталоге, то уточню у коллег детали вычислений и чуть позже вернусь прокомментировать.
Благодарю!
В аналитике позиции товаров в поиске не учитываем те, которые не увидели покупатели. А на результат самих показов смотрим уже после применения фильтров и сортировки. То есть, если бы за соревнованиями наблюдал Ozon, то рассчитывали бы среднее арифметическое занятых мест лишь среди реальных участников :)
Однако отмечу, что на графике этой метрики нулевые показы учитываем. Об этом знаем – работаем над тем, чтобы исправить. Пока доверять можно показателям из таблицы.
И почему Ваш ответ противоречит тому комментарию, который я получил в поддержке? Виктория, к меня впечатление, что Вам просто надули с уши и вернули сюда….
Давайте разберём на примере. Возьмём зелёный свитер. Всего для него существует, например, 4 выдачи с настроенными фильтрами по запросам: «Зеленый свитер», «Свитер», «Тёплая одежда» и «Зелёный».
В первых двух ситуациях товар оказался на 1 и 2 страницах соответственно. Покупатель увидел карточку товара в обоих случаях – учтём их в расчётах.
Для тёплой одежды свитер оказался на 18 странице, посетитель сайта дошёл до нее, увидел и купил свитер – учтём позицию в выдаче.
А в последнем запросе товар оказался на 80 странице, покупатель остановился на 4 и не увидел карточку – считаем для этого случая значение «0». Этот ноль в метрику не попадёт.
В итоге посчитаем так: (1+2+18)/3. В аналитике позиция в поиске и каталоге у товара будет 7.
Вижу, в поддержке вам подсказали всё верно и в этом же направлении – проверьте, пожалуйста. А ещё о метриках рассказываем здесь: https://ozon.ru/t/zdwz1NW
Виктория, сейчас я вижу, что данные в разделе "Аналитика" приняли иной вид, и уже не отображаются дробные позиции. Но я беру данные по API (прошу прощения - упустил данное уточнение), а там воз и ныне там. Еще раз повторюсь: то, что Вы говорите, не может соответствовать действительности: число ниже единицы можно получить лишь в том случае, если изначально в расчет берутся числа меньше нуля. Думаю, Вам преподносят недостоверную информацию. Мой Tg skyline360_1 Я могу Вам дать конкретные примеры таких данных: с датами, SKU и данными по позициям.
Значение «0» мы получаем, если по конкретному поисковому запросу покупатель не дошел до страницы с вашим товаром. А в самом разделе аналитики нулевое итоговое значение будет только в том случае, если за период карточку не посмотрели ни по одному запросу. Такое бывает, если, например, продавец плохо заполнил название товара и характеристики, либо в них есть какие-то ошибки.
Разумеется, будем рады, если поделитесь примерами данных, где считаем иначе. Передам коллегам – возьмём на вооружение)
Виктория, и можно как-то связаться с более компетентным в этом вопросе сотрудником? Ничем не хочу обидеть, но Вы явно не владеете предметом: то в одном комментарии пишите, что не считаете нули, то уже считаете их… кстати, как я понял, с позициями в аналитики сейчас просто решили загнать в потолок до целого числа… Все? Вместо того, чтобы лечить ногу, вы ее решили отрезать и ещё больше усложнить жизнь партнерам????
Андрей, простите, если запутала, давайте ещё раз. В разделе «Аналитика» есть график и таблица под ним. В графике считаем нулевые показы, тут вы правы – этот момент исправляем. А в таблице ноль появляется в единственном случае – когда у товара не было показов совсем. Если там любая другая цифра, то рассчитали её по принципу, который описала в примере с зеленым свитером. Поэтому значение меньше единицы действительно не может получиться – если видели обратное в личном кабинете, поделитесь, пожалуйста, скриншотом, чтобы мы проверили.
Если же проблема в том, что получаете такие цифры по API, а в личном кабинете всё в порядке – напишите в поддержку с темой «API OZON Marketplace» → «Ошибки при работе с API».
Добрый день! Нет ли новостей по моему вопросу?
Добрый день! Нет, быстро поправить не получится — нужно больше времени. Увы, пока не сориентируем по срокам.
Хорошо, спасибо!
Виктория, если Вас не затруднит, то проконтролируйте, пожалуйста, запрос #14490529 - тоже проблема с API
Также хотел бы попросить не игнорировать запросы по Api Perfomace, а сейчас именно так и происходит.
А, ну раз исправляете, то пока вопрос снят, спасибо большое!
Жду запроса на tg skyline360_1