Mapear antes de mudar
Pode manter-se recolha no navegador, envio ao servidor e reencaminhamento a destinos. Consent Mode comunica estados e adapta comportamentos; não fornece sozinho um painel de escolha ou validação jurídica.
| Etapa | Controlo | Prova procurada |
|---|---|---|
| Navegador ou aplicação | Campos e escolhas recolhidos. | Pedidos realmente emitidos. |
| Servidor de recolha | Validação, filtragem e acesso. | Eventos aceites ou rejeitados. |
| Destino | Dados efetivamente enviados. | Conteúdo e regras de consentimento. |
| Operação | Conservação, permissões e recuperação. | Testes de eliminação, falha e acesso. |
Testar o que é realmente enviado
- Defina campos e destinatários permitidos por finalidade. Inspecione URL, parâmetros, identificadores e registos antes de transmitir; não presuma filtragem predefinida.
- Teste aceitação, recusa e mudanças de escolha de ponta a ponta. Verifique navegador, contentor servidor e cada destino.
- Reconcilie eventos recebidos, aceites e enviados. Teste duplicados, perdas, falhas e recuperação; meça custo e carga do servidor.
Avaliar benefícios e obrigações separadamente
Verifique desempenho em percursos comparáveis; a recolha inicial no navegador pode continuar necessária. Um domínio próprio não é uma isenção. Em França, a isenção para certas ferramentas de audiência é condicional e não abrange automaticamente etiquetas publicitárias.
Fontes primárias
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
A marcação no servidor ainda precisa de testes de fluxo.
Mover tags para um servidor não torna automaticamente a medição compatível ou mínima. Inspecione as solicitações emitidas, os destinatários, os identificadores e o comportamento após a recusa na implementação real.
- Mapeie o navegador, o servidor de coleta, os fornecedores e os campos transmitidos.
- Teste antes da escolha, após a recusa e após a retirada do consentimento.
- Compare as configurações com as finalidades declaradas e as condições relevantes da CNIL.
Fonte primária: CNIL — Outils de mesure d’audience et traceurs. Método relacionado: consultar o guia prático.
Quotas e limites de API
Os limites afetam capacidade, novas tentativas e distribuição entre clientes.
- Documente se a quota se aplica a conta, chave ou recurso e quantas operações paralelas o cliente admite. Uma fila ilimitada pode saturar o serviço mesmo com uma frequência média baixa.
- Perante 429 interprete Retry-After, quando presente, e espere antes de outra chamada. Combine espera crescente e variação entre clientes com limite de tentativas e prazo total.
- Numa escrita com resposta perdida, verifique o estado antes de repetir. Em testes simulados combine quotas, respostas tardias e cancelamento; a fila deve terminar sem duplicar efeitos.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do 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
}
}Decisão esperada
Respeite 30 segundos, escalone os 20 trabalhadores e limite novas tentativas.
Vinte clientes: distribuir e contar tentativas
Exemplo fictício: 20 trabalhadores recebem a +0 s uma resposta 429 com Retry-After: 30. Os horários mostram uma distribuição possível, sem garantir capacidade do servidor. Cada trabalhador tem 3 novas tentativas além da solicitação inicial.
| Política | Cálculo ou horário | Efeito |
|---|---|---|
| Retomada simultânea | 20 × 1 = 20 @ +30 s | Esperar 30 segundos respeita o prazo, mas as 20 solicitações retornam juntas: a rajada pode se repetir. |
| Retomada distribuída | 4 × 5 = 20 @ +30…+34 s | Quatro solicitações por segundo durante cinco segundos distribuem as 20 tentativas sem reduzir sua quantidade. O horário ilustrativo não substitui uma política de espera progressiva com variação aleatória. |
| Prazo de 25 segundos | 25 s < 30 s → 0 | Se o tempo restante for inferior aos 30 segundos exigidos, parar ou adiar conforme o contrato. Não encurtar a espera para cumprir o prazo. |
| Orçamento máximo | 20 × (1 + 3) = 80 | Usar todas as tentativas resulta em 20 solicitações iniciais mais 60 repetições: 80 solicitações. O limite não garante sucesso nem repetição segura. |
Procedimento de verificação
- Registe quota, âmbito e orçamento de tentativas.
- Esgote a quota só em testes autorizados.
- Conserve 429, Retry-After e sequência limitada.
- Simule sem carga externa quatro camadas com três chamadas totais cada e conte tentativas.
- Faça expirar uma tarefa fictícia em fila e verifique ausência de nova operação.
- Reponha trabalho autorizado gradualmente após falha simulada e guarde chamadas, prazos e resultados únicos.
429 prova que uma escrita anterior não aconteceu?
Não. A operação sem resposta precisa de reconciliação independente; a resposta de outra tentativa não demonstra o seu estado.
Fonte primária: IETF — RFC 6585, HTTP 429. Método relacionado: consultar o guia prático.
Limites da medição de carbono
Comparações precisam de fronteiras e unidade funcional comuns.
- Liste componentes, região, período e unidade funcional, por exemplo uma operação concluída. Compare cenários com o mesmo serviço prestado.
- Registe energia, fator de emissões e parcela do hardware. Distinga medição e estimativa; documente exclusões sem assumir impacto nulo.
- Exemplo fictício: (12 + 3) gCO2e / 5 operações = 3 gCO2e por operação. Varie hipóteses incertas e compare também emissões totais.
Caso de aceitação reproduzível
Exemplo fictício: estes dados não descrevem clientes nem resultados observados.
Ver dados do 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
}Decisão esperada
(2 × 100 + 50)/100 = 2,5 gCO2e por tarefa, apenas no perímetro declarado.
Procedimento de verificação
- Fixe perímetro, unidade funcional e fatores.
- Separe energia, emissões incorporadas e resultados.
- Conserve origem e cálculo sem compensação implícita.
Fonte primária: Green Software Foundation — Software Carbon Intensity. Método relacionado: consultar o guia prático.
API: evitar tentativas multiplicadas entre camadas
Aplicação, SDK, proxy e serviço podem repetir a chamada. Quatro camadas fictícias com três tentativas totais cada produzem até 81 chamadas à dependência em falha. Acrescente orçamento partilhado e prazo útil aos controlos de quota.
- Mapeie aplicação, SDK, proxy e dependências com tentativas automáticas. Escolha a camada responsável e desative ou coordene repetições adicionais pelo contrato. Conte a tentativa inicial no orçamento. Guarde ID e verifique efeitos incertos antes de repetir operações não idempotentes.
- Defina prazo global para espera, ligação e processamento segundo limites reais do cliente. Rejeite tarefas expiradas antes de entrar em fila. Cancelar localmente não prova paragem do servidor: reconcilie estado. Recupere tráfego gradualmente sem reativar todas as filas juntas.
Três tentativas por camada são três no total?
Não. Quatro camadas fictícias com três tentativas totais cada dão até 3⁴ = 81 chamadas finais.
Expirar uma tarefa anula o efeito remoto?
Não necessariamente. Evita trabalho novo obsoleto; operação remota iniciada precisa de verificação e compensação se possível.
Fonte primária: AWS — Timeouts, retries, and backoff with jitter. Método relacionado: consultar o guia prático.