Розробка сайту брендового одягу, взуття та аксесуарів

Паралельно з розробкою сайту клієнт співпрацював з нашою командою з послугою Пошукового просування. З першими результатами робіт під час та одразу після запуску вебпроєкту можна ознайомитись за посиланням.

Роботи з розробки сайту

Сайт реалізовувався на базі 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: (наприклад: роздрібна, оптова, акційна).

Наявних 3х категорій (Аксесуари, Одяг, Взуття) недостатньо для якісного SEO та навігації. Ми рекомендували створити підкатегорії (наприклад: Одяг - Худі / Футболки / Штани), що дозволило би автоматично розподіляти товари по відповідних розділах сайту під час імпорту.

4. Кроки по реалізації:

1. Налаштування в CRM логіки зв'язку "Батьківський товар - Модифікації" (мав втілити розробник).
2. Аудит бази, злиття дублікатів в одну модель та дозаповнення відсутніх мовних версій (особливо назв та описів) - завдання контент-менеджера.
3. Визначення, чи всі три типи цін (Ціна 1, 2, 3) мали вивантажуватися на сайт, чи деякі призначені лише для внутрішнього використання в CRM (звітна особа - замовник).

Технічні вимоги до полів Опцій та Фільтрів у CRM

1. Логіка формування Опцій. Для того, щоб на сайті замість дублікатів з'явилася одна картка з вибором параметрів, необхідно було впровадити автоматизацію на основі конкретних полів у CRM.

• Автоматичне створення: ми рекомендували формувати опції автоматично при імпорті.
• Необхідні поля в CRM:
  • Розмір: числове або буквене значення (напр. 42, XL, 38).
  • Колір (UA/RU): текстове поле або довідник (напр. Чорний / Черный).
• Результат: система групує товари за Артикулом/Моделлю, а значення з цих полів перетворює на кнопки вибору у картці товару на сайті.

2. Структура полів для фільтрації. Для коректної роботи фільтрів на сайті, кожна характеристика в CRM мусить мати двомовне значення. Ми рекомендували використовувати тип поля "Випадаючий список" (Dropdown) або "Мультиселект", адже це виключає помилки (наприклад, "Lviv", "lviv" та "Львів" система сприйме як різні значення, якщо вводити їх вручну).

3. Переваги уніфікації через списки

1. Чистота даних: на сайті відсутні сміттєві фільтри через друкарські помилки в CRM.
2. Швидкість контент-менеджменту: співробітнику простіше обрати варіант зі списку, ніж щоразу вводити текст на двох мовах.
3. 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 ми рекомендували встановити заборону на збереження картки, якщо не заповнені: Артикул, Ціна, Кількість та Назва (UA). Це б вберегло клієнта від ситуації, коли на сайт вивантажується битий товар без назви або з нульовою ціною.

*відображення додаткових рівнів цін (Ціна 2 та Ціна 3) не було реалізоване через перегляд комерційної логіки проєкту.

Поля для опцій

Необхідно було визначити: чи створюються опції (розмір, колір) автоматично. Якщо так, у CRM потрібно було додати:

• Розмір
• Колір (укр / рос)

На основі цих полів формуються опції товарів на сайті.

Поля для фільтрів

Щоб фільтри на сайті працювали коректно, у CRM мали бути поля:

• Доставка
• Тип
• Колекція
• Сезон
• Призначення

Усі значення мали бути вказані двома мовами. Важливо: ми рекомендували використовувати випадаючі списки, а не вільний ввід тексту - так дані уніфікуються, що пришвидшує роботу.

Логіка даних при створенні товару на сайті:

• Якщо не заповнено поле Бренд (рос), береться значення з поля Бренд.
• Якщо не заповнено поле Модель, береться значення з поля Артикул.
• Якщо не заповнено поле Назва товару (рос), береться значення з поля Назва товару.
• Якщо не заповнено поле Опис (рос), береться значення з поля Опис (укр).
• Характеристики товару заповнюються на основі таких полів: Тип, Колір, Колекція, Сезон, Призначення.
• На основі характеристик та опцій автоматично створюються фільтри.

Додатково ми створили модуль, в якому можна вказувати ключ API та інші параметри.

Після того, як клієнт вніс товари в CRM, ми завершили технічну інтеграцію сайту з CRM, що дозволило повністю автоматизувати імпорт товарної номенклатури та атрибутів (фільтрів). Для подальших робіт ми надіслалаи запит на інформацію:

1. SEO-дані для фільтрів (ЧПУ)

Для кожної сторінки фільтрації необхідно було підготувати:

• Заголовок H1 та URL-адресу.
• Мета-теги: Title та Description.
• Контент: текстовий опис категорії.
• Технічне: перелік активованих фільтрів для коректної логіки меню.

2. Контактна інформація та сервісні сторінки

• Контакти: номери телефонів, e-mail, посилання на соцмережі.
• FAQ: підготовка відповідей на типові запитання клієнтів.
• Сайт: текст Про нас.
• Юридичне: тексти Правил використання сертифікатів, Політики конфіденційності, Публічної оферти.

3. Контент-маркетинг та соціальний доказ

• Блог: написання статей (тексти + візуальне оформлення).
• Відгуки: наповнення загальними відгуками про магазин та окремими - про конкретні товари.

Після реалізації наданих даних клієнт провів підсумковий аудит ресурсу та надав перелік фінальних правок. Ми їх опративно реалізували.

В кінці лютого відбувся реліз проєкта. Далі клієнт перейшов на послугу SEO-оптимізація сайту, де ми сфокусувалися на безпечному переході до релізу. Наша команда провела передрелізну та післярелізну перевірки, за результатами яких було виконано необхідні технічні вдосконалення.