Всю остальную инфо: ссылку на пост сохранил, изучу.
А саму пасту по логам: кол-во страниц на пользователя, кол-во пользователей на страницу, популярность страницы в охвате всего сайта по логам, отфильтрованным от ботов - такое не собираете?Ведь анализ логов и нужен (в том числе) для понимания успехов конкретного сайта (ну, я так предполагаю).
Просто вся эта "борода" в один момент меня настолько разозлила, что я психанул и вот, пока на таблицах, а потом уже буду думать о софте (параллельно учусь писать код, вот, проект-то уже готов - учись - не хочу :D).
Если бы я еще мог написать что-то дельное :) Но может быть что-то полезное вы для себя найдёте, это тоже хорошо.
Маркетинг считают в основном по аналитическим логам. То есть бэкенд-логи это в основном антифрод. А маркетологи работают по данным ГуглАналитикс(360) или другим подобным системам.
У нас на бэкенде есть группировка двух основных таких показателей: страниц на IP на сеанс и время IP на одной странице (или время между запросами), группируется по AS-кам или двум октетам, больше как показатель для антифрод-аналитики.
А каким образом вы вычисляете виртуальных браузеров, селениумов, зеннопостеров и подобных вещей?
У них есть фингерпринты, типичные баги в обработке подобранных для них JS-ловушек и поведение в основном странное. Расставляются и JS и логические ловушки. Например, у пользователей есть стандартный паттерн поведения и стабильный процент вероятности следущего действия.
Например, после "Действия А" в 67-74% случаев идёт "Действие Б". Ботоводы, даже работающие прицельно, не хотят настолько напрягаться. Потому группируем процент последовательности по AS-кам, а чаще даже по двум первым октетам IP и если какая-то сеть выбивается из статистики идём руками делать grep-ы и смотреть кто и что начал делать. Почти всех "особенных клиентов" аналитики знают в их "лицо", по особенностям поведения и инструментам. Редко бывает кто-то новый.
С методами - понятно.С программами - низкий поклон.
А пул данных какой анализируете? Читаю вот воду водную от русского рерайтного рерайта: кто анализирует ПС, кто страницы. Но как, блин, это поможет, когда БД загажена ботами (могу заблуждаться).
Да ладно, логи - дело скучное. По работе просто смотрю на них почти каждый день уже много лет. Сначала как в матрице обставился пятью мониторами, следил, вчитывался.
Потом, с годами сделал себе панель управления со сводой информацией и скрипты автоматической аналитики. Так вроде удобнее. Но по простому не написать. Понемногу, по одной задаче или параметру дописывал.
У меня есть основной программный инструмент, но про логику его работы наверно не имею права писать, да и вебмастерам он не пригодится.
Для анализа ботов кода используется очень много. Простыми способами отсеять их сложно. А статьи люди не пишут наверно потому, что многие под NDA.
По серверным логам смотрим в основном атаки или попытки разнообразного Fraud-а. Также в страницы встраиваются антифрод-маячки, которые незаметно отправляют на бэкенд сигналы для подсчета ботного рейтинга конкретного посетителя, чтобы отсеять значительную часть виртуальных браузеров, селениумов, зеннопостеров и подобных вещей.
Самое простое, что можно сделать - это открыть лог с помощью
tail -f /var/log/..../my_access_log.txt
Откроется непрерывно бегущая в реальном времени простыня лога.
К этой команде навешиваем grep-ы, наподобие
tail -f /var/log/..../my_access_log.txt | grep --text ';Brand' | grep -v 'Google' (чисто для примера)
и смотрим что там идёт. Если слишком быстро, то довешиваем еще grep -v (исключающее правило).
Медитируем, смотрим закономерности. Фильтруем весь лог grep-ами, сортируем, группируем, считаем. Пишем рекомендации о выделении новой группы логов. Думаем что можно сделать и что еще проанализировать и как.
1. Логи статики пишем в основном в /dev/null
2. Логов пишем несколько. Формат определяем сами. Пишем нужное. Не пишем ненужное. Ошибки отдельно, боты отдельно, корректные запросы пользователей к приложению отдельно.
3. Лучшие инструменты: grep --text, grep -E, grep -v, sort, sort -u, head -n, tail -n, tail -f, sed, awk, wc -l.
Пусть исходное число равно X.
Имеется значение Y, представляющее собой X с прибавленными к нему 130% от X.
Следовательно Y = X + 1.3*X
Или Y = 2.3*X
Так как Y известно, то
X = Y / 2.3
Новое, правильное, значение должно быть 2.2*X или
2.2 * (Y / 2.3)
Если, конечно, вы верно записали, а я правильно понял условия задачи.
Но так или иначе я всё равно не сторонник позиции - забудь и не даже не пытайся.
По другим вашим постам можно понять, что вы действительно оптимистичный и позитивный человек. Это отличные качества. Уверен, такой подход идёт на пользу людям, которых вы консультируете.
Возможно, если ТС обратился бы к вам за помощью в виде консультативного сопровождения, его шансы на успех в создании интернет-магазина сильно возрасли.
Но на том уровне вопросов, что заданы в первом посте темы, вероятность получить прибыль выглядит ниже, чем в случае со стартом на маркетплейсах.
Из этого ответа можно сделать вывод, что не стоит и пытаться.
Человек, образно, нашел ржавый гриф от штанги и спрашивает, не поставить ли ему почти все свои деньги и кучу времени на спор, что он сможет пожать 200 кг.
Для открытия прибыльного интернет-магазина нужен довольно большой объем знаний и умений.
Намного безопаснее попробовать начать с тех же маркетплейсов, чтобы немного разобраться в продукте и рынке. Если продукт уникальный, то он хорошо пойдёт и там. Если неуникальный, маркетплейсы быстро сожрут независимый бизнес за счет преимуществ в маркетинге и логистике.
Можно не полениться посчитать полную сумму затрат на одну сделку и соотнести её с прибыльностью этой сделки. В начале работы собственного интернет-магазина средние затраты на одну сделку будут высокими, поэтому либо первые годы работы в убыток, либо поиск инвестиций путём потери своей доли в бизнесе, либо неконкурентоспособные цены и отсутствие продаж.
Если возникает этот вопрос, то даже и не пытайся.
В контексте общей ситуации с торговлей.
ТС, послушай этого человека. Он знает, что пишет.
они так и не выпустили Yii 3.0
Слышал, что в PHP сейчас хороших фреймворков больше, чем в любом другом языке. Запаса их возможностей хватит почти для любого проекта на PHP.
Создавать новые версии классических фреймворков выглядит уже не очень перспективным. Как новые модели паровозных топок или лошадиных упряжек.
Волна нейросетевых идей только прибывает. Рано или поздно у кого-то могут дойти, наконец, руки до написания качественного транслятора требований на естественном языке или псевдокода в программы LLVM или аналогов.
Пока играются с картинками и автодополнениями. Нейросетевые компиляторы - очевидный следующий шаг.
Что касается вопроса. Делать дopген на PHP фреймворке в 2024 году не выглядит прибыльной стратегией. Видел тесты, где Yii2 показывал хорошую скорость. И читал, что стоимость разработки на нём ниже, чем на некоторых альтернативах.
Только ни дополнительных переходов ни увеличения времени на странице в сравнении со страницами без картинок не замечено.
