La regla es una: el evento más profundo que la cuenta pueda sostener con datos.
- Evento superficial (
view_content, add_to_cart): el algoritmo optimiza para gente que agrega al carrito, no para gente que compra. Resultado típico: muchos carritos, poca caja.
- Evento intermedio (
initiate_checkout, lead): mejor. Sirve cuando el volumen del evento final es demasiado bajo para aprender.
- Evento profundo (
purchase, schedule, submit_application): el que querés. Es el que enseña el valor real.
El límite es el volumen: se necesitan del orden de 30 a 50 eventos por semana por ad set para que el sistema aprenda. Si el evento profundo no llega a ese número, se optimiza por el intermedio y se mide el profundo aparte.
Cómo se implementa en ecommerce: purchase con valor (value + currency). Si el ticket es bajo y el volumen de compras es chico, optimizar por initiate_checkout y leer el ROAS real en el tablero.
Cómo se implementa en servicios: el formulario enviado no es el evento profundo; la reunión agendada sí. En el caso de referencia, el evento optimizado fue invitee_meeting_scheduled: 427 registros, $210 cada uno. Ese es el número que se defiende en una reunión de negocio.
Verificación obligatoria antes de arrancar: que el evento no esté duplicado (píxel + API disparando lo mismo). Un duplicado multiplica las conversiones reportadas y el sistema aprende con una señal inflada.