- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Речь про динамические характеристики. Возраст и другие факторы скорее статические и общие для всего сайта.
Так, походу, надо согласовать терминологию на более низком уровне. Что, по-Вашему - динамические и статические факторы? Я под динамическими подразумеваю зависящие от запроса, а под статическими - не зависящие.
Миш, а я вот помню, еще до отмены "линк" и "анкор" бывало, что некоторые ссылки работали, а другие - нет, в пределах ОДНОЙ страницы. Как думаешь, что это было?
До отмены было много интересных фишек. Тот же, к примеру, абсолютно фильтровавшийся сквозняк.
Если таки ввести векторный Трастранк, то тогда его донорская компонента таки имеет смысл применяться к кластеру. Впрочем, оперировать скаляром в Вашей модели - Ваше право.
Как я понимаю, основной вопрос стоит в том, стоит ли выделять две компоненты ТР - ТР_собственный (влияющий на ранжирование самого сайта) и ТР_передаваемый (с точки зрения работспособности сайта как донора) для моделирования или можно ограничиться ТР в целом и наблюдаемые различия в работе ссылок с одного донора обосновывать зависимостью от ТР_передаваемого и ТР_собственного_акцептора (т.е. связки (ТР_донораТР_акцептора)).
Блин, нужно как-то обозначить весь этот ужас :)
Что Вы подразумеваете под положительным результатом в данном случае?
Изменение видимости донора (за счет возможного изменения ТР_собственного) или изменение влияния исходящей ссылки с донора (за счет возможного изменения ТР_передаваемого).
Ни того, ни другого замечено не было (на тестовой коллекции).
Так, походу, надо согласовать терминологию на более низком уровне. Что, по-Вашему - динамические и статические факторы? Я под динамическими подразумеваю зависящие от запроса, а под статическими - не зависящие.
Сергей, я не думаю, что ТР есть запросозависимая величина. В моем контексте скорее подразумевались внешние и внутренние факторы, назовем их там во избежание путаницы.
Ни того, ни другого замечено не было (на тестовой коллекции).
Вполне возможно, что тестовая коллекция не имела необходимых свойств.
У меня несколько иной подход. Для меня тестовая коллекция - весь индекс. Любые её сужения могут привести к потере определенных свойств, увы.
Сергей, я не думаю, что ТР есть запросозависимая величина.
И я не думаю. Поэтому и не понял, почему Вы упомянули про какие-то динамические характеристики.
Вполне возможно, что тестовая коллекция не имела необходимых свойств.
У меня несколько иной подход. Для меня тестовая коллекция - весь индекс. Любые её сужения могут привести к потере определенных свойств, увы.
Верно и обратное - можно не учесть всех факторов, эмпирически равных на тестовой коллекции и вносящих шум в результаты эксперимента над полным индексом.
Верно и обратное - можно не учесть всех факторов, эмпирически равных на тестовой коллекции и вносящих шум в результаты эксперимента над полным индексом.
А это уже забота метода ;)
А как ранжируются бэки в панели Яндекса?
Было бы очень странно, если б принцип ранжирования в панели мог бы дать сколько-нибудь полезную практическую информацию для определения лучших доноров. Ранжировка, имхо, там идет по степени передаваемого веса помноженного на некий фактор шума. В любом случае, панель, наверняка задумывалась как информатор, а не подарок оптимизаторам от застеснявшегося своей строгости Яндекса.
Кстати я вот не верю, что траст накладывается на весь домен, а не на его кластер. Это какая-то алогичная уравниловка получается. Вот полно же, особенно сейчас, сайтов, предоставляющих социальные кластеры-странички-блоги-интерактивы, например, страницы турпортала, которые ведут разные менеджеры и путешественники с разной квалификацией. При этом главная безбожно барыжит ссылками и имеет PR3 и там исторически уже полный непот почти до 0, а внутренние подразделы девственно чисты и имеют PR6, просто нетронутый гуглом. Тьфу на почти бесполезный PR, но суть такова что это по сути совершенно разные квалификационные матрицы, то есть кластеры.
Наверное, можно же как-то ввести условные обозначения для каждой виртуальной величины?
А то трастов всяких много, и у каждого он свой, любимый.
Как бы так:
В рамках одного сайта:
TRs
TRsite - ТР собственный (возможно влияющий на ранжирование самого сайта, но в этом случае зависящий от... дополнительных иных факторов;)
TRl
TRlink - ТР максимально теоретически передаваемый (с точки зрения работоспособности сайта как донора)
В рамках взаимосвязи двух сайтов:
TRd - ТР_донора (причем в связи с акцептором, меньший теоретически максимального TRl)
TRa - ТР_акцептора
различия в работе ссылок с одного донора получаются из-за: TRw =(ТР_донора - ТР_акцептора)
Тогда w - это и есть эта width winwow - ширина окна.
Однако, не факт, что TR не является запросозависимым, то есть, как я понял, тематически зависимым. Вполне можно собрать вручную небольшие, но значимые, и максимально однозначные коллекции запросов, по которым назначить свои (кластеры трастов) запросозависимые авторитеты. Для достаточно точно определяемых документов по тематике, когда там достаточно точно выделятся тематика, например, кондиционирования, можно назначить иную верхушку или вкрапление-коэффициент траст рейтинга, включающего в себя крупнейшие порталы по климатике, отраслевые журналы, подразделы авторитетных классификаторов и иные отобранные хабы. Это очень просто и наверняка используется в некоей мере при помощи обученых ассесоров. Другое дело что использоватся эта методика может для ограниченной части запросов и сайтов, что и привносит шум.
В этом случае можно было бы ввести непостоянный классификатор t тематичности, при котором если уровни качества-доверия по некоей выборке имеют много пересечений:
TRd(t) и TRa(t) тождественны по t, то вводить дополнительную бонусную функцию, например. Так как это может потребовать немаленьких расчетных ресурсов, это можно расчитывать раз в 2-3 месяца, чаще и не нужно.
А если еще учесть, что существуют коллекции "коммерческих" запросов Директа, которые можно ранжировать по уровню ставок в нем... то еще одной переменной d можно ужесточать требования, обрезать влияние общетематических источников. Тогда "погода в Москве($0.1)" и "недвижимость в москве($3)" при прочих равных будет иметь неодинаковый вес. Практически это экспериментально не вычислить сходу, так как совершенно неконкурентная первая тема.
Но конечно и TRwdt в отношении связи донор-рецепиент далеко не самодостаточен. Возрастные факторы, возраст ссылки и ее текстовое окружение (с чем все сейчас извращаются кто как может) и даже эмоциональная семантика навроде "лучший в нашем рейтинге" могут привносить (или не привносить) свои нюансы. Хотя сейчас наверняка чаще всего неопределяющие как правило.
Вот почему я думаю, что анализ взаимодействия двух сайтов не может базироваться на их анализе по отдельности, по опыту их взаимодействия в других связях, выборках, коллекциях. Сама эволюция поиска будет этому препятствовать.
Ранжировка, имхо, там идет по степени передаваемого веса помноженного на некий фактор шума.
Я очень сильно сомневаюсь, что при ранжировании беклинков хоть когда-либо хоть каким-либо боком использовалась эта пресловутая "степень передаваемого веса". Во всяком случае, в операторе link в 2006-2007 годах её точно не было.