🧬 Портфельная Data-Архитектура

1 Философия

2 Технический стек

3 8 блоков модульной архитектуры

3.1. CORE — URL master (фундамент)

3.2. CONTENT — контент страниц

3.3. HOTELS (для bestonline) / PROGRAMS (для ayurtour / panchakarma)

3.4. ANALYTICS — внешние метрики

3.5. SEO — позиции, keywords, backlinks

3.6. LEADS — заявки и продажи

3.7. NOTIFICATIONS — push и email

3.8. ADMIN — пользователи, роли, audit

4 Блок 9 — AI Analyst (будущее)

5 Контракт блока (формат MCP)

{
  "name": "core",
  "version": "1.0.0",
  "status": "active",
  "exports": {
    "tables": ["urls_master", "templates", "tags", "redirects"],
    "views": ["published_urls", "urls_by_template"],
    "api": ["GET /urls", "POST /urls", "DELETE /urls/:id"]
  },
  "imports": {
    "none": "ядро не зависит от других блоков"
  },
  "events_emitted": [
    "url_added", "url_updated", "url_deleted", "template_changed"
  ],
  "events_subscribed": [],
  "health_check": "SELECT COUNT(*) > 0 FROM urls_master",
  "can_disable": false,
  "owners": ["system"],
  "retention": "infinite"
}

6 Safe Evolution — правила развития

6.1. 5-Pass Review ТЗ

Каждое ТЗ проходит 5 разных проверок:

Между passes — пауза (минимум 1 час). Чтобы увидеть свежим глазом.

6.2. Правила «Новое не портит старое»

6.3. Правила «Правим не мешая»

• Soft deprecation — помечаем, работает 3-6 месяцев
• Rolling migration — кусками по 1000 записей, не разом
• Shadow reads/writes — пишем в оба места, сравниваем
• Canary releases — 5% → 20% → 100% трафика
• Zero-downtime — без остановки системы
• Rollback план обязателен — каждая миграция имеет обратную

7 Block-toggle — модульные страницы

8 15 шаблонов × тысячи страниц

9 🔒 Критический принцип: изоляция данных

🧬 Метафора ДНК

Карта Supabase projects (6 изолированных БД)

Каждый проект:

• Свой Supabase URL / API-keys / JWT secrets
• Те же 8 schemas с теми же именами таблиц
• Общие migrations в git (как шаблон)
• Свой keep-alive cron против автопаузы Free Tier (7 дней)
• Свои данные, ПДн, audit log

Вариант А (рекомендую): Отдельный Supabase project на каждый сайт

• Свой URL, свой API-key, свои бэкапы
• Одна архитектурная модель (8 схем с одинаковыми именами)
• Общий git-репо с migrations как шаблон, применяется к каждому проекту
• Свой Looker Studio (или один с фильтрами per dataset)

Вариант Б (не рекомендую): один Supabase с отдельными schemas per сайт

• Сложнее RLS
• Риск смешения ПДн
• Один сбой = все сайты легли

10 Cross-portfolio применение (маппинг)

10 План внедрения (5 фаз)

11 Защита от «сыпется»

12 Гибридная визуализация: Looker + Custom

Looker Studio — «что происходит?»

• SEO позиции месяц к месяцу
• Трафик по странам / шаблонам / источникам
• Отчёты для инвестора
• Сравнение 6 сайтов портфеля side-by-side
• Простые drill-downs и фильтры

Custom Dashboard — «что делать?»

• Главная панель менеджера (как описано в admin-cms)
• AI-рекомендации «сегодня важно: ...»
• Алерты + кнопки «принять меры»
• Block-toggle управление страницами
• Массовые операции (bulk 21k отелей)
• Импорт / экспорт
• Live-статус блоков БД (health checks)
• Чат с AI-аналитиком в интерфейсе

Технический стек Custom Dashboard

dashboard.{site}.ru  (свой поддомен)
├── Frontend: Vanilla JS + Chart.js
├── Data: Supabase REST API + Realtime WebSocket
├── Auth: Supabase Auth (Basic Auth для MVP)
├── Hosting: Cloudflare Pages (бесплатно)
├── AI: Claude API через Supabase Edge Function
└── Style: единый дизайн с сайтом

Слой 10: CUSTOM DASHBOARD (UI для всех блоков)
   ↑ читает
Слой 9:  AI ANALYST (Claude API)
   ↑ анализирует
Слои 1-8: 8 блоков данных (Supabase)

Views в Supabase — общий источник для обоих дашбордов

И Looker, и Custom читают одни и те же views — консистентность данных:

-- VIEW: master dashboard
CREATE VIEW public.v_url_status AS
SELECT
  u.url, u.tier, u.template_type, u.status,
  c.h1, c.title, c.blocks_enabled,
  a.clicks, a.impressions, a.position,
  s.indexation_status,
  l.requests_count
FROM core.urls_master u
LEFT JOIN content.pages c ON c.url_id = u.id
LEFT JOIN analytics.v_gsc_last30 a ON a.url_id = u.id
LEFT JOIN seo.indexation_status s ON s.url_id = u.id
LEFT JOIN leads.v_requests_last30 l ON l.url_id = u.id;

Если какой-то блок не работает — в колонках NULL, dashboard не падает.

13 Полный комплект документов

14 🔌 Битрикс24 — полная интеграция данных

Что можно тянуть из Битрикс24 REST API

🎯 CRM — основное

📞 Коммуникации

📋 Активность и операционка

📊 Отчёты и сводки

🎁 Особое ценное — Звонки + AI

Схема интеграции

Таблицы в Supabase (расширенные)

-- Сырые события (аудит, всегда)
leads.bitrix_events (event_type, payload jsonb, received_at)

-- Нормализованные сущности
leads.deals (bitrix_id, title, stage, amount, contact_id, ...)
leads.leads (bitrix_id, source, status, ...)
leads.contacts (bitrix_id, name, phone, email, ...)
leads.companies (bitrix_id, name, inn, ...)

-- Коммуникации
leads.calls (bitrix_id, duration, record_url, contact_id, transcript)
leads.messages (channel, from, to, text, timestamp)
leads.activities (type, subject, contact_id, ...)

-- Аналитика
leads.pipeline_stages (bitrix_id, name, order, probability)
leads.user_performance (user_id, deals_closed, revenue, avg_deal_size)

Webhook events — приоритизация

MVP за 1 день (что реально успеваем)

Что нужно от владельца Битрикса

1. URL аккаунта — company.bitrix24.ru
2. Доступ к настройке webhooks — администратор
3. Решение: входящий webhook (Битрикс → нам) или исходящий (мы → Битрикс) или оба
4. Минимум прав: crm (сделки/лиды/контакты), telephony (звонки), imopenlines (чаты)

15 Что делаем сейчас

Обновлено 24.04.2026 · Cross-fire портфеля — единая data-архитектура для 6 сайтов
Применяется ко всем проектам WORKJET portfolio