BackboneOS

Contexto

Si lideras marketing o ventas en una pyme, probablemente reconoces esta escena: Google Analytics en un tab, el CRM en otro, el email marketing en un tercero, y WhatsApp como canal real donde se cierran conversaciones — pero sin conexión con el resto. Cada herramienta guarda su propia versión del cliente. Nadie puede responder con certeza qué canal generó la venta.

Ese es el costo del SaaS sprawl: muchas suscripciones, poca visibilidad unificada. Los pixels de terceros capturan sesiones anónimas; el CRM registra oportunidades; el equipo de marketing optimiza campañas en silos. La atribución queda rota porque los datos nunca viven en el mismo lugar.

BackboneOS nace como respuesta a ese problema. No es solo el producto que comercializamos en backboneos.com: es la infraestructura first-party que The Backbone Group usa internamente para unificar touchpoints, atribuir conversiones y operar el sistema de creación de clientes — incluyendo el sitio corporativo y, en roadmap, ventures como TuChamba.pe.

La propuesta se resume en una frase: la columna vertebral de tu sistema de creación de clientes.

El problema

Estos son los dolores concretos que BackboneOS aborda — y que vemos en pymes que crecen sin un stack integrado:

• No saber qué canal convierte — Inviertes en ads, contenido y referidos, pero el CRM no sabe de dónde vino el lead.
• Datos fragmentados — El sitio web, el email y WhatsApp viven en sistemas distintos; armar el journey completo requiere exportar CSVs y cruces manuales.
• Marketing sin vista unificada — El equipo optimiza métricas de plataforma (clics, sesiones) sin conectarlas a oportunidades reales en ventas.
• Costo de herramientas que no conversan — HubSpot + GA4 + ESP + automatizaciones: cada una cobra, ninguna es fuente de verdad.
• Dependencia de pixels third-party — Los datos de comportamiento viven en servidores ajenos; cambios de privacidad o bloqueadores erosionan la señal.
• CRM desconectado del customer journey — El vendedor ve un contacto; no ve las páginas que visitó, los formularios que completó ni la campaña que lo trajo.

Enfoque y solución

BackboneOS organiza la operación comercial en tres pilares, alineados con el mensaje de backboneos.com:

Atribución

Captura qué canales generan conversiones reales — no solo clics. El tracker web registra page views, engagement, formularios y señales UTM/referrer. Cada evento se convierte en una interacción trazable dentro del CRM, con clasificación de canal, medio y touchpoint.

Predicción

Dirección estratégica del producto: priorizar prospectos con señal de intención a partir del volumen de interacciones acumuladas. Hoy el pipeline comercial permite priorización manual en ventas; los modelos predictivos están en roadmap — no forman parte del producto en producción actual.

Verdadero CRM

El journey completo en una vista: desde la primera visita web hasta la oportunidad en ventas. Personas, organizaciones, productos, ofertas, campañas e interacciones comparten la misma base de datos — PostgreSQL bajo tu control.

Diferenciador vs stack típico de pyme

Aspecto	Stack típico (HubSpot + GA4)	BackboneOS
Datos	Pixels y silos SaaS	PostgreSQL propio, first-party
Atribución	Sesiones en GA4, desconectadas del CRM	Interacciones + campañas en el mismo sistema
CRM	Módulo separado del tracking web	Mismo backend que captura touchpoints
Control	Vendor lock-in	Open source (MIT), self-hosted o hosted por TBG
Costo	Suscripciones acumuladas por módulo	Infraestructura que tú operas o delegas

Qué construimos

Plataforma en producción operada por The Backbone Group, con código abierto disponible para implementadores en github.com/josedante/BackboneOS.

Arquitectura (alto nivel)

Capa	Tecnología
Backend + CRM operativo	Django 5.2 + Django REST Framework + templates/Tailwind
Base de datos	PostgreSQL 14
Cache, sesiones y colas	Redis 7 + Celery + Celery Beat
Contenedores	Docker + Docker Compose (desarrollo)
Producción	Docker en cloud, autodeploy desde main
Observabilidad	Sentry, Flower (monitoreo de tareas)

Un solo proceso Django sirve el CRM HTML y la API REST — sin frontend separado. Las integraciones externas (tracker web, webhooks futuros) consumen la API; los operadores trabajan en el CRM.

