GKit – это украинский интернет-магазин, специализирующийся на продаже брендовой одежды, обуви и аксессуаров.
Магазин предлагает продукцию для мужчин, женщин и детей: обувь (кроссовки, кеды, ботинки, сандалии, тапочки Air Jordan, Nike Dunk, New Balance 9060 и др.), одежда (футболки, худи, свитшоты, брюки, шорты, куртки, жилетки), аксессуары: сумки, рюкзаки, рюкзаки мячи и т.д.
Доставка: осуществляется по всей Украине. Оплата: наличными или картой (поддержка Privat24, Monopay, Visa, Mastercard). Обмен и возврат в течение 14 дней. Консультации по выбору размера и поиску товаров под заказ.
Проект основан з целью создания прозрачного сервиса для покупки оригинальных вещей. Компания отмечает, что работает исключительно с проверенными поставщиками и не продает реплики или копии.
Главным ориентиром при разработке проекта являлось создание максимально удобного, логического и интуитивно понятного интернет-магазина для конечного пользователя.
Для этого наши специалисты на этапе старта провели глубокий аудит начального макета и сформировали комплекс рекомендаций по разработке, архитектуре данных и SEO.
В конце февраля 2026 г. состоялся официальный запуск интернет-магазина. Проект успешно прошел предрелизную и послерелизную проверки и перешел на этап окончательного заполнения сайта товарами и последующего SEO-продвижения.
Системное дублирование товаров. Главным техническим вызовом было загромождение базы: одинаковые товары разных размеров вносились как отдельные позиции. Это повторно требовало перестройки архитектуры данных, создания модели «Родительский товар + Модификации» и настройки автоматического формирования опций и фильтров.
Пробелы в дизайне и слабая UX/SEO структура. Первоначальный макет имел UI-пробелы (отсутствие индикаторов в корзине, состояния переключателя языков и формы отзывов в карточке) и небольшую категоризацию (только 3 базовых раздела). Это потребовало доработки макетов, создания подкатегорий и разработки ЧПУ-структуры для SEO.
Непоследовательность решений и изменение бизнес-логики. Проект столкнулся с изменением требований со стороны заказчика уже при разработке. Поэтому некоторые разработанные и согласованные решения не были реализованы на финальном этапе.
Риски человеческого фактора и качество данных CRM. Существовала постоянная угроза выгрузки «битых» товаров (без названий, цен или с ошибками в фильтрах из-за свободного ввода текста). Для устранения этого пришлось вводить правила обязательности полей в CRM, автоподставку языковых версий и форматировать данные через выпадающие списки.
Параллельно с разработкой сайта клиент сотрудничал с нашей командой по услуге Поискового продвижения.
Работы по разработке сайта
Сайт был реализован на базе OpenCart. Как только проект зашел на разработку, наш программист провел анализ существующего макета и выдал правки, упростившие техническую архитектуру и обеспечившие корректное отображение сайта на всех типах устройств.
Отсутствующие элементы (UI Gaps)
- Переключатель языков: в дизайне отсутствовал внешний вид выпадающего списка (dropdown), следовало прорисовать состояние при нажатии.
- Индикаторы в шапке: на иконках Корзины и Избранного не отображалось количество товаров (счетчик в виде цифр). Следовало добавить эти элементы, чтобы пользователь видел наполненность без перехода на страницу.
- Карта товара: отсутствовала форма добавления отзыва, в то время как пользователь должен был иметь возможность оставить фидбек непосредственно на странице товара.
Предложения по логике (UX Optimizations)
Страница Отзывы:
- Изменение структуры (сетка): мы предложили разместить отзывы в формате 3 единицы в один ряд (в 3 колонки), что обеспечило бы симметрию интерфейса и удобство сканирования текста глазом.
- Оптимизация контента: в общем списке отзывов следовало добавить изображение товара и прямую ссылку на него. Это помогло бы пользователям быстрее идентифицировать товар и перейти к покупке.
- Управление кнопками: мы предложили убрать кнопку Добавить отзыв с этой страницы, поскольку основным местом для написания отзывов должны стать карточки товаров.
Сформированный пакет предложений мы предоставили клиенту для рассмотрения и внедрения. Дальше нас ждал промежуточный аудит обновленного макета.
Текущее состояние сайта на момент проведения аудита
- Категоризация: в системе было создано 3 базовые категории: Аксессуары, Одежда и Обувь.
- Карточка товара: вся имеющаяся информация о товаре была ограничена.
- Дублирование позиций: одинаковые товары разных размеров внесены в базу как отдельные товарные единицы, а не как вариации одной модели.
Предложения по оптимизации
Мы предоставили предложение объединить разные размеры и характеристики одного артикула в одну карточку товара через функционал модификаций. Преимущества такого подхода:
- Чистота базы: избегание создания огромного количества дублей одинаковых товаров.
- Удобство учета: проще отслеживать остатки конкретной модели в разрезе размеров/цветов.
- Пользовательский опыт: в карточке товара (если это синхронизировано с сайтом) клиенту будет удобнее выбирать нужный размер, не переходя на другие страницы.
Такое решение сократит количество лишних товаров и в дальнейшем сделает импорт корректным.
Поскольку наполнение сайта планировалось через CRM-систему (клиент выбрал KeepinCRM), мы сосредоточились на построении архитектуры данных – разработали логику автоматизации товарных опций и определили источники входных данных. Сложившееся видение передали клиенту для согласования технического стека интеграции.
1. Автоматизация опций (размер и цвет)
Следовало подтвердить, создаем ли мы опции товаров автоматически (размер, цвет) на двух языках. Если да, то в каждой карточке товара в CRM обязательно должны быть заполнены соответствующие поля. Именно на их основе должны быть сформированы модификации при импорте.
2. Соответствие обязательных полей
Клиенту необходимо было указать, из каких именно полей в CRM (или файле выгрузки) следует забирать данные для следующих параметров:

