Последние сообщения

Попробовали и можно с точностью сказать что DST Marketplace разработан с учетом лучших практик создания маркетплейсов, что делает его действительно ценным инструментом. 

Для нас стало главным что в системе управления сайтом все продумано до мелочей, что позволяет значительно сократить время на работу с платформой. Возможности, предоставляемые системой, такие как управление маркетингом и IT-инфраструктурой, позволяют сосредоточиться на стратегии развития бизнеса, а не на технических деталях. Также отлично реализованы экспорт и импорт товаров и широкие возможности коммуникации с поставщиками. 

Я недавно ознакомился с программным обеспечением DST Marketplace, и могу с уверенностью сказать, что это отличный инструмент для быстрого запуска маркетплейсов. Чудесно, что он основан на профессиональной платформе DST Platform, что обеспечивает его надежность и мощность.

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

Также радует оптимизация платформы под конкретные отраслевые требования, что даёт возможность разработать специализированные маркетплейсы для B2B и B2C. С уверенностью рекомендую DST Marketplace всем, кто хочет быстро реализовать идеи в сфере электронной коммерции!

Ничего сложного, в DST Store есть прекрасная функция клонирования товарной карточки и массово расставления атрибутов (фильтров) к товарам, если приноровиться, то можно и самому спокойно добавить 10 тысяч товаров за несколько дней.

У меня ушло два дня чтоб понять как что работает и далее в течении еще двух дней я добавил все товары сам, главное понять, как добавлять массово атрибуты т.к. именно на них тратиться больше всего времени.

Я просто люблю делать все сам чтоб понимать, как работает и как говориться, когда делаешь сам получаешь то что хочешь. 

Наполнение Интернет-магазина можно сделать несколькими способами.

1. Способ это, собственно, самому.

2. Если номенклатуры среднее количество, например более от 500 до 5000 штук то это проще сделать, заказав работы у контент-менеджеров, на фрилансе или в самом DST, мы заказывали в DSTони сделали все быстро в течении полторы недели добавили 4500 товаров, с атрибутами и картинками. По оплате не скажу, делали давно, но обошлось не дорого.

3. Если товаров много, более 10000 штук то тут скорей всего заказать написать парсер, его заказать также можно в ДСТ, чем больше доноров источников откуда брать информацию, тем дороже парсер. Парсить можно откуда угодно, с любого сайта или файла

Мы работаем и с Яндекс.Метрикой и с Google Analytics, DST Analitics приводить смысла нет т.к. это уже не сторонний скрипт аналитики и являеться больше вспомогательным для основных, из опыта могу сказать так — клик фиксируется на нашей стороне, когда пользователь кликает по ссылке в рекламе.

Визит и сеанс фиксируются системами веб-аналитики: Яндекс.Метрикой и Google Analytics соответственно. Когда пользователь заходит на сайт, браузер загружает счётчик систем, и они фиксируют визит и сеанс.

Из-за чего кликов больше, чем визитов и сеансов

Низкая скорость загрузки сайта

По статистике, до 50% пользователей уходят с сайта, если он грузится больше 3 секунд. Сайт может грузиться долго по нескольким причинам:

— на нём есть тяжёлые изображения — весом более 100 Кбайт

— некорректно установлены скрипты систем аналитики

— низкая скорость ответа сервера

— у сайта нет мобильной версии

Перед запуском мобильных рекламных кампаний проверьте скорость загрузки сайта на телефоне.

Низкая скорость или нестабильная работа интернета

Если пользователь кликнул по ссылке, сессия может не начаться из-за низкой скорости интернета или его нестабильной работы.

Это может произойти в метро: если пользователь кликнет по ссылке, но связь прервётся до того, как загрузится счётчик, системы аналитики не засчитают сеанс.

Пользователь кликнул по ссылке случайно

Если сайт начнёт загружаться в браузере, но пользователь закроет его до того, как загрузится счётчик, система аналитики не засчитает сеанс.

Нет UTM-меток в рекламной ссылке

Если вы не поставите UTM-метки, системы аналитики не смогут определить источник перехода. Все сессии на сайте будут уходить в «Прямые переходы» в отчётах Google Analytics или в источник «Не определено» в Яндекс.Метрике.

