Mappare prima di spostare
Può restare raccolta nel browser, invio al server e inoltro ai destinatari. Consent Mode comunica stati e adatta comportamenti; da solo non fornisce banner di scelta o validazione giuridica.
| Fase | Controllo | Prova cercata |
|---|---|---|
| Browser o app | Campi e scelte raccolti. | Richieste realmente inviate. |
| Server di raccolta | Validazione, filtri e accesso. | Eventi accettati o rifiutati. |
| Destinazione | Dati effettivamente inoltrati. | Contenuto e regole del consenso. |
| Gestione | Conservazione, permessi e recupero. | Test di eliminazione, guasto e accesso. |
Testare ciò che viene davvero inviato
- Definite campi e destinatari consentiti per finalità. Ispezionate URL, parametri, identificatori e registri prima dell’invio; non presumete filtri predefiniti.
- Testate accettazione, rifiuto e cambi di scelta lungo l’intera catena. Verificate browser, contenitore server e ogni destinazione.
- Riconciliate eventi ricevuti, accettati e inoltrati. Testate duplicati, perdite, guasti e recupero; misurate costi e carico del server.
Valutare separatamente benefici e obblighi
Verificate prestazioni su percorsi confrontabili; può servire ancora raccolta iniziale nel browser. Un dominio proprietario non è un’esenzione. In Francia l’esenzione per alcuni strumenti di misurazione del pubblico è condizionata e non copre automaticamente tag pubblicitari.
Fonti primarie
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
L'etichettatura lato server necessita ancora di test di flusso.
Lo spostamento dei tag su un server non rende automaticamente la misurazione conforme o minima. Ispezionare le richieste emesse, i destinatari, gli identificatori e il comportamento dopo il rifiuto nell'implementazione effettiva.
- Mappare browser, server di raccolta, fornitori e campi trasmessi.
- Eseguire test prima della scelta, dopo il rifiuto e dopo la revoca del consenso.
- Confrontare le impostazioni con gli scopi dichiarati e le condizioni pertinenti della CNIL.
Fonte primaria: CNIL — Outils de mesure d’audience et traceurs. Metodo correlato: consultare la guida pratica.
Quote e limiti delle API
I limiti condizionano capacità, ritentativi e distribuzione tra clienti.
- Documenta se la quota riguarda account, chiave o risorsa e quante operazioni parallele ammette il client. Una coda illimitata può sovraccaricare il servizio anche con una frequenza media bassa.
- Con 429 interpreta Retry-After, se presente, e attendi prima di un’altra richiesta. Combina attese crescenti e variazione tra client con un massimo di tentativi e una scadenza complessiva.
- Per una scrittura con risposta persa verifica lo stato prima di ripetere. Nei test simulati combina limiti, risposte tardive e annullamento: la coda deve terminare senza duplicare effetti.
Caso di accettazione riproducibile
Esempio fittizio: questi dati non descrivono clienti o risultati osservati.
Vedi dati 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
}
}Decisione attesa
Rispetta 30 secondi, scagliona i 20 worker e limita i tentativi.
Venti client: distribuire e contare i tentativi
Esempio immaginario: 20 worker ricevono a +0 s una risposta 429 con Retry-After: 30. Gli orari mostrano una possibile distribuzione, senza garantire capacità del server. Ogni worker ha 3 nuovi tentativi oltre alla richiesta iniziale.
| Politica | Calcolo o orario | Effetto |
|---|---|---|
| Ripresa simultanea | 20 × 1 = 20 @ +30 s | Attendere 30 secondi rispetta il ritardo, ma le 20 richieste tornano insieme: il picco può ripetersi. |
| Ripresa distribuita | 4 × 5 = 20 @ +30…+34 s | Quattro richieste al secondo per cinque secondi distribuiscono i 20 tentativi senza ridurne il numero. Questo orario illustrativo non sostituisce una politica di attesa progressiva con variazione casuale. |
| Scadenza a 25 secondi | 25 s < 30 s → 0 | Se il tempo residuo è inferiore ai 30 secondi richiesti, fermare o rinviare secondo il contratto. Non abbreviare l’attesa per rispettare la scadenza. |
| Budget massimo | 20 × (1 + 3) = 80 | Usando tutti i tentativi, 20 richieste iniziali più 60 ripetizioni fanno 80 richieste. Il limite non garantisce successo né ripetizioni prive di effetti indesiderati. |
Procedura di verifica
- Registra quota, ambito e budget dei tentativi.
- Esaurisci la quota solo in prove autorizzate.
- Conserva 429, Retry-After e sequenza limitata.
- Simula senza carico esterno quattro livelli da tre chiamate totali e conta i tentativi.
- Fai scadere un’attività fittizia in coda e verifica che non avvii un’operazione nuova.
- Ripristina lavoro autorizzato gradualmente dopo un guasto simulato e conserva chiamate, scadenze e risultati unici.
429 dimostra che una scrittura precedente non è avvenuta?
No. L’operazione con risposta persa richiede una riconciliazione separata; la risposta di un altro tentativo non ne dimostra lo stato.
Fonte primaria: IETF — RFC 6585, HTTP 429. Metodo correlato: consultare la guida pratica.
Perimetro della misura del carbonio
Un confronto necessita di confini e unità funzionali comuni.
- Elenca componenti, regione, periodo e unità funzionale, per esempio un’operazione completata. Confronta scenari con lo stesso servizio reso.
- Registra energia, fattore emissivo e quota dell’hardware. Distingui misure e stime; documenta esclusioni senza assumere impatto nullo.
- Esempio fittizio: (12 + 3) gCO2e / 5 operazioni = 3 gCO2e per operazione. Varia ipotesi incerte e confronta anche emissioni totali.
Caso di accettazione riproducibile
Esempio fittizio: questi dati non descrivono clienti o risultati osservati.
Vedi dati 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
}Decisione attesa
(2 × 100 + 50)/100 = 2,5 gCO2e per attività, solo nel perimetro dichiarato.
Procedura di verifica
- Fissa perimetro, unità funzionale e fattori.
- Separa energia, emissioni incorporate e risultati.
- Conserva provenienza e calcolo senza compensazione implicita.
Fonte primaria: Green Software Foundation — Software Carbon Intensity. Metodo correlato: consultare la guida pratica.
API: evitare tentativi moltiplicati tra livelli
Applicazione, SDK, proxy e servizio possono ripetere la stessa chiamata. Quattro livelli fittizi con tre tentativi totali ciascuno producono fino a 81 chiamate alla dipendenza guasta. Aggiungi budget condiviso e scadenza utile ai controlli di quota.
- Mappa applicazione, SDK, proxy e dipendenze con tentativi automatici. Scegli il livello responsabile e disattiva o coordina ripetizioni extra secondo contratto. Conta il tentativo iniziale nel budget. Conserva ID e verifica effetti incerti prima di ripetere operazioni non idempotenti.
- Definisci scadenza complessiva per attesa, connessione ed elaborazione secondo limiti del client. Rifiuta attività scadute prima della coda. Annullare localmente non prova arresto del server: riconcilia stato. Ripristina traffico gradualmente senza riavviare tutte le code insieme.
Tre tentativi per livello significano tre totali?
No. Quattro livelli fittizi con tre tentativi ciascuno danno fino a 3⁴ = 81 chiamate finali.
La scadenza annulla l’effetto remoto?
Non sempre. Impedisce nuovo lavoro obsoleto; un’operazione remota avviata richiede controllo dello stato e compensazione se possibile.
Fonte primaria: AWS — Timeouts, retries, and backoff with jitter. Metodo correlato: consultare la guida pratica.