Фильтры типа (Размер, Цвет - будут созданы на основании опций). Для всех других фильтров также нужно было создать поля в CRM: Доставка, Тип, Коллекция, Сезон, Назначение. Мы рекомендовали использовать список со значениями в CRM, а не поле для ввода, это стандартизировало выбор вариантов и ускорило бы заполнение товаров.
Основной принцип системы - CRM является главным узлом для учета остатков и управления данными о товарах. Мы предложили следующую логику.
1. Обновление товаров (CRM – Сайт). Весь учет складских остатков ведется только в CRM. Процесс обновления выглядит следующим образом:
- Маркер синхронизации: в карточке товара в CRM создается специальный элемент управления (выпадающий список или чекбокс).
- Включено: при сохранении изменений в CRM данные автоматически передаются на сайт.
- Исключено: изменения в CRM остаются только внутри системы, синхронизации с сайтом не происходит.
- Приоритет данных: CRM имеет более высокий приоритет. Если администратор изменит данные о товаре непосредственно в админпанели сайта, возникнет расхождение. Однако при следующем обновлении этого же товара со стороны CRM данные на сайте будут перезаписаны актуальной информацией с CRM.
2. Создание заказов (Сайт – CRM). Процесс обработки заказов работает в обратном направлении для обеспечения операционного учета:
- Автоматическое создание: как только клиент оформляет заказ на сайте, система автоматически генерирует новый заказ в CRM.
- Передача данных: в CRM передается полный пакет информации:
- Перечень заказанных товаров;
- Количество и цена;
- Контактные данные покупателя;
- Методы доставки и оплаты.
Далее мы разработали технический план оптимизации данных в CRM для синхронизации с сайтом.
1. Реструктуризация товарной сетки (устранение дублирования)
Основная проблема - создание отдельных карт для каждого размера, что загромождало базу и усложняло фильтрацию на сайте.
- Переход к модели «Товар + Вариации»: вместо 5 отдельных товаров (например, кроссовки размеров 40, 41, 42, 43, 44) создается одна родительская карта модели. Размеры и цвета выносятся в модификации (SKU) внутри этой карты.
- Логика объединения: объединить дубликаты по признаку "Модель+Бренд". Это позволило бы клиенту на сайте видеть одну карточку с выпадающим списком размеров, что значительно улучшило бы UX (пользовательский опыт).
2. Внедрение обязательных полей (мультиязычность)
Для корректного отображения товаров на сайте, в CRM необходимо было настроить следующие поля:
Идентификация и логистика:
- Артикул (SKU): неповторимый идентификатор (обязательно для синхронизации остатков).
- Модель: группирующее название для объединения модификаций.
- Количество: актуальный остаток на складе.
- Цена/Цена 2/Цена 3: (например: розничная, оптовая, акционная).
| Поле | UA (Українська) | RU (Русский) | Примечание |
| Название товара | Обязательно | Обязательно | Четкое название (напр. "Кроссовки беговые") |
| Описание | Обязательно | Обязательно | Подробный текст о товаре |
| Характеристики | Обязательно | Обязательно | Состав, материал, сезонность и т.п. |
| Бренд | Обязательно | Обязательно | Для работы фильтров на сайте |
Имеющихся 3х категорий (Аксессуары, Одежда, Обувь) недостаточно для качественного SEO и навигации. Мы рекомендовали создать подкатегории (например: Одежда - Худи / Футболки / Брюки), что позволило автоматически распределять товары по соответствующим разделам сайта во время импорта.
4. Шаги по реализации:
- Настройка в CRM логики связки "Родительский товар - Модификации" (должен был воплотить разработчик).
- Аудит базы, слияние дубликатов в одну модель и дозаполнение отсутствующих языковых версий (особенно названий и описаний) – задача контент-менеджера.
- Определение, все ли три типа цен (Цена 1, 2, 3) должны были выгружаться на сайт, или некоторые предназначены только для внутреннего использования в CRM (отчетное лицо - заказчик).
Технические требования к полям Опций и Фильтров в CRM
1. Логика формирования опций. Для того чтобы на сайте вместо дубликатов появилась одна карточка с выбором параметров, необходимо было внедрить автоматизацию на основе конкретных полей в CRM.
- Автоматическое создание: мы рекомендовали формировать настройки автоматически при импорте.
- Необходимые поля в CRM:
- Размер: числовое или буквенное значение (например, 42, XL, 38).
- Цвет (UA/RU): текстовое поле или справочник (например, Чорний / Черный).
- Результат: система группирует товары по Артикулу/Модель, а значение из этих полей превращает в кнопки выбора в карточке товара на сайте.
2. Структура полей для фильтрации. Для корректной работы фильтров на сайте, каждая характеристика CRM должна иметь двуязычное значение. Мы рекомендовали использовать тип поля "Выпадающий список" (Dropdown) или "Мультиселект", т. к. это исключает ошибки (например, "Lviv", "lviv" и "Львов" система воспримет как разные значения, если вводить их вручную).
| Характеристика | Тип поля в CRM | UA (Украинский) | RU (Русский) |
| Доставка | Выпадающий список | Напр. "В наявності" | Напр. "В наличии" |
| Тип | Выпадающий список | Напр. "Кросівки" | Напр. "Кроссовки" |
| Коллекция | Выпадающий список | Напр. "Весна 2026" | Напр. "Весна 2026" |
| Сезон | Выпадающий список | Напр. "Демісезон" | Напр. "Демисезон" |
| Назначение | Мультиселект | Напр. "Для спорту" | Напр. "Для спорта" |
3. Преимущества унификации через списки
- Чистота данных: на сайте отсутствуют мусорные фильтры из-за опечаток в CRM.
- Скорость контент-менеджмента: сотруднику проще выбрать вариант из списка, чем каждый раз вводить текст на двух языках.
- SEO-оптимизация: фильтры с четкими названиями лучше индексируются поисковиками.
Также на сайте у CRM нужно было создать чекбокс или выпадающий список: "Обновлять товар на сайте?". Он позволил бы управлять тем, должен ли товар быть синхронизирован при сохранении.
При настройке СРМ системы появились вопросы на будущее, на которые мы предоставили рекомендации.
1. Где хранить данные (исходники). Загружать фотографии непосредственно в CRM – не лучшая идея для высоконагруженных проектов, поскольку базы данных CRM не оптимизированы для хранения и быстрой раздачи больших медиафайлов.
Рекомендация:
- CRM выступает как «мозг»: в карточке товара хранятся только текстовые ссылки (URL) на фотографии.
- Облачное хранилище (например, S3 или bunny.net) выступает как «склад»: там лежат подлинники высокого качества.
2. Как это работает в цепочке: CRM – Сайт – Клиент. Логика следующая:
- Менеджер скачивает фото. Скрипт автоматически помещает его в хранилище, а в CRM записывает только ссылку: https://cdn.yourdomain.com/products/image_123.jpg.
- Сайт через API забирает с CRM данные о товаре (названии, цене) вместе с этим линком.
- Когда клиент открывает страницу, его браузер запрашивает фото не у вашего сервера/сайта, а непосредственно у CDN.
3. Достоинства использования CDN (на примере bunny.net). Клиент внес предложение использовать «нарезку» (Image Optimizer), т. к. это критично для SEO и скорости:
- Адаптивность: загружается одно большое фото, а CDN отдает смартфону картинку размером 400px, а монитору – 1200px.
- Форматы: автоматическая конвертация в WebP или AVIF, что уменьшает вес файла на 30-50% без потери качества.
- Скорость: благодаря сети дата-центров по всему миру (PoP) клиент в Киеве получит фото с сервера в Восточной Европе, а не из США.
4. Риски и нюансы. Чтобы система работала стабильно, следует учесть следующее:
- Синхронизация названий: файлы в хранилище должны иметь понятную структуру или ID, соответствующую ID товара в CRM во избежание путаницы.
- Стоимость оптимизации: сервисы типа Bunny Optimizer или Cloudflare Images обычно платные (например, $1/мес за зону + оплата за трафик). Но это дешевле, чем терять клиентов из-за медленного сайта.
- Отказоустойчивость: если CDN упадет (что бывает редко), сайт останется без картинок. Поэтому важно настроить корректное кэширование на стороне браузера.

