Описать поток до переноса
Сбор может оставаться в браузере, затем идти на сервер и получателям. Consent Mode передаёт состояния и адаптирует поведение; сам он не даёт баннер выбора или юридическую проверку.
| Этап | Контроль | Нужное свидетельство |
|---|---|---|
| Браузер или приложение | Собранные поля и выбор. | Реально отправленные запросы. |
| Сервер сбора | Проверка, фильтрация и доступ. | Допущенные и отклонённые события. |
| Получатель | Реально переданные данные. | Содержимое и правила согласия. |
| Эксплуатация | Хранение, права и восстановление. | Проверки удаления, сбоя и доступа. |
Проверять реальную передачу
- Определите разрешённые поля и получателей по целям. Проверьте URL, параметры, идентификаторы и журналы до отправки; не предполагайте фильтрацию по умолчанию.
- Проверьте согласие, отказ и изменение выбора по всей цепочке. Изучите браузер, серверный контейнер и каждое назначение.
- Сверьте принятые, допущенные и пересланные события. Проверьте дубли, потери, сбой и восстановление, затем стоимость и нагрузку сервера.
Оценивать пользу и обязанности отдельно
Проверяйте скорость на сопоставимых путях; исходный сбор в браузере может остаться необходимым. Собственный домен не даёт исключения. Во Франции освобождение некоторых средств измерения аудитории условно и не охватывает автоматически рекламные теги.
Первоисточники
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
Серверная разметка тегов по-прежнему требует тестирования потока.
Перемещение тегов на сервер не делает автоматически измерения соответствующими требованиям или минимальными. Проверяйте отправленные запросы, получателей, идентификаторы и поведение после отказа в реальном развертывании.
- Сопоставление браузера, сервера сбора данных, поставщиков и передаваемых полей.
- Тестирование до выбора, после отказа и после отзыва согласия.
- Сравнение настроек с заявленными целями и соответствующими условиями CNIL.
Первичный источник: CNIL — Outils de mesure d’audience et traceurs. Связанный метод: прочитать практическое руководство.
Квоты и ограничения API
Ограничения влияют на ёмкость, повторы и распределение между клиентами.
- Запишите, относится ли квота к аккаунту, ключу или ресурсу, и сколько параллельных операций допускает клиент. Безграничная очередь может перегрузить сервис при невысокой средней частоте.
- При 429 учитывайте Retry-After, если он есть, и подождите перед следующим запросом. Совмещайте растущую задержку и рассредоточение клиентов с пределом попыток и общим сроком.
- После потери ответа на запись проверьте состояние до повтора. В имитации сочетайте квоты, поздние ответы и отмену: очередь должна завершиться без повторных эффектов.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"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
}
}Ожидаемое решение
Выдержите 30 секунд, распределите повторы 20 обработчиков и ограничьте их количество.
Двадцать клиентов: распределить и посчитать повторы
Вымышленный пример: 20 обработчиков в момент +0 s получают 429 с Retry-After: 30. Расписание показывает один вариант распределения, не гарантируя мощности сервера. У каждого есть 3 повтора помимо исходного запроса.
| Правило | Расчёт или расписание | Результат |
|---|---|---|
| Одновременный повтор | 20 × 1 = 20 @ +30 s | Ожидание 30 секунд соблюдает задержку, но все 20 запросов возвращаются вместе. Всплеск нагрузки может повториться. |
| Распределённый повтор | 4 × 5 = 20 @ +30…+34 s | Четыре запроса в секунду в течение пяти секунд распределяют 20 повторов, не уменьшая их число. Пример расписания не заменяет политику нарастающих задержек со случайным разбросом. |
| Срок 25 секунд | 25 s < 30 s → 0 | Если оставшееся время меньше требуемых 30 секунд, остановитесь или отложите запрос согласно контракту. Не сокращайте ожидание ради срока. |
| Максимальный бюджет | 20 × (1 + 3) = 80 | Все попытки дают 20 исходных запросов и 60 повторов: всего 80. Ограничение не гарантирует успеха или безопасного повторения. |
Процедура проверки
- Запишите область квоты и бюджет повторов.
- Исчерпайте квоту только в разрешённом тесте.
- Сохраните 429, Retry-After и ограниченную последовательность. Различайте техническое ограничение и результат операции: исчерпанную квоту нельзя превращать в сообщение о нулевом наличии.
- Симулируйте без внешней нагрузки четыре слоя по три общих вызова и посчитайте попытки.
- Просрочьте вымышленную задачу в очереди и проверьте отсутствие новой операции.
- Восстановите разрешённую работу постепенно после симулированного сбоя и сохраните вызовы, сроки и уникальные результаты.
Доказывает ли 429, что предыдущая запись не выполнилась?
Нет. Операция без ответа требует отдельной сверки; ответ на другую попытку не подтверждает её состояние.
Первичный источник: IETF — RFC 6585, HTTP 429. Связанный метод: прочитать практическое руководство.
Границы измерения углерода
Сравнение требует общих границ и функциональной единицы.
- Перечислите компоненты, регион, период и функциональную единицу, например завершённую операцию. Сравнивайте сценарии с одинаковой предоставленной услугой.
- Запишите энергию, коэффициент выбросов и выделенную долю оборудования. Различайте измерение и оценку; исключённый компонент не означает нулевой след.
- Вымышленный пример: (12 + 3) gCO2e / 5 операций = 3 gCO2e на операцию. Меняйте неопределённые допущения и сравнивайте суммарные выбросы.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Ожидаемое решение
(2 × 100 + 50)/100 = 2,5 г CO2e на задачу, только в заявленных границах.
Процедура проверки
- Определите границы, функциональную единицу и коэффициенты.
- Разделите энергию, воплощённые выбросы и результаты.
- Сохраните происхождение и расчёт без скрытых компенсаций.
Первичный источник: Green Software Foundation — Software Carbon Intensity. Связанный метод: прочитать практическое руководство.
API: не допускать умножения попыток между слоями
Приложение, SDK, прокси и сервис могут повторять один вызов. Четыре вымышленных слоя с тремя общими попытками каждый дают до 81 вызова неисправной зависимости. Добавьте общий бюджет и полезный срок к контролю квот.
- Опишите автоматические попытки приложения, SDK, прокси и зависимостей. Выберите ответственный слой и отключите или согласуйте дополнительные повторы. Считайте начальную попытку в бюджете. Сохраняйте ID операции и проверяйте неопределённые эффекты до неидемпотентного повтора.
- Задайте общий срок ожидания, соединения и обработки с реальными ограничениями клиента. Отклоните просроченные задачи до очереди. Локальная отмена не доказывает остановку сервера: сверяйте состояние. Восстанавливайте трафик постепенно без запуска всех очередей сразу.
Три попытки на слой означают три всего?
Нет. Четыре вымышленных слоя по три общие попытки дают до 3⁴ = 81 последнего вызова.
Истечение срока отменяет удалённый эффект?
Не обязательно. Оно предотвращает новую устаревшую работу; начатая операция требует проверки состояния и возможной компенсации.
Первичный источник: AWS — Timeouts, retries, and backoff with jitter. Связанный метод: прочитать практическое руководство.