Розробка Sankey-діаграм для візуалізації воронки та потоків

При аналізі воронки продажів на сайті електронної комерції з 50 000 щомісячних сесій ми виявили, що 40% трафіку йде на сторінку каталогу і не переходить далі. Стандартні звіти показували лише конверсію 2,5% на цьому етапі, але не пояснювали причин. Sankey-діаграма допомогла виявити, що користувачі з платної реклами часто переходять прямо на картку товару, минаючи каталог, і конвертуються в 3 рази частіше, ніж з органіки. Після перерозподілу бюджету конверсія зросла на 20%. Це інструмент, який візуалізує кожен перехід між сторінками, каналами або етапами. Без такої візуалізації ви не побачите, де конкретно втрачаєте трафік.

Чому стандартні воронки не показують повної картини?

Стандартні звіти по воронці показують конверсію на кожному кроці, але не показують, звідки приходять найцінніші користувачі і куди вони йдуть. Sankey-діаграма вирішує цю проблему, виводячи всі потоки між вузлами. Наприклад, ви можете побачити, що користувачі з платної реклами часто переходять прямо на картку товару, минаючи каталог, і здійснюють покупки в 3 рази частіше, ніж з органіки. Це дозволяє перерозподілити бюджет і підвищити ROI.

Як Sankey-діаграма покращує аналітику?

Санкей дає відповіді на питання, які не видно в таблицях: звідки приходять найконверсійніші користувачі, який шлях приводить до максимального LTV, де втрачається найбільше трафіку. Ми використовуємо drill-down — клік по вузлу розкриває внутрішню структуру, що дозволяє копати вглиб без зупинки. У товарній аналітиці Sankey покаже, які комбінації каналів (organic → product → cart) ведуть до покупки, а які — до відмови. Для циклічних даних (коли користувачі ходять по колу) застосовуємо d3-sankey-circular.

Що дає drill-down?

Drill-down дозволяє деталізувати вибраний вузол, розкриваючи його внутрішню структуру. Наприклад, клікнувши на вузол «Кошик», можна побачити, з яких джерел прийшли користувачі та які дії вони виконали далі. Це особливо корисно для глибокого аналізу воронок з багатьма етапами.

Порівняння стандартної воронки та Sankey-діаграми

Технічна реалізація Sankey на React

Ми використовуємо сучасний стек: React 18, TypeScript, d3-sankey. Це забезпечує плавний рендеринг навіть при 10 000+ зв'язках – за даними офіційної документації d3-sankey.

Встановлення та залежності

npm install d3-sankey d3
npm install --save-dev @types/d3-sankey

Структура даних

Дані для Sankey складаються з вузлів (nodes) та зв'язків (links). Кожен зв'язок містить source, target і value. Приклад для воронки e-commerce:

interface SankeyNode {
  id: string;
  label: string;
  color?: string;
}

interface SankeyLink {
  source: string;  // id вузла-джерела
  target: string;  // id вузла-цілі
  value: number;   // обсяг потоку
}

interface SankeyData {
  nodes: SankeyNode[];
  links: SankeyLink[];
}

// Приклад: воронка e-commerce
const data: SankeyData = {
  nodes: [
    { id: 'organic', label: 'Органіка' },
    { id: 'paid', label: 'Платна реклама' },
    { id: 'direct', label: 'Прямі' },
    { id: 'catalog', label: 'Каталог' },
    { id: 'product', label: 'Картка товару' },
    { id: 'cart', label: 'Кошик' },
    { id: 'checkout', label: 'Оформлення' },
    { id: 'purchase', label: 'Покупка' },
    { id: 'exit', label: 'Вихід' },
  ],
  links: [
    { source: 'organic', target: 'catalog', value: 4200 },
    { source: 'organic', target: 'product', value: 1800 },
    { source: 'paid', target: 'catalog', value: 2100 },
    { source: 'paid', target: 'product', value: 3400 },
    { source: 'direct', target: 'catalog', value: 900 },
    { source: 'catalog', target: 'product', value: 5600 },
    { source: 'catalog', target: 'exit', value: 3100 },
    { source: 'product', target: 'cart', value: 2900 },
    { source: 'product', target: 'exit', value: 4800 },
    { source: 'cart', target: 'checkout', value: 1600 },
    { source: 'cart', target: 'exit', value: 1300 },
    { source: 'checkout', target: 'purchase', value: 1100 },
    { source: 'checkout', target: 'exit', value: 500 },
  ],
};

