Urlik — швидкий сервіс коротких посилань з аналітикою та API

01Огляд проєкту

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

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

Ми спроєктували й зібрали продукт цілком: від архітектури швидких редіректів і схеми зберігання статистики до дашборда, генерації QR-кодів і документації до API. Нижче розбираємо, яке завдання розв'язує Urlik, як він улаштований усередині та які інженерні рішення дозволили поєднати швидкість редіректа з багатою аналітикою, не жертвуючи ні тим, ні іншим.

Важливо підкреслити контекст. Urlik задумувався не як разовий віджет «скороти посилання», а як самостійний інструмент із безкоштовним тарифом і платними можливостями. Безкоштовний план знімає поріг входу й приводить аудиторію, а кастомні аліаси, розширена аналітика та API дають привід залишитися й підключити сервіс до робочих процесів. Така модель визначала пріоритети на всіх етапах: швидкість і надійність базового редіректа важливіші за будь-які прикраси, бо саме від них залежить довіра до продукту.

02Контекст і завдання

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

• Швидкість редіректа — це продукт. Коротке посилання стоїть між користувачем і потрібною йому сторінкою. Кожна зайва сотня мілісекунд на редіректі — це роздратування й відтік. Редірект зобов'язаний бути практично миттєвим за будь-якого навантаження.
• Аптайм критичний. Якщо сервіс коротких посилань падає, перестають працювати всі вже роздані посилання — у листах, постах, QR-кодах на друкованих матеріалах. Це не та система, яку можна «іноді» впустити.
• Аналітика без втрати швидкості. Кожен перехід треба порахувати й збагатити даними (гео, пристрій, джерело), але так, щоб збір статистики не гальмував сам редірект.
• Унікальність і читабельність кодів. Короткі коди мають не перетинатися, бути достатньо короткими й при цьому не складатися у випадкові непристойні чи оманливі комбінації.
• Кастомні аліаси. Бізнесу потрібен не безликий набір символів, а осмислений «хвіст» посилання під бренд чи кампанію — зі своєю логікою перевірки зайнятості й валідності.
• Захист від зловживань. Будь-який публічний скорочувач одразу стає мішенню для спаму й фішингу, тому потрібні обмеження, валідація й механіка протидії.

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

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

03Цілі проєкту

Із завдання виросли конкретні продуктові й інженерні цілі, які ми тримали в голові на кожному етапі:

• Миттєвий редірект. Базовий сценарій — перехід за коротким посиланням — має бути швидким за будь-яких умов. Це головна метрика якості продукту.
• Високий аптайм. Сервіс, від якого залежать усі роздані посилання, зобов'язаний працювати стабільно. Простій неприпустимий як клас.
• Просте скорочення в один крок. Вставив довгий URL — отримав коротке посилання, QR-код і посилання на статистику. Без реєстрації для базового сценарію, без зайвих екранів.
• Кастомні аліаси. Можливість задати свій «хвіст» посилання під бренд чи кампанію з перевіркою зайнятості й коректності.
• Детальна аналітика. За кожним посиланням — кількість кліків, гео переходів, пристрої й браузери, джерела й реферери, динаміка в часі.
• QR-код на кожне посилання. Коротке посилання і QR — це дві форми того самого, особливо для офлайн-матеріалів; QR має генеруватися автоматично.
• Публічний REST API. Щоб сервіс можна було вбудувати в чужі продукти й автоматизувати: створювати посилання й забирати статистику програмно.
• Безкоштовний тариф. Низький поріг входу як двигун зростання: базові можливості доступні безкоштовно, просунуті — на платних планах.

Ці цілі свідомо розставлені за пріоритетом. Швидкість і аптайм ідуть першими, бо вони — фундамент довіри. Усе інше — аналітика, аліаси, API — нашаровується зверху й не має сенсу, якщо базовий редірект працює погано.

04Що ми зробили

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

Поверх цього ядра — особистий кабінет, де користувач керує своїми посиланнями, дивиться статистику й забирає QR-коди, і документація до API, за якою розробник підключається без дзвінків. Усе це зібрано в єдиний продукт зі швидким редіректом в основі.

05Архітектура рішення

Головна архітектурна ідея Urlik — розділити два дуже різні за характером навантаження сценарії: дешевий і надчастий редірект і важчу роботу дашборда й аналітики. Ці завдання мають різний профіль звернень і різні вимоги до швидкості, тому змішувати їх в одному «товстому» обробнику було б помилкою.

Логічно система ділиться на чотири блоки:

