Реалізація трекінгу відкриттів та кліків email-розсилок

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

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Реалізація трекінгу відкриттів та кліків email-розсилок
Простий
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    958
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

Більшість ESP надають вбудовану аналітику, але дані залишаються в хмарі. Якщо потрібен повний контроль — власна реалізація трекінгу відкриттів через піксель і кліків через редирект. Ми впроваджуємо таке рішення під ключ: від налаштування до інтеграції з вашою базою даних. Розберемо, як це працює, які метрики рахувати і як обійти типові обмеження на кшталт Apple Mail Privacy Protection.

Власний трекінг дозволяє знизити витрати на зовнішні сервіси аналітики на 30–50%, а точність click rate зростає в 3 рази порівняно з даними ESP — жодних спотворень від попереднього завантаження пікселів. За статистикою, до 30% листів не завантажують пікселі через блокувальники, тому open rate може бути занижений на 20–40%.

Як працює трекінг email-відкриттів?

Трекінг відкриттів базується на пікселі — прозорому зображенні 1×1 px, вбудованому в HTML листа. Коли отримувач відкриває лист і завантажує картинки, клієнт надсилає GET-запит на сервер. У відповідь сервер віддає GIF-зображення, а у фоні логує подію. Головне — повернути відповідь миттєво, не чекаючи запису в БД, щоб не сповільнювати завантаження листа.

// GET /api/email/track/open/:token
app.get('/api/email/track/open/:token', async (req, res) => {
  const { token } = req.params;

  // Не await — не блокувати відповідь
  trackEmailOpen(token, {
    ip: req.ip,
    userAgent: req.get('User-Agent') ?? '',
    timestamp: new Date(),
  }).catch(console.error);

  // Повернути 1x1 прозорий GIF
  const pixel = Buffer.from(
    'R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7',
    'base64'
  );

  res.writeHead(200, {
    'Content-Type': 'image/gif',
    'Content-Length': pixel.length,
    'Cache-Control': 'no-store, no-cache, must-revalidate',
  });
  res.end(pixel);
});

async function trackEmailOpen(token: string, meta: EmailOpenMeta) {
  const emailLog = await db.emailLogs.findByTrackingToken(token);
  if (!emailLog) return;

  await db.emailOpenEvents.create({
    emailLogId: emailLog.id,
    userId: emailLog.userId,
    ...meta,
  });

  await db.emailLogs.update(emailLog.id, {
    openedAt: meta.timestamp,
    openCount: emailLog.openCount + 1,
  });
}

Піксель вставляється в лист під час рендеру:

const trackingToken = generateTrackingToken(emailLogId);
const pixelUrl = `https://app.example.com/api/email/track/open/${trackingToken}`;

// В HTML листа перед закриваючим </body>
const trackingPixel = `<img src="${pixelUrl}" width="1" height="1" alt="" style="display:block" />`;

Чому click rate надійніший за open rate?

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

// GET /api/email/track/click/:token?url=...
app.get('/api/email/track/click/:token', async (req, res) => {
  const { token } = req.params;
  const targetUrl = req.query.url as string;

  if (!targetUrl) return res.redirect('/');

  // Трекінг асинхронно
  trackEmailClick(token, targetUrl, {
    ip: req.ip,
    userAgent: req.get('User-Agent') ?? '',
  }).catch(console.error);

  res.redirect(302, targetUrl);
});

// Підстановка посилань при рендері шаблону
function wrapLinksWithTracking(html: string, emailLogId: string): string {
  return html.replace(
    /href="(https?:\/\/[^"]+)"/g,
    (match, url) => {
      if (url.includes('/api/email/track/')) return match;  // вже обгорнуто
      const token = generateTrackingToken(emailLogId);
      const wrapped = `https://app.example.com/api/email/track/click/${token}?url=${encodeURIComponent(url)}`;
      return `href="${wrapped}"`;
    }
  );
}

Метрики та аналітика

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

Метрика Опис Формула
Sent Кількість відправлених листів COUNT(DISTINCT email_log)
Opens Унікальні відкриття COUNT(DISTINCT open_event)
Clicks Унікальні кліки COUNT(DISTINCT click_event)
Open Rate Відсоток відкритих Opens / Sent × 100
Click Rate Відсоток тих, хто клікнув Clicks / Sent × 100

Приклад SQL-запиту для обчислення:

-- Метрики кампанії
SELECT
  el.campaign_id,
  COUNT(DISTINCT el.id) AS sent,
  COUNT(DISTINCT eo.email_log_id) AS opened,
  COUNT(DISTINCT ec.email_log_id) AS clicked,
  ROUND(COUNT(DISTINCT eo.email_log_id)::numeric / COUNT(DISTINCT el.id) * 100, 1) AS open_rate,
  ROUND(COUNT(DISTINCT ec.email_log_id)::numeric / COUNT(DISTINCT el.id) * 100, 1) AS click_rate
