Map the flow before moving it
A setup may still collect data in the browser, send events to a server and forward them to destinations. Consent Mode communicates states and adapts some behavior; by itself it supplies neither a choice banner nor legal validation.
| Stage | Control | Evidence to seek |
|---|---|---|
| Browser or app | Collected fields and choices. | Requests actually sent. |
| Collection server | Validation, filtering and access. | Accepted or rejected events. |
| Destination | Data actually forwarded. | Payload and consent rules. |
| Operation | Retention, permissions and recovery. | Deletion, failure and access tests. |
Test what is actually transmitted
- Define allowed fields and recipients for each purpose. Inspect URLs, parameters, identifiers and logs before transmission; do not assume filtering exists by default.
- Test acceptance, refusal and changed choices end to end. Check browser, server-container and destination behavior.
- Reconcile received, accepted and forwarded events. Test duplicates, loss, failure and recovery, then measure server cost and load.
Assess benefits and obligations separately
Check performance on comparable journeys: initial browser collection may remain necessary. A first-party domain is not an exemption. In France, the exemption for certain audience-measurement tools is conditional and does not automatically cover advertising tagging.
Primary references
- 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 still needs flow testing
Moving tags to a server does not automatically make measurement compliant or minimal. Inspect emitted requests, recipients, identifiers and behavior after refusal in the actual deployment.
- Map browser, collection server, vendors and transmitted fields.
- Test before choice, after refusal and after consent withdrawal.
- Compare settings with declared purposes and relevant CNIL conditions.
Primary reference: CNIL — Outils de mesure d’audience et traceurs. Related method: read the practical guide.
Separate rate, budget and concurrency
A requests-per-minute limit may not protect an expensive operation. Define relevant units and exercise recovery with a bounded attempt budget.
- Unit, window, identity and route
- Response, delay and user message
- Attempt budget, duplicates and stopping
- Tested load, rejections and restoration
Acceptance case to reproduce
Fictional example: these inputs describe no customer or observed result.
View case inputs
{
"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
}
}Expected decision
Respect the 30-second wait; stagger the 20 workers and bound the retry budget.
Twenty clients: spread retries and count attempts
Fictional example: 20 workers each receive a 429 response at +0 s with Retry-After: 30. These times illustrate one possible distribution, without guaranteeing server capacity. Each worker has 3 retries in addition to its initial request.
| Policy | Calculation or schedule | What changes |
|---|---|---|
| Simultaneous retry | 20 × 1 = 20 @ +30 s | Waiting 30 seconds respects the delay, but all 20 requests return together: the burst can recur. |
| Distributed retry | 4 × 5 = 20 @ +30…+34 s | Four requests per second for five seconds spread the 20 retries without reducing their number. This illustrative schedule is not a substitute for a backoff policy with jitter. |
| Deadline at 25 seconds | 25 s < 30 s → 0 | If the remaining time is shorter than the required 30 seconds, stop or defer according to the contract. Do not shorten the delay to meet the deadline. |
| Maximum budget | 20 × (1 + 3) = 80 | If every attempt is used, 20 initial requests plus 60 retries make 80 requests overall. The cap guarantees neither success nor safe repetition. |
Verification procedure
- Record quota scope and retry budget.
- Exhaust the quota only in an authorized test.
- Keep 429, Retry-After and bounded retry chronology. Distinguish technical throttling from the business result: an exhausted quota should not become a response reporting zero stock.
- In a simulation without external load, count attempts across four layers each capped at three total calls.
- Expire a fictional queued task and verify it does not start as a new operation.
- Gradually restore authorized work after a simulated outage and retain calls, deadlines and unique business results.
Is HTTP 429 sufficient protection?
No. It describes rejection; cost, concurrency, queues and client behavior also require control.
Primary reference: IETF — RFC 6585, HTTP 429. Related method: read the practical guide.
Software carbon impact: define boundaries before comparing
Separate transferred volume, energy, emissions and delivered service to avoid unverified environmental gains.
Acceptance case to reproduce
Fictional example: these inputs describe no customer or observed result.
View case inputs
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Expected decision
The scenario gives (2 × 100 + 50)/100 = 2.5 gCO2e per task, within the declared boundary only.
Verification procedure
- Fix boundary, functional unit and factors.
- Separate energy, embodied emissions and accepted outcomes.
- Keep assumptions, provenance and calculations without implicit offsets.
Primary reference: Green Software Foundation — Software Carbon Intensity. Related method: read the practical guide.
APIs: prevent retries multiplying across layers
An application, SDK, proxy and service can each retry one call. In a fictional chain with four layers making three total attempts each, up to 81 calls reach the failing dependency. This method adds a shared budget and useful deadline to existing quota controls.
- Map application, SDK, proxy and dependencies with their automatic attempts. Choose the responsible layer and disable or coordinate extra retries under the contract. Count the initial attempt in the total budget. Retain the business operation ID and check uncertain effects before retrying a non-idempotent operation.
- Define an end-to-end deadline covering waiting, connection and processing, accounting for actual client limits. Reject expired tasks before queue admission. Local cancellation does not establish server termination: reconcile its state. Test gradual traffic recovery without restarting every queue simultaneously.
Do three attempts per layer mean three overall?
No. They can multiply. Four fictional layers with three total attempts each yield up to 3⁴ = 81 calls at the last dependency.
Does task expiry cancel its remote effect?
Not necessarily. It should prevent new obsolete work; a remote operation already started needs a state check and appropriate compensation if available.
Primary reference: AWS — Timeouts, retries, and backoff with jitter. Related method: read the practical guide.