Citadel Tracker · Routing · Domains · Ops
Traffic operations platform

Citadel — routing, attribution і platform control

Routing, tracking і branded flows в одній системі.

Citadel зводить в один operational flow те, що зазвичай розкидано по різних сервісах: entry links, routing policies, branded domains, landing events, live stats і platform-admin для керування інстансами.

Policy-driven routing Branded domain delivery Submit-level attribution
Відкрити Admin Live stats Integration guide
Control room One surface for routing, domains and attribution
Why it matters Менше ручної склейки між ads, landing і policy layers
3 layers
Django + FastAPI + Edge worker
1 click_id
від переходу до submit
2 routes
public fallback / secure destination

Platform overview

Citadel збирає трафікову інфраструктуру в один зрозумілий контур.

Замість набору розрізнених інструментів ви отримуєте один маршрут: від рекламного кліку і policy decision до landing events, звітів і platform operations.

01

Tracking + routing ядро

Tracking link створює click_id, policy одразу приймає decision, а branded route веде користувача далі без ручної склейки між сервісами.

  • єдиний entrypoint для ads traffic;
  • одна attribution path до submit;
  • зрозумілий decision trail для команди.
02

Policy control

GEO, ASN, IP ranges, duplicate window, automation checks і rollout percentage керуються з одного policy engine.

03

Branded domains

DNS verify, SSL/nginx provisioning і policy-aware paths дозволяють запускати branded flows без окремої ручної збірки.

04

Operational visibility

Stats, event log, share reports і platform-admin дають видимість не тільки по кліках, а по всьому runtime flow.

Runtime flow

Один реальний request проходить через routing engine, domain logic, click storage і analytics pipeline.

01 → 05

Кожен крок не просто веде далі по URL, а додає state, який потім читають stats, reports і admin surfaces.

01

Entry point

Трафік заходить через /r/<slug>/ або branded custom domain path. Citadel знаходить потрібний tracking link і policy.

GET /r/pl-finance-main/?source=facebook
02

Policy decision

Routing engine перевіряє allowed countries, blocked ASNs, IP ranges, duplicate window, automation markers, fraud thresholds і secure rollout bucket.

decision = serve_secure_assets | serve_public_fallback
03

Audit write

Citadel зберігає click, destination, reason, served domain і policy revision, а також пише TrafficAuditLedger для подальшого розбору.

Click + TrafficAuditLedger + EventLog
04

Landing script

Landing page отримує click_id, відправляє landed, а після успішної форми повертає submitted або через helper, або через success URL match.

window.CitadelTracker.markSubmitted()
05

Read model

Stats, dashboard, share reports і admin UI одразу бачать requests, landed, submitted, CR і події по link, policy, domain, funnel і vertical.

Admin stats + public share reports

Сloaking

Policy engine — одна з найсильніших частин системи, бо саме вона перетворює “трекер” на traffic control platform.

Що вміє policy engine

  • розділяти public fallback і secure destination;
  • обмежувати трафік по країнах, ASN і IP ranges;
  • ловити duplicate/request pressure через cache window;
  • блокувати automation і datacenter traffic за правилами policy;
  • керувати secure rollout через deterministic percentage bucket;
  • повертати reason + destination + revision для runtime layer.
Policy scopes 7+ основних типів rule checks
Decision paths 2 secure або public fallback
Audit trail Saved click + ledger + event log
Cross-layer use Shared Django, FastAPI і edge flow

Operational surfaces

Кожна surface закриває окрему частину щоденної роботи з трафіком.

Admin traffic desk

Керування campaigns, funnels, tracking links, clicks, cloaking, stats report і event log з одного Django admin surface.

Platform admin

Окремий `platform-admin` для client setup links, client instances, provisioning, deprovisioning і runtime instance lifecycle.

Public reporting

Share links дають безпечний read-only доступ до обмежених metrics для партнерів або клієнтів без показу money fields.

Rollout path

Перед запуском нового flow достатньо зібрати шість опорних елементів.

1 Routing Policy

Назва policy, endpoints, GEO/ASN/IP правила, fraud controls, secure rollout percentage і path prefix.

2 Tracking Link

Slug, funnel binding, source/geo/vertical labels, landing success mode і готові public/custom-domain URLs.

3 Tracking Domain

Домен, DNS verify, SSL/nginx provisioning, service name і прив’язка до links/policies.

4 Landing Script

Generated snippet для `landed` і `submitted` events, який можна вставити без ручного написання інтеграційного коду.

5 Stats Surface

Admin stats report, dashboard cards і share links для live monitoring requests, landed, submitted і CR.

6 Instance rollout

Якщо це клієнтський інстанс, setup link і platform-admin готують окреме оточення, env, DB, Redis і service lifecycle.

Launch principle

Flow виглядає готовим лише тоді, коли link, policy, domain і landing script зібрані як одна маршрутна система, а не як окремі налаштування.

Key endpoints

Ключові runtime endpoints, через які проходить інтеграція

GET /r/pl-finance-main/?source=facebook
GET /offer-domain.com/onlyaff/pl-finance-main/
POST /internal/routing/resolve/
decision + reason + destination + revision
GET /api/tracking/click/<click_id>/event/landed/
POST /api/tracking/click/<click_id>/event/submitted/
GET /gateway
POST /v1/verify-token
POST /v1/verify-request
Integration principle

Ці endpoints мають виглядати як одна узгоджена surface: один flow, одна naming model, одна schema expectation для runtime і reporting шарів.

New landing

Citadel варто показувати як зібрану traffic platform, а не як набір окремих редіректних блоків.

Коли routing, branded delivery, attribution і reporting відчуваються як одна система, продукт виглядає дорожче і зрозуміліше для команди.

Перейти в Admin Відкрити Live stats
Policyrouting control
Domainbranded delivery
Eventssubmit analytics