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

Вы запустили партнёрскую программу, но партнёры не видят статистику — расчёты вручную в 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. Стоимость рассчитывается индивидуально после аудита ваших требований. Свяжитесь для предварительной оценки.

Опыт нашей команды — 7 лет в веб-разработке, более 40 выполненных проектов по партнёрским программам. Гарантируем прозрачную архитектуру, полную документацию и поддержку после релиза. Закажите разработку Affiliate Dashboard — оценим ваш проект за 1 день.

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

Мы знаем эту боль наизусть. Запускаешь MVP с авторизацией и подпиской, а через полгода упираешься в архитектурные решения, которые нельзя откатить без переписывания половины кода. Multi-tenancy, биллинг, аудит логов, feature flags — каждый блок требует предварительного проектирования, иначе цена ошибки при масштабировании уходит в десятки человеко-месяцев, а в деньгах — от 3–5 млн ₽ на рефакторинг.

За 8 лет работы над 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 описана в Wikipedia: Multitenancy — рекомендуем ознакомиться для понимания trade-off'ов.

Почему биллинг — самый недооценённый блок

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

Для рынка СНГ — ЮKassa или Tinkoff recurring. API менее удобны, но покрывают требования 54-ФЗ.

Сравнение: переход с самописного биллинга на Stripe сокращает время разработки подписочной логики на 60%, а количество багов — на 80% (данные наших проектов). Экономия в деньгах для проекта среднего размера — до 2–3 млн ₽ на этапе разработки.

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-платформами работают инженеры с 8+ летним опытом, за плечами — 50+ проектов, от стартапов до enterprise с миллионными нагрузками. Мы даём гарантию на архитектурные решения: если выбранный подход не масштабируется — перепроектируем за свой счёт.

Deliverables и гарантии

• Документация архитектуры: схемы, 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, настройка мониторинга, передача документации.

Ориентиры по срокам

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