Saltar al contenido principal

​
Resumen

Un Contact es el registro unificado de una persona, y el objeto central de Customer Data. CXF resuelve a la misma persona entre canales y dispositivos en un solo contact mediante identifiers, le da estructura con Profiles y lo agrupa bajo una Organization. Los contacts también llevan taxonomies, tags, relationships, workflows, ownership, archive y pertenencia a segments. Para el panorama completo, consulta el overview de Customer Data.

​
Dónde encontrarlo

Los contacts están en Customer Data → Contacts.

​
Tipos de contact

El tipo de un contact se calcula automáticamente a partir de sus identifiers, su nombre y el flag de vendor — no lo defines a mano:
TipoQué significa
GhostAnónimo o sin identificar — solo un token anónimo, o sin nombre. Se crea cuando alguien interactúa antes de identificarse.
LeadTiene nombre y al menos un email o teléfono, pero ninguno validado aún.
ContactTiene nombre y al menos un email o teléfono validado.
VendorUn contact marcado como vendor (un proveedor), sin importar la validación.

​
Identifiers

Un identifier es un valor que identifica a un contact — un email, un teléfono, un UUID, un token OAuth, etc. La resolución de identidad consolida los múltiples identifiers de una persona en un solo contact, para tener un registro 360° en lugar de fragmentos. Cada identifier lleva:
PropertyDescripción
semantic_typeEl tipo de identifier — email, phone, oauth, uuid, …
identifierEl valor en sí (p. ej. [email protected]).
slugUna etiqueta dentro de su tipo — Main, Work, Personal. Reemplaza un único flag “main”.
is_validatedSi el valor fue verificado, y cómo/cuándo (OTP, magic link, manual).
sourceDe dónde vino (datos de event, import, manual).
outreachSi es un método de contacto por el que puedes comunicarte.
El slug de un identifier es único por semantic type por contact — un contact no puede tener dos emails Work, pero sí un email Work y un teléfono Work. Cada tipo tiene un slug Main (que no se puede quitar); el email y el teléfono principales del contact se resuelven desde él. El catálogo de slugs se configura en Settings → Customer Data → Manage Identifiers.

​
Properties

PropertyTipoRequeridoDescripción
given_namestringCondicionalNombre — requerido para que un contact sea más que un ghost.
last_namestringCondicionalApellido — requerido para que un contact sea más que un ghost.
identifiersarrayNoLos identifiers del contact.
emailstringAutoEmail principal, resuelto desde el identifier de email Main.
phonestringAutoTeléfono principal, resuelto desde el identifier de teléfono Main.
is_vendorbooleanNoMarca al contact como vendor.
typeenumAutoCalculado: ghost, lead, contact o vendor.
organization_idreferenceNoLa organization a la que pertenece el contact.
profilesarrayNoProfiles adoptados — definen los attributes del contact.
segmentsarrayAutoLos segments que el contact cumple actualmente.
Los campos personalizados de un contact vienen de los profiles que adopta; las taxonomies, tags y ownership aplican como en cualquier objeto de customer data.

​
Cómo se crean los contacts

  • Ghost — se crea automáticamente cuando un visitante anónimo interactúa (un funnel, un chat widget, un canal web). El ghost se trackea con un token anónimo.
  • Lead / registro completo — un alta pública crea un lead (nombre + email/teléfono, sin validar aún) o un registro completo (con contraseña). Validar un identifier promueve un lead a contact.
  • Admin — un usuario crea un contact directamente desde el dashboard.
Cuando hay un token conocido presente, registrarse mejora el ghost existente en lugar de crear un duplicado.

​
Comportamiento y reglas

  • El tipo se deriva, no se define — se recalcula a partir del nombre, los identifiers y el flag de vendor del contact.
  • La validación promueve — un lead se vuelve contact cuando uno de sus identifiers se valida (OTP o magic link).
  • Pertenece a una organization — definir organization_id agrupa al contact; renombrar la organization actualiza el nombre de organization denormalizado del contact.
  • Limpieza de ghosts — los ghost contacts se pueden eliminar automáticamente tras un periodo de inactividad, configurable en Customer Data Settings.

​
Seeds

Los contacts viajan entre entornos como Seeds estructurales. Un contact lleva su nombre, identifiers, valores de attributes, profiles adoptados (por slug) y una referencia a su organization (resuelta con un reference helper): 
[
  {
    "object_type": "contacts",
    "data": {
      "given_name": "Roslyn",
      "last_name": "Hill",
      "organization_id": "{{getRecordAttribute('organizations', 'slug', 'lehner-plc')}}",
      "identifiers": [
        {
          "identifier": "+10096376673",
          "semantic_type": "phone",
          "slug": "main",
          "source": "import",
          "validation_method": "manual",
          "is_validated": true,
          "outreach": true
        }
      ],
      "default": {
        "pet_name": "Rosie",
        "favorite_book": "The Hobbit"
      },
      "profiles": ["financial-profile", "sales-profile"],
      "is_vendor": false
    }
  }
]
Los valores de attributes del contact viven bajo el slug de su grupo de attributes (aquí default); profiles lista los profiles que adopta, por slug.

​
Gobernanza y permisos

Un super admin o un Master puede gestionar cualquier contact. Los contacts llevan Ownership, así que un Journey Manager gestiona los contacts que posee.

​
Acceso por API

Los contacts tienen CRUD completo por la User API. Los flujos públicos de cara al contacto — captura de leads, registro y validación de identifiers — corren por la Contact API.

​
Relacionado

Profiles

El esquema de attributes que adopta un contact.

Organizations

La empresa o cuenta a la que pertenece un contact.

Segments

Audiencias dinámicas en las que puede caer un contact.

Document Templates

Documentos estructurados adjuntos a un contact.