Компонент з tooltip та інтерактивом

Наш компонент на React рендерить SVG з використанням d3. У ньому реалізовано:

• Плавні шляхи із заокругленнями
• Tooltip при наведенні на вузол або зв'язок
• Колірне кодування вузлів (шкала Tableau10)
• Адаптивна ширина та висота

import { useEffect, useRef } from 'react';
import * as d3 from 'd3';
import { sankey, sankeyLinkHorizontal, sankeyLeft } from 'd3-sankey';

export function SankeyDiagram({ data, width = 800, height = 500 }: { data: SankeyData; width?: number; height?: number }) {
  const svgRef = useRef<SVGSVGElement>(null);
  const margin = { top: 20, right: 20, bottom: 20, left: 20 };

  useEffect(() => {
    if (!svgRef.current) return;

    const svg = d3.select(svgRef.current);
    svg.selectAll('*').remove();

    const iw = width - margin.left - margin.right;
    const ih = height - margin.top - margin.bottom;

    // Підготовка даних для d3-sankey
    const nodeMap = new Map(data.nodes.map((n, i) => [n.id, { ...n, index: i }]));

    const sankeyData = {
      nodes: data.nodes.map(n => ({ ...n })),
      links: data.links.map(l => ({
        source: data.nodes.findIndex(n => n.id === l.source),
        target: data.nodes.findIndex(n => n.id === l.target),
        value: l.value,
      })),
    };

    const sankeyLayout = sankey()
      .nodeWidth(20)
      .nodePadding(12)
      .nodeAlign(sankeyLeft)
      .extent([[0, 0], [iw, ih]]);

    const { nodes, links } = sankeyLayout(sankeyData as any);

    const colorScale = d3.scaleOrdinal(d3.schemeTableau10);

    const g = svg.append('g').attr('transform', `translate(${margin.left},${margin.top})`);

    // Tooltip
    const tooltip = d3.select('body').append('div')
      .style('position', 'absolute')
      .style('display', 'none')
      .style('background', 'rgba(0,0,0,0.8)')
      .style('color', '#fff')
      .style('padding', '8px 12px')
      .style('border-radius', '4px')
      .style('font-size', '13px')
      .style('pointer-events', 'none');

    // Links
    g.append('g')
      .selectAll('.link')
      .data(links)
      .join('path')
      .attr('class', 'link')
      .attr('d', sankeyLinkHorizontal())
      .attr('fill', 'none')
      .attr('stroke', (d: any) => colorScale(String(d.source.index)))
      .attr('stroke-width', (d: any) => Math.max(1, d.width))
      .attr('stroke-opacity', 0.4)
      .on('mouseover', (event, d: any) => {
        d3.select(event.currentTarget).attr('stroke-opacity', 0.7);
        tooltip
          .style('display', 'block')
          .style('left', `${event.pageX + 12}px`)
          .style('top', `${event.pageY - 28}px`)
          .html(`<strong>${d.source.label} → ${d.target.label}</strong><br/>${d3.format(',.0f')(d.value)} користувачів`);
      })
      .on('mouseout', (event) => {
        d3.select(event.currentTarget).attr('stroke-opacity', 0.4);
        tooltip.style('display', 'none');
      });

    // Nodes
    const nodeG = g.append('g')
      .selectAll('.node')
      .data(nodes)
      .join('g')
      .attr('class', 'node');

    nodeG.append('rect')
      .attr('x', (d: any) => d.x0)
      .attr('y', (d: any) => d.y0)
      .attr('width', (d: any) => d.x1 - d.x0)
      .attr('height', (d: any) => Math.max(1, d.y1 - d.y0))
      .attr('fill', (d: any) => colorScale(String(d.index)))
      .attr('rx', 3)
      .on('mouseover', (event, d: any) => {
        tooltip
          .style('display', 'block')
          .style('left', `${event.pageX + 12}px`)
          .style('top', `${event.pageY - 28}px`)
          .html(`<strong>${d.label}</strong><br/>Обсяг: ${d3.format(',.0f')(d.value)}`);
      })
      .on('mouseout', () => tooltip.style('display', 'none'));

    // Labels
    nodeG.append('text')
      .attr('x', (d: any) => d.x0 < iw / 2 ? d.x1 + 6 : d.x0 - 6)
      .attr('y', (d: any) => (d.y0 + d.y1) / 2)
      .attr('dy', '0.35em')
      .attr('text-anchor', (d: any) => d.x0 < iw / 2 ? 'start' : 'end')
      .attr('font-size', 12)
      .attr('fill', '#374151')
      .text((d: any) => d.label);

    return () => { tooltip.remove(); };
  }, [data, width, height]);

  return <svg ref={svgRef} width={width} height={height} />;
}