Всегда вставляйте в рекламные ссылки UTM-метки.

Параметры utm_source и utm_medium — обязательные. Для рекламных кампаний в МТС Маркетологе можете использовать такой вариант: site.ru/?utm_source=marketolog&utm_medium=sms

Когда кликов меньше, чем визитов и сеансов

Сохранение ссылки с UTM-разметкой

Если пользователь сохранит ссылку с меткой в закладках и будет переходить по ней, система аналитики будет засчитывать новый сеанс каждый раз. При этом мы уже не будем засчитывать клики. Поэтому даже после завершения рекламной кампании вы можете наблюдать «остаточный трафик».

Атрибуцирование в Google Analytics

Google Analytics использует модель атрибуции «По последнему непрямому взаимодействию».

Допустим, пользователь зашёл на сайт по рекламной ссылке, а после этого зашёл напрямую и совершил конверсионное действие. Конверсия будет приписана первому источнику — рекламе. 

Насчет некорректной метрики это вообще целая проблема, мы специально в течении нескольких месяцев замеряли и тестировали Яндекс метрику и скрипт аналитики DST Analitics, который установили и который работает прям на сервере, можно сказать одно Яша не досчитывает примерно 30-40% всего трафика, что приводит к неправильной статистики а та в таком случае к аналитике и подходу в бизнесе, так что доверие Яндекс Метрике ноль  

Спасибо, вот это очень было полезно и нужно 

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

$my_array = array_diff($my_array, array('Value_to_remove'));

Например:

$my_array = array('Andy', 'Bertha', 'Charles', 'Diana'); echo sizeof($my_array) . "\n"; $my_array = array_diff($my_array, array('Charles')); echo sizeof($my_array);

Это отображает следующее:

4 3 

В этом примере элемент со значением «charles» удаляется, как это можно проверить с помощью вызовов SizeOf (), которые сообщают об размере 4 для начального массива, и 3 после удаления.

Вместо того, чтобы выполнять цикл Foreach () на массиве, было бы быстрее использовать array_search (), чтобы найти правильный ключ. На небольших массивах я бы пошел с Foreach для лучшей занятости, но для больших массивов или часто выполняемых кодов это должно быть немного более оптимальным:

 
$result=array_search($unwantedValue,$array,true); if($result !== false) {   unset($array[$result]);    }
 

Строгий оператор COMPARSION! == необходим, потому что Array_Search () может вернуть 0 в качестве индекса $ нежелательной.

Кроме того, приведенный выше пример удалит только первое значение $ notemedValue, если $ noteantEdValue может произойти более чем один раз в массиве $, вы должны использовать array_keys (), чтобы найти все из них:

 
$result=array_keys($array,$unwantedValue,true) foreach($result as $key) {   unset($array[$key]); }
 

Лучшее решение — использовать array_filter Функция:

$display_related_tags =     array_filter($display_related_tags, function($e) use($found_tag){         return $e != $found_tag['name'];     }); 

CMS — это программное приложение, которое позволяет нетехническим пользователям управлять содержимым сайта, не требуя знания HTML или языков программирования. Платформы CMS предоставляют удобный интерфейс для создания, редактирования и публикации контента. 

Плюсы:

Легкость в настройке: CMS-платформы имеют готовые темы и шаблоны, которые можно настроить в соответствии с вашими потребностями, что означает, что они относительно быстро устанавливаются.

Удобство в использовании: Платформы CMS имеют дружественный интерфейс, что делает их простыми в использовании даже для нетехнических пользователей.

Управление контентом: Платформы CMS предназначены для управления содержимым сайта, что означает, что они имеют встроенные функции для создания, редактирования и публикации содержимого.

Плагины и расширения: Платформы CMS имеют широкий спектр плагинов и расширений, которые могут расширить их функциональность, не требуя дополнительного кодирования.

Минусы:

Ограниченная настройка: Платформы CMS разработаны для удобства пользователей, что означает, что они имеют ограниченные возможности настройки. Если вам нужен уникальный дизайн или специфическая функциональность, вам, возможно, придется нанять разработчика, чтобы сделать настройки.

Проблемы с производительностью: Платформы CMS могут быть ресурсоемкими, что может привести к проблемам с производительностью при неправильной оптимизации.