Apps del ecosistema

App	Rol
World	Ontología y taxonomías (industrias, segmentos, competencias)
Entities	Personas y organizaciones — núcleo semántico del CRM
Products	Catálogo comercial con analytics
Offers	Ofertas comerciales y precios dinámicos
Campaigns	Campañas multicanal con targeting semántico
Interactions	Sustrato del customer journey
Websites	Tracking web y procesamiento de eventos
Connectors	Framework de resolución de touchpoints
Intake	Leads inbound desde formularios y API
Sales	Pipeline comercial, oportunidades, listas de contacto
Emailing	Fundación del conector email (Phase 0)
Dashboard	Home operativo del CRM
Our Institution	Estructura organizacional propia
Users	Autenticación, RBAC, JWT
Core	Utilidades y comandos de gestión

Flujo comercial

World → Entities → Products → Offers → Campaigns → Interactions

La ontología (World) define el vocabulario del negocio. Entities modelan clientes y prospectos. Products y Offers estructuran qué vendes y cómo. Campaigns promueven con contexto de canal. Interactions registran cada touchpoint del journey.

Website tracker

El sitio corporativo thebackbonegroup.com envía eventos a la API de BackboneOS mediante un script de tracking first-party. El flujo:

1. El visitante carga una página con el script de tracking.
2. El script envía eventos vía POST a /api/websites/events/{tipo}/.
3. La app Websites valida el dominio, procesa el evento y resuelve el touchpoint.
4. Se crean registros Interaction + WebInteraction en PostgreSQL.
5. El operador ve el journey en el CRM (dashboard, interacciones, pipeline de ventas).

Eventos soportados hoy (client-side):

event_type	Descripción
page_view	Vista de página
page_read	Lectura / scroll profundo
click	Clic en elemento
form_submit	Envío de formulario (conecta con Intake)
download	Descarga de archivo
video_play	Reproducción de video
search	Búsqueda en sitio
newsletter_signup	Suscripción a newsletter

Adicionalmente, el servidor infiere session_start (landing pages) y referrer_click (atribución desde referrer externo o UTM) sin intervención del script.

Sitio de producto

El marketing site público está en backboneos.com. El CRM operativo y la API REST se despliegan por tenant — cada implementación usa sus propios dominios; no publicamos URLs de infraestructura interna en el case study.

Integraciones y conectores

Touchpoint	Estado
Web tracker	Producción — 8 tipos de evento + atribución UTM/referrer
Formularios → Intake	Producción — vía form_submit
Email (ESP webhooks)	Phase 0 — modelos, taxonomía y protocolo de adaptadores
WhatsApp	Framework de resolución; sin app dedicada ni webhooks en producción
Plataformas de ads	Atribución por UTM en landing pages; sin API directa a Meta/Google Ads
TuChamba.pe	Operación actual con Make.com + Google Analytics; migración planificada a BackboneOS

Dogfooding

The Backbone Group usa BackboneOS como infraestructura interna:

• thebackbonegroup.com — tracker activo en nuestro sitio corporativo.
• backboneos.com — sitio de producto; mismo ecosistema de marca.
• TuChamba.pe — venture del portafolio TBG; case study publicado en thebackbonegroup.com/portafolio/tuchamba-pe. La migración de su stack operativo (Make.com + GA) a BackboneOS está en roadmap.

Resultados

Plataforma en producción operada por The Backbone Group desde el 4 de julio de 2025.

Sitios con tracker activo: thebackbonegroup.com (dogfooding en producción).

Aprendizajes:

• First-party data elimina la dependencia de pixels de terceros para construir el journey comercial — los eventos viven en tu PostgreSQL, no en un vendor.
• Unificar captura + CRM reduce silos entre marketing y ventas: la misma interacción web alimenta atribución y pipeline.
• Dogfooding expone gaps reales antes de vender a clientes — si el tracker falla en nuestro sitio, lo arreglamos antes de prometerlo afuera.
• Open source (MIT) acelera iteración, pero exige disciplina de ops: migraciones, Celery, Redis y despliegue no son opcionales.
• Predicción requiere volumen — la atribución y la captura consistente son el cimiento; los modelos vienen después, con datos propios acumulados.