• Редірект-шар — максимально легкий шлях «короткий код → цільовий URL → перенаправлення». Тут усе підпорядковане швидкості: мінімум роботи на запит, агресивне кешування відповідностей «код → посилання», швидка відповідь браузеру.
• Шар створення посилань — генерація унікальних кодів, перевірка й резервування кастомних аліасів, валідація вихідного URL, генерація QR-коду.
• Шар аналітики — приймання й обробка подій переходу: розбір гео, пристрою, браузера й джерела, агрегація за часом для графіків динаміки.
• API і кабінет — програмний інтерфейс і вебінтерфейс поверх тих самих даних: створення посилань, керування ними й видача статистики.

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

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

06Як улаштований життєвий цикл посилання

З погляду користувача весь потік укладається в кілька кроків, і більша частина складності прихована від нього.

• 1. Створення. Користувач вставляє довгий URL (або передає його через API). Сервіс валідує адресу, генерує унікальний короткий код або приймає кастомний аліас, зберігає відповідність і одразу віддає коротке посилання й QR-код.
• 2. Роздавання. Коротке посилання (і за потреби QR) користувач розміщує будь-де: у пості, листі, рекламі, на друкованих матеріалах.
• 3. Перехід. Хтось відкриває коротке посилання. Редірект-шар за кодом знаходить цільовий URL і миттєво перенаправляє відвідувача.
• 4. Облік. Паралельно фіксується подія переходу: час, гео, тип пристрою й браузер, джерело/реферер. Це відбувається так, щоб не затримувати сам редірект.
• 5. Аналіз. У дашборді власник посилання бачить зведену й детальну статистику: скільки було кліків, звідки, з яких пристроїв і як змінювалася динаміка в часі.

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

07Скорочення посилань і кастомні аліаси

Серце сервісу — перетворення довгого URL на короткий код. На перший погляд тривіальна операція, але саме в ній сховано кілька важливих інженерних рішень.

Генерація коротких кодів

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

Кастомні аліаси

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

Валідація вихідного URL

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

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

08QR-коди для кожного посилання

Коротке посилання і QR-код — це дві форми тієї самої адреси. Посилання зручно вставити в текст, а QR — навести камерою телефона з друкованого носія: пакування, плаката, візитки, меню, листівки. Тому в Urlik QR-код генерується для кожного короткого посилання автоматично, без окремих дій з боку користувача.

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

09Аналітика переходів

Саме аналітика перетворює Urlik із простого скорочувача на інструмент для маркетингу. За кожним посиланням сервіс показує не просто лічильник кліків, а розгорнуту картину того, хто, звідки і як по ньому переходить.

Що рахується

• Кількість кліків. Скільки всього переходів за посиланням — базова, але найчастіша метрика.
• Географія. З яких країн і регіонів приходять переходи — важливо для гео-таргетингу кампаній.
• Пристрої й браузери. Десктоп чи мобільний, який браузер — розуміння аудиторії та якості посадкової під різні пристрої.
• Джерела й реферери. Звідки прийшов перехід — з якої соцмережі, листа, месенджера чи сайту, якщо джерело визначається.
• Динаміка в часі. Як розподілялися кліки за днями й годинами — видно сплески після публікацій і згасання інтересу.

Навіщо це бізнесу

Зв'язка «коротке посилання + аналітика» робить будь-який канал вимірюваним. Запустили розсилку — бачите, скільки людей реально перейшли й з яких пристроїв. Роздали різні посилання за різними каналами — можете порівняти ефективність каналів між собою. Поставили QR на плакат — розумієте віддачу офлайн-носія. По суті, кожне коротке посилання стає міні-аналітичною точкою, яку легко вбудувати в маркетинговий облік.

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

10Дашборд і керування посиланнями

Щоб продукт був самостійним, мало швидкого редіректа й API — потрібен інтерфейс, у якому користувач керує своїми посиланнями й бачить результат. Дашборд Urlik — це «пульт» над усіма посиланнями акаунта.

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

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

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

11Публічний REST API

Urlik задумувався не лише як сайт, на який заходять руками, а як інструмент, який можна вбудувати в чужі продукти й процеси. Для цього є публічний REST API, через який скорочення посилань і отримання статистики автоматизується.

Через API можна програмно створювати короткі посилання (зокрема з кастомними аліасами), отримувати їхні реквізити й QR, а також забирати статистику переходів. Це відкриває масу сценаріїв автоматизації:

• Масове створення посилань. Коли треба скоротити не одне посилання, а сотні — під товари, статті, кампанії — це робиться одним скриптом, а не руками.
• Вбудовування у свій продукт. Сервіс може видавати короткі посилання всередині власного інтерфейсу, використовуючи Urlik як рушій під капотом.
• Зведення статистики. Аналітику переходів можна автоматично забирати у свої дашборди й звіти, не заходячи в кабінет вручну.
• Інтеграція з автоматизацією. Зв'язки з CRM, розсильниками й no-code платформами, де посилання створюються й обліковуються автоматично за тригерами.

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