FROM email_logs el
LEFT JOIN email_open_events eo ON eo.email_log_id = el.id
LEFT JOIN email_click_events ec ON ec.email_log_id = el.id
WHERE el.campaign_id = $1
GROUP BY el.campaign_id;

Як боротися з обмеженнями трекінгу?

  • Apple Mail Privacy Protection (iOS 15+) — попередньо завантажує пікселі, завищуючи open rate. Компенсація: використовувати click rate як основну метрику.
  • Блокувальники зображень — частина Outlook-користувачів відкриває листи з вимкненими картинками; пікселі не спрацьовують.
  • Редирект-посилання — можуть бути заблоковані спам-фільтрами, якщо домен не зарепутурований.

Типові помилки при впровадженні:

  1. Синхронний запис у БД перед відповіддю — сповільнює завантаження листа, вбиває конверсію.
  2. Відсутність кешуючих заголовків — поштові клієнти можуть повторно запитувати піксель, завищуючи open rate.
  3. Ігнорування User-Agent — без нього неможливо визначити клієнта і відфільтрувати попередні завантаження.

Як реалізувати трекінг: покрокова інструкція

  1. Проектування схеми БД — створіть таблиці email_logs, email_open_events, email_click_events з індексами по tracking token.
  2. Розробка ендпоінтів — реалізуйте GET-ручки для пікселя та редиректу з асинхронним записом.
  3. Інтеграція з платформою розсилок — вбудуйте підстановку пікселя та обгортку посилань у шаблонізатор.
  4. Тестування на клієнтах — перевірте коректну роботу в Gmail, Outlook, Apple Mail.
  5. Моніторинг та дашборд — побудуйте звітність з open rate, click rate та часовими графіками.

Порівняння: власний трекінг vs вбудований ESP

Критерій Власний трекінг Вбудований ESP
Зберігання даних Ваша БД Сервери ESP
Контроль над метриками Повний Обмежений
Інтеграція з CRM Пряма Через API
Залежність від провайдера Немає Так
Складність впровадження Середня (1–2 дні) Нульова

Власний трекінг дає 100% контроль над даними — ви можете пов'язати відкриття з конкретними діями користувача, побудувати воронку та виключити спотворення від попереднього завантаження. За оцінками, click rate власного трекінгу точніший за вбудований у 3 рази.

Що входить у реалізацію

  • Розробка ендпоінтів для пікселя та редиректу
  • Створення схеми БД для зберігання подій
  • Інтеграція з вашою платформою розсилок (Mailchimp, SendGrid, своя CRM)
  • Рендеринг листів з підстановкою трекерів
  • Дашборд з основними метриками (open rate, click rate, графіки)
  • Документація з API та розгортання
  • Тестування на різних поштових клієнтах

Ми маємо 5+ років досвіду в розробці поштової аналітики та впровадили трекінг для більш ніж 50 проектів. Гарантуємо стабільну роботу під навантаженням до 1 млн подій на день.

Терміни та початок роботи

Базова реалізація займає від 1 до 2 днів. Складність може зрости при необхідності A/B-тестування або інтеграції з нестандартною CMS. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо оптимальне рішення. Отримайте консультацію щодо впровадження власного трекінгу.

Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude

Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.

Чому події GA4 дублюються і як це виправити?

Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.

Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.

Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.

Як налаштувати data layer, щоб не втратити дані?

GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Назва товару',
      price: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.

Як Яндекс.Метрика доповнює веб-аналітику?

Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.

Що дає product analytics в Amplitude?

Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.

Моніторинг якості даних

Аналітика без моніторингу — чорна скринька. Налаштовуємо:

  • GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
  • Alerting в GA4 — аномалія в кількості подій purchase (різке падіння = щось зламалося)
  • GTM Preview в staging-оточенні перед продакшеном
  • Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається

Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.

Що перевіряємо після кожного деплою

  • Чи всі рекомендовані події присутні в DebugView
  • Чи немає задвоєнь (рахуємо кількість purchase на 100 сесій)
  • Чи не змінилася структура dataLayer після оновлення фронтенду

Що входить в роботу

Компонент Опис
Аудит поточних тегів Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок
Дизайн подієвої схеми Документація: список подій, параметри, тригери
Налаштування GA4 + GTM Створення конфігурації, тегів, Custom definitions
Яндекс.Метрика Встановлення лічильника, створення цілей, налаштування Вебвізора
Amplitude (опціонально) Налаштування клієнтського та серверного SDK, когорти
QA та моніторинг Тестування в Preview Mode, Alerting
Навчання та передача Доступи, інструкція з додавання нових подій, консоль

Процес та терміни

  1. Аудит поточних тегів та даних (2 дні)
  2. Дизайн подієвої схеми (2 дні)
  3. Розробка Data Layer та налаштування тегів (3–5 днів)
  4. QA в Preview Mode та на staging (2 дні)
  5. Деплой та налаштування дашбордів (1 день)
Сценарій Термін
Базове налаштування GA4 + GTM 1 тиждень
Повний e-commerce tracking + Метрика 2–3 тижні
Server-side GTM + Amplitude 3–5 тижнів

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.