Уязвимости в системе безопасности: Платформы CMS являются популярной мишенью для хакеров, что означает, что они могут быть уязвимы к нарушениям безопасности, если они не защищены должным образом.

Фреймворк — это набор инструментов и библиотек, которые облегчают разработку веб-приложений. 

Плюсы:

Персонализация: Фреймворки обеспечивают высокую степень кастомизации, что означает, что вы можете создать уникальный дизайн и функциональность в соответствии с вашими конкретными требованиями.

Производительность: Фреймворки оптимизированы для производительности, что означает, что они могут обрабатывать большие объемы трафика и данных без замедления.

Безопасность: Фреймворки разработаны с учетом требований безопасности, что означает наличие встроенных функций безопасности для защиты от распространенных уязвимостей.

Минусы:

Тяжелая кривая обучения: Фреймворки могут иметь крутую кривую обучения, что означает, что для эффективной работы с ними требуются опытные разработчики.

Время разработки: Разработка на основе фреймворка может занять много времени, поскольку она предполагает создание всего с нуля.

Обслуживание: Фреймворки требуют постоянного обслуживания и обновлений для обеспечения их безопасности и актуальности.

Основное отличие между CMS и фреймворком заключается в том, что CMS — это система управления сайтом с готовым функционалом, а фреймворк — набор библиотек, инструмент для разработчика.

По сути, CMS — это уже собранный сайт, который нужно адаптировать под свои нужды. Любая CMS собирается как конструктор из готовых элементов, разработка сайтов на фреймворке требует организации кода.

Фреймворк даёт каркас для будущего проекта. В отличие от CMS, это более низкоуровневое решение, требующее привлечения разработчиков. 

Реляционным хранилищам данных (ХД) более трех десятков лет. За последние 10 лет закат традиционной аналитики на их основе предрекали как минимум два раза. Сначала — при появлении облачных ХД, затем — озер данных.

Построение хранилища данных на территории заказчика (“on premises”) — инвестиционно-емкий проект, который может занимать до одного года и более. Облачные ХД были призваны удешевить стоимость развертывания хранилища, а также справиться с постоянно растущими объемами исходных данных. Но повсеместного перехода с традиционных ХД на облачные не произошло. По результатам последнего опроса IDC, 47% предприятий в мире используют централизованную архитектуру облачного хранилища. Но через два года этот показатель сократится до 22%. Основная причина в том, что возможности передачи данных растут медленнее, чем емкости хранилищ.

Что касается высокопроизводительных программно-аппаратных комплексов, используемых при построении ХД, таких как Oracle Exadata, то в России уже сегодня наблюдается опережающий спрос на «on-premises» решения.

После облачных ХД следующей «угрозой» для традиционных хранилищ стали озера данных. По оценке IDC, с 2010 по 2020 год объем мировой «цифровой вселенной» вырос в 32 раза и достиг 64 ЗБ. Аналитика больших данных превратилась в быстрорастущий ИТ-сегмент, а озера данных — в ключевой элемент Big Data инфраструктуры. Появились предположения, что озера могут отвоевать долю рынка у реляционных баз данных и даже «поглотить» традиционные ХД. Но сегодня каждое из них: хранилище и озеро — по-прежнему обслуживает собственную аналитическую нишу.

Одно из последних предсказаний о закате реляционных ХД связано с новой гибридной архитектурой — data lakehouse. Предполагается, что она придет на смену хранилищам и озерам данных, объединив эта два инструмента подготовки данных для аналитики. Термин data lakehouse условно можно перевести как «хранилище и озеро данных».

Ознаменует ли появление data lakehouse конец жизненного цикла ХД, или это просто новая организация работы с данными? Попробуем разобраться.

Почему появилась идея data lakehouse

Традиционные банковские ХД обрабатывают структурированные данные и обслуживают традиционную аналитику — выпуск различных видов отчетности и подготовку данных для аналитических задач, в том числе для прогнозирования на основе накопленных данных. Архитектура хранилищ оптимизирована для быстрого извлечения данных и одновременной работы большого количества пользователей.

