Qué debe viajar entre ambos.
- Contactos y datos básicos
- Segmentos y etiquetas
- Altas y bajas de suscripción
- Aperturas y clics
- Rebotes y direcciones inválidas
- Origen de cada suscriptor
La baja es el dato más importante.
Cuando alguien se da de baja en Mailchimp, esa información tiene que llegar al CRM inmediatamente y de forma irreversible. Si la sincronización es solo de CRM hacia Mailchimp, en la siguiente carga volverás a añadir a quien pidió no recibir nada.
Por eso la baja debe viajar siempre en sentido contrario y marcarse como estado protegido: ningún proceso automático debería poder revertirla. Es la diferencia entre una integración correcta y una sanción.
Dónde suele fallar.
- Bajas que se sobrescriben
- Contactos duplicados por mayúsculas
- Segmentos que se reconstruyen mal
- Rebotes que nadie limpia
- Límites de la API en cargas masivas
- Consentimiento sin trazabilidad
Cómo decidimos la vía técnica.
- Conector nativo si existe y basta
Es lo más barato de mantener. Si cubre el caso, no hay razón para construir nada.
- Automatización no-code si hay lógica
Make o n8n cuando hay condiciones, transformaciones o varios pasos encadenados.
- API y webhooks si hay volumen o reglas propias
Cuando el caso es específico, el volumen alto o hace falta control sobre errores y reintentos.
- Siempre con registro de errores
Toda integración falla alguna vez. La diferencia es si te enteras el mismo día o tres semanas después.
Preguntas frecuentes
¿Merece la pena si ya tenemos Zoho Campaigns?
Si ya usáis Campaigns, normalmente no: la integración nativa dentro del mismo ecosistema es más simple. Tiene sentido cuando hay una razón real para seguir en Mailchimp.
¿Se puede sincronizar solo un segmento concreto?
Sí. Sincronizar todo rara vez es buena idea: es preferible definir qué contactos entran y bajo qué criterio.
¿Cómo se acredita el consentimiento?
Guardando origen, fecha y método de alta en el CRM, de modo que ante una reclamación se pueda demostrar cuándo y cómo se obtuvo.