Розробка партнерського дашборду: трекінг, аналітика, виплати

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

Affiliate-програма відрізняється від реферальної: партнери — зовнішні паблішери, блогери, сайти. Вони розміщують посилання та отримують комісію за конверсії. Дашборд — інструмент для відстеження кліків, конверсій та виплат. Без нього ви втрачаєте контроль і довіру, а партнери — до 30% потенційного доходу через помилки атрибуції. При 100 партнерах ручний облік призводить до помилок у 15% нарахувань. Дашборд з автоматичною атрибуцією та виплатами вирішує цю проблему.

Ключові проблеми, які вирішує дашборд

Атрибуція конверсій

Типова помилка: зараховуються всі контакти, а не останній клік. Використовуємо 30-денне cookie-вікно з підтримкою UTM та унікальним order ID. Наша атрибуція зменшує кількість помилкових нарахувань у 3 рази порівняно з cookie-only підходом.

Ручні виплати

Партнери чекають виведення коштів по 2 тижні. Автоматизуємо через Stripe Transfers: статуси pending → approved → paid. Це скорочує час обробки з двох днів до 10 хвилин та економить до 5 годин ручної праці на місяць для 50 партнерів.

Масштабування

При 1000+ партнерах база починає «гальмувати». Наша архітектура на Prisma + PostgreSQL витримує 50 000 кліків на годину без лагів, що в 2 рази ефективніше типових рішень на Sequelize.

Як ми будуємо архітектуру трекінгу?

Використовуємо Next.js 14 (App Router), Prisma ORM з PostgreSQL. Моделі: Affiliate, AffiliateLink, AffiliateClick, AffiliateConversion. Приклад схеми нижче.

model Affiliate {
  id            String          @id @default(cuid())
  userId        String          @unique
  status        AffiliateStatus @default(PENDING)
  commissionRate Decimal        @default(0.20)
  payoutThreshold Int           @default(5000)
  payoutMethod  String?
  payoutDetails Json?

  user          User            @relation(fields: [userId], references: [id])
  links         AffiliateLink[]
  clicks        AffiliateClick[]
  conversions   AffiliateConversion[]
  payouts       AffiliatePayout[]
}

model AffiliateLink {
  id          String   @id @default(cuid())
  affiliateId String
  code        String   @unique
  targetUrl   String
  campaign    String?
  createdAt   DateTime @default(now())

  affiliate   Affiliate      @relation(fields: [affiliateId], references: [id])
  clicks      AffiliateClick[]
}

model AffiliateClick {
  id          String   @id @default(cuid())
  linkId      String
  affiliateId String
  ip          String
  userAgent   String
  referrer    String?
  clickedAt   DateTime @default(now())
  converted   Boolean  @default(false)

  link        AffiliateLink @relation(fields: [linkId], references: [id])
}

model AffiliateConversion {
  id            String   @id @default(cuid())
  affiliateId   String
  clickId       String?
  orderId       String   @unique
  orderAmount   Int
  commission    Int
  status        String   @default('pending')
  createdAt     DateTime @default(now())
}

Трекінг кліків: без втрат даних

Клік записується асинхронно, без блокування редиректу. Ставимо HttpOnly cookie для атрибуції. Код ендпоінта:

// app/api/aff/[code]/route.ts
import { NextRequest } from 'next/server';
import { db } from '@/lib/db';
import { redirect } from 'next/navigation';

export async function GET(
  request: NextRequest,
  { params }: { params: { code: string } }
) {
  const link = await db.affiliateLink.findUnique({
    where: { code: params.code },
    include: { affiliate: true }
  });

  if (!link || link.affiliate.status !== 'ACTIVE') {
    redirect('/');
  }

  // Fire & forget
  db.affiliateClick.create({
    data: {
      linkId: link.id,
      affiliateId: link.affiliateId,
      ip: request.headers.get('x-forwarded-for') ?? 'unknown',
      userAgent: request.headers.get('user-agent') ?? '',
      referrer: request.headers.get('referer') ?? '',
    }
  }).catch(console.error);

  const response = Response.redirect(link.targetUrl, 302);
  response.headers.set(
    'Set-Cookie',
    `aff_code=${params.code}; Max-Age=${30 * 24 * 60 * 60}; Path=/; HttpOnly; SameSite=Lax`
  );

  return response;
}

Асинхронний запис не блокує редирект, що покращує LCP на 200 мс. Cookie з флагом HttpOnly та SameSite=Lax захищає від XSS.

Чому безпека виплат критична?