Представленные рекомендации были согласованы с заказчиком, однако не внедрены из-за изменения бизнес-логики проекта на стороне заказчика.
Далее следовало создать и заполнить обязательные поля в CRM – этой работой занималась команда заказчика.
Следующий этап – спецификация обязательных полей товарной карты в CRM.
Для стабильного импорта и корректного отображения товаров на сайте (в обеих языковых версиях), необходимо было внедрить следующую структуру:
1. Идентификация и состав (системные поля). Эти поля критичны для синхронизации остатков и заказов.
- Артикул (SKU): обязательно это уникальный идентификатор товара. Без него автоматическое обновление цены/количества невозможно.
- Модель: обязательно, т. к. используется для группировки вариаций (например, разные цвета одной модели).
- Количество: обязательно, поскольку нужно знать остаток на складе.
2. Ценообразование.
- Цена (розничная): обязательно (основная цена на сайте).
- Цена 2/Цена 3: опционально (могут использоваться для акционных цен, оптовых прайсов или различных программ лояльности).
3. Контент (локализация: UA/RU). Чтобы сайт не имел пустых страниц, эти поля должны быть заполнены в обеих языковых версиях.
- Название товара: обязательно.
- Описание: обязательно (для SEO и информирования клиента).
- Характеристики: обязательно (материал, размер, состав и т.п.).
- Бренд: обязательно (для фильтрации на сайте).
Также на уровне CRM мы рекомендовали установить запрет на сохранение карты, если не заполнены: Артикул, Цена, Количество и Название (RU). Это уберегло бы клиента от ситуации, когда на сайт выгружается битый товар без названия или с нулевой ценой.
*отображение дополнительных уровней цен (Цена 2 и Цена 3) не было реализовано из-за пересмотра коммерческой логики проекта.
Поля для опций
Необходимо было определить: создаются ли опции (размер, цвет) автоматически. Если да, в CRM нужно было добавить:
- Размер
- Цвет (укр/рус)
На основе этих полей формируются опции товаров на сайте.
Поля для фильтров
Чтобы фильтры на сайте работали корректно, у CRM должны быть поля:
- Доставка
- Тип
- Коллекция
- Сезон
- Назначение
Все значения должны быть указаны на двух языках. Важно: мы рекомендовали использовать выпадающие списки, а не свободный ввод текста – так данные унифицируются, что ускоряет работу.
Логика данных при создании товара на сайте:
- Если поле Бренд не заполнено, берется значение из поля Бренд.
- Если поле Модель не заполнено, берется значение из поля Артикул.
- Если не заполнено поле Назва товара, берется значение из поля Название товара.
- Если не заполнено поле Опис, берется значение из поля Описание.
- Характеристики товара заполняются на основе следующих полей: Тип, Цвет, Коллекция, Сезон, Назначение.
- На основе параметров и опций автоматически создаются фильтры.
Дополнительно мы создали модуль, в котором можно указать ключ API и другие параметры.
После того, как клиент внес товары в CRM, мы завершили техническую интеграцию сайта с CRM, что позволило полностью автоматизировать импорт товарной номенклатуры и атрибутов (фильтров). Для дальнейших работ мы направили запрос на информацию:
1. SEO-данные для фильтров (ЧПУ)
Для каждой страницы фильтрации необходимо было подготовить:
- Заголовок H1 и URL.
- Мета-теги: Title и Description.
- Контент: текстовое описание категории.
- Техническое: список активированных фильтров для корректной логики меню.
2. Контактная информация и сервисные страницы
- Контакты: номера телефонов, e-mail, ссылки на соцсети.
- FAQ: подготовка ответов на вопросы клиентов.
- Сайт: текст О нас.
- Юридическое: тексты Правил использования сертификатов, Политики конфиденциальности, Публичной оферты.
3. Контент-маркетинг и социальное доказательство
- Блог: написание статей (тексты + визуальное оформление).
- Отзывы: наполнение общими отзывами о магазине и отдельными – о конкретных товарах.
После реализации предоставленных данных клиент провел итоговый аудит ресурса и предоставил перечень финальных правок. Мы их оперативно реализовали.
В конце февраля состоялся релиз проекта. Далее клиент перешел на услугу SEO-оптимизации сайта, где мы сфокусировались на безопасном переходе к релизу. Наша команда провела предрелизную и послерелизную проверки, по результатам которых были выполнены необходимые технические усовершенствования.