Breng de stroom eerst in kaart
Verzameling in de browser kan blijven bestaan, gevolgd door server en bestemmingen. Consent Mode geeft toestanden door en past gedrag aan; het levert alleen geen keuzebanner of juridische validatie.
| Stap | Controle | Gezocht bewijs |
|---|---|---|
| Browser of app | Verzamelde velden en keuzes. | Echt verzonden verzoeken. |
| Verzamelserver | Validatie, filtering en toegang. | Geaccepteerde of geweigerde gebeurtenissen. |
| Bestemming | Werkelijk doorgestuurde gegevens. | Inhoud en toestemmingsregels. |
| Beheer | Bewaring, rechten en herstel. | Verwijder-, uitval- en toegangstests. |
Test wat echt wordt verstuurd
- Definieer toegestane velden en ontvangers per doel. Inspecteer URL’s, parameters, ID’s en logs vóór verzending; veronderstel geen standaardfiltering.
- Test toestemming, weigering en gewijzigde keuzes door de hele keten. Controleer browser, servercontainer en iedere bestemming.
- Vergelijk ontvangen, geaccepteerde en doorgestuurde gebeurtenissen. Test dubbelen, verlies, uitval en herstel; meet serverkosten en belasting.
Beoordeel voordelen en verplichtingen apart
Controleer prestaties op vergelijkbare routes; browserverzameling kan nog nodig zijn. Een eigen domein is geen vrijstelling. In Frankrijk is de vrijstelling voor bepaalde publieksmeting voorwaardelijk en geldt zij niet automatisch voor advertentietags.
Primaire bronnen
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
Server-side tagging vereist nog steeds flowtesten.
Het verplaatsen van tags naar een server maakt metingen niet automatisch conform of minimaal. Inspecteer verzonden verzoeken, ontvangers, identificatoren en gedrag na weigering in de daadwerkelijke implementatie.
- Breng browser, verzamelserver, leveranciers en verzonden velden in kaart.
- Test vóór de keuze, na weigering en na intrekking van toestemming.
- Vergelijk instellingen met de opgegeven doeleinden en relevante CNIL-voorwaarden.
Primaire bron: CNIL — Outils de mesure d’audience et traceurs. Verwante methode: lees de praktische gids.
API-quota en snelheidslimieten
Limieten beïnvloeden capaciteit, herhalingen en verdeling tussen klanten.
- Leg vast of het quotum account, sleutel of bron betreft en hoeveel parallelle handelingen de client toestaat. Een onbeperkte wachtrij kan ondanks een laag gemiddelde de dienst overbelasten.
- Lees bij 429 de eventuele Retry-After en wacht voor een nieuw verzoek. Combineer oplopende wachttijd en spreiding tussen clients met een poginglimiet en totale deadline.
- Controleer bij een verloren schrijfantwoord eerst de status. Combineer in gesimuleerde tests quota, late antwoorden en annulering; de wachtrij moet eindigen zonder dubbele effecten.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"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
}
}Verwachte beslissing
Wacht 30 seconden, spreid de 20 workers en begrens het aantal herhalingen.
Twintig clients: herhalingen spreiden en tellen
Fictief voorbeeld: 20 workers ontvangen bij +0 s ieder 429 met Retry-After: 30. De tijden tonen één mogelijke spreiding, zonder servercapaciteit te garanderen. Iedere worker heeft 3 herhalingen naast het eerste verzoek.
| Beleid | Berekening of tijdschema | Gevolg |
|---|---|---|
| Gelijktijdig herhalen | 20 × 1 = 20 @ +30 s | 30 seconden wachten respecteert de vertraging, maar alle 20 verzoeken keren tegelijk terug. De piek kan terugkomen. |
| Gespreid herhalen | 4 × 5 = 20 @ +30…+34 s | Vier verzoeken per seconde gedurende vijf seconden spreiden 20 herhalingen zonder het aantal te verminderen. Dit voorbeeldschema vervangt geen oplopende wachttijd met willekeurige spreiding. |
| Deadline op 25 seconden | 25 s < 30 s → 0 | Is de resterende tijd korter dan de vereiste 30 seconden, stop of stel uit volgens het contract. Verkort de wachttijd niet om de deadline te halen. |
| Maximaal budget | 20 × (1 + 3) = 80 | Alle pogingen gebruiken betekent 20 eerste verzoeken plus 60 herhalingen: 80 verzoeken. Het plafond garandeert geen succes of veilige herhaling. |
Verificatieprocedure
- Noteer quotabereik en herhalingsbudget.
- Put quota alleen uit in geautoriseerde tests.
- Bewaar 429, Retry-After en begrensde tijdlijn.
- Simuleer zonder externe belasting vier lagen van elk drie totale oproepen en tel pogingen.
- Laat een fictieve wachtrijtaak verlopen en controleer dat geen nieuwe operatie start.
- Herstel bevoegd werk geleidelijk na een gesimuleerde storing en bewaar oproepen, deadlines en unieke resultaten.
Bewijst 429 dat een eerdere schrijfactie niet is uitgevoerd?
Nee. De handeling zonder antwoord vereist eigen aansluiting; een antwoord op een andere poging bewijst haar status niet.
Primaire bron: IETF — RFC 6585, HTTP 429. Verwante methode: lees de praktische gids.
Grenzen van koolstofmeting
Een vergelijking vereist dezelfde grenzen en functionele eenheid.
- Noteer onderdelen, regio, periode en functionele eenheid, bijvoorbeeld een afgeronde handeling. Vergelijk scenario’s die dezelfde dienst leveren.
- Leg energie, emissiefactor en toegewezen hardwareaandeel vast. Scheid meting en schatting; noteer uitsluitingen zonder nulimpact aan te nemen.
- Fictief voorbeeld: (12 + 3) gCO2e / 5 handelingen = 3 gCO2e per handeling. Varieer onzekere aannames en vergelijk ook totale uitstoot.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Verwachte beslissing
(2 × 100 + 50)/100 = 2,5 gCO2e per taak, alleen binnen de aangegeven grens.
Verificatieprocedure
- Bepaal grens, functionele eenheid en factoren.
- Scheid energie, ingebedde uitstoot en resultaten.
- Bewaar herkomst en berekening zonder impliciete compensatie.
Primaire bron: Green Software Foundation — Software Carbon Intensity. Verwante methode: lees de praktische gids.
API’s: vermenigvuldigde pogingen tussen lagen voorkomen
Applicatie, SDK, proxy en dienst kunnen ieder dezelfde oproep herhalen. Vier fictieve lagen met elk drie totale pogingen leveren tot 81 oproepen aan de falende afhankelijkheid. Voeg gedeeld budget en bruikbare deadline toe aan quotacontroles.
- Breng automatische pogingen in applicatie, SDK, proxy en afhankelijkheden in kaart. Kies de verantwoordelijke laag en schakel extra pogingen uit of coördineer ze volgens contract. Tel de eerste poging mee. Bewaar operatie-ID en controleer onzekere effecten vóór een niet-idempotente herhaling.
- Bepaal een totale deadline voor wachten, verbinden en verwerken binnen echte clientgrenzen. Weiger verlopen taken vóór wachtrijtoelating. Lokale annulering bewijst geen serverstop: vergelijk de toestand. Herstel verkeer geleidelijk zonder alle wachtrijen tegelijk te starten.
Betekenen drie pogingen per laag drie in totaal?
Nee. Vier fictieve lagen met elk drie totale pogingen geven tot 3⁴ = 81 laatste oproepen.
Annuleert taakverloop het externe effect?
Niet noodzakelijk. Het voorkomt nieuw achterhaald werk; gestart extern werk vereist toestandcontrole en mogelijke compensatie.
Primaire bron: AWS — Timeouts, retries, and backoff with jitter. Verwante methode: lees de praktische gids.