Por lo general, cuando un equipo de marketing viene a nosotros frustrado con sus números de atribución, nos muestran un dashboard donde dos charts en la misma página discrepan. Paid search es la fuente top en una tarjeta y la tercera fuente en otra. El equipo ha pasado la mañana discutiendo cuál chart es correcto. El chart no es el problema. La única propiedad de lead source que alimenta ambos charts es el problema, y juguetear a nivel de report no lo arreglará. El arreglo vive una capa más abajo, en la arquitectura de propiedad sobre el contact record.
Por qué importa ahora
Los buyer journeys B2B siguen volviéndose más largos y más ruidosos, los touches de paid se apilan sobre los orgánicos, el chat se solapa con form fills, y un solo contacto acumula docenas de interacciones antes de que el SDR levante el teléfono. La atribución last-click era la respuesta fácil, pero last-click «misrepresenta cómo la combinación compleja de hoy de esfuerzos de marketing influye en los outcomes de compra,» como Harvard Business Review lo expresó en su pieza sobre por qué las métricas de marketing no cuadran. (hbr.org) El instinto es arreglar el report. El arreglo real es dejar de permitir que una propiedad lleve el peso de tres preguntas distintas.
Por qué una sola propiedad de lead source siempre pierde
A una sola propiedad de lead source se le pide, cada día, responder al menos tres preguntas distintas, qué canal introdujo a este contacto a nosotros; qué canal le tocó por última vez antes de la actividad de hoy; y qué canal estaba activo en el momento en que levantó la mano. Esos son tres trabajos. Una sola propiedad solo puede sostener un valor a la vez, así que termina sosteniendo cualquier señal que ganara la condición de carrera más reciente, normalmente el último form fill o el último paid click sobrescribiendo lo que estuviera allí.
Por ejemplo: un contacto le descubre a través de un blog post orgánico, vuelve dos semanas después vía un anuncio de paid social, y finalmente convierte en un formulario de webinar. La sola propiedad de lead source lee «webinar», o «paid social,» dependiendo de qué workflow disparó al final. El equipo de contenido piensa que el blog está muerto. El equipo de paid se atribuye el crédito. Ninguno tiene razón, porque la propiedad nunca tuvo espacio para contar la historia completa.
First-touch, last-touch, converting-touch, tres propiedades, tres trabajos
El arreglo es dejar de tratar lead source como una propiedad y empezar a tratarla como tres. Cada una tiene un trabajo claramente definido, una regla de escritura claramente definida, y un consumidor claramente definido.
First-touch, write-once, puesto en la creación de contacto
La propiedad first-touch responde: qué canal introdujo a este contacto a nosotros. Se pone en el momento en que el contact record se crea y nunca se sobrescribe: ni por un workflow, ni por una integración, ni por un formulario. La regla de escritura es dura, settable solo en create, locked desde entonces. Este es el campo que los equipos de contenido y SEO deberían mirar, porque es el único que sobrevive el lifecycle completo del contacto sin que paid o actividad de last-mile reescriban la historia.
Last-touch, última interacción no-directa, actualizable
La propiedad last-touch responde: qué canal tocó por última vez a este contacto antes de lo que sea que esté haciendo ahora mismo. Se actualiza cuando aterriza una interacción no-directa, un paid click, una etiqueta de campaign, una referral. El tráfico directo no la sobrescribe (si no, cada URL tecleada borra la señal de marketing real). Este es el campo que el equipo de paid debería mirar, porque refleja si el presupuesto está aún haciendo su trabajo tarde en el ciclo.
Converting-touch, anclado en el momento de la conversión
La propiedad converting-touch responde: qué canal estaba activo en el momento en que este contacto realmente convirtió, envió el demo form, alcanzó MQL, levantó la mano. Se pone en el evento de conversión y, como first-touch, nunca se sobrescribe después. Este es el campo que el handoff de ventas y el routing de SDR deberían mirar, porque captura el canal de intención más que el canal de awareness o el canal de última exposición de campaign.
Las reglas de escritura, qué propiedad puede tocar cada sistema
Tres propiedades solo funcionan si las reglas de escritura son herméticas, aplicadas a través de forms, workflows e integration sync. Los formularios ponen first-touch en create y converting-touch en submit, punto, nunca escriben last-touch. Los workflows actualizan last-touch cuando una regla de atribución de campaign dispara, pero tienen prohibido tocar first-touch o converting-touch después de que se pongan. Las integraciones nativas de ads y los feeds de reverse-ETL obtienen acceso de escritura solo a last-touch. Si la superficie de escritura de una propiedad no está restringida, la arquitectura colapsa de vuelta al desorden de una propiedad dentro de un trimestre.
Un detalle práctico: bloquee los campos first-touch y converting-touch usando lógica «set once» en workflows que verifican si el campo está vacío antes de escribir. La plataforma no aplica write-once nativamente, así que la disciplina vive en la capa de workflow. Esto necesita tomarse con un grano de sal, ningún enforcement es perfecto, especialmente cuando alguien importa un CSV, pero el patrón aguanta si los workflows se nombran consistentemente y se revisan trimestralmente.
La capa de reporting, elija una propiedad por report, nunca las promedie
Tres propiedades significan tres reports, no un report que promedia entre ellas. El dashboard de atribución de contenido lee solo first-touch. El dashboard de eficiencia de paid lee solo last-touch. El dashboard de handoff MQL-a-SQL lee solo converting-touch. Cada report nombra el campo en su título y en el subtítulo del chart, para que cualquiera que se acerque entienda qué pregunta está respondiendo. La tentación de construir un único report de «lead source» que cambie entre los tres campos en un dropdown es real, y debería resistirse, cada equipo que use el dropdown olvidará cuál está actualmente seleccionado y discutirá sobre el resultado.
Un problema hermano que vale la pena marcar, una vez que un contacto es conocido, las UTMs en sesiones subsiguientes dejan de capturarse por el tracking por defecto, un modo de fallo separado del que trata este post. La arquitectura de propiedad aquí asume que los inputs están limpios. Si el UTM stitching está roto aguas arriba, el modelo de tres propiedades fielmente registra tres sabores de datos malos.
Patrón de campo
Un equipo de marketing B2B SaaS en DACH en fase late-Series-A vino a nosotros con exactamente esta contradicción de dashboard. Su único campo «original source» se sobrescribía por un workflow de paid social cada vez que un contacto re-engaged hacía click en un anuncio, así que el report mensual del equipo de contenido seguía colapsando a medida que contactos originalmente sourced del blog se re-atribuían a paid meses después. El CFO preguntó, razonablemente, por qué existía el presupuesto de contenido. Dividimos la propiedad en tres en una build de dos semanas, first-touch como un nuevo campo backfilled desde el snapshot histórico de record-create, last-touch cableado al workflow de paid existente con la regla de escritura estrechada, converting-touch puesto en form submit y bloqueado. Dentro de un mes la contribución del equipo de contenido dejó de desaparecer, el equipo de paid mantuvo su crédito de last-touch donde el presupuesto realmente re-engaged a un contacto, y el handoff de ventas tenía un canal estable de intención sobre el que enrutar. Ninguno de los tres números se movió mucho; era la misma actividad, finalmente separada.
Resolución, un playbook para instalar el modelo de tres propiedades
- Audite la propiedad de lead source existente. Liste cada workflow, integración y formulario que escribe sobre ella. Está buscando las race conditions, los lugares donde dos sistemas se sobrescriben uno al otro. Esta lista normalmente sorprende al equipo.
- Cree tres nuevas propiedades. Un campo first-touch channel, un campo last-touch channel, un campo converting-touch channel. No reutilice el campo de lead source existente en la primera pasada, déjelo en su lugar para que los reports históricos sigan funcionando.
- Defina los valores del picklist una vez, compartidos entre los tres. Mismos valores, mismo casing, mismo orden. Los reports colapsan en el momento en que un campo tiene «paid social» y otro tiene «paid - social.»
- Cablee las reglas de escritura. Los formularios ponen first-touch (solo si está vacío) y converting-touch en submit. Las integraciones de paid escriben solo last-touch. Cada workflow que toque estos campos recibe un prefijo de nombre que marca qué propiedad posee.
- Backfill first-touch desde timestamps de record-create. Para contactos existentes, use los datos de original-source que la plataforma ya retiene donde sobrevive, y acepte un known-unknown para el resto. Documente la fecha de corte.
- Reconstruya los reports contra los nuevos campos. Un report por propiedad. Titule cada uno con el nombre de la propiedad. Retire el viejo report de fuente única o márquelo como deprecated para que nadie confíe en él.
- Revise el inventario de workflows trimestralmente. La arquitectura solo se mantiene limpia si alguien posee la revisión. Añádalo a la agenda permanente de marketing ops.
Dónde entra Checkpoint
La arquitectura de propiedad es el trabajo poco glamuroso detrás de cada dashboard de HubSpot en el que alguien realmente confía. Es la mayor parte de lo que hacemos en el lado de marketing operations en Checkpoint. Si su dashboard de lead source se contradice a sí mismo, o si contenido, paid y ventas han dejado de estar de acuerdo sobre lo que significa «source», el arreglo es casi siempre una capa por debajo del dashboard. Hable con nosotros antes de que la próxima revisión trimestral fuerce otra discusión sobre qué chart es correcto.
Fuentes
- Lindsay. «Why Your Marketing Metrics Don’t Add Up.» Harvard Business Review, 9 de septiembre de 2014. hbr.org
- Hossain. «A Simple Framework for Unlocking Full-Funnel Marketing Attribution Intelligence.» OpenView Labs. openviewpartners.com
Noah Charak