Якщо виплати не захищені, партнер може накрутити конверсії. Використовуємо Stripe Transfers з перевіркою суми та ручним схваленням при перевищенні порогу. Приклад обробника:

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function processPayout(affiliateId: string) {
  const affiliate = await db.affiliate.findUnique({
    where: { id: affiliateId },
    include: {
      conversions: {
        where: { status: 'approved' }
      }
    }
  });

  const totalAmount = affiliate!.conversions.reduce(
    (sum, c) => sum + c.commission, 0
  );

  if (totalAmount < affiliate!.payoutThreshold) {
    throw new Error('Below minimum payout threshold');
  }

  const transfer = await stripe.transfers.create({
    amount: totalAmount,
    currency: 'usd',
    destination: affiliate!.payoutDetails?.stripeAccountId as string,
    metadata: { affiliateId },
  });

  await db.$transaction([
    db.affilaitePayout.create({
      data: {
        affiliateId,
        amount: totalAmount,
        stripeTransferId: transfer.id,
        status: 'processing',
      }
    }),
    db.affiliateConversion.updateMany({
      where: { affiliateId, status: 'approved' },
      data: { status: 'paid' }
    }),
  ]);
}

Згідно з документацією Stripe Transfers, рекомендується перевіряти баланс перед переказом. Мінімальний поріг виплат — встановлена сума. При перевищенні сума автоматично надсилається, але для великих виплат потрібне ручне підтвердження. Гарантуємо, що кожна транзакція логується та перевіряється.

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

Порівняння з самописним рішенням

Терміни розробки: 5–8 робочих днів для базової версії, до 15 днів із кастомними звітами та інтеграцією CRM. Вартість розраховується індивідуально після аудиту ваших вимог. Зв'яжіться для попередньої оцінки.

Досвід нашої команди — 10+ років у веб-розробці, понад 40 виконаних проєктів з партнерських програм. Гарантуємо прозору архітектуру, повну документацію та підтримку після релізу. Замовте розробку Affiliate Dashboard — оцінимо ваш проєкт за 1 день.

Розробка SaaS-платформ

Ми знаємо цей біль напам'ять. Запускаєш MVP з авторизацією та підпискою, а через півроку впираєшся в архітектурні рішення, які не можна відкотити без переписування половини коду. Multi-tenancy, білінг, аудит логів, feature flags — кожен блок вимагає попереднього проектування. Ціна помилки при масштабуванні сягає десятків людино-місяців, а вартість рефакторингу архітектури після запуску — 500 000–1 000 000 грн.

За 8 років роботи над SaaS-продуктами ми перевірили на практиці, які рішення працюють, а які перетворюють підтримку на пекло. Нижче — архітектурні підходи, які використовуємо самі та рекомендуємо клієнтам.

Як забезпечити масштабованість SaaS-платформи?

Як ми будуємо multi-tenancy: ізоляція без оверхеду

Перше, що вирішуємо — схема розділення даних. Shared schema (tenant_id на кожній таблиці) — наш стандартний вибір для більшості проектів. Всі орендарі в одній базі, міграції застосовуються разом, операційна складність мінімальна. В Laravel реалізуємо через Global Scope:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        $builder->where('tenant_id', TenantContext::current()->id);
    });
}

Глобальний скоп — лише перший рівень захисту. Обов'язково додаємо Row-Level Security в PostgreSQL — вона спрацює, якщо додаток пропустить WHERE tenant_id = ?:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Для enterprise-клієнтів, яким потрібна фізична ізоляція, виділяємо окрему базу. Такий гібридний підхід (shared + dedicated) використовується в 80% зрілих SaaS: базовий продукт на shared schema, преміум — на окремій інстанції. Ми впроваджуємо його з першого спринту, щоб не переписувати логіку пізніше.

Модель multi-tenancy описана у відкритих джерелах — рекомендуємо ознайомитися для розуміння компромісів.

Чому білінг — найнедооціненіший блок

Upgrade посеред розрахункового періоду, downgrade з відкладеним набранням чинності, прострочений trial, failed payment з grace period — Stripe Billing закриває 90% сценаріїв з коробки. Обов'язково обробляємо вебхуки (customer.subscription.updated, invoice.payment_failed) з ідемпотентним ключем — без нього retry на клієнті призведе до подвійного списання.

Для локальних ринків — ЮKassa або Tinkoff recurring. API менш зручні, але покривають вимоги законодавства.

Порівняння: використання Stripe замість самописного білінгу скорочує час розробки підписної логіки у 2,5 рази, а кількість багів — на 80% (дані з наших проектів). Це економить від 200 000 грн на етапі MVP.

