SABSUS / ADVERTISING GUIDESABSUS / РУКОВОДСТВО ПО РЕКЛАМЕ
How to accept advertising measurement with evidenceКак принять измерение рекламы по проверяемым данным
Define business events, consent states and evidence across browser, server and partner paths. Test duplicates, delivery and reconciled totals before reporting.Словарь событий, состояния согласия и доказательства для браузера, сервера и партнёров. Проверьте дубли, доставку и сверку итогов до использования отчётов.
What this guide helps you checkЧто поможет проверить эта инструкция
Before using conversion reports to move an advertising budget, agree what each event means and ask for evidence that the configured systems preserve that meaning. A useful acceptance record connects a business fact, the permitted measurement path and the result visible at its destination.
This guide is for the business owner accepting the work and the implementer producing the evidence. The example is a fictional home-cleaning company: a visitor requests a quotation, the company records an agreed job, and a payment is confirmed. All identifiers, amounts and test cases below are illustrative. No customer results or completed tests are reported.
Use the landing page launch checklist for the page and form experience. For ChatGPT-specific event choices and launch requirements, use the ChatGPT Ads conversion checklist. Here, the deliverable is a shared event dictionary and a test evidence matrix across systems.
Прежде чем перераспределять рекламный бюджет по отчёту о конверсиях, договоритесь о смысле каждого события и потребуйте подтверждение, что настроенные системы сохраняют этот смысл. Полезный протокол приёмки связывает факт в работе бизнеса, разрешённый маршрут измерения и результат в системе-получателе.
Это руководство для владельца, который принимает работу, и специалиста, который готовит доказательства. Пример — вымышленная компания по уборке домов: посетитель запрашивает расчёт, компания фиксирует согласованный заказ на работы, затем подтверждается оплата. Все идентификаторы, суммы и тестовые случаи условные. Здесь нет результатов клиентов или отчёта о выполненных тестах.
Для проверки страницы и формы используйте чек-лист посадочной страницы. Выбор событий и требования запуска именно ChatGPT Ads разобраны в руководстве по конверсиям ChatGPT Ads. Задача этой статьи — общий словарь событий и матрица доказательств для нескольких систем.
1. Define the acceptance record before testing1. Заведите протокол до начала тестов
Create one record for the configuration being accepted. Give it a version, date, site or application, environment, receiving property or account, implementer and business approver. List the browser tags, server integrations and partners included. Record exclusions explicitly, such as telephone enquiries entered manually.
Attach the dictionary, configuration evidence, test matrix and reconciliation notes. Each test needs an expected result, observed result, evidence reference and status: passed, failed, blocked or untested. Leave the observed result empty until somebody checks it. A vendor's feature description cannot fill that field.
Define the decision this evidence will support. “Use confirmed payments in the weekly acquisition report” is testable. “Tracking works” leaves the event, destination and use unspecified. A path may pass collection checks while its advertising attribution remains unverified; approve only the use that the evidence supports.
Создайте один протокол для принимаемой конфигурации. Укажите версию, дату, сайт или приложение, среду, ресурс или аккаунт получателя, исполнителя и ответственного со стороны бизнеса. Перечислите браузерные теги, серверные интеграции и партнёрские подключения, которые входят в проверку. Явно отметьте исключения, например обращения по телефону, внесённые вручную.
Приложите словарь, подтверждения настроек, матрицу тестов и результаты сверки. Для каждого случая нужны ожидаемый результат, наблюдаемый результат, ссылка на доказательство и статус: пройден, ошибка, заблокирован или не проверен. Поле наблюдаемого результата остаётся пустым до проверки. Описание функции поставщиком не заменяет это поле.
Определите решение, для которого собираете доказательства. «Использовать подтверждённые оплаты в еженедельном отчёте о привлечении» можно проверить. В формулировке «аналитика работает» не определены событие, получатель и назначение. Сбор событий может пройти проверку, пока рекламная атрибуция остаётся неподтверждённой. Принимайте только то использование, которое подтверждено.
2. Give each business event a precise boundary2. Задайте точную границу каждого бизнес-события
Start with facts the cleaning company can retrieve from its operational records. Choose an authoritative system for each fact. The following names describe the example's internal dictionary; they are not a universal platform vocabulary.
| Business event | It exists when | Source of truth | Counting unit |
|---|---|---|---|
| Submission attempted | A send action starts | Form diagnostic record | One attempt |
| Quotation request accepted | The server durably stores an accepted enquiry | Lead record | One accepted enquiry |
| Job agreed | Approved scope and acceptance are recorded | Job or CRM record | One agreed job |
| Payment confirmed | The payment is verified and recorded against the order | Final order and payment ledger | One defined purchase transaction |
| Refund confirmed | A verified refund is recorded | Refund ledger linked to the order | One refund operation |
A button click cannot establish an accepted enquiry. An enquiry cannot establish that the job was agreed, and a payment-page visit cannot establish payment. Define cancellation, reopening and corrections too: changing a job's notes should not create another “job agreed” event.
Map each business meaning separately. GA4 provides generate_lead, purchase and refund with defined parameters. The accepted-enquiry boundary here is the business's chosen design. GA4 event reference
For every dictionary entry, add the trigger, record owner, allowed fields, permitted destinations and mapping version. Keep an agreed job as an operational event if no suitable destination mapping has been implemented. Do not silently call it a payment to obtain a familiar report.
For this example, one fully paid order is one purchase. Deposits or instalments need a separately agreed mapping; sending the full order value for every instalment would overstate sales.
Начните с фактов, которые компания по уборке может найти в рабочих записях. Для каждого выберите авторитетный источник. Следующие названия относятся к внутреннему словарю примера; это не универсальные имена событий рекламных платформ.
| Бизнес-событие | Когда оно произошло | Источник истины | Единица учёта |
|---|---|---|---|
| Попытка отправки | Началось действие отправки | Диагностическая запись формы | Одна попытка |
| Запрос расчёта принят | Сервер надёжно сохранил принятое обращение | Карточка лида | Одно принятое обращение |
| Работы согласованы | Зафиксированы утверждённый объём и согласие заказчика | Заказ на работы или CRM | Один согласованный заказ |
| Оплата подтверждена | Платёж проверен и записан по заказу | Финальный заказ и платёжный журнал | Одна определённая покупка |
| Возврат подтверждён | Проверенный возврат записан | Журнал возвратов со ссылкой на заказ | Одна операция возврата |
Нажатие кнопки не подтверждает принятие обращения. Обращение не подтверждает согласование работ, а просмотр страницы оплаты не подтверждает платёж. Опишите отмену, повторное открытие и исправления: изменение примечания к заказу не должно создавать ещё одно событие «работы согласованы».
Сопоставляйте каждый бизнес-факт отдельно. GA4 предлагает generate_lead, purchase и refund с заданными параметрами. Граница «принятое обращение» в этом примере выбрана самим бизнесом. Справочник событий GA4
Для каждой строки добавьте триггер, владельца записи, разрешённые поля, получателей и версию сопоставления. Согласованные работы могут оставаться только операционным событием, если подходящая передача ещё не реализована. Не называйте их оплатой ради привычного отчёта.
В этом примере один полностью оплаченный заказ — одна покупка. Предоплата и оплата частями требуют отдельного согласованного сопоставления: передача полной стоимости заказа для каждого взноса завысит продажи.
Fictional home-cleaning example
- Attempt: Sending started
- Enquiry: Server accepted it
- Job: Work was agreed
- Payment: Payment confirmed
Each later fact needs its own evidence. Progression is not guaranteed.
Учебный пример компании по уборке
- Попытка: Отправка началась
- Обращение: Сервер принял запрос
- Заказ: Работы согласованы
- Оплата: Платёж подтверждён
Каждый следующий факт требует своего подтверждения. Переход не гарантирован.
3. Separate business identity, event identity and retries3. Разделите идентификаторы объекта, события и попытки
Use distinct identifiers for distinct jobs:
- A business ID identifies the enquiry, job or order
- An event ID identifies one occurrence, such as that order's confirmed payment
- An attempt ID identifies one delivery attempt of that event
- An idempotency key, where supported, controls repetition of a specific business operation
In the example, payment event evt-test-pay-07 belongs to order ord-test-07. A delivery retry retains that event identity and gets another attempt ID. A later refund gets its own event identity and a reference to the original order. None of these IDs contains a name, email address or street address.
Two enquiries from the same person may be separate business requests. Conversely, two network submissions may be retries of one operation. Define that distinction and test the application's behaviour. Preventing duplicate analytics delivery cannot establish that the form itself creates only one lead.
Provider rules need separate evidence. TikTok's overlapping Pixel and Events API copies require the corresponding event name and event_id to meet its deduplication rules. This does not make a shared identifier a universal rule for other providers. TikTok event deduplication
GA4's transaction_id helps prevent duplicate purchases; it is not a general idempotency contract for arbitrary events. Record which destination field, event type and documented rule the implementation uses. GA4 purchase reference
У разных идентификаторов разные задачи:
- ID бизнес-объекта обозначает обращение, работы или заказ
- ID события обозначает отдельный факт, например подтверждённую оплату этого заказа
- ID попытки обозначает конкретную попытку доставки события
- Ключ идемпотентности, если он поддерживается, управляет повтором определённой бизнес-операции
В примере событие оплаты evt-test-pay-07 относится к заказу ord-test-07. Повтор доставки сохраняет идентичность события и получает новый ID попытки. Позднейший возврат получает собственный ID события и ссылку на исходный заказ. Эти идентификаторы не содержат имя, email или адрес дома.
Два обращения одного человека могут быть самостоятельными запросами. Две сетевые отправки, напротив, могут повторять одну операцию. Зафиксируйте различие и проверьте поведение приложения. Устранение дублей в аналитике не доказывает, что форма создаёт только один лид.
Правила получателей проверяются отдельно. Для пересекающихся копий TikTok Pixel и Events API нужны соответствующие имя события и event_id с соблюдением правил дедупликации TikTok. Общий идентификатор не становится универсальным механизмом других платформ. Дедупликация событий TikTok
В GA4 transaction_id помогает избежать повторного учёта покупок, но не задаёт общую идемпотентность произвольных событий. Запишите поле получателя, тип события и документированное правило, которое использует реализация. Покупки в GA4
4. Fix the meaning of time, value and units4. Закрепите смысл времени, суммы и единиц
Record the business occurrence time separately from queue time, delivery time and destination observation time. Use an explicit timezone or UTC offset. State which timestamp assigns an event to a reporting day; otherwise a late evening payment and next-morning delivery can appear to disagree.
The internal schema should specify data types, allowed values, required fields, handling of missing fields and version. A useful payment test includes the order reference, event reference, occurrence time, amount basis, currency, item quantity and consent evidence reference. Do not copy the whole CRM record into the payload.
In a fictional test, an internal amount of 12,000 euro cents becomes 120.00 EUR at a destination expecting major currency units. Decide explicitly whether that amount represents service value, tax, fees or the total collected. Keep currencies separate unless the report declares its exchange-rate source and conversion date.
For GA4 purchase mapping, follow its definition of value, tax and shipping, and supply currency when value is supplied. Do not equate every payment-ledger total with the purchase value field. GA4 purchase parameters
Measurement Protocol's timestamp_micros uses microseconds. Include a test for the actual timestamp conversion, including delayed delivery. Measurement Protocol reference
Храните время бизнес-факта отдельно от постановки в очередь, отправки и появления результата у получателя. Используйте явный часовой пояс или смещение UTC. Укажите, по какому времени событие относится к отчётному дню. Иначе вечерняя оплата и утренняя доставка будут выглядеть как расхождение.
Во внутренней схеме нужны типы данных, допустимые значения, обязательные поля, обработка отсутствующих полей и версия. Полезный тест оплаты содержит ссылки на заказ и событие, время факта, основу суммы, валюту, количество услуг и ссылку на подтверждение согласия. Не копируйте в отправку всю карточку CRM.
В условном тесте внутренняя сумма 12 000 евроцентов преобразуется в 120,00 EUR для получателя, который ожидает основные денежные единицы. Явно решите, обозначает ли сумма стоимость услуги, налог, комиссии или всё полученное. Валюты учитывайте отдельно, если отчёт не определяет источник курса и дату пересчёта.
При передаче покупки в GA4 соблюдайте определения стоимости, налога и доставки; вместе со стоимостью передавайте валюту. Не приравнивайте любой итог платёжного журнала к полю стоимости покупки. Параметры покупки GA4
Поле timestamp_micros Measurement Protocol использует микросекунды. Добавьте тест фактического преобразования времени, включая отложенную доставку. Справочник Measurement Protocol
5. Test consent by purpose and transition5. Проверьте цели и переходы согласия
Keep processing the quotation request, analytics, advertising data use and marketing subscription as separate purposes. Document the applicable configuration and business-approved requirements for each. This is an implementation acceptance guide, not a legal assessment or a guarantee of compliance.
Use these four states in the internal record. They are test states, not four interchangeable values accepted by every platform API.
| Internal state | Meaning | Evidence to collect |
|---|---|---|
| Unknown | No recorded choice for the purpose | Initial defaults and actual outgoing requests |
| Denied | The purpose was refused | Effective settings and observed restricted behaviour |
| Granted | A choice allowing the purpose is recorded | Choice time, version and enabled destination path |
| Withdrawn | A previous grant was later revoked | Transition time and behaviour after the change |
Unknown must not be silently turned into granted. Withdrawal requires its own test: exercise a later page, a new event and any waiting server delivery. Decide what happens to queued work under the current configuration; an old grant must not automatically justify every later transmission. Record any retention or deletion requirements separately with the responsible owner.
Google distinguishes analytics storage, advertising storage, advertising user data and personalization. Basic and advanced consent mode have different transmission behaviour: advanced mode can send cookieless measurements while storage consent is denied. A banner screenshot alone therefore cannot establish what was sent. Google consent mode overview
For the fictional acceptance exercise, choose a documented policy that gates the tested analytics path until grant. This is an example configuration, not a claim about every installation. Verify state updates where choices change and before navigation; record the observed outcome. Google consent implementation guidance
Разделяйте обработку запроса расчёта, аналитику, использование данных для рекламы и маркетинговую подписку. Для каждой цели зафиксируйте применимые настройки и утверждённые бизнесом требования. Это руководство по технической приёмке, а не юридическая оценка или гарантия соблюдения законодательства.
Используйте во внутреннем протоколе четыре состояния. Это состояния теста, а не четыре взаимозаменяемых значения для API любой платформы.
| Внутреннее состояние | Значение | Что подтвердить |
|---|---|---|
| Unknown: выбор неизвестен | Для цели нет записанного решения | Исходные настройки и реальные исходящие запросы |
| Denied: отказ | Пользователь отказал в этой цели | Действующие настройки и наблюдаемые ограничения |
| Granted: согласие | Разрешающий выбор записан | Время, версия выбора и включённый маршрут |
| Withdrawn: отзыв | Ранее выданное согласие отозвано | Время перехода и последующее поведение |
Не превращайте неизвестный выбор в согласие незаметно. Для отзыва нужен отдельный тест: следующая страница, новое событие и ожидающая серверная отправка. Определите судьбу очереди с учётом актуальной конфигурации. Старое согласие не должно автоматически оправдывать любую последующую передачу. Требования хранения и удаления фиксируйте отдельно с ответственным.
Google различает хранение для аналитики, рекламное хранение, рекламные пользовательские данные и персонализацию. Базовый и расширенный consent mode передают данные по-разному: расширенный режим может отправлять измерения без cookie при отказе в хранении. Поэтому скриншот баннера не доказывает состав передачи. Обзор Google consent mode
Для учебной приёмки выберите документированную политику, которая блокирует проверяемый маршрут аналитики до согласия. Это конфигурация примера, а не утверждение о каждой установке. Проверьте обновление состояния при смене выбора и до перехода на другую страницу; запишите наблюдение. Реализация Google consent mode
6. Inventory every browser, server and partner path6. Перечислите браузерные, серверные и партнёрские маршруты
Make a route register: destination account, sending component, event mapping, trigger, consent decision, duplicate rule and evidence owner. Include installed partner integrations and custom tags. A second plugin can send the same purchase even when the custom implementation looks correct.
For each business event, decide which path sends it. If multiple paths intentionally send copies, compare their meaning, business reference, deduplication fields, amount, currency and occurrence time. Browser and server envelopes may differ; the underlying business fact should agree.
Test the active combination as well as individual paths. Disabling a browser tag temporarily can help isolate a server route in a controlled environment. Restore and retest the intended configuration before accepting it. Record partner-controlled fields you cannot inspect as an evidence gap, with an owner and next step.
Server delivery also needs a permitted purpose and a configuration check. Moving an event out of the browser does not itself establish permission, recover missing consent or prove attribution.
Составьте реестр маршрутов: аккаунт получателя, отправляющий компонент, сопоставление события, триггер, решение о согласии, правило дублей и ответственный за доказательства. Включите партнёрские интеграции и собственные теги. Дополнительный модуль может отправлять ту же покупку, даже если ваш код выглядит правильно.
Для каждого бизнес-события решите, какой маршрут его передаёт. Если несколько маршрутов намеренно отправляют копии, сравните смысл, ссылку на бизнес-объект, поля дедупликации, сумму, валюту и время факта. Структура браузерной и серверной отправки может различаться; лежащий в основе факт должен совпадать.
Проверяйте рабочую комбинацию вместе с отдельными маршрутами. Временное отключение браузерного тега в контролируемой среде помогает изолировать серверный путь. До приёмки восстановите и повторно проверьте нужную конфигурацию. Недоступные для проверки партнёрские поля отметьте как пробел в доказательствах, назначьте ответственного и следующий шаг.
Для серверной передачи также нужны разрешённая цель и проверка настроек. Перенос события из браузера сам по себе не устанавливает разрешение, не восстанавливает отсутствующее согласие и не подтверждает атрибуцию.
7. Distinguish receipt, processing and attribution7. Различайте получение, обработку и атрибуцию
Keep four evidence levels separate:
- The authoritative record proves the business fact
- The outbound record shows the permitted payload and intended destination
- Destination validation or event diagnostics shows what was accepted or processed
- A named report shows whether and how the event was counted or attributed
A screenshot at one level does not fill the others. For GA4 Measurement Protocol, HTTP 2xx confirms receipt of the HTTP request; malformed or unprocessed payloads may still receive that response. Measurement Protocol transport
Use the GA4 validation endpoint to check structure, then verify the intended destination independently. Validation requests do not populate reports, and validation does not verify every credential. Google event validation
For report evidence, save the property/account, report name, date basis, filters, extraction time and relevant attribution settings. Use “not yet observed” while a result is pending. An event can be processed without receiving advertising credit. Do not label receipt “attributed revenue”.
Храните четыре уровня доказательств отдельно:
- Авторитетная рабочая запись подтверждает бизнес-факт
- Исходящая запись показывает разрешённые данные и адресата
- Валидация или диагностика получателя показывает принятие либо обработку
- Конкретный отчёт показывает учёт события или его атрибуцию
Скриншот одного уровня не заменяет остальные. В GA4 Measurement Protocol HTTP 2xx подтверждает получение HTTP-запроса; такой ответ возможен и для некорректных или необработанных данных. Транспорт Measurement Protocol
Проверьте структуру через валидатор GA4, затем независимо проверьте нужного получателя. Запросы в валидатор не попадают в отчёты; валидатор также не проверяет все реквизиты доступа. Проверка событий Google
В подтверждении отчёта сохраните ресурс или аккаунт, название отчёта, основу даты, фильтры, время выгрузки и существенные настройки атрибуции. Пока результат ожидается, пишите «пока не наблюдается». Обработанное событие может не получить рекламную атрибуцию. Не называйте получение запроса «выручкой от рекламы».
Keep every missing level visible
- Fact: Business record
- Sent: Payload and destination
- Processed: Destination diagnostics
- Reported: Counting and attribution
A transport response proves only its own level. Report use needs separate evidence.
Не закрывайте пропущенный уровень догадкой
- Факт: Запись бизнеса
- Отправка: Данные и получатель
- Обработка: Диагностика системы
- Отчёт: Учёт и атрибуция
Ответ транспорта подтверждает только свой уровень. Для отчёта нужны отдельные доказательства.
8. Run a synthetic evidence matrix8. Пройдите матрицу на синтетических данных
Use a sandbox or isolated test configuration where possible. Use synthetic records, neutral service codes and opaque test IDs; avoid real customer details and real charges. Confirm that any necessary report test is isolated from bidding and ordinary business reporting. A fixture test proves the tested path, not a live monetary lifecycle.
Inspect outgoing event fields, URLs and page titles. Google warns that these can carry PII accidentally, including information entered in forms. Keep contact details and free text out of ordinary Analytics events. Google Analytics PII guidance
For campaign source fields and their preservation through URL changes, use the paired UTM and source preservation guide.
This matrix specifies expected evidence. Add actual observations and links when executing it; no row below represents a completed test.
| Case | Expected operational result | Measurement evidence required |
|---|---|---|
| Accepted enquiry, grant recorded | One retrievable accepted test enquiry | Correct mapped event, destination and consent state |
| Rejected enquiry | No accepted lead from that attempt | No accepted-enquiry event |
| No choice, then refusal | Request processing follows its separate rules | Tested analytics path remains gated under the example policy |
| Grant, then withdrawal | Business record remains identifiable internally | Later events and queued work follow updated settings |
| Retry after lost response | Status is resolved against the original operation | No invented new event identity to conceal uncertainty |
| Same event through two paths | One underlying business occurrence | Provider-specific duplicate handling demonstrated |
| Two legitimate new requests | Two records if the business accepts both | Distinct occurrences preserved |
| Confirmed payment and later refund | Separate verified ledger changes | Correct linked references, values, currency and event mappings |
| Delayed event or wrong units | Original business time and amount remain intact | Valid conversion or explicit rejection with an explanation |
| Preview and wrong destination | Test scope remains identifiable | No accidental production event; account mismatch blocks acceptance |
For each row, attach a sanitized operational reference, payload sample, relevant response or diagnostic, and report evidence when required. Store detailed logs with limited access and a defined retention period. Do not place secrets or customer records in a shared acceptance document.
По возможности используйте тестовую среду или изолированную конфигурацию. Создавайте синтетические записи, нейтральные коды услуг и произвольные тестовые ID; обходите реальные клиентские данные и списания. Убедитесь, что необходимый тест отчёта изолирован от ставок и обычной отчётности бизнеса. Тест на заготовленных данных доказывает проверенный путь, а не реальный денежный цикл.
Осмотрите исходящие поля, URL и заголовки страниц. Google предупреждает, что через них могут случайно передаваться персональные идентифицирующие сведения, включая введённое в формы. Контакты и свободный текст должны оставаться вне обычных событий Analytics. Рекомендации Google Analytics по PII
Поля источника кампании и их сохранение при изменении URL разобраны в парном руководстве по UTM и сохранению источника.
Матрица задаёт ожидаемые доказательства. Реальные наблюдения и ссылки добавляют при выполнении; ни одна строка ниже не означает пройденный тест.
| Случай | Ожидаемый результат в работе бизнеса | Нужное подтверждение измерения |
|---|---|---|
| Обращение принято, согласие записано | Одно доступное принятое тестовое обращение | Верные событие, получатель и состояние согласия |
| Обращение отклонено | Эта попытка не создала принятый лид | Нет события принятого обращения |
| Нет выбора, затем отказ | Обработка обращения следует отдельным правилам | Маршрут аналитики заблокирован по политике примера |
| Согласие, затем отзыв | Бизнес-запись остаётся различимой внутри системы | Последующие события и очередь следуют новым настройкам |
| Повтор после потери ответа | Выяснен статус исходной операции | Не создан новый ID события ради сокрытия неопределённости |
| Одно событие по двум маршрутам | Один исходный бизнес-факт | Доказана обработка дублей именно этим получателем |
| Два самостоятельных новых запроса | Две записи, если бизнес принял оба | Сохранены отдельные события |
| Подтверждённая оплата, затем возврат | Раздельные проверенные изменения журнала | Верные связи, суммы, валюта и сопоставления |
| Задержка или неправильные единицы | Сохранены исходные время и сумма | Верное преобразование либо явное отклонение с причиной |
| Предпросмотр и неверный получатель | Область теста различима | Нет случайного рабочего события; чужой аккаунт блокирует приёмку |
К каждой строке приложите очищенную ссылку на рабочую запись, пример отправки, ответ или диагностику и, если требуется, подтверждение отчёта. Подробные журналы храните с ограниченным доступом и сроком хранения. Секретам и карточкам клиентов не место в общем протоколе.
9. Give errors and unknown outcomes different actions9. Назначьте разные действия для ошибок и неизвестного результата
Classify failures before retrying. A rejected field needs correction. A permission or destination mismatch needs configuration repair. A timeout may mean the receiver processed the operation but the response was lost. Record that as unknown until evidence resolves it.
Maintain attempt history with the event reference, attempt time, outcome, error category and next action. Retry only under the destination's documented rules and the operation's established repeat behaviour. Preserve the original business fact; do not generate a new identity just to make a request appear successful.
Google's Measurement Protocol reference specifically advises correcting HTTP errors rather than repeating the unchanged request. Do not apply a universal retry recipe to every API. Measurement Protocol transport guidance
When an uncertain operation could repeat an external action, require review. The record should identify who investigates, what evidence resolves it and whether the affected report can currently be used. A blocked row is more useful than an unqualified green status.
Перед повтором классифицируйте проблему. Отклонённое поле требует исправления. Ошибка прав или аккаунта — изменения конфигурации. При таймауте получатель мог выполнить операцию, а ответ потеряться. Оставьте результат неизвестным, пока доказательства не разрешат ситуацию.
Ведите историю попыток: ссылка на событие, время попытки, результат, категория ошибки и следующий шаг. Повторяйте только по документированным правилам получателя и установленному поведению операции при повторе. Сохраняйте исходный бизнес-факт; не создавайте новую идентичность ради видимого успеха отправки.
Справочник Google Measurement Protocol прямо рекомендует исправлять HTTP-ошибки, а не повторять неизменённый запрос. Универсальный рецепт повторов не подходит всем API. Рекомендации по транспорту Measurement Protocol
Если неизвестный исход может привести к повторному внешнему действию, нужна проверка. Укажите, кто разбирает ситуацию, какое доказательство её разрешит и можно ли пока использовать затронутый отчёт. Статус «заблокировано» полезнее безусловной зелёной отметки.
10. Reconcile totals without forcing equality10. Сверьте итоги, не требуя искусственного равенства
Choose a closed reporting interval and compare equivalent populations. Start with operational enquiries or payments, then identify the subset eligible for the particular measurement path. Keep accepted business records, measurement-eligible records, delivery attempts, processed events and attributed results as separate quantities.
For each difference, record a reason and evidence: consent restriction, excluded test, failed delivery, delayed processing, duplicate handling, changed date basis, refund treatment or attribution settings. If the cause is unknown, keep an unexplained remainder and an owner. Do not assign every gap to consent because that explanation sounds plausible.
Compare amounts in the same currency and on the same gross/net basis. Do not add purchase and refund events together as though both were sales, or add attribution totals across platforms as though they were disjoint customers. This reconciliation explains what each report measures; it does not prove incremental advertising effect.
Agree on operational thresholds with the business, such as which unexplained payment discrepancy blocks use of a report. There is no universal acceptable difference supplied by this guide. Retest after a mapping, partner, consent or reporting-setting change.
Выберите завершённый отчётный интервал и сравнивайте одинаковые наборы. Начните с рабочих обращений или оплат, затем выделите записи, допустимые для конкретного маршрута измерения. Принятые бизнес-записи, допустимые для измерения записи, попытки доставки, обработанные события и атрибутированные результаты — разные величины.
Для расхождений укажите причину и подтверждение: ограничение согласия, исключённый тест, ошибка доставки, задержка обработки, обработка дублей, другая основа даты, возвраты или настройки атрибуции. Если причина неизвестна, сохраните необъяснённый остаток и назначьте ответственного. Не списывайте любой разрыв на согласие только потому, что объяснение правдоподобно.
Суммы сравнивайте в одной валюте и на одинаковой основе до или после вычетов. Не складывайте покупки и возвраты как две продажи и не суммируйте атрибуцию площадок как непересекающихся клиентов. Такая сверка объясняет содержание отчётов; она не доказывает дополнительный эффект рекламы.
Пороги принятия решения согласуйте с бизнесом: например, какое необъяснённое расхождение по оплатам блокирует использование отчёта. Универсального допустимого процента в этом руководстве нет. После изменения сопоставления, партнёра, согласий или настроек отчёта повторите затронутые проверки.
11. Apply the record to the configured SABSUS path11. Примените протокол к настроенному маршруту SABSUS
The verified SABSUS Site contract separates measurement and CRM consent. Its Google tag loads after measurement grant. An accepted native Lead can claim one PII-free generate_lead; preview, refusal, rejected leads and repeated claims emit none. This does not establish universal form idempotency. Native payment confirmation and verified refund queue GA4 Measurement Protocol events from the final Order; Google Ads import requires separate evidence. SABSUS Site
Configured native Lead creation and the existing Flow's outbox entry are atomic. Saved runId and executed node IDs support investigation; uncertain outcomes use needs_review. These records do not prove external message delivery. SABSUS CRM · SABSUS Flow
These product references accompany the verified contract scope; accept the actual company's setup with its own test evidence. Check the selected site, form, destination and consent configuration. An installed platform identifier or connected account is not sufficient evidence for an event route.
Проверенный контракт SABSUS Site разделяет согласие на измерение и согласие CRM. Тег Google загружается после согласия на измерение. Принятый лид встроенной формы допускает один запрос generate_lead без персональных идентифицирующих сведений (PII). Предпросмотр, отказ, отклонённый лид и повторный запрос на событие его не создают. Это не универсальная идемпотентность форм. Подтверждённая оплата и проверенный возврат ставят события GA4 Measurement Protocol из финального заказа в очередь; импорт Google Ads требует отдельного подтверждения. SABSUS Site
Настроенное создание лида встроенной формы и запись в очереди существующего Flow выполняются одной транзакцией. Сохранённые runId и ID выполненных узлов помогают разбору; неизвестные исходы получают needs_review. Эти записи не доказывают доставку внешнего сообщения. SABSUS CRM · SABSUS Flow
Ссылки на продукты сопровождают проверенный объём контракта; конкретную настройку компании принимайте по её собственным тестам. Проверьте выбранные сайт, форму, получателя и конфигурацию согласия. Установленного идентификатора площадки или подключённого аккаунта недостаточно для подтверждения маршрута события.
12. Record what the evidence allows the team to use12. Зафиксируйте разрешённое использование результатов
Complete the acceptance record with:
- Configuration and dictionary versions, scope and named owners
- Passed cases with evidence; failed, blocked and untested cases kept visible
- Approved reporting uses and any excluded event paths
- Unexplained differences, responsible people and resolution dates
- The approver's decision date and changes that require another check
A useful decision is specific: “Accepted-enquiry reporting can be used; payment attribution remains blocked until the destination test is evidenced.” This is an illustrative decision, not a finding about a live installation.
The owner should be able to explain what the number means. The implementer should be able to show why it was counted. When either answer is missing, the acceptance record identifies the next test.
Завершите протокол следующими сведениями:
- Версии конфигурации и словаря, область проверки и ответственные
- Пройденные случаи с доказательствами; видимые ошибки, блокировки и непроверенные случаи
- Разрешённое использование отчётов и исключённые маршруты
- Необъяснённые расхождения, ответственные и сроки решения
- Дата решения принимающего и изменения, требующие новой проверки
Полезное решение конкретно: «Отчёт о принятых обращениях можно использовать; атрибуция оплат заблокирована до подтверждения теста получателя». Это пример формулировки, а не вывод о действующей установке.
Владелец должен объяснить смысл числа. Исполнитель — показать, почему оно было учтено. Если одного из ответов нет, протокол подскажет следующий тест.