| Masita писал(а): |
Я предлагаю не отвечать лично за приглашенных, а отвечать своим рейтингом... |
Ура! хоть одного единомышленника увидел, правда прямо в след предложении сам себе противоречишь (рейтинг не равен кол-ву аплоада, это отношение UL/DL)
По поводу делиться аплоадом жестко если у приглашаемого гигантский тунель в инет, а у Вас голосовой модем ... Надо отбирать трафик у приглашающего ТОЛЬКО за ошибку, и отобранный трафик должен быть пропорционален даунлоаду, иначе вы теряете контингент из не-Питеро-Москво-Киево-Алма-Ато-Астана-город.
ЕСЛИ для ВАС ниже "МНОГАБУКФ", то можете пропустить
Мне почему-то кажется, что давать инвайты за аплоад идея вкорне неверная. Поясняю...
Для того, чтобы ЧТО-ЛИБО решать необходимо определиться с критериями оценки. На мой взгляд столько бесед и споров с пеной у рта происходит из-за того, что нет объективного критерия оценки "полезности человека" трекеру. Если построить такую формулу, то можно на базу полученной величины выдавать соответствующее кол-во инвайтов, приглашать в админы. Если воспользоваться опытом MBA, то можно увидеть, что с развитием бизнеса все меньше цениться просто умение дешевле купить/дороже продать(читай UL/DL), а оценивается ряд параметров (отношение объема проданного к закупкам, сколько клиентов новых притащил менеджер за год, кол-во нового товара в год и т.п.). Попытаемся эмпирически составить формулу оценки качества юзера для трекера.
I. Определение компонентов критерия оценки Активность каждого человека определяется несколькими объективными факторами:
1. RAT= рейтинг(НЕ АПЛОАД);
2. TIM= время, которое человек сидирует умноженное на объем сидируемого(НЕ АПЛОАД, А ОБЪЕМ ВЫЛОЖЕННОГО);
3. REL=кол-во релизов;
4. MON=материальная помощь;
5. SCR=разные достижения, например, попадание на доску почета по "кол-ву скачивания релизов за месяц", "кол-во благодарностей релизов за месяц", "лучшие релизы за месяц"
6. MAS=количество успешного народу, которое он пригнал на трекер.
*Замечание: функция sqrt(х) = квадратный корень числа х. Если будет сложно считать корень, то можно брать в формулах сам х, но тогда величины будут падать сильнее.
ЭТОТ РАЗДЕЛ МОЖНО ПРОПУСТИТЬ, если не хочется вникать как и что считается
II. Анализ компонентов критерия оценки 1. RAT=рейтинг(НЕ АПЛОАД), у человека может быть жёский асимметричный канал, как например(утрирую)
СТРИМ в Москве DL=2.5MB/UL=112KB (отличие в 23! РАЗА), а если канал на ап страшно медленный, так что ж ему теперь подыхать чтоли? Такие юзеры обычно очень избирательны, много не качают, но у них почти нет большого аплоада, поэтому они хотябы стараются держать рейтинг в норме, ведь иначе даже скачать не смогут. Поэтому это должна быть основная\базовая цифра в формуле. И именно этим параметром человек должен отвечать , если в течении какого-то испытательного срока(пусть будет 4 мес) приведенный будет забанен на трекере или его рейтинг к концу периода будет ниже, например,
1, ну то есть он уже что-то качал и точно научился зарабывать рейтинг сам. Наказание, например,
ратио=ратио-1. Надо испытательный срок ограничивать, так как надо понимать, что жизнь штука переменчивая и люди будут уходить\ будут приходить новые. И если актив, который привел 50 пассивов, в течении пары лет их потеряет он сам окажется в минусе и вылетит из клуба. А испытательный срок это своеобразное совершеннолетие, когда человек имеет свою голову на плечах (рейтинг 1) и уже сам отвечает за свои поступки. Нормировать этот параметр как-либо даже не представляю себе как, но знаю одно, что если у человека рейтинг>100 это уже либо маньяк, который накручивает себе рейтинг, либо чел, который ввел себе привычку всегда сидить, имеет гигантский стаж, и за этим уже давно не гонится. Поэтому нормированный параметр я бы считал так: Если RAT<100, то RAT_NORM=RAT, если RAT>=100, то RAT_NORM=100 (Область значений: максимум 100, не менее 0,3).
2. время, которое человек сидирует умноженное на объем сидируемого (на кол-во смысла множить нет - будут рулить публикующие кучу мелкого софта). Можно сказать, что это не справедливо, так как надо для этого иметь гигантский винт, не у всех такое есть и т.п. но это тоже работа, это ценно для трекера, значит заводить надо винты, чтобы быть полезным трекеру. Этот параметр должен скорее всего входить как коэффициент\множитель в формулу. Считаю нормальным сидировать всреднем 300ГБ, для среднестатистического юзера,а комп должен быть включен не менее 15 дней в месяц(половина). То есть коэффициент TIM = средний_объем*время_сидирования/(300ГБ*15дней), к сожалению, параметр должен быть бегущим окном, то есть нести статистику за последние 31 день, иначе будет несправедливо к начинающим-активным юзерам, а "старички" будут недосягаемы, просто засчет стажа в клубе, кроме того, параметры соответствующие динамике "подстегивают". (Область значений: разумный максимум 6, обычно <1). Как провести нормирование к 1 данного числа не представляю даже.
3. кол-во релизов. С этим все понятно, но вы скажете, что надо учесть качество, но я не представляю как: есть области в которых легче релизить -мелкий софт и фильмы, где сложнее релизить - "собственный уникальный релиз", я описания к таким делаю по 2-3 часа минимум, а если еще и
контент свой, то такой релиз может и более месяца делаться. Этот параметр должен скорее всего входить как коэффициент\множитель в формулу. Нормой для среднего активного участника считаю 1 релиз в месяц. соответственно Коэффицинет REL= колво_релизов_в_мес. (Область значений: разумный максимум 30, обычно 1). Чтобы провести нормирование, можно сделать переменную типа: Если REL=0, то REL_NORM=0, в другом случае REL_NORM=2-1/sqrt(REL) (Область значений: максимум 2, обычно 1)
4. можно говорить про нематериальную ценность, но так же считаю, что это важный параметр, так как он напрямую связан с возможностями по развитию трекера администрацией, в отличие от остальных, которые касаются только юзеров. Нормой для среднестатистически активного юзера считаю 100р (3EUR=4USD)/мес. Соответственно коэффициент MON=пожертвования_в_рублях/100р; (Область значений: максимум -, обычно 1). Чтобы провести нормирование , можно сделать переменную типа: Если MON=0, то MON_NORM=0, в другом случае MON_NORM=2-1/sqrt(MON) (Область значений: максимум 2, обычно 1)
5. разные достижения, например, попадание на доску почета по "кол-ву скачивания релизов за месяц", "кол-во благодарностей релизов за месяц", "лучшие релизы за месяц", ну тут сложно сказать... для меня это не главный параметр, поскольку мои релизы нужны только специалистам в очень узкой области, а фильмы я просто не смотрю, соответственно я как и основная масса почти не имеем даже шансов попасть в эту таблицу, соответственно это ложен быть как доп бонус, опять же вычисляться бегущим окном - должно определяться среднее время нахождение в таблицах за последние 31 день. SCR = (дней_в_таб_скачивания+дней_в_таб_благодарностей+дней_в_таб_релизов)/31 (Область значений: максимум 3, обычно 0).
6. количество успешного народу, которое он пригнал на трекер. Думаю это должен быть доп параметр: Если кол_во=0, то MAS=0, в другом случае MAS=2-1/sqrt(кол_во) (Область значений: максимум 2, обычно 1)
III. Формулирование критерия оценкиНеобходимо использовать нормализованные параметры(подробнее выше), иначе эта цифра будет только расти, а так она будет плавать, показывая динамику участия юзера в жизни трекера. Общая полезность может быть охарактеризована так:
Полезность= RAT_NORM*(TIM+REL_NORM+MON_NORM+SCR+MAS)
Предельно допустимый разумный максимум по-моему получается так: Полезность_макс= 100*(6+2+2+3+2)=1500
Красивое потолочное число
Теперь по поводу приглашений. В соответствии с II. п. 1(читать выше), если приглашенный к концу испытательного срока - 4 мес не смог достичь рейтинга 1 или был забанен по каким-либо причинам, приглашающего надо наказать. Наказывать надо приглашающего отрезанием РЕЙТИНГА(НЕ АПЛОАДА!, хотя уменьшение рейтинга будет урезанием аплоада, но резать надо пропорционально DL), причем резать надо около одной единицы, на мой взгляд. Единственное, что должно смягчать, так это только бурное участие этого чела в жизни клуба, но если он привел много людей, то ему надо сделать поблажку. А значит:
Отрезаемый рейтинг = (1-0,5*MAS)*4/(TIM+REL_NORM+MON_NORM+SCR)
Вооооот, что я хотел вынести на обсуждение, надеюсь ясно выразился
коэффициенты скорее всего требуют коррекции, возможно формулы нормированных величин надо будет править. Ну и есть вопросы по поводу реализуемости всего этого
P.S. Конено же для реализации корректного подсчета полезности надо будет делать защитные механизмы вычисления читеров. К, примеру, время*объем_сидируемого можно увеличить встав на раздачу кучи штук и поставив их на паузу, в таком случае нужно анализировать объем переданного за сутки и определять читит он или действительно не такой уж и популярный контент и т.п.
готова плюсодинить каждый пост...