В отличие от хранилищ, озера данных ориентированы на обработку неструктурированных и структурированных данных (Big Data), первые могут составлять до 80%. Данные могут извлекаться из потоков — социальных сетей, электронной коммерции, датчиков и Интернета вещей (IoT). Схема озера данных определяется «по чтению» (on read), а хранилища — «по записи» (on write). Наконец, озера не предусматривают высокую производительность обработки запросов и поддержку многопользовательского режима работы. Собранные в них данные — основа для применения методов машинного обучения (machine learning) и различных подходов «науки данных» (Data Science).

Как правило, хранилища и озера работают изолированно друг друга. Появление концепции гибридной архитектуры — это попытка объединить данные, собранные в хранилища и озера, и аналитические выводы, полученные на их основе.

Гибридная архитектура может не только расширить возможности хранилищ в части аналитики неструктурированных данных, но и устранить ограничения озер в обеспечении качества данных. Ряд экспертов также считает, что вычислительные возможности open-source платформ для озер данных начинают не справляться с нагрузкой, что подрывает идею об их экономичности.

Согласно исследованию TDWI, сегодня озера часто выполняют вспомогательную роль в подготовке аналитики. Только треть опрошенных компаний (37,3%) использует озера данных по прямому назначению — для продвинутой и ML-аналитики. Остальные — как область для временного хранения копии исходных данных перед их ETL-обработкой (37,3% опрошенных) или как расширение хранилища данных (36,7% опрошенных).

Data lakehouse: когда ждать пришествия варяга

Гибридная архитектура пока находится на уровне концепции, а соответствующая терминология только формируется. Например, большинство участников исследования TDWI предпочитают использовать термины, связанные с архитектурой. 43% называют ее корпоративной архитектурой данных (enterprise data architecture), 36% — гибридной архитектурой данных (hybrid data architecture), 35% — современной архитектурой хранилища данных (modern data warehouse architecture). Сами эксперты TDWI склоняются к термину мультиплатформенная архитектура данных (multiplatform data architecture), а аналитики Gartner используют data lakehouse.

По мнению последних, data lakehouse является развитием концепции логического хранилища данных, которое Gartner представил около 15 лет назад. Аналитики описывают ее как конвергентную инфраструктурную среду, в которой обеспечиваются все шаги по обработке и преобразованию данных: от сырых данных до информации, готовой для «употребления». Технология data lakehouse только прорабатывается, и пройдет пять-десять лет, пока она выйдет на так называемое плато продуктивности на кривой хайп-технологий в области управления данными.

Чем привлекательна гибридная архитектура

Основная выгода, которую принесет data lakehouse — извлечение еще большей ценности из данных. Об этом заявили 64% участников упомянутого опроса TDWI.

Переход к гибридной архитектуре позволяет унифицировать источники данных: и хранилища, и озера — в масштабе всей организации и обеспечить получение непротиворечивой отчетности и аналитики для разных бизнес-вертикалей. Так считают 53% участников опроса TDWI.

Сегодня корпоративные ХД могут ограниченно использовать ML-методы. По мнению 49% респондентов TDWI, применение data lakehouse дает возможность расшить «узкие места» традиционной аналитики. Если хранилища и озера будут унифицированы, а данные в озерах — структурированы, и их можно будет обрабатывать с помощью запросов, гибридная архитектура может стать основой для аналитической обработки традиционных и новых типов данных.

Очевидно, что говорить о закате технологии реляционных хранилищ данных по-прежнему более чем преждевременно. Если новая гибридная архитектура найдет свое промышленное воплощений, что неизбежно с учетом роста объемов и разнообразия данных, то она упрочит позиции корпоративных ХД в ИТ-ландшафте банка. Они обеспечат традиционную непротиворечивость и надежность отчетных данных, а в связке в другими аналитическими технологиями позволят извлекать из них еще большую ценность.

Есть еще способы, например ленивая загрузка или загрузка по требованию на клиентской части

Бывает так, что некоторое содержание страницы нужно не всем или не всегда, но на генерацию этого материала или для его передачи тратится много ресурсов. В этом случае имеет смысл сделать загрузку «ленивой», то есть не генерировать и не загружать в браузер информацию до тех пор, пока она не понадобится.

