Какой алгоритм ротации, и как всё это реализовано, я не знаю...
Но очень похоже, что просто все новые тумбы равномерно показываются в отведенных для теста местах в соответствии с группами, до тех пор пока не наберут заданное кол-во показов,
после чего уже начинают выводиться в группах в соответствии с набраным цтр.
А было бы неплохо, если бы тумбы, которые при тестировании уже получили достаточно высокий цтр (например >0.5), но всё еще новые, получали бы какой-то приоритет, и показывались в тестовых позициях чаще. А тумбы, которые показаны уже более половины лайвтайма новых тумб, но имеют цтр <0.01 к примеру, могли бы получать пессимизацию, и показываться на тестовых местах реже, как менее перспективные.
Думаю, что это повысило бы качество ротации.
Алгоритм ротации - приоритеты
Re: Алгоритм ротации - приоритеты
Добавлена галочка main only в экспорте.
Don't forget to run script update
Re: Алгоритм ротации - приоритеты
причем тут экспорт?
Я про ротацию в пределах сайта говорю...
К примеру, если добавить сразу много новых тумб (тыщ 5), то на небольшом (~10к дэйли) трафе они будут ротироваться офигенно долго... причем явно хорошие тумбы будут зависать в одной очереди наравне с явно плохими.
Т.е. стоит ТТЛ новой тумбы 1000 показов. У одной тумбы 700 показов и цтр 0.7,
у второй тумбы 900 показов, и цтр 0.01... явно же первая тумба лучше, чем вторая.
Но мариноваться в числе новых она будет дольше.
Можно избежать проблемы, если добавлять тумбы маленькими порциями, ждать, пока все новые отротируются, и добавлять еще. Но это довольно неудобно.
Разве что есть какая-то возможность проверять, сколько осталось новых тумб, и если меньше указаного числа, то добавлять порцию из Pool? Ничего не удаляя при этом (т.к. удалишь с мастера плохую тумбу... а на слэйве она хорошая... и жопа)
Я про ротацию в пределах сайта говорю...
К примеру, если добавить сразу много новых тумб (тыщ 5), то на небольшом (~10к дэйли) трафе они будут ротироваться офигенно долго... причем явно хорошие тумбы будут зависать в одной очереди наравне с явно плохими.
Т.е. стоит ТТЛ новой тумбы 1000 показов. У одной тумбы 700 показов и цтр 0.7,
у второй тумбы 900 показов, и цтр 0.01... явно же первая тумба лучше, чем вторая.
Но мариноваться в числе новых она будет дольше.
Можно избежать проблемы, если добавлять тумбы маленькими порциями, ждать, пока все новые отротируются, и добавлять еще. Но это довольно неудобно.
Разве что есть какая-то возможность проверять, сколько осталось новых тумб, и если меньше указаного числа, то добавлять порцию из Pool? Ничего не удаляя при этом (т.к. удалишь с мастера плохую тумбу... а на слэйве она хорошая... и жопа)
Re: Алгоритм ротации - приоритеты
Сорри, не туда ответил.
По данному вопросу - можно просто сделать короче тестовое время. Результат будет тот же.
По данному вопросу - можно просто сделать короче тестовое время. Результат будет тот же.
Don't forget to run script update
Re: Алгоритм ротации - приоритеты
Не... результат не будет тот же. Совсем не будет.
Ведь тумба могла получить хороший цтр на первых кликах из-за какого нибудь дурного залетного индуса, которому тумба напомнила его мамочку, и он несколько раз кликнул по ней, чтобы убедиться, что ошибся. На самом то деле тумба гавно, а будет считаться хорошей, если сократить тестовое время.
Я же думаю о чем-то вроде Cast Priority (только не для тумб с одной галерки, а для всех новых тумб). И более мягкого, не Yes/No, а High/Normal/Low, и соответственно, повышающего/не меняющего/понижающего шансы конкретной тумбы попадать в тестирование (местов для тестирования ведь заведомо меньше, чем новых тумб?)
И чтобы параметр этот был динамическим, т.е. выставлялся не руками, а программой, в зависимости от текущего цтр каждой конкретной тумбы.
Тогда, если тумба реально хороша, то она, получив бонус, будет показываться чаще, и кликаться чаще, и быстрее попадет наверх. Если тумба плохая, то она будет показываться реже, и уступит дорогу на тестирование более кликабельным тумбам. А если тумба на первых показах получила хороший цтр по ошибке, то при дальнейшем тестировании она быстро потеряет этот цтр, т.к. показываться станет чаще, а кликать по ней перестанут. И, соответственно, при очередном пересчете приоритета потеряет бонус.
Ведь тумба могла получить хороший цтр на первых кликах из-за какого нибудь дурного залетного индуса, которому тумба напомнила его мамочку, и он несколько раз кликнул по ней, чтобы убедиться, что ошибся. На самом то деле тумба гавно, а будет считаться хорошей, если сократить тестовое время.
Я же думаю о чем-то вроде Cast Priority (только не для тумб с одной галерки, а для всех новых тумб). И более мягкого, не Yes/No, а High/Normal/Low, и соответственно, повышающего/не меняющего/понижающего шансы конкретной тумбы попадать в тестирование (местов для тестирования ведь заведомо меньше, чем новых тумб?)
И чтобы параметр этот был динамическим, т.е. выставлялся не руками, а программой, в зависимости от текущего цтр каждой конкретной тумбы.
Тогда, если тумба реально хороша, то она, получив бонус, будет показываться чаще, и кликаться чаще, и быстрее попадет наверх. Если тумба плохая, то она будет показываться реже, и уступит дорогу на тестирование более кликабельным тумбам. А если тумба на первых показах получила хороший цтр по ошибке, то при дальнейшем тестировании она быстро потеряет этот цтр, т.к. показываться станет чаще, а кликать по ней перестанут. И, соответственно, при очередном пересчете приоритета потеряет бонус.
Re: Алгоритм ротации - приоритеты
Если у тумбы хороший ЦТР то она сразу попадает наверх.
Тумбы выводятся по ЦТР на всех странице, кроме первхы по дефолту 10 мест - где показывает именно отротированные. на 11м месте может быть новая тумба, с хорошим цтр даже если они считается еще новой, главное что б по цтр она была на 11м. И таким образом она получит просмотры быстрее.
Тумбы выводятся по ЦТР на всех странице, кроме первхы по дефолту 10 мест - где показывает именно отротированные. на 11м месте может быть новая тумба, с хорошим цтр даже если они считается еще новой, главное что б по цтр она была на 11м. И таким образом она получит просмотры быстрее.
Don't forget to run script update
Re: Алгоритм ротации - приоритеты
Прошу прощения, но абсолютно согласен с админом - результат тотже. Случайно или не случайно набран цтр на начале теста, но как только тест окончен если цтр хороший (считайте что это половина просмотра для новых) она будет показана вверху. И если этот результат случайный , то показавшись еще 300 (ну или сколько там) раз и не получив кликов, цтр галеры станет низкий и она упадет вниз - ровно то что и произошло бы по предложенному вами алгоритму, но с увеличеным показом нью.admin wrote: По данному вопросу - можно просто сделать короче тестовое время. Результат будет тот же.
И еще, поставьте в настройках New Rotation: New thumbs placement значение yes. Ротация пойдет заметно быстрее.
Re: Алгоритм ротации - приоритеты
Не... ну не хотите, не надо.
Хотя уменьшение времени ротации приведет лишь к значительно более грубой и подверженой случайностям ротации, что отрицательно скажется на продуктивности.
Хотя уменьшение времени ротации приведет лишь к значительно более грубой и подверженой случайностям ротации, что отрицательно скажется на продуктивности.
Re: Алгоритм ротации - приоритеты
Вот это примерно то, по смыслу, о чем я говорил... но в у себя в админке смартсиджа 1.50 я этого не вижу в упор.Jabar wrote: И еще, поставьте в настройках New Rotation: New thumbs placement значение yes. Ротация пойдет заметно быстрее.
У меня,походу, нет настроек New Rotation... и нигде нет фразы New thumbs placement
(я тупо кликаю по меню, и ищу эту фразу на странице)
Re: Алгоритм ротации - приоритеты
New Rotation: New thumbs placement
Place new thumb (shows less then New thumbs timelive)
on places other then Test positions start if it has good CTR.
оно Yes по дефолту
в тестовых сетингах ротации, свернут пункт по деофлту
Place new thumb (shows less then New thumbs timelive)
on places other then Test positions start if it has good CTR.
оно Yes по дефолту
в тестовых сетингах ротации, свернут пункт по деофлту
Don't forget to run script update