Компанія підбирає для своїх клієнтів вживані автомобілі з Європи. Запити приходять щодня: потрібна така-то модель, не старша за такий-то рік, з пробігом до стількох-то кілометрів, у межах бюджету. Менеджер відкриває двадцять європейських майданчиків, вручну вводить запит у кожен, гортає видачу і копіює те, що підходить, у свою табличку. На один запит іде від сорока хвилин до півтори години.
Задача звучала просто: менеджер вводить запит в одному місці, а через кілька хвилин отримує зведену таблицю з усіх двадцяти сайтів. Нижче – як це влаштовано зсередини, з якими проблемами довелося розібратися і чому інтерфейсом стала звичайна Google Таблиця, а не веб-застосунок.
Чому інтерфейсом стала Google Таблиця
Перше, що спадає на думку в такій задачі, – зробити сайт із формою пошуку. Я від цього відмовився свідомо, і ось чому.
- Нульовий поріг входу. Менеджери й так працюють у таблицях цілий день. Новий інтерфейс означав би навчання, інструкції, опір. Таблицю не треба пояснювати.
- Не потрібна авторизація. Доступ до документа роздає керівник через звичайний доступ Google. Прийшов новий співробітник – додали пошту, пішов – прибрали. Ніякої власної системи користувачів і паролів.
- Історія запитів утворюється сама. Кожен рядок на головному аркуші – це збережений запит із датою, автором і посиланням на результат. Керівник бачить, хто що шукав, без окремих звітів.
- Результат одразу придатний до роботи. Менеджер фільтрує, сортує, ставить свої позначки прямо в тому ж документі. Нічого не треба вивантажувати і кудись переносити.
Таблиця тут – це оболонка. Уся робота відбувається на сервері, а таблиця тільки приймає запит і показує результат.
Як це працює крок за кроком
1. Менеджер вводить запит
На головному аркуші є кілька колонок: марка, модель, рік, пробіг і бюджет. Менеджер заповнює рядок. Скрипт, прив’язаний до таблиці, ловить зміну і надсилає запит на сервер.
2. Сервер розкладає запит на двадцять окремих
Двадцять європейських майданчиків – це двадцять різних сайтів. Кожен зі своєю структурою, своїми назвами категорій і своєю логікою пошуку. Один шукає за параметрами в адресі, другий – через внутрішній API, третій вимагає форму з токеном зі сторінки, четвертий віддає результати частинами при прокручуванні.
Тому для кожного сайту написаний свій адаптер: він знає, як перетворити запит менеджера на коректний пошук саме на цьому майданчику, як пройти пагінацію і де на сторінці лежать потрібні поля. Зверху – загальний диспетчер, який запускає всі адаптери паралельно і збирає відповіді в один список.
3. Приведення до єдиного вигляду
Це найнудніша і найважливіша частина. З кожного сайту приходить своя каша:
- ціна може бути “45 000 EUR”, “45.000,00 €”, “EUR 45000” або “ціна за запитом”;
- рік випуску буває окремим полем, а буває всередині назви;
- пробіг вказують у кілометрах, милях або взагалі не вказують;
- фото іноді лежить прямим посиланням, іноді ховається за скриптом галереї.
Усе це нормалізується: ціна приводиться до числа і валюти, рік – до чотирьох цифр, пробіг – до кілометрів, посилання на фото перевіряється на доступність. Якщо поле дістати не вийшло, воно лишається порожнім, а не заповнюється сміттям. Порожня комірка чесніша за неправильне число.
4. Результат лягає в новий аркуш
Під кожен запит створюється окремий аркуш: фото, назва, посилання на оригінальне оголошення, ціна, рік, пробіг, країна продавця, майданчик-джерело. На головному аркуші, в тому самому рядку, куди менеджер вводив запит, з’являється посилання на цей аркуш.
Менеджер бачить усе на одному екрані, фільтрує за ціною і роком, відкриває потрібне оголошення і зв’язується з продавцем.
Технічні проблеми, з якими довелося розібратися
Ліміти Google Таблиць
Таблиця не безмежна: є стеля за кількістю комірок і аркушів у документі. Щоденні запити, кожен зі своїм аркушем на сотні рядків, – і за кілька місяців документ пухне. Тому старі аркуші архівуються: результати, старші за визначений строк, переносяться в окремий документ, а посилання на головному аркуші лишається робочим.
Швидкість
Послідовний обхід двадцяти сайтів займав би багато хвилин. Запити йдуть паралельно, з обмеженням на кількість одночасних з’єднань до одного домену, щоб не навантажувати джерело. Разом пошук укладається в кілька хвилин.
Сайти постійно змінюються
Це головна витрата в такому проєкті, і про неї варто говорити чесно. Майданчики регулярно змінюють верстку, структуру адрес чи спосіб віддачі даних. Тому передбачений моніторинг: якщо адаптер повертає підозріло мало результатів або нуль там, де раніше стабільно щось було, я отримую сповіщення і йду дивитися, що змінилося.
Саме тому подібні проєкти живуть у форматі щомісячної підтримки, а не разової розробки. Разово зроблений пошуковик по двадцяти сайтах перестане працювати за кілька місяців, і зазвичай у найгірший момент.
Захист від ботів
Частина майданчиків стоїть за захистом, який відсіює автоматичні запити. Це вирішується коректною поведінкою клієнта, розумною частотою звернень і, де потрібно, проксі. Детальніше про підходи я писав на сторінці парсинг сайтів із захистом від ботів.
Що отримав бізнес
Головна зміна навіть не в економії часу, хоча вона очевидна: те, що займало годину, тепер займає кілька хвилин очікування. Важливіше інше.
- Повнота охоплення. Під кінець дня людина втомлюється і перевіряє п’ять сайтів замість двадцяти. Скрипт перевіряє всі двадцять завжди, незалежно від настрою і навантаження.
- Швидкість відповіді клієнту. На ринку вживаних авто виграє той, хто першим запропонував варіант. Різниця між “передзвоню завтра” і “ось три варіанти, дивіться” – це різниця між угодою і втраченим клієнтом.
- Однаковий результат у всієї команди. Досвідчений менеджер і новачок отримують однаково повну вибірку. Знання про те, “де саме шукати”, перестало бути особистим активом окремих людей і стало активом компанії.
- Керованість. Керівник бачить усі запити в одному документі: що шукали, як часто, на що найбільший попит.
Кому підійде така схема
Схема “запит у таблиці – обробка на сервері – результат окремим аркушем” працює скрізь, де кілька людей регулярно шукають одне й те саме на багатьох джерелах:
- закупники, що порівнюють пропозиції постачальників;
- агентства нерухомості, що збирають оголошення по містах і районах;
- відділи продажів, що перевіряють наявність товару в конкурентів;
- компанії, що моніторять тендерні та аукціонні майданчики.
Замість таблиці інтерфейсом може бути група в Telegram: людина пише запит повідомленням, бот відповідає посиланням на готовий файл. Такий варіант я теж роблю і часто пропоную, коли користувачів мало, а запити рідкі.
Скільки це коштує і скільки займає
Вартість залежить від кількості джерел і від того, наскільки складно з кожного дістати дані. Двадцять сайтів, частина з яких під захистом, – це вже повноцінний проєкт.
Далі йде щомісячна підтримка: сервер, проксі, моніторинг і, головне, адаптація парсерів, коли джерела змінюються. Без підтримки такий проєкт не має сенсу – він просто тихо помре за кілька місяців.
Якщо у вас схожа задача, опишіть її – за п’ятнадцять-двадцять хвилин розмови я скажу, чи вона вирішується, скільки джерел реально потягнути і в що це обійдеться. Консультація ні до чого не зобов’язує.