Mapear antes de trasladar
Puede mantenerse recogida en el navegador, envío al servidor y reenvío a destinos. Consent Mode comunica estados y adapta comportamientos; no proporciona por sí solo una interfaz de elección ni validación jurídica.
| Etapa | Control | Evidencia buscada |
|---|---|---|
| Navegador o aplicación | Campos y decisiones recogidos. | Peticiones realmente emitidas. |
| Servidor de recogida | Validación, filtrado y acceso. | Eventos aceptados o rechazados. |
| Destino | Datos realmente reenviados. | Contenido y reglas de consentimiento. |
| Operación | Conservación, permisos y recuperación. | Pruebas de borrado, fallo y acceso. |
Probar lo que realmente se envía
- Defina campos y destinatarios permitidos por finalidad. Inspeccione URL, parámetros, identificadores y registros antes de transmitir; no suponga filtrado predeterminado.
- Pruebe aceptación, rechazo y cambios de decisión de extremo a extremo. Compruebe navegador, contenedor servidor y cada destino.
- Concilie eventos recibidos, aceptados y reenviados. Pruebe duplicados, pérdidas, fallos y recuperación; mida coste y carga del servidor.
Evaluar beneficios y obligaciones por separado
Compruebe rendimiento en recorridos comparables; puede seguir siendo necesaria recogida inicial en navegador. Un dominio propio no es una exención. En Francia, la exención de ciertas herramientas de audiencia es condicional y no cubre automáticamente el etiquetado publicitario.
Fuentes primarias
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
El etiquetado del lado del servidor aún requiere pruebas de flujo.
Mover etiquetas a un servidor no garantiza automáticamente que la medición cumpla con los requisitos mínimos. Inspeccionar las solicitudes emitidas, los destinatarios, los identificadores y el comportamiento tras el rechazo en la implementación real.
- Mapear el navegador, el servidor de recopilación, los proveedores y los campos transmitidos.
- Realizar pruebas antes de la elección, tras el rechazo y tras la revocación del consentimiento.
- Comparar la configuración con los fines declarados y las condiciones pertinentes de la CNIL.
Fuente primaria: CNIL — Outils de mesure d’audience et traceurs. Método relacionado: consultar la guía práctica.
Cuotas y límites de API
Los límites condicionan capacidad, reintentos y reparto entre clientes.
- Documente si la cuota se aplica a cuenta, clave o recurso y cuántas operaciones simultáneas permite el cliente. Una cola sin límite puede saturar el servicio aunque la frecuencia media parezca baja.
- Ante 429, interprete Retry-After cuando esté presente y espere antes de otra solicitud. Combine espera creciente y variación entre clientes con un máximo de intentos y un plazo total.
- Para una escritura con respuesta perdida, compruebe el estado antes de reintentar. En pruebas simuladas, mezcle límites, respuestas tardías y cancelación para verificar que la cola termina sin duplicar efectos.
Caso de aceptación reproducible
Ejemplo ficticio: estos datos no describen clientes ni resultados observados.
Ver datos del caso
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}Decisión esperada
Respete los 30 segundos, escalone los 20 trabajadores y limite los reintentos.
Veinte clientes: repartir reintentos y contar intentos
Ejemplo ficticio: 20 trabajadores reciben a +0 s una respuesta 429 con Retry-After: 30. Los horarios muestran una distribución posible, sin garantizar capacidad del servidor. Cada trabajador dispone de 3 reintentos además de su solicitud inicial.
| Política | Cálculo u horario | Qué cambia |
|---|---|---|
| Reintento simultáneo | 20 × 1 = 20 @ +30 s | Esperar 30 segundos respeta el plazo, pero las 20 solicitudes vuelven juntas y la ráfaga puede repetirse. |
| Reintento repartido | 4 × 5 = 20 @ +30…+34 s | Cuatro solicitudes por segundo durante cinco segundos reparten los 20 reintentos sin reducir su número. Este horario ilustrativo no sustituye una política de espera progresiva con variación aleatoria. |
| Plazo de 25 segundos | 25 s < 30 s → 0 | Si queda menos tiempo que los 30 segundos requeridos, detener o aplazar según el contrato. No acortar la espera para cumplir el plazo. |
| Presupuesto máximo | 20 × (1 + 3) = 80 | Usar todos los intentos supone 20 solicitudes iniciales y 60 reintentos: 80 solicitudes. El límite no garantiza éxito ni repetición segura. |
Procedimiento de verificación
- Registre cuota, alcance y presupuesto de reintentos.
- Agote la cuota en pruebas autorizadas.
- Conserve 429, Retry-After y secuencia limitada.
- Simula sin carga externa cuatro capas con tres llamadas totales cada una y cuenta intentos.
- Haz vencer una tarea ficticia en cola y comprueba que no inicia una operación nueva.
- Restaura trabajo autorizado gradualmente tras fallo simulado y conserva llamadas, plazos y resultados únicos.
¿429 garantiza que una escritura anterior no se realizó?
No. La operación cuya respuesta se perdió requiere una reconciliación independiente; no deduzca su estado de una respuesta de otro intento.
Fuente primaria: IETF — RFC 6585, HTTP 429. Método relacionado: consultar la guía práctica.
Límites de la medición de carbono
Una comparación necesita un perímetro y una unidad funcional comunes.
- Lista los componentes incluidos, la región, el periodo y la unidad funcional: por ejemplo, una operación completada. Compara escenarios con el mismo servicio prestado.
- Registra energía, factor de emisiones y parte asignada del hardware. Distingue mediciones y estimaciones; documenta las exclusiones en vez de suponer impacto cero.
- Ejemplo ficticio: (12 + 3) gCO2e / 5 operaciones = 3 gCO2e por operación. Cambia las hipótesis inciertas y compara también emisiones totales.
Caso de aceptación reproducible
Ejemplo ficticio: estos datos no describen clientes ni resultados observados.
Ver datos del caso
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Decisión esperada
(2 × 100 + 50)/100 = 2,5 gCO2e por tarea, solo en el perímetro declarado.
Procedimiento de verificación
- Fije perímetro, unidad funcional y factores.
- Separe energía, emisiones incorporadas y resultados.
- Conserve procedencia y cálculo sin compensación implícita.
Fuente primaria: Green Software Foundation — Software Carbon Intensity. Método relacionado: consultar la guía práctica.
API: evitar reintentos multiplicados entre capas
Aplicación, SDK, proxy y servicio pueden reintentar una llamada. En una cadena ficticia de cuatro capas con tres intentos totales cada una, hasta 81 llamadas llegan a la dependencia fallida. Añade presupuesto compartido y plazo útil a los controles de cuota.
- Mapea aplicación, SDK, proxy y dependencias con intentos automáticos. Elige la capa responsable y desactiva o coordina repeticiones adicionales según contrato. Cuenta el intento inicial en el presupuesto. Conserva el ID de operación y comprueba efectos inciertos antes de repetir acciones no idempotentes.
- Define plazo total incluyendo espera, conexión y proceso, según límites reales del cliente. Rechaza tareas vencidas antes de admitirlas en cola. Cancelar localmente no prueba parada del servidor: comprueba su estado. Recupera tráfico gradualmente sin reactivar todas las colas juntas.
¿Tres intentos por capa son tres en total?
No. Pueden multiplicarse: cuatro capas ficticias con tres intentos totales cada una dan hasta 3⁴ = 81 llamadas finales.
¿Vencer una tarea cancela su efecto remoto?
No necesariamente. Evita nuevo trabajo obsoleto; una operación remota iniciada necesita comprobar estado y compensar si es posible.
Fuente primaria: AWS — Timeouts, retries, and backoff with jitter. Método relacionado: consultar la guía práctica.