Кейс: сайт зовнішньої реклами AIM Group і 80 000 площин

Сайт AIM Group — агенції зовнішньої реклами, яка продає білборди по всій Україні — вів один підрядник. Сім років. Його позиція була простою: редизайн не потрібен, дизайн на продажі не впливає. Клієнт із цим не погодився і передав проєкт нам за рекомендацією знайомого маркетолога. Далі — про те, що виявилося всередині, чому головною роботою став не дизайн, а імпорт даних, і як одного дня 435 рекламних площин зникли з сайту, не показавши жодної помилки.

Сім років одного підрядника

Нас порекомендували: у клієнта був сайт, а підрядник, який його вів, перестав братися за задачі. Перше, що ми почули, — що з ним було важко мати справу і що будь-яка пропозиція оновити зовнішній вигляд упиралася в одну відповідь: дизайн не впливає на продажі.

Це поширена й зручна позиція. Зручна тим, що її неможливо спростувати без роботи, яку саме й пропонують не робити. Ознаки, за якими редизайн справді потрібен, ми розбирали окремо — у матеріалі про сигнали, що сайту час оновитися.

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

Що ми отримали разом із сайтом

Проєкт — це Ruby on Rails 7.2 з PostgreSQL: близько 800 файлів чужого коду, який сім років поспіль дописували різні руки. Переписувати його з нуля ніхто не просив, та й потреби не було: сайт працює, приносить заявки, а переписування означало б місяці без результату для бізнесу.

Значно гіршою була інша річ. У компанії, яка живе з бази рекламних конструкцій, не було нормального способу цією базою керувати. Тому перше, що з’явилося в репозиторії, — не нові сторінки, а адмінка: авторизація з блокуванням після невдалих спроб, дашборд із живими метриками, заявки, довідники міст, регіонів, районів, операторів і типів конструкцій.

SEO, яке роблять щотижня, а не раз на рік

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

Задачі за ці місяці були різні: шаблони title, description і H1 для сторінок міст і типів конструкцій, генерація XML-карт, канонічні URL, мовні версії, 301-редіректи для площин, які зникають з бази при оновленні сітки оператора. Останнє критичне: без редіректів кожне оновлення бази перетворювало б тисячі сторінок на 404. Загальний підхід до таких переїздів ми описували в чеклісті SEO-міграції.

Найцікавіша задача виглядала як дрібниця. Площини на сторінках типів і міст показувалися в одному й тому ж порядку, і SEO-фахівець побачив у цьому проблему: Google вирішить, що база не оновлюється, і скануватиме сторінки рідше. Він же й сформулював бажаний результат — «змінювати порядок не при кожному завантаженні, а час від часу» — і чесно додав, що не уявляє, як це реалізувати.

Рішенням став денний seed: порядок перемішується раз на добу опівночі, а всередині доби лишається стабільним. Google щодня бачить на першій сторінці нові площини й індексує їх, а пагінація не ламається — сторінки 1, 2 і 3 в межах одного дня не перетинаються між собою. Випадковий порядок на кожне завантаження дав би саме таке перетинання і дублі в індексі.

П’ятнадцять хвилин на кожен файл

AIM Group не володіє білбордами — вона їх перепродає. Це означає, що база сайту складається з прайсів десятків операторів, і кожен оператор надсилає свій файл: свої колонки, свій порядок, свої назви. Разом це близько вісімдесяти тисяч площин, які ще й регулярно змінюються.

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

1. 1Скопіювати шапку з шаблону в нову таблицю.
2. 2По одній колонці перенести потрібні дані з файлу оператора.
3. 3Прибрати зайві верхні рядки, службові написи й порожні блоки.
4. 4Дописати те, чого немає взагалі — наприклад, область і місто.
5. 5Вручну виправити назви типів конструкцій під ті, що прийняті на сайті.

На питання, скільки це забирає часу, прийшла відповідь, яку варто прочитати двічі: «Та поки не багато часу йде бо це сітки хороші мережевих підрядників, +- 15 хвилин йде». П’ятнадцять хвилин — це оцінка для *хорошого* файлу.

Замість того щоб залишити цей процес людині, ми перенесли його в код. Тепер завантажується сирий файл оператора, а система сама зіставляє його колонки з полями бази — комбінацією евристик і мовної моделі, — показує прев’ю з тим, що розпізналося, і дає перевизначити будь-яке зіставлення руками, якщо вона помилилася.

Найскладнішим виявився не формат, а мова. Одну й ту саму конструкцію оператори називають по-різному: щит, борд, прапорець — це білборд; екран — відеоборд; лайтбокс — сітілайт. Раніше кожна така назва створювала в базі новий тип, і площина просто не знаходилася через фільтр на сайті. Ми попросили в клієнта список їхнього професійного жаргону — і отримали його за одинадцять хвилин.