Реализуется ленивая загрузка при помощи AJAX и инициируется событиями, отслеживаемыми при помощи JavaScript. То есть для работы методики необходима поддержка JS браузером, то есть перед тем, как применить ленивую загрузку, стоит знать, что пользователи без JS воспользоваться функцией не смогут, а поисковые роботы скрытый таким образом контент скорее всего не увидят (или увидят отдельные страницы, с которых этот контент браться будет).

Разновидности ленивой загрузки:

— Загрузка «по клику» — например, раскрывающийся текст по ссылке «показать больше» или «подробнее», справочная информация в модальных окнах или загрузка большого изображения при нажатии на миниатюру. Это наиболее распространённый способ для представления контента, который с не очень высокой вероятностью заинтересует пользователя. В случае, если контент скорее всего заинтересует или текст важен для поисковых систем, а цель скрытия — экономия пространства, то лучше реализовывать функциональность не на AJAX, а на простом JS — загружать сразу, но отображать по требованию.

— Загрузка «при скроллинге» — загрузка следующей партии материалов в тот момент, когда пользователь уже почти ознакомился с изначально загруженным содержанием. Этот способ ленивой загрузки используется в социальных сетях («бесконечные» ленты новостей), но также применим для интернет-магазинов, каталогов и сайтов СМИ. В случае «бесконечных» лент стоит помнить о доступности навигации: нужна либо фиксированная панель меню, либо кнопка «наверх».

— Фоновая загрузка «по времени» — если страница уже загружена, а пользователь остаётся на открытой странице сайта, то можно в фоновом режиме загрузить какие‑либо ресурсы (большие изображения, например), которые понадобятся ему при дальнейшей работе с сайтом. Метод может ускорить сайт, если загружать действительно необходимые при дальнейшей работе материалы, но требует осторожного применения — необходимо знать, что именно загружать (это можно определить на основании статистики посещений, например), а также учитывать скорость доступа посетителя к сети интернет (пользователь медленного мобильного интернета не будет вам благодарен за такую «заботу»).

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

Афанасий Никольцев

Все верно Афанасий, чаще всего на стороне браузера кешируются файлы изображений, JS и CSS файлы. Чуть реже имеет смысл кешировать страницы и бинарные файлы (медиа-файлы, PDF, скачиваемые документы и архивы и т.д.).

Статические ресурсы должны иметь хотя бы недельное время жизни кеша, а лучше кешировать их сразу на год. Таким образом, эти ресурсы будут только один раз скачиваться с сервера, а затем браузер будет либо сразу использовать локальную копию (если указан заголовок Expires или Cache-Control), либо после проверки на неизменность (если указан заголовок Last-Modifed или ETag).

Заголовки Expires и Cache-Control: max-age

В качестве значения у этих заголовков используется дата. До тех пор, пока она не настала, браузер будет без каких‑либо дополнительных проверок использовать закешированную версию ресурса. Expires поддерживается чуть шире, чем Cache-Control: max-age, поэтому лучше использовать именно его.

Заголовки Last-Modifed и ETag

В качестве значения заголовка Last-Modifed используется дата, а для заголовка ETag — произвольная строка. Если используются эти заголовки, то браузер, прежде чем использовать закешированный ресурс, получит с сервера текущее значение заголовка и сравнит его с заголовком закешированной версии — если данные совпадут, то будет использоваться локальная версия, а если нет — произойдёт повторная загрузка. Запросы проверки происходят быстрее, чем полная загрузка ресурсов, что даёт прирост производительности сайта при повторном использовании ресурсов.

Оптимальная стратегия клиентского кеширования

Для редко меняющихся файлов стоит поставить Expires на дату, которая наступит через год, а в момент изменения этих ресурсов использовать метод «отпечатков пальцев» (fingerprinting) — добавлять к имени файла небольшую часть хеша, которая фомируется на основе его содержания. Таким образом, вся статика всегда закеширована на клиенте, а при изменении этой самой статики меняются имена файлов и они автоматически перезагружаются браузером.

Собственно техника fingerprinting активно используется для статичных ресурсов (стилей и скриптов) во многих фреймворках (в частности, в Ruby on Rails). А массовую простановку для всех типов статичных файлов заголовка Expires можно реализовать на стороне веб‑сервера (в nginx, например).