Vor der Verlagerung den Fluss erfassen
Eine Lösung kann weiter im Browser erfassen, zum Server senden und an Ziele weiterleiten. Consent Mode übermittelt Zustände und passt Verhalten an; er liefert allein weder Auswahlbanner noch rechtliche Prüfung.
| Stufe | Kontrolle | Gesuchter Nachweis |
|---|---|---|
| Browser oder App | Erfasste Felder und Auswahl. | Tatsächlich gesendete Anfragen. |
| Erfassungsserver | Validierung, Filterung und Zugriff. | Angenommene oder abgelehnte Ereignisse. |
| Ziel | Tatsächlich weitergeleitete Daten. | Nutzlast und Einwilligungsregeln. |
| Betrieb | Aufbewahrung, Rechte und Wiederaufnahme. | Lösch-, Ausfall- und Zugriffstests. |
Tatsächliche Übertragung testen
- Definieren Sie erlaubte Felder und Empfänger pro Zweck. Prüfen Sie URLs, Parameter, Kennungen und Protokolle vor der Übertragung; setzen Sie Filterung nicht voraus.
- Testen Sie Zustimmung, Ablehnung und geänderte Auswahl durchgehend. Prüfen Sie Browser, Servercontainer und jedes Ziel.
- Gleichen Sie empfangene, akzeptierte und weitergeleitete Ereignisse ab. Testen Sie Duplikate, Verluste, Ausfall und Wiederaufnahme sowie Serverkosten und Last.
Nutzen und Pflichten getrennt bewerten
Prüfen Sie Leistung auf vergleichbaren Abläufen; Browsererfassung kann weiter nötig sein. Eine eigene Domain ist keine Ausnahmegenehmigung. In Frankreich ist die Ausnahme für bestimmte Reichweitenmessung bedingt und deckt Werbetagging nicht automatisch ab.
Primärquellen
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
Serverseitiges Tagging erfordert weiterhin Ablauftests.
Das Verschieben von Tags auf einen Server führt nicht automatisch zu konformen oder minimalen Messungen. Gesendete Anfragen, Empfänger, Kennungen und Verhalten nach Ablehnung im tatsächlichen Einsatz prüfen.
- Browser, Erfassungsserver, Anbieter und übertragene Felder zuordnen.
- Vor der Auswahl, nach Ablehnung und nach Widerruf der Einwilligung testen.
- Einstellungen mit den angegebenen Zwecken und den relevanten CNIL-Bedingungen vergleichen.
Primärquelle: CNIL — Outils de mesure d’audience et traceurs. Verwandte Methode: den praktischen Leitfaden lesen.
API-Kontingente und Begrenzungen
Begrenzungen beeinflussen Kapazität, Wiederholungen und Kundentrennung.
- Klären Sie, ob das Kontingent Konto, Schlüssel oder Ressource betrifft und wie viele parallele Vorgänge der Client zulässt. Eine unbegrenzte Warteschlange kann trotz niedriger Durchschnittsrate überlasten.
- Bei 429 Retry-After auswerten, falls vorhanden, und vor der nächsten Anfrage warten. Steigende Wartezeiten und zeitliche Streuung zwischen Clients mit Versuchslimit und Gesamtdauer verbinden.
- Bei verlorener Schreibantwort den Zustand vor einer Wiederholung prüfen. In simulierten Tests Grenzen, späte Antworten und Abbruch kombinieren; die Warteschlange muss ohne doppelte Wirkungen enden.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"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
}
}Erwartete Entscheidung
30 Sekunden warten, die 20 Worker zeitlich verteilen und Wiederholungen begrenzen.
Zwanzig Clients: Wiederholungen verteilen und zählen
Fiktives Beispiel: 20 Worker erhalten bei +0 s jeweils 429 mit Retry-After: 30. Die Zeiten zeigen eine mögliche Verteilung, keine garantierte Serverkapazität. Jeder Worker hat zusätzlich zur ersten Anfrage 3 Wiederholungen.
| Strategie | Berechnung oder Zeitplan | Auswirkung |
|---|---|---|
| Gleichzeitige Wiederholung | 20 × 1 = 20 @ +30 s | 30 Sekunden Warten hält die Frist ein, doch alle 20 Anfragen kommen gleichzeitig zurück. Die Lastspitze kann erneut auftreten. |
| Verteilte Wiederholung | 4 × 5 = 20 @ +30…+34 s | Vier Anfragen pro Sekunde über fünf Sekunden verteilen 20 Wiederholungen, ohne deren Zahl zu senken. Der Beispielplan ersetzt keine Backoff-Strategie mit zufälliger Streuung. |
| Frist von 25 Sekunden | 25 s < 30 s → 0 | Ist die verbleibende Zeit kürzer als die geforderten 30 Sekunden, gemäß Vertrag stoppen oder verschieben. Die Wartezeit nicht zur Einhaltung der Frist verkürzen. |
| Maximales Budget | 20 × (1 + 3) = 80 | Bei vollständiger Nutzung ergeben 20 erste Anfragen plus 60 Wiederholungen insgesamt 80 Anfragen. Das Limit garantiert weder Erfolg noch gefahrloses Wiederholen. |
Prüfverfahren
- Quotenumfang und Wiederholungsbudget erfassen.
- Quota nur im autorisierten Test ausschöpfen.
- 429, Retry-After und begrenzte Wiederholungsfolge aufbewahren.
- Simuliere ohne externe Last vier Schichten mit je drei Gesamtaufrufen und zähle Versuche.
- Lass eine fiktive Warteschlangenaufgabe ablaufen und prüfe, dass kein neuer Vorgang beginnt.
- Stelle erlaubte Arbeit nach simuliertem Ausfall schrittweise wieder her und bewahre Aufrufe, Fristen und eindeutige Ergebnisse.
Beweist 429, dass ein früherer Schreibvorgang nicht ausgeführt wurde?
Nein. Die Operation mit verlorener Antwort muss getrennt abgeglichen werden; die Antwort eines anderen Versuchs belegt ihren Zustand nicht.
Primärquelle: IETF — RFC 6585, HTTP 429. Verwandte Methode: den praktischen Leitfaden lesen.
Grenzen der Kohlenstoffmessung
Vergleiche brauchen gleiche Systemgrenzen und eine gemeinsame funktionelle Einheit.
- Liste Komponenten, Region, Zeitraum und funktionelle Einheit auf, etwa einen abgeschlossenen Vorgang. Vergleiche Szenarien mit derselben erbrachten Leistung.
- Erfasse Energie, Emissionsfaktor und zugeordneten Hardwareanteil. Trenne Messung und Schätzung; dokumentiere Ausschlüsse statt Nullwirkung anzunehmen.
- Fiktives Beispiel: (12 + 3) gCO2e / 5 Vorgänge = 3 gCO2e je Vorgang. Variiere unsichere Annahmen und vergleiche auch Gesamtemissionen.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Erwartete Entscheidung
(2 × 100 + 50)/100 = 2,5 gCO2e je Aufgabe, nur innerhalb der angegebenen Grenze.
Prüfverfahren
- Grenze, funktionale Einheit und Faktoren festlegen.
- Energie, verkörperte Emissionen und Ergebnisse trennen.
- Herkunft und Rechnung ohne implizite Kompensation aufbewahren.
Primärquelle: Green Software Foundation — Software Carbon Intensity. Verwandte Methode: den praktischen Leitfaden lesen.
APIs: vervielfachte Wiederholungen zwischen Schichten vermeiden
Anwendung, SDK, Proxy und Dienst können denselben Aufruf wiederholen. Vier fiktive Schichten mit je drei Gesamtversuchen erzeugen bis zu 81 Aufrufe an der fehlerhaften Abhängigkeit. Ergänze Quoten um gemeinsames Budget und nutzbare Frist.
- Erfasse automatische Versuche in Anwendung, SDK, Proxy und Abhängigkeiten. Bestimme eine verantwortliche Schicht und deaktiviere oder koordiniere zusätzliche Wiederholungen nach Vertrag. Zähle den ersten Versuch ins Gesamtbudget. Bewahre Vorgangs-ID und prüfe ungewisse Wirkungen vor nicht idempotenter Wiederholung.
- Definiere Ende-zu-Ende-Frist für Warten, Verbindung und Verarbeitung unter tatsächlichen Clientgrenzen. Lehne abgelaufene Aufgaben vor Warteschlangenaufnahme ab. Lokaler Abbruch beweist keinen Serverstopp: gleiche Zustand ab. Teste schrittweise Rückkehr ohne gleichzeitigen Neustart aller Warteschlangen.
Sind drei Versuche je Schicht insgesamt drei?
Nein. Vier fiktive Schichten mit je drei Gesamtversuchen liefern bis zu 3⁴ = 81 letzte Aufrufe.
Stoppt Aufgabenablauf die Fernwirkung?
Nicht zwingend. Verhindere neue überholte Arbeit; laufende Fernoperationen brauchen Zustandsprüfung und mögliche Kompensation.
Primärquelle: AWS — Timeouts, retries, and backoff with jitter. Verwandte Methode: den praktischen Leitfaden lesen.