Un entorno de trabajo en el que el agente que se ocupa de tus campañas de Google Ads y Meta lee los informes, propone el cambio con el motivo escrito y ejecuta solo dentro de los límites que le has dado.
El servicio es una oferta, no una realización, y lo decimos primero: hoy no tenemos un sistema que cambie presupuestos o licitaciones en Google Ads o Meta. Tenemos construidas y ejecutadas las piezas con las que se hace uno — el envío de la señal de conversión real a Google, un motor que compra promoción pagada con dry-run activado por defecto, un registro que escribe cada acción que cuesta, y un interruptor que detiene un orchestrator sin ruta de desvío.
Oferta, con condiciones„offer”, nu „delivered”, și motivul se poate verifica în câteva secunde. Am căutat în peste 150 de depozite proprii câmpurile prin care API-urile de reclamă mișcă bani — `budget_micros`, `campaignBudget`, `target_cpa`, `target_roas`, `bid_strategy` — și nu apar nicăieri, nici la Google, nici la Meta. Nu gestionăm azi bugete de reclamă. Ce apare, și se poate deschide fișier cu fișier, sunt piesele care despart o automatizare de un accident: trimiterea conversiilor offline către Google prin Data Manager API, 264 de linii într-un proiect de producție al nostru; un motor de promovare plătită care cumpără boostere, etichete și pachete cu dry-run pornit implicit; un A/B tester bayesian care refuză să declare câștigător sub 100 de afișări per variantă, și orchestratorul de campanii din MEGA CRM cu întrerupător fără `--force`. Serviciul e descris din aceste piese. Nu dintr-un panou care nu există.
Un agente que se ocupa de campañas no es un botón que diga «optimiza». Es un programa que tiene permiso para leer ciertos informes, permiso para escribir ciertos campos y ningún otro permiso. La parte difícil no es proponer un cambio — los modelos hacen eso bien y rápido. La parte difícil es escribir dónde se detiene, cómo prueba lo que hizo, y qué pasa cuando se equivoca. De eso trata el trabajo, y desde ahí empezamos la discusión.
Decimos desde el principio lo que no tenemos, para que no lo sepas por otra persona. Hoy no ejecuta con nosotros un sistema que sube un presupuesto en Google Ads o que cambia una puja en Meta. Lo que sí ejecuta, y se puede mostrar línea por línea, son los mecanismos de seguridad que hemos escrito para otras automatizaciones que gastan dinero real: dry-run activado por defecto, contador por cada acción de pago, temporización ante error para que el fallo no se repita en bucle, umbral de prueba antes de una decisión, y un interruptor que se niega a arrancar el orquestador.
La pieza que ya tenemos construida no es un cambio de presupuesto, sino una señal — y es la que proponemos que se tome como punto de partida. Google aprende de lo que le dices que es una conversión. Si le dices «formulario enviado», buscará personas que envían formularios. Hemos escrito la integración que le dice «solicitud llegada realmente al sistema del cliente», con el identificador del clic y con identificadores de usuario pasados por SHA-256, mediante Data Manager API. Eso se puede empezar de inmediato, porque es código existente, no una promesa.
El resto del entorno de trabajo — la capa que lee informes, la capa que propone, la capa que ejecuta — se construye con el mismo patrón que hemos usado donde ya hemos gastado dinero mediante código. Se empieza estrictamente con lectura, se pasa a propuestas sin ejecución, y solo al final se abre la ejecución, campo por campo, con un límite escrito en cada uno.
Qué incluye
El trabajo, por componentes
Lee los informes, no el panel
Se define desde el principio qué lee el agente y de dónde: el gasto por campaña y por grupo de anuncios, las conversiones atribuidas, el coste por adquisición, la cuota de impresiones perdida por presupuesto frente a la perdida por posición — dos cifras distintas que requieren decisiones distintas. La lectura se hace por API, con una cuenta de servicio separada, no mediante capturas de pantalla de la interfaz. La capa de lectura se entrega y se pone en marcha primero, sola, sin ningún permiso de escritura sobre la cuenta.
Propone el cambio con el motivo escrito junto a él
Una propuesta no es una cifra. Es el campo que cambia, el valor anterior, el valor nuevo, la ventana de datos con la que se tomó la decisión, y el porqué. Las propuestas se reúnen en un informe que lee una persona, en la forma «subiría el presupuesto diario de la campaña X de A a B porque en los últimos N días estuvo limitada por presupuesto en M% de las pujas, con un coste por adquisición por debajo del umbral acordado». Si el motivo no se puede escribir, la propuesta no se hace.
Tres umbrales: lo que hace solo, lo que pide a una persona, lo que nunca hace
Cada campo entra en una de tres categorías, escritas antes de poner nada en marcha. Solo: cambios por debajo de un porcentaje acordado, dentro de un límite diario, en campañas marcadas como abiertas. Con aprobación: cualquier superación del límite, cualquier campaña nueva, cualquier público nuevo, cualquier modificación de puja. Nunca: detener una campaña que no arrancó él, cambiar el método de pago, tocar las cuentas de facturación. La lista se escribe en el contrato, no en el código, y el código la lee.
Dry-run activado por defecto — el patrón que traemos con nosotros
En nuestro motor de promoción de pago de 999.md, la función que decide si se gasta dinero está escrita al revés de como suele escribirse: dry-run está activo si la variable de entorno no tiene exactamente el valor `false`. Sin definir, vacía, `true`, escrita mal — todo mantiene dry-run activado. Es una elección deliberada: un error de configuración no puede abrir el grifo, solo puede mantenerlo cerrado. Esa misma función existe en dos lugares independientes, el motor de promoción y el ejecutor de republicación.
Cada acción que cuesta se escribe en un registro
En el sistema de promoción, toda ejecución entra en una tabla `agent_costs` con el anuncio, el usuario, el tipo de acción, la suma en lei, si tuvo éxito, la respuesta bruta del proveedor y una marca `dry_run`. La escritura se hace en la misma transacción que la actualización de la programación, así que no puede existir un gasto sin rastro ni un rastro sin gasto. Cuando es dry-run, la suma registrada es cero, pero la fila existe — se ve exactamente lo que habría pasado.
La señal de conversión real — la pieza que ya existe
Cuando alguien llega desde un clic de pago y envía una solicitud, la señal se envía a Google solo después de que la solicitud entra en el sistema del cliente, no al pulsar el botón. La integración usa `https://datamanager.googleapis.com/v1/events:ingest`, envía el identificador del clic, el momento, el valor y la moneda, más identificadores de usuario pasados por SHA-256 — la dirección normalizada en minúsculas, el teléfono llevado al formato internacional. Sin el identificador del clic, el envío se detiene solo y se marca como omitido, porque no sería atribuible.
El consentimiento se coloca antes de las etiquetas, no después
Consent Mode v2 se inicializa con todos los fines de marketing y análisis en `denied`, antes de que arranque cualquier script de Google, con una ventana de espera de 500 ms para la actualización. Se pasa a `granted` solo con la interacción de la persona con el banner, sin recargar la página. El almacenamiento funcional y el de seguridad siguen activos, porque sin ellos la página no funciona. Se escribe una vez y se ejecuta en cada visita.
La decisión entre dos variantes se toma con evidencia, no por impresión
El tester A/B que construimos modela cada variante como Beta-Binomial con prior uniforme y estima la probabilidad de que una sea mejor mediante 10.000 muestras Monte Carlo. No declara ganadora por debajo de 100 impresiones por variante y por debajo de una probabilidad de 0,95. Si a las 168 horas no se ha decidido, cierra el experimento y dice que expiró, en lugar de nombrar una ganadora que no puede sostener.
Un interruptor que no se puede eludir
El orquestador de campañas de nuestro sistema interno verifica una variable de entorno antes de cualquier cosa. Si está puesta, se niega a arrancar — no existe `--force`, no existe argumento que lo sobrepase. Se añadió después de un incidente real de envíos duplicados, no como decoración. Ese mismo patrón se aplica aquí: un conmutador a nivel de cuenta que detiene todas las escrituras, dejando la lectura y el reporte seguir adelante.
Qué aspecto tiene
El recorrido, paso a paso.
01
El inventario de cuentas y de derechos
Se enumeran las cuentas de anuncios, quién tiene acceso hoy y con qué rol, qué conversiones están definidas y cuáles de ellas son en realidad duplicados del mismo evento. Se establecen las tres listas de campos — solo, con aprobación, nunca. Entregamos: el inventario escrito, la lista de conversiones con lo que mide realmente cada una, y el acuerdo sobre las tres listas.
02
La capa de lectura, arrancada sola
Se conecta la lectura por API con una cuenta que no tiene derecho de escritura, y se pone en marcha el informe diario. Nada cambia en las cuentas en esta etapa — solo se ve lo que ve el agente. Es el momento en que salen a la luz las conversiones que contaban mal, las campañas limitadas por presupuesto sin que nadie lo supiera, y las audiencias que se solapan. Entregamos: el informe diario y la lista de lo que encontramos al leer.
03
La señal de conversión real
Se captura el identificador del clic en la página de aterrizaje, se vincula con la solicitud en vuestro sistema y se envía a Google solo cuando la solicitud se confirma en el flujo posterior, no al pulsar el botón. Se activa el reintento para los envíos fallidos, dentro de la ventana de 90 días. Entregamos: la integración funcional, un modo de verificación que envía sin registrar, y el registro con lo que salió y lo que se omitió y por qué.
04
La capa de propuestas, sin ejecución
El agente empieza a escribir propuestas: campo, valor antiguo, valor nuevo, motivo, ventana de datos. Nada se ejecuta. Se corre así hasta que las propuestas se vuelven aburridas — es decir, hasta que la persona que las lee habría pulsado de todos modos «sí» a casi todas. Entregamos: el flujo de propuestas, con todo lo que se propuso y lo que aprobasteis o rechazasteis, para que se vea dónde falla.
05
La apertura de la ejecución, campo por campo
Se abre la ejecución para el primer campo de la lista «solo», con dry-run activado por defecto y con límite diario. Se verifica en el registro que lo escrito es lo propuesto. Luego el segundo campo. Entregamos: el registro de acciones, el conmutador que detiene todas las escrituras dejando la lectura activa, y el procedimiento escrito para lo que se hace cuando el agente se ha equivocado.
Traseul unei decizii
Los datos
Qué tocamos, dónde están y cuánto se quedan
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Qué datos toca
Informes de campaña, grupo de anuncios y palabra clave leídos por API. El identificador de clic del anuncio, capturado desde la dirección de la página de aterrizaje y guardado en la solicitud del cliente. Eventos de conversión con momento, valor y moneda. A petición explícita, la dirección de email y el teléfono de la persona que convirtió, pero solo en forma de resumen criptográfico.
Qué sale hacia Google y en qué forma
El identificador del clic sale en claro — eso es, un identificador de clic. El email y el teléfono salen solo como SHA-256, calculado localmente antes del envío: el email limpiado de espacios y pasado a minúsculas, el teléfono llevado al formato internacional. La dirección postal no se envía en absoluto, porque el esquema de Google la pide completa con código postal y código de región, y el código postal no es consecuente en los datos reales — el motivo está escrito en el código, no supuesto.
Dónde están y quién los ve
Los datos de campaña y los eventos están en la base de vuestro proyecto, en la infraestructura convenida. Las credenciales de las cuentas de anuncios están en un archivo de entorno leído por el servicio del sistema, no en el código y no en el repositorio de fuentes. El token de acceso se guarda en memoria como máximo 55 minutos, aunque el proveedor lo da válido durante 3.600 segundos — el margen es intencionado, para no usar nunca uno caducado.
Cuánto tiempo puede seguir enviándose un evento
La ventana práctica es de 90 días desde el momento de la conversión — eso acepta Google para conversiones offline. El reintento de los envíos fallidos funciona exactamente en esta ventana, por lotes, con un máximo de cinco intentos por solicitud. Después de cinco intentos, la solicitud se deja en paz y queda marcada como no enviada, en lugar de reintentarse sin fin.
Qué no hacemos con los datos
No construimos públicos a partir de vuestras listas de clientes sin una base legal escrita y sin que aparezca en la información que ve la persona. No pasamos datos entre las cuentas de dos clientes distintos. No guardamos copias de los informes de campaña fuera del sistema convenido. El registro de tratamientos se completa antes del primer envío, no después.
Un caso
Una campaña que pagaba por formularios, no por solicitudes
La situación
Una plataforma de Chișinău que recibe solicitudes online compraba tráfico de búsqueda. La conversión definida en la cuenta de anuncios era «formulario enviado». El algoritmo de pujas hacía exactamente lo que se le pedía: traía gente que envía formularios. Cuántos de ellos se convertían en solicitudes reales, más adelante en la cadena, nunca volvía a la plataforma de anuncios.
Qué construimos
Movimos el momento de la conversión más tarde en la cadena. El identificador del clic se captura en la página de aterrizaje y se conserva en la solicitud. La solicitud sigue hacia el sistema aguas abajo; si este devuelve un identificador propio —es decir, si entró de verdad— solo entonces sale el evento hacia Google, mediante Data Manager API, con el momento, el valor, la moneda e identificadores de usuario pasados por SHA-256. Sin identificador de clic, el envío se detiene solo y se marca como omitido. Añadimos un job de reintento que busca las solicitudes con identificador de clic y sin marca de envío, en los últimos 90 días, en lotes de 50, con un máximo de cinco intentos.
Qué salió
La señal que recibe la plataforma de anuncios ahora describe las solicitudes que llegan a destino, no las pulsaciones de botón. Todas las operaciones son inertes si la integración no está configurada o está detenida — la función verifica las siete credenciales antes de cualquier cosa, y devuelve «omitido» si falta una. Los errores se registran, pero no se propagan: si Google no responde, la solicitud del cliente sigue adelante intacta.
Qué no dice el caso
Esta es una integración de señal, no de gestión de campaña. No cambia ningún presupuesto ni ninguna puja. El efecto sobre el coste por adquisición no ha sido medido por nosotros y no lo publicamos — en el código existe una espera escrita por el autor, no una medición, y entre las dos está toda la diferencia.
Preguntas
Lo que nos pregunta la gente antes de llamar
¿Quién asume la responsabilidad cuando el agente aumenta un presupuesto y el gasto sube?
Vosotros. Y por eso el entorno está construido para que podáis asumir la responsabilidad con conocimiento de causa, no para sorprenderos. Concretamente: el agente no tiene ningún permiso de escritura que alguien no le haya dado por nombre, por escrito, campo por campo; cada campo abierto tiene un techo por encima del cual la propuesta va a aprobación humana; cada acción ejecutada se escribe en un registro con el valor viejo, el valor nuevo y el motivo, en la misma transacción que la ejecución; y existe un interruptor que detiene todas las escrituras sin detener la lectura. Nosotros respondemos por lo que hemos construido — que los límites que habéis escrito se respetan por el código, que el registro está completo, que la parada funciona. No respondemos por el resultado comercial de un cambio que vosotros aprobasteis, igual que tampoco responde la agencia que pulsa el botón manual. Si alguien os promete otra cosa, preguntadle qué pone en el contrato en el capítulo de limitación de responsabilidad.
¿Tenéis hoy un sistema que gestione campañas de Google Ads o Meta?
No. En ninguna parte de nuestro código aparece algún campo mediante el cual se cambie un presupuesto, una puja o una estrategia de puja en Google o en Meta. Verificamos buscando exactamente esos nombres de campo en todos los repositorios. Lo que tenemos es el envío de conversiones a Google, un motor que compra promoción de pago en otra plataforma, y los mecanismos de seguridad a su alrededor. El servicio se construye partiendo de ahí, y está marcado como oferta precisamente para que no haya confusión.
Entonces, ¿qué es exactamente lo que ya han construido y consume dinero real?
Nuestro motor de promoción de pago de una plataforma de anuncios clasificados de Moldavia. Añade etiquetas de pago, inicia boosters con límite diario y precio por clic, activa paquetes y republica anuncios después de un intervalo calculado a partir de la velocidad real de la categoría. Rechaza iniciar un booster cuyo límite diario no sea mayor que el precio por clic — una verificación pequeña, pero justo el tipo de verificación que suele faltar. Cada acción pasa por la verificación de dry-run antes de cualquier llamada que cueste.
¿Qué puede cambiar por sí solo y qué requiere aprobación?
Se decide juntos, de antemano, y se escribe. Nuestro punto de partida en la discusión: por sí solo — ajustes inferiores a un porcentaje acordado del presupuesto diario, dentro de un tope diario absoluto, en las campañas que ustedes hayan marcado como abiertas; con aprobación — cualquier superación del tope, campañas nuevas, públicos nuevos, cualquier modificación de las pujas; nunca — detener campañas iniciadas por otra persona, métodos de pago, cuentas de facturación. Si al principio quieren todo con aprobación, es una opción válida y nosotros la preferimos.
¿Cómo sabe el agente que una conversión es real y no un formulario vacío?
Porque la señal no se envía al pulsar el botón. Sale solo cuando la solicitud se confirma aguas abajo, en el sistema que os importa a ustedes — un identificador de solicitud devuelto por el CRM o por el socio. Hasta entonces no ha ocurrido nada que merezca llamarse conversión. La diferencia no es cosmética: el algoritmo de pujas de Google aprende de lo que le envías, así que si le envías formularios, te traerá personas que completan formularios.
¿Qué pasa con los datos personales de quienes convierten?
El correo electrónico y el teléfono se envían solo como resumen criptográfico SHA-256, calculado localmente antes del envío, con normalización — correo sin espacios y en minúsculas, teléfono llevado al formato internacional. La dirección postal no se envía en absoluto. Nada se envía antes de que la persona haya aceptado la finalidad de marketing en el banner, porque Consent Mode arranca por completo en `denied`. La base legal y la información se redactan antes del primer envío, no después de la primera pregunta de alguien.
¿Qué pasa si la llamada a la plataforma de anuncios falla a mitad de camino?
Se registra el fallo con la respuesta bruta, y la acción se aplaza — en nuestro executor de republicación, con el máximo entre el enfriamiento configurado y cinco minutos, de forma explícita para que un error no se convierta en un bucle de llamadas. Los envíos de conversiones fallidos se reintentan mediante un job separado, en lotes de 50, con como máximo cinco intentos por solicitud, dentro de la ventana de 90 días. Después del quinto intento se detiene y queda marcado como no enviado, para que se vea, no para que desaparezca.
¿Cómo lo detengo, por completo y rápido?
El interruptor de escritura. La lectura y la notificación continúan, la ejecución se detiene. En nuestros sistemas existentes esto está implementado de dos formas, ambas verificables: una variable de entorno que debe tener exactamente el valor `false` para que se gaste dinero — cualquier otra cosa mantiene el grifo cerrado — y un interruptor en el orquestador de campañas que rechaza el inicio y no tiene `--force`. No dependemos de un botón en una interfaz que puede no cargarse.
¿Me garantizan una reducción del coste por adquisición?
No, y vale la pena decir por qué, porque en nuestro código existe exactamente una cifra así. En el comentario del encabezado de la integración de conversiones aparece una expectativa: cuánto podría bajar el coste por adquisición y cuánto podría subir la cuota de impresiones. Es una expectativa escrita por quien la construyó, no una medición, y por eso no la encontrarás en ningún lugar de este sitio como resultado. Lo que podemos prometerte es que la medición podrá hacerse: con conversiones que significan algo y con un registro de cada cambio, la comparación antes-después se vuelve posible. Sin ellas, no.
En qué se basan las afirmaciones anteriores (20 fuentes)
20 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.