Key Collector - автоматизированная система анализа семантического ядра. Часть 3.

Юмор, это когда есть слово "лопата", после которого надо смеяться. Раз тут лопаты нет, надо просто голосовать.

Ну я собственно почему и спросил. Надо же раз и навсегда прояснить сомнительный момент.

jorevo, способ продвижения вперед нужных функций :)

1 раз уже сработал :))

Fruit, над деревом нужно поработать :).

Дерево полостью и безоговорочно поддерживаю! :)

Это понятно :)

Но, как мне кажется, это верное направление развития программы. Если мы говорим о составлении семантического ядра для сайта, то вторым этапом после подбора запросов является как раз их разбиение по группам, которые лягут в основу ТЗ для текстов страниц. Разбить 10-15 запросов можно достаточно быстро, а вот при ставке на большое количество СЧ и НЧ (что видится более перспективным, нежели ВЧ и СЧ) работа затягивается на много часов.

В то же время общие правила для распределения групп по запросам вполне поддаются частичной автоматизации. Запросы почти всегда образуют группы вокруг "родительского" ключа:

группа 1:

купить дом - родитель

купить недорогой дом

купить дом в Москве

выгодно купить дом

группа 2:

построить дом - родитель

построить дом недорого

построить дом своими руками

как построить дом

Гораздо реже случается, что в одну группу попадают ключи, не содержащие общей основы (но опять же это происходит из-за синонимов или разных частей речи: построить дом, строительство домов, возведение домов), в этом случае, конечно, придется объединять их вручную.

По сути, выделение из группы ключей "родителя" и привязка к нему дочерних запросов и является задачей, на мой взгляд, относительно не сложной. На сколько я понимаю, это можно реализовать, как надстройку над интерфейсом запросов (т.е. для пользователя ключи отображаются в категориях, а хранятся как и раньше - списком).

На базовом уровне что-то подобное уже работает в Магадане:

Но там есть ряд явных недостатков:

1) Нет учета словоформ. Кстати, бесплатное решение этого вопроса предоставил Яндекс ;)

2) Нет игнорирования предлогов при выделении родительских запросов (получаются категории из ключа "в" и т.п.)

3) Нет гибкой работы с ветками запросов: перенос ключа из одной категории в другую, объединение/разбивание/удаление категорий

а мне вот знаете как неудобно ;) сейчас наткнулся, делаю парсинг с большим количеством фильтров. Потом решил поменять настройки - остановил, поменял, запустил обратно. Парсинг начался с того же места, где и закончился. Это раз - было бы неплохо предлагать после прерывания парсинга возможность выбора - продолжить или начать новый. И самое неудобное - это то, что для начала нового парсинга надо удалить все фильтры, чтобы удалить все спарсенные запросы. И приходится мне, горемычному, опять ручками все эти фильтры заколачивать. В общем, есть мнение, что еще нужен экспорт/импорт фильтров.

MIND, почему-то-как-то так:

-- открываем окно для добавления слов, там у нас слова (наш сохраненный проект),

нажимаем "очистить список", закрываем окно. Открываем окно снова, очищенные слова снова здесь.

и вот так:

--красная ли кнопка парсинга, поисковая ли строка, но:

берем конструкцию [подарок !на] ---- программа парсит левую колонку,

берем конструкцию ["подарок !на"] ---- программа парсит правую колонку

Каждый раз что-то с этими словами меняю и каждый раз после обновления Вы говорите о новой штуке :). Спасибо.

Если не так, то вообще ничего не выводить?