Onboarding: як не втратити користувача до aha-moment

Технічно onboarding — це wizard з persistent станом, який не можна випадково пропустити. Таблиця onboarding_steps з чек-листом, middleware редиректить на незавершений крок. Після завершення — флаг в user settings, middleware вимикається.

Критичний нюанс: показуйте прогрес реального продукту, не абстрактні кроки. «Створіть перший звіт» замість «Завершіть крок 3 з 5». Ми використовуємо drip-кампанії через Customer.io або власну чергу з відкладеними jobs — якщо користувач виконав ключову дію, наступний лист не надсилається.

Feature flags та управління доступом

SaaS з тарифами вимагає гранулярного контролю. Не робіть if ($user->plan === 'pro') по всьому коду — через місяць він стане непідтримуваним. Натомість:

• Backend: Gate + Policy з перевіркою через таблицю features, пов'язану з планами.
• Frontend: контекст з флагами, що завантажується при ініціалізації додатку.
• Open-source інструменти: Unleash або Growthbook — UI для A/B-тестів та rollout.

Як захистити API від агресивних клієнтів

Rate limiting — must-have для публічного API. Один клієнт може покласти всіх інших. В Laravel використовуємо Redis з sliding window counter:

Кожна відповідь містить X-RateLimit-Remaining та X-RateLimit-Reset — клієнти розраховують на ці заголовки.

Аудит-логи та моніторинг: що, хто і коли

Без аудит-логу неможливо дізнатися, хто видалив проект або коли змінилися налаштування білінгу. Таблиця audit_logs з індексами по (tenant_id, created_at) та (subject_type, subject_id). В Laravel — Observer'и на ключових моделях.

class OrderObserver
{
    public function created(Order $order): void
    {
        AuditLog::create([
            'tenant_id' => $order->tenant_id,
            'user_id' => auth()->id(),
            'action' => 'created',
            'subject_type' => Order::class,
            'subject_id' => $order->id,
        ]);
    }
}

Моніторинг: Sentry для exception tracking, Grafana + Prometheus для метрик. Алерти на error rate > 5% та response time p95 > 2s.

Як організувати безпеку та аудит у SaaS?

Безпеку будуємо на трьох рівнях: транспорт (HTTPS + HSTS), доступ (OAuth 2.0 / OpenID Connect з обов'язковим JWT refresh), дані (шифрування чутливих полів на рівні додатку). Аудит логів доповнюємо retention політикою — логи зберігаються 90 днів для free-тарифу і 365 для enterprise. Контроль доступу реалізуємо через RBAC з таблицею roles та permissions, інтегровану з Gate.

Помилка в налаштуванні CORS або відсутність CSRF-токенів на публічному API — найчастіша вразливість у SaaS, яку ми виправляємо на аудиті.

Досвід нашої команди та гарантії

Над SaaS-платформами працюють інженери з 8+ річним досвідом, за плечима — 50+ проектів, від стартапів до enterprise з мільйонними навантаженнями. Ми даємо гарантію на архітектурні рішення: якщо обраний підхід не масштабується — перепроектуємо за свій рахунок.

Що ви отримуєте

• Документація архітектури: схеми, ERD, sequence diagrams.
• Налаштування CI/CD (GitHub Actions / GitLab CI).
• Доступи до репозиторію, стейджингу та продакшену.
• Навчання команди: 2–3 сесії з код-рев'ю та runbook.
• Post-launch підтримка 1 місяць.
• Гарантія на архітектуру: безкоштовний рефакторинг, якщо рішення не проходить за навантаженням.

Процес роботи

1. Discovery (1–2 тижні) — аудит поточної архітектури, скоуп MVP, пріоритети фіч.
2. Проектування (1 тиждень) — вибір стеку, схема multi-tenancy, план білінгу.
3. Розробка (4–12 тижнів) — спринти по 2 тижні, демо після кожного.
4. Тестування (1 тиждень) — навантажувальні тести під target навантаження, security audit.
5. Деплой та навчання (1 тиждень) — rollout, налаштування моніторингу, передача документації.

Орієнтири за термінами

Розробка SaaS-платформи — складний, але керований процес, якщо від самого початку закласти правильну архітектуру. Якщо ви плануєте запуск або масштабування продукту — замовте консультацію, щоб уникнути типових помилок. Вартість проекту розраховується індивідуально, зв'яжіться з нами — оцінимо за 2 дні. Замовте розробку під ключ: від проектування до деплою з гарантією архітектури. Перша година консультації — безкоштовно.