Воронка електронної комерції має більше точок контакту, ніж будь-яка інша вертикаль, з якою я працюю. Клієнт бачить рекламу в Meta, переходить на сторінку товару, залишає кошик, отримує імейл про відновлення через три години, сканує QR-код на пакуванні після доставки та повторно купує через WhatsApp-розсилку після покупки через дев'ять днів. Кожен із цих контактів проходить через URL - і кожен URL має бути атрибутованим, з можливістю перенаправлення та достатньо витривалим, щоб пережити наступне оновлення приватності рекламної платформи.
Це основна стаття для кластера електронної комерції. Вона охоплює структуру інтеграції, яка тримає воронку разом: де знаходиться коротке посилання на кожному етапі, які дані атрибуції воно несе, як серверна передача конверсій закриває цикл із рекламними платформами, і як виглядає операційний інструментарій, коли ви керуєте звичайним магазином на Shopify із двома платними каналами та програмою життєвого циклу.
Я буду конкретно говорити про Shopify, оскільки це платформа, яку я бачу найчастіше, але ці патерни є загальними. WooCommerce, BigCommerce, Centra, Commercetools - точки інтеграції однакові; відрізняється лише форма корисного навантаження вебхука.
П'ять етапів воронки електронної комерції#
Кожен аудит воронки, який я проводжу, має однакову форму. Реалізація відрізняється в деталях, етапи - ні.
Платне залучення. Meta, Google Ads, TikTok, Pinterest. Рекламна поверхня містить креатив; пунктом призначення є коротке посилання, яке фіксує клік і перенаправляє на цільову сторінку або сторінку товару (PDP) зі збереженням параметрів атрибуції.
Залучення через власні канали. Email, SMS, push-повідомлення, повідомлення в додатку, WhatsApp. Скорочувач створює посилання для кожної відправки (транзакційна типізація за кампанією), щоб аналітика збиралася за відправкою, а не за URL.
Конверсія на сайті. Сторінка товару, кошик, оформлення замовлення. Скорочувач не бере участі в обробці запитів тут - клік уже відбувся - але click_id з редиректу має потрапити в запис замовлення, щоб пізніше можна було прив'язати конверсію.
Після покупки. Сторінка підтвердження замовлення, імейл із підтвердженням замовлення, вкладиш у пакуванні, QR-код на коробці. Короткі посилання супроводжують клієнта на етапі після покупки та передають сигнал даних назад у маркетингову площину даних.
Утримання та реактивація. Імейли життєвого циклу, відновлення покинутих кошиків, сповіщення про повернення товару в наявність, кампанії з повернення клієнтів. Скорочувач бачить їх як довгий хвіст програмних створень, часто через інтеграцію з ESP або платформою автоматизації маркетингу.
Кожен етап має дещо різні вимоги до атрибуції. Структура інтеграції, яка обробляє всі п'ять, - це те, про що ця стаття.
Етап 1: платне залучення#
Завдання на цьому етапі подвійне. Коротке посилання має привести користувача до правильного пункту призначення, і воно має зафіксувати достатньо контексту атрибуції, щоб замовлення - зроблене через три години з іншого пристрою після оновлення сторінки та маніпуляцій із промокодом - можна було пов'язати з рекламою.
Структура, яка працює: URL призначення оголошення - це коротке посилання (elido.me/spring-jeans-de або яка б там не була конвенція слагів), коротке посилання перенаправляє на PDP з доданими UTM-параметрами та параметрами click_id, а відповідь редиректу встановлює первинний ідентифікатор, який зберігається під час навігації.
У випадку Elido редирект додає ?elido_click=<click_id> (налаштовується для кожного робочого простору), і PDP або зчитує його з рядка запиту та записує у первинний cookie, або - краще - менеджер тегів торгової платформи підхоплює його через подію dataLayer і зберігає в спеціальних атрибутах замовлення, коли кошик сформовано.
Перевага цієї структури в тому, що click_id є надійним ідентифікатором для решти воронки. Cookie браузера може бути втрачено через ITP. Сесія може закінчитися. Користувач може змінити пристрій. Поки click_id є в записі замовлення, ви можете запустити серверну передачу конверсії в момент оплати замовлення та отримати кредит на атрибуцію, навіть якщо оригінальна сесія браузера мертва.
Щодо операційної механіки - шаблону UTM на рівні робочого простору, перевизначень на рівні кампанії, масового імпорту з Таблиць, верифікації передачі конверсій - посібник із наскрізного відстеження UTM є основним джерелом інформації.
Етап 2: залучення через власні канали#
Власні канали мають більший обсяг, нижчу вартість і їх важче виміряти, ніж платні. Кожна розсилка імейлів на список зі 100 тисяч підписників створює 100 тисяч коротких посилань, якщо контент динамічний; кожне транзакційне сповіщення (відправлено, доставлено, запит на відгук) - це ще одне посилання з власним контекстом атрибуції.
Патерн, який масштабується: кампанія у скорочувачі відповідає відправці в ESP. Кампанія володіє шаблоном UTM (utm_source=email, utm_medium=lifecycle, utm_campaign=cart-recovery-2026-05) та патерном URL призначення. Інтеграція з ESP створює унікальне коротке посилання для кожного одержувача під час відправки з вбудованим click_id і записує click_id назад у профіль одержувача, щоб ланцюжок відкриття/кліку/конверсії можна було спостерігати наскрізь.
Тут важлива кінцева точка масового імпорту. Створення 100 тисяч коротких посилань через стандартну кінцеву точку POST /v1/links призведе до послідовного виконання через ліміти API навіть на рівні Pro. Правильним інструментом є POST /v1/links/bulk із тілом CSV - Elido перевіряє кожен рядок, фіксує зміни атомарно (без наполовину імпортованих розсилок) і повертає список слагів, прив'язаних до ідентифікаторів вхідних рядків, щоб ESP могла зіставити слаг з одержувачем.
Для Klaviyo, Customer.io та Iterable структура інтеграції - це вебхук, який спрацьовує при завершенні відправки: ESP надсилає список одержувачів, скорочувач створює посилання, відповідь надсилається назад в ESP для підстановки контенту в шаблон імейла. Для Shopify Email та програми Shopify Marketing структура схожа, але підстановка відбувається в шаблоні Liquid, а не при завершенні відправки.
Туторіал з масового імпорту через Таблиці охоплює ручну версію; версія на основі API задокументована в довіднику API.
Етап 3: конверсія на сайті#
Скорочувач не бере участі в обробці запитів на сайті. Проте click_id має потрапити в запис замовлення.
Конкретно для Shopify інтеграція проста. PDP підхоплює ?elido_click= з URL, вбудований додаток теми (або код вашої теми, або розширення для оформлення замовлення Shopify Plus) записує його в Shopify.checkout.attributes.elido_click_id, щоб він зберігся в note_attributes замовлення при фіналізації кошика. Під час спрацювання вебхука про оплату замовлення click_id доступний у корисному навантаженні замовлення, і ви передаєте конверсію на серверній стороні.
Для headless-рішень (Hydrogen, Next.js commerce, Centra) еквівалентом є запис click_id у кастомний атрибут кошика через Storefront API в момент створення кошика. Перетворення кошика в замовлення зберігає атрибут, а вебхук замовлення доставляє його до будь-якого бекенду, який виконує передачу конверсії.
Що я бачу не так найчастіше: click_id фіксується в сесійному cookie, але не записується в замовлення. Через три дні маркетингові звіти кажуть, що конверсії на нулі; через тиждень розробник усвідомлює, що атрибут ніколи не передавався через розширення оформлення замовлення. Додайте верифікацію в чек-лист запуску: зробіть тестове замовлення, простежте за вебхуком про оплату замовлення, підтвердьте наявність click_id у корисному навантаженні перед запуском реального трафіку.
Для контексту без кукі / ITP - чому це важливіше у 2026 році, ніж було у 2022-му - дивіться статтю про атрибуцію кліків після Safari ITP та безпосередньо примітки Apple до релізу ITP 2.3.
Етап 4: після покупки#
Замовлення розміщено. Тепер площина даних має зробити дві речі: передати конверсію рекламним платформам на серверній стороні та розпочати шлях клієнта після покупки зі збереженням атрибуції.
Серверна передача конверсій. Саме тут знаходиться більша частина відновленого доходу. Через Safari ITP та поширення блокувальників реклами браузерний піксель пропускає 25-40% конверсій у звичайному магазині Shopify (точне число залежить від складу трафіку; магазини з великою часткою iOS знаходяться на верхній межі). Серверна передача в Meta CAPI, GA4 Measurement Protocol та TikTok Events API компенсує більшу частину цього розриву.
Інтеграція: спрацьовує вебхук оплати замовлення, бекенд зчитує click_id із замовлення, шукає click_id в Elido (або довіряє тому, що вже додано) і надсилає POST-запит із конверсією на кожну підключену платформу. Кінцева точка Elido POST /v1/conversions приймає click_id разом із даними конверсії (value, currency, event_name=Purchase, хешовані ідентифікатори користувачів) і розсилає їх на ті платформи, для яких у робочого простору є облікові дані. Розсилка включає хешування імейла та телефону за алгоритмом SHA-256 - це вимагається Meta CAPI згідно з вимогами Conversions API - а також логіку повторних спроб та дедуплікації, щоб повторна доставка вебхука не призвела до подвійного підрахунку.
Посібник із передачі конверсій проведе вас через налаштування облікових даних; стаття про серверне відстеження конверсій глибше розкриває механіку дедуплікації.
Шлях клієнта після покупки. Імейл із підтвердженням замовлення містить посилання на сторінку статусу замовлення, довідковий центр підтримки, лайфстайл-контент бренду, рекомендації щодо допродажу або аксесуарів. Кожне з них отримує коротке посилання за патерном створення в режимі кампанії з Етапу 2. QR-код на пакуванні є найбільш ефективним: клієнт сканує його після отримання посилки, потрапляє на сторінку подяки та конвертується в програму лояльності або отримує стимул для другої покупки.
Конкретно для QR-коду найкращим вибором є динамічні коди - ви можете оновити пункт призначення після того, як посилка була відправлена. Стаття про динамічні та статичні QR-коди пояснює компроміси.
Етап 5: утримання та реактивація#
Тут обсяг посилань у скорочувачі стає значним. Звичайний магазин Shopify, що використовує Klaviyo або Customer.io, надсилає повідомлення життєвого циклу за десятками тригерів для кожного клієнта. Вітальна серія, покинутий кошик, перегляд товарів, апселл після покупки, поповнення запасів, повернення клієнта, день народження, VIP - кожен з них є кампанією в інструменті автоматизації маркетингу, і кожна кампанія створює посилання під час відправки.
Патерн, який працює: кожна кампанія життєвого циклу в ESP відповідає кампанії в скорочувачі. Кампанія в скорочувачі володіє шаблоном UTM; корисне навантаження для створення посилань з боку ESP змінюється лише залежно від одержувача та продукту. Аналітика збирається за етапом життєвого циклу. Команда маркетингу може бачити: "імейл про відновлення покинутого кошика генерує 4,2% конверсії за ціною €0,14 за клік", а не "ми створили 380 тисяч посилань цього місяця і не знаємо, яка частина з них стосувалася покинутих кошиків".
Інтеграція через вебхуки для додавання також важлива на цьому етапі. Події Klaviyo Email Opened та Email Clicked мають об'єднуватися з подіями Elido click.created на рівні аналітики; для більшості команд це відбувається в їхньому сховищі даних (BigQuery, Snowflake, ClickHouse), де ключем об'єднання є click_id. Посібник з експорту в ClickHouse від Elido охоплює структуру завантаження на стороні сховища.
Брендований домен: невелике покращення з кумулятивним ефектом#
Кожен канал вище виграє від використання брендованого домену. acme.click/spring-jeans-de перевершує bit.ly/3xKj9wZ за показником клікабельності на вимірювану величину - дослідження Прінстона щодо довіри до посилань 2019 року оцінює приріст у діапазоні 12-31% залежно від галузі, а великі вендори електронної комерції, яких я перевіряла, бачать цифри в тому ж діапазоні у своїх власних A/B тестах.
Брендований домен робить три речі одночасно. Він сигналізує про легітимність на платформах, які стають дедалі скептичнішими до скорочених URL (LinkedIn тепер попереджає про bit.ly; спам-фільтри Gmail нараховують штрафні бали за використання загальних скорочувачів у певних типах шаблонів). Він дає вам домен, який ви контролюєте, на випадок, якщо ваші стосунки з постачальником скорочувача зіпсуються. І це дозволяє вам використовувати підстановочні знаки - *.acme.click для окремого піддомену кожного бренду в портфелі - без необхідності створювати запити в підтримку для кожного додавання.
Сторінка функцій кастомних доменів охоплює тарифні плани; операційна інструкція описує налаштування DNS та TLS на вимогу.
Що йде не так у продакшні#
Три типи помилок, які я бачу постійно в магазинах електронної комерції.
Click_id не передається через оформлення замовлення. Уже згадувалося. Завжди тестуйте на реальному замовленні перед запуском.
Передача конверсій без дедуплікації. Спрацьовує вебхук про оплату замовлення, конверсія передається в Meta та GA4. Потім менеджер тегів продавця - який все ще знаходиться на сторінці - активує браузерний піксель конверсії для того ж самого замовлення. І Meta, і GA4 завантажують дані, конверсія підраховується двічі, розподільник бюджету виділяє зайві кошти. Рішення - ідентифікатор дедуплікації: Meta CAPI приймає event_id, GA4 приймає client_id, обидва дедуплікують події браузера та сервера з однаковим ID. Встановіть ID замовлення як event_id, браузерний піксель встановлює те саме значення, обидві платформи проводять дедуплікацію. Документація Meta щодо дедуплікації є основним джерелом.
Невідповідність вікон утримання. Маркетинг хоче вікна атрибуції на 24 місяці для нових покупців. Події кліків за замовчуванням зберігаються 90 днів на більшості аналітичних платформ. Коли хтось вперше запускає когортний аналіз LTV за рік, конверсія за click_id зникає, і звіт не показує кредиту атрибуції. Встановіть термін зберігання відповідно до вікна атрибуції з першого дня - Elido дозволяє налаштувати це для кожного робочого простору; термін зберігання в ClickHouse встановлюється на рівні базової таблиці.
Нотатки щодо закупівлі для покупців у сфері електронної комерції#
Три речі, на які я б звернула особливу увагу для команд із закупівель в електронній комерції.
Резидентство в ЄС. Якщо ваша клієнтська база в основному з ЄС, регіон хостингу вашого скорочувача має значення для обговорення Schrems II. Основна стаття про GDPR для скорочувачів URL охоплює контрактні деталі; сторінка довіри є документом для процесу закупівлі.
Ліміти швидкості API. Обсяг масового створення посилань під час піків (Чорна п'ятниця, свята, вихід спільних колекцій брендів) визначає, чи побачите ви сторінки з помилкою ліміту API у найгірший момент. Переконайтеся, що ліміт на вашому тарифі відповідає вашим піковим значенням, а не середнім. Ліміти швидкості Elido задокументовані для кожної кінцевої точки; кінцева точка масового створення витримує 1,000 запитів на секунду на рівні Pro і не має обмежень на рівні Business.
Інтеграція з Shopify. На момент написання статті додаток Elido для Shopify знаходиться на стадії розгляду. До того часу інтеграція здійснюється через Storefront API плюс простий Cloudflare Worker або функцію Shopify, яка фіксує click_id при переході. Customer.io, Klaviyo та Iterable мають опубліковані інтеграції.
Для порівняння платформ: стаття про функціональні розриви альтернатив Bitly охоплює матрицю функцій; стаття Elido проти Bitly охоплює арифметику ціноутворення.
Читайте кластер#
Це основна стаття кластера індустрій. Споріднені статті: Скорочувачі URL для інфлюенсерів та креаторів (перетин із лайфстайл-комерцією), Скорочувачі URL для ресторанів (використання з акцентом на QR), Скорочувачі URL для SaaS (паралель із B2B). Сторінка рішень для маркетологів - це поверхня, орієнтована на персонажів; посібник із глибоких посилань Shopify - це операційна інструкція для патерна передачі click_id. Для командних робочих процесів навколо кампаній та масового створення сторінка функцій кампаній описує модель даних.