LEO Customer 360
AI-ready Customer 360 infrastructure for identity resolution, unified customer profiles, behavioral data, analytics, and activation.
LEO Customer 360 is an open-source Customer 360 and identity-resolution platform designed as a foundation for a composable Customer Data Platform (CDP).
It brings fragmented customer data into a unified, tenant-aware customer model and provides the infrastructure required to build analytics, segmentation, personalization, scoring, AI, and marketing activation on top of that foundation.
Collect → Resolve → Unify → Understand → Activate
Why LEO Customer 360?
Customer data is usually fragmented across websites, mobile applications, POS systems, CRM platforms, advertising platforms, and transactional systems.
The difficult problem is not simply storing this data.
The difficult problem is answering:
Who is this customer, what do we know about them, and what should the business do next?
LEO Customer 360 addresses the foundation of that problem through:
- Identity Resolution — connect records belonging to the same real-world customer using metadata-driven matching and survivorship rules
- Golden Customer Records — maintain a unified, tenant-isolated customer profile (
cdp_master_profiles) with domain extensions (cdp_domain_profiles)
- Persona Resolution — compute versioned customer personas (
cdp_customer_personas) and shared archetypes (cdp_persona_archetypes) with explainable feature breakdowns
- Identity Graph — preserve relationships between raw identities, master profiles, and business entities
- Behavioral Data Lake — ingest high-throughput events via Redis Streams into immutable S3/MinIO
.jsonl.gz partitions without touching PostgreSQL on the hot path
- Segmentation & IAB Taxonomy — build segments with visual QueryBuilder or natural-language AI drafts, and map standardized IAB Audience Taxonomy 1.1 tags
- Governed Campaign Activation & Ad Sync — execute human-approved multi-step campaign workflows across Email, Zalo ZNS, SMS, Web Push, and hashed custom-audience exports to Meta Ads, Google Ads Customer Match, and TikTok Ads
Architecture
LEO Customer 360 follows a modular architecture built around PostgreSQL 16, Redis, S3-compatible object storage, and eight independently deployable customer360-* components.
Web / Mobile SDK / Webhooks ──> customer360-event-api (:8010) ──> Redis Streams
│
▼
S3 / MinIO (.jsonl.gz)
│
▼
Sources / CRM / S3 Sync ──────> PostgreSQL 16 <──> customer360-backend (Dagster)
(customer360) ├── analytics (S3 -> staging)
│ ├── identity_resolution (CIR + personas)
│ ├── segmentation (SQL rules + IAB tags)
│ ├── data_synch (Meta/Google/TikTok Ads)
│ ├── campaign_activation (FlowEngine)
│ ├── email_engine & notification_engine (ZNS)
│ └── ai_agents_runners
├──> customer360-api (:8008, REST + /mcp) <──> customer360-agent (:8009)
├──> customer360-frontend (:8890, Admin UI)
└──> customer360-promotions (:9009, leo_ads schema)
PostgreSQL 16 stores operational customer, identity, persona, segmentation, CRM, workflow, and application data protected by Row-Level Security (RLS). customer360-event-api validates event batches, durably enqueues them in Redis Streams, and writes immutable .jsonl.gz objects to S3-compatible storage (MinIO in local development); it has zero database dependencies on the request path. Dagster orchestrates backend data pipelines in customer360-backend, while FastAPI services expose REST/MCP contracts and the browser-based Admin UI.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