День, коли 435 площин зникли тихо

Через три тижні після запуску імпорту прийшло повідомлення: «Чого може не загружати сітку, вона загружається, помилок не має, імпортую, потім перевіряю цього підрядника і пусто».

Це найгірший різновид збою. Файл приймається, процес доходить до кінця, звіт каже «оновлено», помилок немає — і саме тому ніхто нічого не помічає. Серед вісімдесяти тисяч площин порожній оператор виявляється лише тоді, коли хтось цілеспрямовано його відкриє.

Причина була в кошику. Площини, видалені раніше, лишалися в базі як приховані. Імпорт шукав збіги за кодом серед усіх записів, включно з видаленими, знаходив їх, чесно позначав як «оновлення» й оновлював — але не повертав із кошика. Технічно все спрацювало. Фактично оператор лишався порожнім.

Масштаб — 435 площин у чотирьох операторів, видалених одним махом трьома днями раніше, плюс кілька тисяч, зачеплених раніше. Виправлення зайняло вечір і звелося до одного рішення: актуальний файл оператора є джерелом правди. Якщо площина є у свіжій сітці, вона має бути на сайті, навіть якщо колись її видалили. Повторний імпорт тепер повертає такі площини з кошика, і на це є тест, щоб та сама причина не повторилася.

Заявки, яких ніхто не залишав

У липні замовниця написала, що замість звичайних звернень пішов потік дивних: «Одного дня з 5 звернень всі не лишали заявок на сайті». Менеджери передзвонювали — люди не розуміли, про що йдеться.

Спокуса тут — пообіцяти технічне рішення. Ми цього не зробили, бо його не було. Валідація на формах уже стояла, а заявки надсилали живі люди з українськими номерами: заходили, вписували текст, натискали кнопку. Захист від ботів проти людей не працює, а фільтр на основі моделі відсіював би стільки ж, скільки й ручне видалення.

Тому відповідь була така: критичного тут немає, це забирає час операторів, і питання походження трафіку — не до розробника, а до тих, хто веде рекламу. Реакція замовниці, чесно кажучи, найкраще описує роль підрядника в такі моменти.

Розв’язку запропонував не код, а маркетолог: прибрати з шапки форму «Замовити дзвінок», додати email і назву компанії в усі решту й зробити всі поля обов’язковими. Заявок стане менше — і саме в цьому сенс.

Ми оцінили роботу в 12–14 годин і зробили її за добу. Це нормальний фінал такої історії: розробник каже, чого зробити не можна, маркетолог пропонує те, що можна, і рішення виявляється не в коді, а в тому, скільки зусиль коштує натиснути кнопку.

26 гігабайтів фотографій

У липні dev-сервер впав через брак місця. Причина була одна: фотографії площин займали 26 ГБ — понад половину диска — і це число зростало з кожним імпортом. На продакшні те саме було питанням часу.

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

Як улаштована співпраця

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

Окремі дрібні поліпшення ми не рахуємо взагалі. Денний seed для порядку площин — приклад саме такого: ідея прийшла від SEO-фахівця, реалізація зайняла небагато, і виставляти за неї рахунок було б дивно. Це не благодійність, а спосіб не перетворювати кожну розмову на торг.

Відгук замовниці

Чого в цьому кейсі немає

Тут немає цифр про трафік, позиції чи конверсію після редизайну. Аналітика й рекламні кабінети — на боці клієнта та його маркетологів, і ми не показуємо чужі дані як свій результат. Технічна частина перевірна: репозиторій, історія комітів, переписка. Все інше з’явиться тут тільки тоді, коли буде чим його підтвердити.

Співпраця триває: задачі приходять щотижня, база оновлюється, наступний великий блок — винесення фотографій площин у хмарне сховище.

Часті питання про цей проєкт

Коротко

• Сайт вів один підрядник сім років, відмовляючись від редизайну з аргументом «дизайн не впливає на продажі»; проєкт передали нам за рекомендацією.
• Першим ділом з’явилася не нова сторінка, а адмінка — без неї компанія не могла керувати власною базою.
• Головною роботою став імпорт: близько 80 000 площин від десятків операторів, кожен зі своїм форматом файлу й своїм жаргоном.
• Ручна підготовка файлу забирала близько 15 хвилин; автоматичне зіставлення колонок і зведення назв конструкцій прибрали цей етап.
• Через три тижні імпорт тихо «загубив» 435 площин у чотирьох операторів — розібрали й виправили того ж дня, покрили тестом.
• Спам у формах вирішили не кодом, а обов’язковими полями: менше заявок, більше змістовних.
• Цифр по трафіку й конверсії в кейсі немає свідомо — аналітика на боці клієнта.