12Швидкість і надійність

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

Швидкий редірект

Шлях «короткий код → цільовий URL» зроблено максимально легким. На запит робиться мінімум роботи, а найгарячіші дані — відповідності кодів і посилань — доступні через швидкий кеш. Мета проста: відвідувач не має відчувати, що між кліком і цільовою сторінкою взагалі щось стоїть.

Облік, що не гальмує

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

Стійкість

Оскільки від сервісу залежать усі роздані посилання, ми закладали запас міцності: редірект-шар улаштований просто й передбачувано, а важчі частини (дашборд, аналітика, API) відокремлені так, щоб їхнє навантаження не впливало на доступність редіректа. Що простіший та ізольованіший гарячий шлях, то спокійніше тримати високий аптайм.

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

13Захист від зловживань

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

Тому захист від зловживань закладався із самого початку. Сервіс валідує вихідні URL, обмежує аномальну активність і не перетворюється на відкритий інструмент для розсилання шкідливих посилань. Мета — щоб короткий домен Urlik залишався чистим і не потрапляв у чорні списки через дії зловмисників.

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

14Технологічний стек

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

• Бекенд — PHP: редірект-шар, створення посилань, генерація кодів і аліасів, API і логіка кабінету.
• Редірект і кеш — гарячі відповідності «код → посилання» обслуговуються через швидкий доступ, щоб перенаправлення було практично миттєвим.
• Аналітичний шар — приймання подій переходу, розбір гео, пристрою, браузера й джерела, агрегація за часом для графіків динаміки.
• QR-генерація — автоматичне створення QR-коду для кожного короткого посилання.
• API — публічний REST-інтерфейс для інтеграцій і автоматизації з передбачуваними відповідями й документацією.

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

15Дизайн і UX

Скорочувач посилань продає простоту, тому інтерфейс Urlik ми робили лаконічним і швидким. Головний екран підпорядкований базовому сценарію: велике поле для довгого посилання, кнопка — і одразу результат із коротким посиланням і QR-кодом. Жодних обов'язкових реєстрацій і зайвих кроків між «вставив» і «отримав».

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

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

16Як ми працювали

Проєкт вели послідовними етапами з демонстрацією результату на кожному кроці:

• Дослідження. Розібрали сценарії використання скорочувачів, болючі точки (швидкість, аптайм, аналітика, абʼюз) і сформулювали пріоритети — гарячий шлях передусім.
• Архітектура. Спроєктували розділення редірект-шару й аналітики, схему генерації кодів і аліасів, модель зберігання статистики й формат API.
• Розробка ядра. Зібрали скорочення посилань, швидкий редірект, генерацію QR, приймання й агрегацію подій переходу.
• Кабінет і аналітика. Зробили дашборд зі списком посилань і детальною статистикою за гео, пристроями, джерелами й динамікою.
• API і документація. Відкрили публічний REST API і описали його так, щоб інтеграція йшла без дзвінків.
• Запуск. Розгорнули сервіс із безкоштовним тарифом і платними можливостями, заклавши захист від зловживань.

На кожному етапі ми поверталися до головного питання — чи не страждає швидкість базового редіректа. Це тримало проєкт у фокусі й не давало перетворити легкий інструмент на перевантажений комбайн.

17Результат

Вийшов не «ще один скорочувач», а легкий і швидкий SaaS-інструмент, у якому базовий сценарій миттєвий, а за ним стоїть повноцінна аналітика та API для бізнесу.

• Базовий сценарій працює в один крок і відчувається миттєвим — редірект не змушує себе чекати.
• Кожне посилання несе QR-код і детальну аналітику переходів: гео, пристрої, джерела, динаміка.
• Кастомні аліаси дають бізнесу брендовані короткі посилання під кампанії.
• Публічний REST API перетворює сервіс на інфраструктурний інструмент для інтеграцій і автоматизації.
• Безкоштовний тариф знижує поріг входу, а платні можливості дають привід залишитися.

18Висновки

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

Головний урок проєкту — дисципліна пріоритетів. Коли фундаментом слугує швидкість і надійність базового сценарію, усе інше — аналітика, QR, API — нашаровується органічно й не ламає головного. Ми свідомо тримали гарячий шлях легким і не дозволяли новим можливостям його сповільнювати.

Для нас це був проєкт на стику продуктивності, аналітики й продуктового мислення — той тип завдань, де простий на вигляд сервіс вимагає охайної архітектури під капотом. Якщо вам потрібен швидкий SaaS-інструмент, сервіс з аналітикою й публічним API або продукт, у якому швидкість і надійність критичні, — ми вміємо доводити таке до запуску.