Kartoita ennen siirtoa
Keruu voi jatkua selaimessa, sitten palvelimella ja vastaanottajilla. Consent Mode välittää tiloja ja muuttaa käyttäytymistä; se ei yksin tarjoa valintabanneria tai oikeudellista arviointia.
| Vaihe | Tarkistus | Etsittävä todiste |
|---|---|---|
| Selain tai sovellus | Kerätyt kentät ja valinnat. | Todella lähetetyt pyynnöt. |
| Keruupalvelin | Validointi, suodatus ja pääsy. | Hyväksytyt tai hylätyt tapahtumat. |
| Kohde | Todella välitetyt tiedot. | Sisältö ja suostumussäännöt. |
| Ylläpito | Säilytys, oikeudet ja palautuminen. | Poisto-, vika- ja pääsytestit. |
Testaa todella lähetetyt tiedot
- Määritä sallitut kentät ja vastaanottajat tarkoituksittain. Tarkasta osoitteet, parametrit, tunnisteet ja lokit ennen lähetystä; älä oleta oletussuodatusta.
- Testaa hyväksyntä, kieltäytyminen ja valinnan muutos koko ketjussa. Tarkista selain, palvelinsäiliö ja jokainen kohde.
- Täsmäytä vastaanotetut, hyväksytyt ja välitetyt tapahtumat. Testaa kaksoiskappaleet, hävikki, vika ja palautuminen sekä palvelimen kulut ja kuorma.
Arvioi hyödyt ja velvoitteet erikseen
Tarkista suorituskyky vastaavilla poluilla; selainkeruu voi yhä olla tarpeen. Oma verkkotunnus ei ole poikkeus. Ranskassa tiettyjen yleisömittausten vapautus on ehdollinen eikä kata mainostagien käyttöä automaattisesti.
Alkuperäiset lähteet
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
Palvelinpuolen tunnisteiden käyttö vaatii edelleen virtaustestausta.
Tunnisteiden siirtäminen palvelimelle ei automaattisesti tee mittauksista vaatimustenmukaisia tai minimaalisia. Tarkasta lähetetyt pyynnöt, vastaanottajat, tunnisteet ja toiminta kieltäytymisen jälkeen varsinaisessa käyttöönotossa.
- Karttaselain, kokoelmapalvelin, toimittajat ja lähetetyt kentät.
- Testaa ennen valintaa, kieltäytymisen jälkeen ja suostumuksen peruuttamisen jälkeen.
- Vertaa asetuksia ilmoitettuihin tarkoituksiin ja asiaankuuluviin CNIL-ehtoihin.
Ensisijainen lähde: CNIL — Outils de mesure d’audience et traceurs. Aiheeseen liittyvä menetelmä: lue käytännön opas.
API-kiintiöt ja rajoitukset
Rajoitukset vaikuttavat kapasiteettiin, uusintoihin ja asiakkaiden väliseen jakoon.
- Kirjaa koskeeko kiintiö tiliä, avainta vai resurssia ja montako rinnakkaista tointa asiakas sallii. Rajaton jono voi ylikuormittaa palvelun, vaikka keskimääräinen pyyntötiheys on matala.
- Tulkitse 429-vastauksen Retry-After, jos se annetaan, ja odota ennen uutta pyyntöä. Yhdistä kasvava odotus ja asiakkaiden ajallinen hajautus yritysrajaan ja kokonaisaikarajaan.
- Jos kirjoituksen vastaus puuttuu, tarkista tila ennen uusintaa. Yhdistä simuloidussa testissä kiintiöt, myöhäiset vastaukset ja peruutus; jonon on päätyttävä ilman toistuvia vaikutuksia.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"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
}
}Odotettu päätös
Odota 30 sekuntia, porrasta 20 työntekijää ja rajaa uudelleenyritykset.
Kaksikymmentä asiakasta: porrasta ja laske yritykset
Kuvitteellinen esimerkki: 20 työntekijää saa hetkellä +0 s vastauksen 429 ja Retry-After: 30. Ajat kuvaavat yhtä mahdollista jakoa, eivät taattua palvelinkapasiteettia. Jokaisella on ensimmäisen pyynnön lisäksi 3 uusintaa.
| Käytäntö | Laskelma tai aikataulu | Vaikutus |
|---|---|---|
| Samanaikainen uusinta | 20 × 1 = 20 @ +30 s | 30 sekunnin odotus noudattaa viivettä, mutta kaikki 20 pyyntöä palaavat yhdessä. Kuormapiikki voi toistua. |
| Porrastettu uusinta | 4 × 5 = 20 @ +30…+34 s | Neljä pyyntöä sekunnissa viiden sekunnin ajan jakaa 20 uusintaa vähentämättä niiden määrää. Esimerkkiaikataulu ei korvaa satunnaisesti hajautettua, kasvavaa odotuskäytäntöä. |
| Määräaika 25 sekuntia | 25 s < 30 s → 0 | Jos aikaa on vähemmän kuin vaaditut 30 sekuntia, lopeta tai siirrä sopimuksen mukaan. Älä lyhennä odotusta määräajan takia. |
| Enimmäisbudjetti | 20 × (1 + 3) = 80 | Kaikkien yritysten käyttö tuottaa 20 ensimmäistä pyyntöä ja 60 uusintaa eli 80 pyyntöä. Raja ei takaa onnistumista tai turvallista toistoa. |
Tarkistusmenettely
- Kirjaa kiintiö, rajaus ja yritysbudjetti.
- Kuluta kiintiö vain luvallisessa testissä.
- Säilytä 429, Retry-After ja rajattu aikajana. Erota tekninen rajoitus liiketoimintatuloksesta: täyttynyttä kiintiötä ei pidä muuttaa nollasaatavuutta ilmoittavaksi vastaukseksi.
- Simuloi ilman ulkoista kuormaa neljää kerrosta, joissa on kolme kokonaiskutsua, ja laske yritykset.
- Anna kuvitteellisen jonotehtävän vanhentua ja varmista, ettei uusi toiminto ala.
- Palauta valtuutettu työ vähitellen simuloidun vian jälkeen ja säilytä kutsut, määräajat ja yksilölliset tulokset.
Todistaako 429, ettei aiempi kirjoitus tapahtunut?
Ei. Vastausta vaille jäänyt toimi on täsmäytettävä erikseen; toisen yrityksen vastaus ei osoita sen tilaa.
Ensisijainen lähde: IETF — RFC 6585, HTTP 429. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Hiilimittauksen rajat
Vertailu tarvitsee yhteiset järjestelmärajat ja toiminnallisen yksikön.
- Luettele osat, alue, ajanjakso ja toiminnallinen yksikkö, esimerkiksi valmis tapahtuma. Vertaa samaa palvelua tuottavia vaihtoehtoja.
- Kirjaa energia, päästökerroin ja laitteiston kohdistettu osuus. Erota mittaus arviosta; kuvaa poissulut olettamatta niiden vaikutusta nollaksi.
- Kuvitteellinen esimerkki: (12 + 3) gCO2e / 5 tapahtumaa = 3 gCO2e tapahtumaa kohti. Vaihtele epävarmoja oletuksia ja vertaa myös kokonaispäästöjä.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Odotettu päätös
(2 × 100 + 50)/100 = 2,5 gCO2e tehtävää kohti, vain ilmoitetulla rajauksella.
Tarkistusmenettely
- Määritä rajaus, toiminnallinen yksikkö ja kertoimet.
- Erota energia, laitteistopäästöt ja tulokset.
- Säilytä alkuperä ja laskelma ilman piilokompensaatiota.
Ensisijainen lähde: Green Software Foundation — Software Carbon Intensity. Aiheeseen liittyvä menetelmä: lue käytännön opas.
API: estä kerrosten kertautuvat uusintayritykset
Sovellus, SDK, välityspalvelin ja palvelu voivat kukin uusia kutsun. Neljä kuvitteellista kerrosta, joissa on kolme kokonaisyritystä kussakin, tuottavat enintään 81 kutsua vialliselle riippuvuudelle. Lisää yhteinen budjetti ja hyödyllinen määräaika kiintiöihin.
- Kartoita sovellus, SDK, välityspalvelin ja riippuvuuksien automaattiset yritykset. Valitse vastuukerros ja poista tai koordinoi lisäyritykset sopimuksen mukaan. Laske ensimmäinen yritys budjettiin. Säilytä toiminnon tunniste ja tarkista epävarmat vaikutukset ennen ei-idempotenttia uusintaa.
- Määritä kokonaismääräaika odotukselle, yhteydelle ja käsittelylle asiakkaan todellisin rajoituksin. Hylkää vanhentunut tehtävä ennen jonoon pääsyä. Paikallinen peruutus ei todista palvelimen pysähtyneen: täsmäytä tila. Palauta liikenne vähitellen ilman kaikkien jonojen yhtäaikaista käynnistystä.
Tarkoittaako kolme yritystä per kerros kolmea yhteensä?
Ei. Neljä kuvitteellista kerrosta ja kolme kokonaisyritystä tuottavat enintään 3⁴ = 81 viimeistä kutsua.
Peruuttaako määräaika ulkoisen vaikutuksen?
Ei välttämättä. Se estää uutta turhaa työtä; aloitettu etätoiminto tarvitsee tilatarkistuksen ja mahdollisen kompensaation.
Ensisijainen lähde: AWS — Timeouts, retries, and backoff with jitter. Aiheeseen liittyvä menetelmä: lue käytännön opas.