Підготовка даних: SQL-агрегація

Дані для Sankey зазвичай агрегуються з подієвого потоку. Приклад SQL-запиту для воронки сайту (послідовні переходи між сторінками в рамках сесії):

WITH ranked_events AS (
  SELECT session_id, page_type,
         LAG(page_type) OVER (PARTITION BY session_id ORDER BY created_at) AS prev_page_type,
         ROW_NUMBER() OVER (PARTITION BY session_id ORDER BY created_at) AS step
  FROM page_views WHERE created_at > NOW() - INTERVAL '30 days'
)
SELECT COALESCE(prev_page_type, 'entry') AS source,
       page_type AS target,
       COUNT(*) AS value
FROM ranked_events
WHERE prev_page_type IS NOT NULL OR step = 1
GROUP BY 1, 2
HAVING COUNT(*) > 50
ORDER BY value DESC;

Цей запит дає таблицю переходів з кількістю користувачів. Для великих обсягів даних ми використовуємо попередню агрегацію за допомогою Materialized View або тригерів.

Налаштування розкладки: який алгоритм обрати?

d3-sankey підтримує кілька алгоритмів вирівнювання вузлів. Вибір впливає на читаємість діаграми.

Для циклічних даних використовуємо d3-sankey-circular або попередньо розриваємо цикли.

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

• Аналітика: вивчення структури даних, визначення ключових метрик та точок інтеграції.
• Проектування: розробка макету, вибір алгоритму розкладки, прототипування інтеракцій.
• Реалізація: кодування компонента на React/TypeScript, налаштування бекенду для агрегації даних.
• Документація: опис API компонента, інструкція з експлуатації та кастомізації.
• Тестування: перевірка на реальних даних, навантажувальне тестування (до 100 000 зв'язків), оптимізація.
• Деплой: інтеграція з вашим інтерфейсом, налаштування автоматичної збірки та розгортання.
• Навчання: вебінар для вашої команди з використання та доопрацювання діаграми.
• Підтримка: 30 днів безкоштовних консультацій та виправлення помилок після впровадження.

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

Наша команда реалізує Sankey-діаграму під ключ. Досвід понад 50 проектів за останні роки.

1. Аналітика: вивчаємо вашу структуру даних, визначаємо ключові метрики.
2. Проектування: розробляємо макет, обираємо алгоритм розкладки, продумуємо інтеракції.
3. Реалізація: кодуємо компонент на React/TypeScript, налаштовуємо бекенд для агрегації.
4. Тестування: перевіряємо на реальних даних, оптимізуємо продуктивність.
5. Деплой: інтегруємо з вашим інтерфейсом, розгортаємо на вашому сервері або хмарі.
6. Підтримка: 30 днів безкоштовних доопрацювань та консультації.

Базова версія з tooltip та взаємодіями — 2–3 дні. Розширена з drill-down, фільтрацією та експортом — 5–7 днів.

Результати впровадження

Після впровадження Sankey-діаграми наші клієнти бачать зростання конверсії на 15–30% та зниження CPA на 20–40% за рахунок виявлення вузьких місць. Ми надаємо гарантію на код 6 місяців та повну документацію. Зв'яжіться з нами, щоб замовити розробку кастомної Sankey-діаграми для вашого сайту. Отримайте консультацію інженера вже сьогодні.

Як налаштувати веб-аналітику: 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 після оновлення фронтенду

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

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

1. Аудит поточних тегів та даних (2 дні)
2. Дизайн подієвої схеми (2 дні)
3. Розробка Data Layer та налаштування тегів (3–5 днів)
4. QA в Preview Mode та на staging (2 дні)
5. Деплой та налаштування дашбордів (1 день)

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