Это все уже из области философии. Есть условные градации определения мышления и вы говорите о самом абстрактном определении. Если взять уровень абстракции чисто биологический, то по некоторым признакам можно сказать что у грибов есть мышление. Более абстрактный уровень, например психолингвистика, докажет что у высших приматов есть мышление, хотя и на уровне трехлетнего ребенка. Если говорить о мышлении как о процессах, которые можно изучать в рамках психологии, то тут понятие мышления применимо только к человеку. И круг замыкается: к человеку какого возраста? У детей 1-2 лет есть мышление?
SSR это решение проблемы индексации реактивных сайтов/SPA/приложений.
Но их не так много тк сложность разработки существенно увеличивается … а возможные пути ее решения редко применяют.
Очень спорно. Я не фронт, но уверен что любой мидл прикрутит SSR за рабочий день в к любому реактивному сайту. Хоть в статику, хоть поднять ноду на сервере и вот оно — изоморфное приложение. Возможно я не прав и фронтэндеры меня поправят.
Ну если уж откровенно, то проблема притянута за уши. SSR даже в виде кривых костылей решал проблему индексирования react/angular/vue приложений. А уже сейчас там вполне стабильные коробочные решения. Например Nuxt.js для Vue: генерит статичные html которые индексируются вполне без проблем.
Я не говорил что GPS абсолютно бесполезен. Да, иногда вполне может пригодиться. Например скачать пожатые им же ресурсы. Быстро оценить загрузку, найти тяжелые картинки.
>Боюсь что ранжирование поисковиком от того же google производится по аналогичным критериям может быть даже работает тот же программный код.
Зачем гуглу юзать кастрированный GPS, когда у него прекрасный Lighthouse? А под закрытым капот наверняка и более продвинутый движек оценки загрузки.
>…все же имеет ощутимый результат … для более высокого поискового рейтинга
Я не видел ни одного кейса, где «подняли сайт в зеленую зону по GPS — прыгнули из топ-20 в топ-10». Из топ-100 в топ-50, 30, 40 видел. Но там трафика нет.
Повторю свое мнение: GPS полезен владельцам сайта или сеошникам, чтобы быстро оценить есть ли проблемы. Но решать эти проблемы будут разрабы, которые будут использовать другие, более информативные инструменты. Говорю вам как владелец, сеошник и разраб =)
Это да, никто не понимает до конца что такое сознание, интеллект и мыслить. Однако это абсолютно не мешает оценивать результаты этого всего. Поэтому апеллировать к этому факту ну такое. Человек мыслит, компьютер нет. Однозначный факт.
В том-то и дело, что когда нет датасета (трафика и конверсий, достаточных для обучения алгоритма) конкретного посетителя, применяется item-based подход: смотрим что покупали с этим товаром, ранжируем по цене, CTR или любой другой метрике, кидаем в рекомендации.
Когда есть датасет, мы обучаем алгоритм (ML) или усложняем текущую рекомендательную систему (SQL) с учетом новых данных, зависит от желаний и возможностей бизнеса. Есть ли разработчик для внедрения ML или ресурсы для его найма. Это user-based подход.
Ну и, собственно как всегда, истина посередине. Хабр
Нейросеть — нет. А вот латентно-семантический анализ или градиентный бустниг над решающими деревьями вполне понятные (не мне =) ) алгоритмы, которые тоже относятся к ML.
Страницы пагинации вполне можно использовать во благо. Например типичный список товаров, отсортированный по цене. На первой странице цены 10-8 т.р., на второй 8-6 т.р., на третьей 6-4 т.р. и так далее. Добавляем в title и meta диапазон, подставляем в описание страницы, разрешаем индексирование и… вуаля, ищемся по запросам вида «купить кроссовки от 4 до 6 тысяч».
Сравните отчеты по этой странице в Lighthouse (без PWA метрик) и Goggle Page Speed. В первом вполне конкретные on-page проблемы, во втором 80% претензий вида «уменьшить размер на 114 Б (21 %)» к CDN. Если для вас GPS более информативен — у меня нет задачи вас переубеждать.
Разработчики не пользуются Goggle Page Speed. Для этих целей есть Dev Tools со всеми метриками, таймингами и прочими FPS. Или Lighthouse. Или еще куча инструментов. Так что да, GPS это чисто сеошный фетиш, зачастую бесполезный.
Тогда зачем вкладываться в ML, если можно дешевле в движек?
При подходе «конверсия B при А+В >5% — кидаем в рекомендации» ML не нужен. Он нужен в случае если мы хотим «конверсия B при А+В <2%, но вот конкретно этот персонаж/сегмент конвертнется с вероятностью >80% — кидаем в рекомендации». Вот это пример «обученного». Для этого нужен датасет именно этого человека/сегмента.
В этом случае будут точечные рекомендации и получится избавиться от маркетолога, ради чего, собственно, все и затевается.
>зато если «зимой плавки+чемодан» — то можно предложить и ласты.
Нельзя. И маркетолог, и SQL движек это поймут — движек из статистики (предлагали, не заходит), а маркетолог из опыта (на курорт со своими ластами не ездят). ML тоже научится, но сроки…
В академических целях это безусловно классный опыт. Удачи.
Но и тут опять все упирается в сегментирование трафика: в северном климате не работает предложка, которая на ура заходит в южном. Например. Откуда ML возьмет это исключение? Маркетолог задаст. Так, стоп, мы ж хотели заменить его на ML…
Да, он конечно же обучится сегментировать сам. Со временем. Но это уже вопрос готов ли бизнес ждать.
Опять не понял =)
Он, маркетолог, работает со статистикой и выдает рекомендации. Как они реализуются — вопрос разработки.
>попытаться решить их на ML
Алгоритмические рекомендательные системы (SQL) на вход получают только статистику. Маркетолог — статистику, свой опыт и здравый смысл.
ML это попытка заменить маркетолога и как-то прикрутить на вход «опыт». А «здравый смысл» задается в исключениях. Например не стоит предлагать холодильник через пол года после покупки холодильника. Или ласты зимой, несмотря на то что летом шорты+ласты заходят на ура, тогда как зимой шорты покупаются для спортзала и ласты в предложке уже безумство, а не cross-sell.
И вот эти самые исключения и есть самое узкое место в ML. Например коллаборативная фильтрация «увидит в статистике», а маркетолог поймет из опыта (или тоже из статистики), что генератор для Приоры можно предлагать хоть каждые 2 месяца, а для Тойоты не стоит вообще его рекомендовать. А чтобы обучить таким исключениям ML нужен нехилый такой датасет. Поэтому я не верю в то что ML лучше. По крайней мере для относительно небольших сайтов и сроков. Если это Амазон и задача за год натаскать сетку, то возможно.
Ну, рекомендации такая штука, которая в принципе не выстрелит сто из ста. А количество шлака «легко» минимизируется. Сегментация пользователей по группам, сегментация правил рекомендаций по группам пользователей, сегментация по истории посещений внутри группы пользователей, сегментация по… да по чему угодно. Естественно это должен делать грамотный маркетолог, а не разработчик, который руководствуется своими догадками.
Какую библиотеку? 100500 лет работают паттерны «С этим товаром смотрели» и «С этим товаров купили». Нафига усложнять все? Статья именно об этом: прежде чем пилить блокчейн с диплернинг на бигдате, стоит повспоминать/подучить проверенные практики.
>Кто будет эти правила забивать, и главное, откуда он вообще их возьмет?
Если говорить об ИИ, то рекомендации будут на основе поведения конкретного человека. Но в том и «глупость» — чтобы натаскать сетку на конкретного человека, нужны большие объемы данных (его трафик и его конверсии). Эти данные есть у поисковиков. Но на обычных сайтах чтобы собрать такой объем потребуется… ну оочень много трафика и конверсий этого конкретного человека. Именно поэтому рекомендательные системы пишутся на основе различных эвристик и прочих коллаборативных фильтраций, основанных на статистике.
Есть варианты интереснее, когда каждый подъезд дома имеет свой номер и получается ул. Леонова д. 51 — это средний подъезд в доме с адресом ул. Леонова 50-52
Очень спорно. Я не фронт, но уверен что любой мидл прикрутит SSR за рабочий день в к любому реактивному сайту. Хоть в статику, хоть поднять ноду на сервере и вот оно — изоморфное приложение. Возможно я не прав и фронтэндеры меня поправят.
>Боюсь что ранжирование поисковиком от того же google производится по аналогичным критериям может быть даже работает тот же программный код.
Зачем гуглу юзать кастрированный GPS, когда у него прекрасный Lighthouse? А под закрытым капот наверняка и более продвинутый движек оценки загрузки.
>…все же имеет ощутимый результат … для более высокого поискового рейтинга
Я не видел ни одного кейса, где «подняли сайт в зеленую зону по GPS — прыгнули из топ-20 в топ-10». Из топ-100 в топ-50, 30, 40 видел. Но там трафика нет.
Повторю свое мнение: GPS полезен владельцам сайта или сеошникам, чтобы быстро оценить есть ли проблемы. Но решать эти проблемы будут разрабы, которые будут использовать другие, более информативные инструменты. Говорю вам как владелец, сеошник и разраб =)
Когда есть датасет, мы обучаем алгоритм (ML) или усложняем текущую рекомендательную систему (SQL) с учетом новых данных, зависит от желаний и возможностей бизнеса. Есть ли разработчик для внедрения ML или ресурсы для его найма. Это user-based подход.
Ну и, собственно как всегда, истина посередине. Хабр
Сравните отчеты по этой странице в Lighthouse (без PWA метрик) и Goggle Page Speed. В первом вполне конкретные on-page проблемы, во втором 80% претензий вида «уменьшить размер на 114 Б (21 %)» к CDN. Если для вас GPS более информативен — у меня нет задачи вас переубеждать.
При подходе «конверсия B при А+В >5% — кидаем в рекомендации» ML не нужен. Он нужен в случае если мы хотим «конверсия B при А+В <2%, но вот конкретно этот персонаж/сегмент конвертнется с вероятностью >80% — кидаем в рекомендации». Вот это пример «обученного». Для этого нужен датасет именно этого человека/сегмента.
В этом случае будут точечные рекомендации и получится избавиться от маркетолога, ради чего, собственно, все и затевается.
Нельзя. И маркетолог, и SQL движек это поймут — движек из статистики (предлагали, не заходит), а маркетолог из опыта (на курорт со своими ластами не ездят). ML тоже научится, но сроки…
В академических целях это безусловно классный опыт. Удачи.
Да, он конечно же обучится сегментировать сам. Со временем. Но это уже вопрос готов ли бизнес ждать.
Опять не понял =)
Он, маркетолог, работает со статистикой и выдает рекомендации. Как они реализуются — вопрос разработки.
>попытаться решить их на ML
Алгоритмические рекомендательные системы (SQL) на вход получают только статистику. Маркетолог — статистику, свой опыт и здравый смысл.
ML это попытка заменить маркетолога и как-то прикрутить на вход «опыт». А «здравый смысл» задается в исключениях. Например не стоит предлагать холодильник через пол года после покупки холодильника. Или ласты зимой, несмотря на то что летом шорты+ласты заходят на ура, тогда как зимой шорты покупаются для спортзала и ласты в предложке уже безумство, а не cross-sell.
И вот эти самые исключения и есть самое узкое место в ML. Например коллаборативная фильтрация «увидит в статистике», а маркетолог поймет из опыта (или тоже из статистики), что генератор для Приоры можно предлагать хоть каждые 2 месяца, а для Тойоты не стоит вообще его рекомендовать. А чтобы обучить таким исключениям ML нужен нехилый такой датасет. Поэтому я не верю в то что ML лучше. По крайней мере для относительно небольших сайтов и сроков. Если это Амазон и задача за год натаскать сетку, то возможно.
Если говорить об ИИ, то рекомендации будут на основе поведения конкретного человека. Но в том и «глупость» — чтобы натаскать сетку на конкретного человека, нужны большие объемы данных (его трафик и его конверсии). Эти данные есть у поисковиков. Но на обычных сайтах чтобы собрать такой объем потребуется… ну оочень много трафика и конверсий этого конкретного человека. Именно поэтому рекомендательные системы пишутся на основе различных эвристик и прочих коллаборативных фильтраций, основанных на статистике.