Нет.
Увидеть можно много чего. Вопрос - стоит ли это принимать как руководство к действию.
При желании можно конечно и все адреса страниц назвать порядковой нумерацией: 1.html, 2.html, 3.html и т.д.
Если у вас ИМ состоит из одной категории и более нет никаких вложенностей, то в принципе имеет.
Про плюсы я вам написал - если у вас несколько или даже полтора десятка однотипных товаров, то новые сущности вам не нужны.
А вот минусов, если это большой магазин, можно перечислять длинным списком. Самый главный - полная неразбериха, какой товар к чему относится, с чем группируется и т.д.
При второй части цикла (при целевом заходе) - это всегда поисковый запрос и на вашем сайте его уже не будет (если вы не выступаете в качестве человека, который старается стимулировать себе ПФ результаты).
Во всех других случаях - это нагул. И он - да, может быть (и чаще всего) прямой, может также идти через директ.
Об этом я написал во второй части предложения, а в этой - я имел ввиду, что вручную часто блокируемые сети наверняка тоже рассматриваются как серые.
На новых - да, но свершенное действие - уже история, а историю можно (и в определённой степени) нужно анализировать.
А вот это, пожалуй, самый интересный вопрос.
Какие данные собирает CF сервис после прохождения капчи - это действительно интересно. Никто не встречал разъяснительных материалов на эту тему?
Не вижу повода не согласится, однако как уже сказал, пока пользователь не начал отправлять post данные, анализировать кроме формальных технических данных особо нечего.
Я про это и говорю, что помимо фактических технических данных, которые доступны из протокола, сервисы типа CF используют свою историю (cвою аналитическую базу). И если в их базе большая часть заходов из отдельной AS имела большую часть отказов, то сервис помечает выбранную подсеть как серую и на старте направляет заходы из этой сети на капчу. Если процент прохождений капчи не растёт, то данная посеть так и остаётся в перечне серых.
Т.е. условная Битерика будет натыкаться на 100% капчу не потому, что мы про неё знаем из наших обсуждений на форуме, а потому что как раз пользователи сервиса её чаще всего блокируют и прохождение капчи там наверняка самый маленький процент.
А заходя с IP-шника домашнего провайдера CF знает про подсеть этого провайдера, что процент прохождения капчи там высокий, следовательно, нет необходимости каждый раз обрабатывать эти заходы через капчу.
Своего рода обучение, где белые подсети, а где серые.
Думаю, что скорее всего это работает так. Ибо логично и вполне резонно.
Ммм.. смотрите.
Есть принципиально две различные стадии.
1) Стадия нагула - т.е. сбор куков и здесь накрутчику принципиально важно, чтобы был счётчик Яндекса.
Это могут быть прямые заходы, поисковые, реферальные.
Чаще всего прямые, потому что они избавляют от необходимости упираться в капчу Яндекса.
Поисковые конечно тоже используются, но позднее, когда профиль собран и уже необходимым образом "прогрет".
2) Стадия целевого захода, когда для эффективности накрутки важно использовать целевой поисковый запрос.
Вы сейчас про первое или про второе?
Хорошо, давайте поразмышляем, как это практически можно было применить.
Давайте с конца.
Поведение мы можем проанализировать лишь постфактум. Т.е. получив первую пачку get/post запросов мы можем анализировать лишь заголовки, выполнить js проверки - всё.
Следовательно, на старте получив запрос от отдельного IP мы ничего не знаем про этого потенциального бота или пользователя.
СF, используя свою накопленную базу, может автоматически пропускать живого пользователя, а предположительного бота втыкать в капчу. Но это решение не на основе последующих данных, это решение на основе собранной статистики по отдельным случаям AS.
Проверка выполняет до загрузки Метрики, поэтому если бот проверку не проходит, то он не попадает в Метрику и не получит куку Яндекса с этого сайта.
Вот одна любопытная деталь, я в группе накрутчиков спрашиваю,
группа почти 5K участников.
И знаете какой я сделал вывод из ответов?
Большинство вслепую гоняют по сайтам готовыми программами и вообще многие слабо понимаю, что я такое спросил.
Из этого (и из моего первого сообщения) вывод - можно даже изначально показывать заглушку с самой просто капчей c отключенной Метрикой (на сомнительную подсеть) - боты будут бестолково ползать по заглушке.
Большая часть "деятелей" банально тупо вслепую направляют ботов на выгул и отрабатывают на объёмы куков.
Вот, кстати, гайд, которые они любят друг другу перекидывать.
Теоретически такое возможно, но года примерно полтора назад (может, больше, вас ещё не было на форуме) мы (и в частности я) - разбирали Антибот.
Я как раз приводил скриншоты и показывал, что Антибот просто отправляет всех на капчу и практические все участники обсуждения подтвердили, что - да, заходили под своими рабочими IP-шниками и всем приходится разгадывать капчу.
При желании можно найти эту переписку, точно в ней участвовали Дима Алаев и Серафим, остальных сейчас не вспомню.
Ну вот и получается, что в итоге решает результат прохождения капчи, а не сервис.
Впрочем, надо признать, что CF часть серверных проксей действительно жёстко банит (я с этим время от времени сталкиваюсь).
Смотрите. Мой домашний IP-шник и мой рабочий компьютер он никак не связан с работой прокси - это отдельный компьютер. Вся работа с прокси идёт строго с другого компа, где другое железо и каждый рабочий вход начинает с процедуры проверки анонимности. Я провожу проверку под двум сервисам анонимности и если сгенерированная конфигурация не проходит проверку, последующие шаги невозможны (происходит это программно, поэтому человеческий фактор исключён).
Думаю, Антибот просто проверяет любого нового пользователя и перестраховывается капчей, вот и всё.
Но в этом случае мы просто может использовать капчу, как доп. проверку на роботность.
Вот о том и речь, что получается неразрешимая вилка, с одной стороны бот заходы с мобильных подсетей статистику и поведенческие, с другой стороны мы не можем банить эти точки входа, потому что оттуда возможен поток живых пользователей и клиентов.
