Skip to content
Entender qué se hizo y por qué (no solo el “qué”, que muchas veces está en el historial).Evitar huecos cuando:cambia el analista,hay traspasos temporales,el líder audita,pasan 15–30 días y nadie recuerda el motivo del volantazo.Dejar evidencia del aprendizaje / criterio del analista (responsabilidad técnica).
Cambio de estrategia de puja (p.ej. Max Conversions → tCPA / tROAS)Cambios fuertes de estructura (campañas/adsets, segmentación, ubicaciones)Escalado o recorte significativo de presupuestoPausar/activar un canal relevante (ej. “WhatsApp Santa Fe”)Cambio de objetivo / evento de conversión / tracking que afecta medición
Problemas con Google/Meta (rechazos, verificaciones, billing, políticas)Tracking roto
evidenciar por qué se frenó,que no “desaparezca” cuando se resuelve,sostener la explicación en un trimestre (“fuimos lentos por X”).
“Agregué negativas”“Ajusté extensiones”“Cambios menores de $20.000 a $20.200”“Hice optimizaciones habituales”“Chequeé 4 cosas”
IBEX sigue siendo el medio de ejecución del equipo (tareas con dueño, fecha, dependencias).La bitácora no reemplaza IBEX: registra el “relato técnico” y el “por qué”.Si es un bloqueo o dependencia del cliente:debe existir tarea IBEX con dependencia del cliente (y su fecha/compromiso),y la bitácora deja el “asiento” visible y rastreable.
La bitácora se completa en el momento del cambio o al cierre del día (no al final del mes).Se debe revisar en el check semanal como parte del ritual.
Bitácora (en CODA) — Proceso y estándar
Objetivo
La Bitácora existe para dar visibilidad trazable de cambios y situaciones relevantes de una cuenta.
Sirve para:
La bitácora no es para “justificar que trabajé hoy”. Es para registrar lo que cambia el rumbo.
Dónde está (importante)
La bitácora vive dentro del Check y seguimiento de cuentas en CODA (como una entidad/tabla del mismo documento), nunca como un archivo suelto y aislado.
Todo lo operativo y la visibilidad tienen que estar en un solo lugar.
Qué se registra (reglas simples)
Se registra solo lo que cumple al menos 1 de estas condiciones:
A. Cambios trascendentales en plataforma
Ejemplos:
B. Bloqueos / incidentes
C. Dependencias del cliente que frenan ejecución
Si la pelota queda del lado del cliente (info, assets, permisos, definiciones), se registra para:
Qué NO se registra
Todo lo banal / mecánico:
Regla mental: si no afecta decisiones futuras, no va.
Estructura de la Bitácora (mínima, 1 texto)
Para reducir tiempo y burocracia: un solo campo de texto estructurado.
Formato del texto único (plantilla)
Acción: qué cambió
Por qué: motivo/hipótesis/trigger (dato o situación)
Qué espero: qué debería pasar y en cuánto tiempo (criterio de evaluación)
Link IBEX: link a tarea/ticket si aplica (siempre que exista)
Ejemplo bueno:
Acción: cambié puja de Max Conv a tCPA en Search “Servicios X”. Por qué: CPA venía subiendo 3 semanas y el volumen permite controlar. Qué espero: estabilizar CPA en 14–21 días; si cae volumen, vuelvo a Max Conv. Link IBEX: [tarea #...]
Ejemplo bueno (dependencia cliente):
Acción: quedó pendiente integración de eventos GA4 (purchase/lead). Por qué: cliente no dio acceso a GTM/Shopify; sin eso no podemos validar conv. Qué espero: destrabar con call; hasta entonces, optimización limitada. Link IBEX: [tarea #...]
Ejemplo malo:
“Bajé presupuesto.” Insuficiente: falta el por qué.
Relación con IBEX (política)
Frecuencia / actualización
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.