1. Чтобы снять позицию страницы в нашем случае пришлось брать конкретные запросы, а не кластеры. Если есть возможность узнать средние позиции страницы в целом кластере, полагаю, что это тоже можно использовать. 2. Я пока не хочу ссылаться на продукт, чтобы это не выглядело рекламой. Старые страницы мероприятий почти всегда остаются открыты к индексации и ловят трафик, который мы стараемся конвертировать на схожие по экспириенсу или на будущие этого же артиста/группы, если такие планируются (не редирект, а соответствующие элементы в UX).
Все верно! Так как описан верхнеуровнево подход, то вариантов применения может быть множество. Можно делать графики уже по отдельным группам, а можно все склеивать в один.
Пока для нас это adhoc задача, которая не встала на поток. Вполне вероятно, что мы будем эволюционировать этот метод и развивать его в дальнейшем. Если это произойдет, я обязательно напишу вторую часть этой статьи с апдейтами.
В заключении я дал небольшой комментарий, что на реальных данных нужно задать группу заранее уже в наборе данных, так как просто наглядно на графике это будет совсем не очевидно. Уже перед визуализацией данные, в идеале, должны выглядеть как-то так: entityId;query;pagePath;pageGroup
Элемент на графике это запрос+страница, а группа таких элементов — это какая-то условная группа, если вам нужно ее выделить. Как в моем примере — это разные типы страниц: страница товара и страница категории.
1. Чтобы снять позицию страницы в нашем случае пришлось брать конкретные запросы, а не кластеры. Если есть возможность узнать средние позиции страницы в целом кластере, полагаю, что это тоже можно использовать.
2. Я пока не хочу ссылаться на продукт, чтобы это не выглядело рекламой. Старые страницы мероприятий почти всегда остаются открыты к индексации и ловят трафик, который мы стараемся конвертировать на схожие по экспириенсу или на будущие этого же артиста/группы, если такие планируются (не редирект, а соответствующие элементы в UX).
Все верно! Так как описан верхнеуровнево подход, то вариантов применения может быть множество. Можно делать графики уже по отдельным группам, а можно все склеивать в один.
Пока для нас это adhoc задача, которая не встала на поток. Вполне вероятно, что мы будем эволюционировать этот метод и развивать его в дальнейшем. Если это произойдет, я обязательно напишу вторую часть этой статьи с апдейтами.
В заключении я дал небольшой комментарий, что на реальных данных нужно задать группу заранее уже в наборе данных, так как просто наглядно на графике это будет совсем не очевидно. Уже перед визуализацией данные, в идеале, должны выглядеть как-то так: entityId;query;pagePath;pageGroup
Элемент на графике это запрос+страница, а группа таких элементов — это какая-то условная группа, если вам нужно ее выделить. Как в моем примере — это разные типы страниц: страница товара и страница категории.
Спасибо! Мне остаётся только стать дата-сатанистом, чтобы писать про него больше :)