SABSUS
Help me chooseПомочь выбрать Book a demoПолучить демо

SABSUS / ADVERTISING GUIDESABSUS / РУКОВОДСТВО ПО РЕКЛАМЕ

Google offline conversions and Data Manager for CRM outcomesGoogle offline conversions и Data Manager для результатов CRM

Map qualified leads and paid CRM outcomes to Google offline conversions. Check identifiers, consent, Data Manager routes, corrections and acceptance evidence.Карта передачи квалифицированных лидов и оплат из CRM в Google: идентификаторы, согласия, Data Manager, корректировки и доказательства для приёмки.

SABSUS EditorialРедакция SABSUSIllustrative business examplesУчебные бизнес-примеры

What this guide helps you checkЧто поможет проверить эта инструкция

A completed appointment or a paid job often appears in the CRM days after the original advertising enquiry. To use that outcome in Google Ads, agree its business meaning, retain a permitted matching identifier and select a supported import route. Then verify processing and reporting separately.

This guide is a technical connection map for an owner and implementer. It continues the Google Ads local-service setup guide; campaign creation, keywords and budgets are covered there. Here, the deliverable is a field map, responsibility map and acceptance record for offline outcomes.

The example is a fictional appliance-repair workshop that takes bookings and collects payment after a visit. All records, amounts and counts are invented. This article does not report a completed integration or establish a working SABSUS offline-import connector. Google documentation was checked on 7 October 2026; verify the current account interface and selected connector before implementation.

Выполненный визит или оплаченный заказ часто появляется в CRM через несколько дней после рекламного обращения. Чтобы передавать такой результат в Google Ads, сначала определите его бизнес-смысл, сохраните разрешённый идентификатор для сопоставления и выберите поддерживаемый способ импорта. Затем отдельно проверьте обработку и отражение в отчёте.

Это техническая карта подключения для владельца бизнеса и исполнителя. Она продолжает руководство по Google Ads для локального сервиса, где разобраны кампания, ключевые слова и бюджет. Здесь результат работы другой: карта полей, распределение ответственности и протокол приёмки офлайн-результатов.

Учебный пример: вымышленная мастерская ремонта бытовой техники, которая записывает клиентов и получает оплату после визита. Все записи, суммы и количества придуманы. Статья не описывает выполненное подключение и не подтверждает работающий коннектор офлайн-импорта SABSUS. Документация Google проверена 7 октября 2026 года; перед внедрением проверьте текущий интерфейс аккаунта и выбранное подключение.

Two staff members in a fictional appliance-repair workshop review a completed repair at the service counter.
AI illustration. The people, workshop and situation are fictional; this is not a SABSUS interface or customer result.AI-иллюстрация. Люди, мастерская и ситуация вымышлены; это не интерфейс SABSUS и не результат клиента.

1. Decide which CRM outcome becomes a conversion1. Определите результат CRM для передачи в рекламу

Define a milestone that an employee can verify from an operational record. Google distinguishes qualified leads from converted leads; their categories should reflect the business step being measured. Google’s offline conversion FAQ

For the fictional workshop, use these proposed definitions:

CRM fact Evidence required Proposed treatment
Enquiry accepted A durable lead record exists Keep the original enquiry measurement separate
Lead qualified A staff member confirms service fit and service area A distinct qualified-lead action
Appointment confirmed A slot and customer agreement are recorded Operational milestone, not proof of revenue
Work completed and paid Job completion and payment are reconciled A distinct converted-lead action
Refund confirmed Refund ledger references the paid order Evaluate a value correction using the chosen route

Give each milestone one counting unit. In this design, one lead can qualify once and one completed order can produce one paid-outcome event. Reopening a record or editing its notes does not generate a new conversion. Deposits and instalments need their own rule before export.

Do not add the qualified-lead value and the full paid-order value together as though they were separate sales. Keep funnel stages distinguishable in reports. Choose the bidding outcome deliberately after accepting the data.

Выберите этап, который сотрудник может подтвердить операционной записью. Google различает qualified lead и converted lead; категория должна соответствовать измеряемому шагу бизнеса. Вопросы об офлайн-конверсиях Google

Для учебной мастерской предложим такие определения:

Факт в CRM Необходимое подтверждение Предлагаемый учёт
Обращение принято Существует сохранённая запись лида Измерение исходного обращения остаётся отдельным
Лид квалифицирован Сотрудник подтвердил подходящую услугу и зону обслуживания Отдельное действие qualified lead
Запись подтверждена Зафиксированы время и согласие клиента Операционный этап, ещё не подтверждённая выручка
Работа выполнена и оплачена Выполнение и платёж сверены Отдельное действие converted lead
Возврат подтверждён Запись возврата связана с оплаченным заказом Проверка корректировки ценности для выбранного маршрута

Для каждого этапа задайте единицу счёта. В этой модели лид квалифицируется один раз, а один выполненный заказ создаёт одно событие оплаченного результата. Повторное открытие карточки и изменение комментария не создают новую конверсию. Для авансов и оплаты частями правило нужно согласовать до выгрузки.

Не складывайте ценность квалифицированного лида и полную ценность оплаченного заказа как две самостоятельные продажи. В отчёте этапы воронки должны различаться. Цель для управления ставками выбирают отдельно, после приёмки данных.

From a CRM outcome to Google reporting

Proposed connection map

  1. CRM: Qualification or completed paid work
  2. Eligible event: Permitted fields and identifiers
  3. Selected route: Data Manager source or API
  4. Result checks: Receipt → diagnostics → report

Verify each transition. This diagram does not establish a native SABSUS export.

От результата CRM к отчёту Google

Предлагаемая карта подключения

  1. CRM: Квалификация или оплаченная работа
  2. Допустимое событие: Разрешённые поля и идентификаторы
  3. Выбранный маршрут: Источник Data Manager или API
  4. Проверка результата: Квитанция → диагностика → отчёт

Каждый переход требует проверки. Нативная выгрузка SABSUS здесь не подтверждена.

2. Choose a documented Google route2. Выберите документированный маршрут Google

Data Manager is available both as a Google Ads interface for connecting sources and as a programmatic API. A connection to one Google product does not establish another product’s event mapping.

Route When to evaluate it Evidence needed
Data Manager source connection The business can maintain a supported CRM, file or data-warehouse source Source availability for offline conversions, mapping, schedule, permissions and import history
Data Manager API An implementer will own a server-side export and delivery process Current API contract, destination, authorised credentials, diagnostics and recovery procedure
Partner integration A supported partner supplies the required export Exact source and destination support, field coverage and operational owner
Existing Google Ads API uploader A legacy implementation already exists Current legacy eligibility and migration plan; historical success alone is insufficient

Google’s source directory distinguishes supported destinations. Google Sheets and BigQuery have documented offline-conversion workflows; this does not mean every CRM exports to them or every connector supports the same transformations. Supported data sources · Google Sheets · BigQuery

For a new custom uploader, design against Data Manager API. Google’s current documentation describes restrictions on starting legacy Google Ads API uploads from 15 June 2026, with eligibility-dependent legacy access. Some help pages still mention the older API in general descriptions. Confirm the account’s actual access rather than treating those descriptions as a new-integration guarantee. Current legacy warning · Data Manager offline conversions

For a UI connection, review filters, mapped fields and refresh schedule together. Google documents daily imports and daily refresh scheduling. Updating a CRM every minute does not establish minute-by-minute delivery through that connection. Connect a data source

Data Manager существует как интерфейс подключения источников в Google Ads и как программный API. Подключение одного продукта Google не подтверждает передачу нужного события в другой.

Маршрут Когда его рассматривать Какие доказательства нужны
Источник в Data Manager Бизнес может поддерживать совместимый CRM-источник, файл или хранилище Поддержка офлайн-конверсий, поля, расписание, права и история импорта
Data Manager API Исполнитель отвечает за серверную выгрузку и доставку Текущий контракт API, получатель, разрешённый доступ, диагностика и восстановление
Партнёрская интеграция Нужную выгрузку предоставляет поддерживаемый партнёр Поддержка конкретной пары систем, состав полей и ответственный
Существующая выгрузка через Google Ads API Уже работает прежняя реализация Актуальный legacy-допуск и план миграции; старого успешного запуска недостаточно

В каталоге Google поддерживаемые назначения указаны отдельно. Для Google Sheets и BigQuery есть документированные сценарии офлайн-конверсий. Это не означает, что любая CRM умеет выгружать туда данные или что все коннекторы одинаково преобразуют поля. Поддерживаемые источники · Google Sheets · BigQuery

Новую программную выгрузку проектируйте для Data Manager API. Текущая документация Google описывает ограничения на запуск прежнего импорта через Google Ads API с 15 июня 2026 года; сохранение legacy-доступа зависит от допуска. В некоторых справочных текстах старый API ещё перечислен среди способов подключения. Проверяйте фактический доступ аккаунта, не считая такое упоминание гарантией для новой реализации. Актуальное предупреждение о legacy-доступе · Офлайн-конверсии через Data Manager

Для подключения через интерфейс проверяйте вместе фильтры, соответствие полей и расписание. Google документирует ежедневный импорт и планирование ежедневных обновлений. Если CRM обновляется каждую минуту, это ещё не подтверждает поминутную доставку через выбранное подключение. Подключение источника

3. Identify the destination and its owner3. Установите получателя и владельца конверсии

Record the advertiser, Google Ads account receiving the outcome, conversion-action ID, conversion owner, data-source owner and person responsible for incidents. An agency’s login account may differ from the account that owns the conversion action.

In Data Manager API, the destination’s operating account must be the Google Ads conversion customer, meaning the owner of that conversion action. Do not copy an old uploader’s account ID without checking this relationship. Destination ownership during migration

The offline API workflow uses an UPLOAD_CLICKS action. Confirm the numeric destination ID, source type and intended business milestone together. Send offline events

The business owner approves the meaning and permitted use of data. The CRM owner approves the export. The implementer owns delivery and errors. The advertising specialist verifies action settings and reporting. Access grants and acceptance of customer-data terms require their own authorised decisions; an editorial map grants neither.

Запишите рекламодателя, аккаунт Google Ads для результата, ID действия-конверсии, владельца этого действия, владельца источника и ответственного за ошибки. Аккаунт входа агентства может отличаться от аккаунта, которому принадлежит действие.

В Data Manager API операционным аккаунтом назначения должен быть Google Ads conversion customer, то есть владелец выбранного действия-конверсии. Не переносите ID аккаунта из старой выгрузки без проверки этой связи. Владелец назначения при миграции

Офлайн-маршрут API использует действие типа UPLOAD_CLICKS. Проверьте вместе числовой ID назначения, тип источника и бизнес-этап. Отправка офлайн-событий

Владелец бизнеса утверждает смысл и допустимое использование данных. Владелец CRM согласует выгрузку. Исполнитель отвечает за доставку и ошибки. Специалист по рекламе проверяет настройки действия и отчёты. Предоставление доступа и принятие условий использования клиентских данных требуют отдельных решений уполномоченного лица; редакционная схема не заменяет их.

4. Keep matching identifiers separate from record IDs4. Разделите идентификаторы сопоставления и записей

A lead ID identifies your business record. A click identifier helps Google relate an outcome to an advertising interaction. A transaction ID distinguishes the conversion event. A request ID tracks processing of a delivery. These roles are not interchangeable.

For enhanced conversions for leads, Google uses first-party user-provided data, such as a permitted email address, alongside available Google identifiers. The documented website-tag workflow connects information collected at the lead stage with later imported outcomes. Continue sending available GCLIDs; without a tag collecting user-provided data, Google says GCLID is required for that implementation. A hash alone does not guarantee a match. Enhanced conversions for leads

For this workshop’s first design, evaluate GCLID and permitted first-party email or phone data. Preserve any captured GBRAID or WBRAID in their original, separate fields and verify support in the selected route. The current API reference documents additional identifier options; adopting them needs a separate purpose and implementation review. Offline event identifier requirements

Never manufacture a click ID, put a UTM value into the GCLID field, or attach every job by the same customer to their oldest advertising click. Preserve source provenance and distinguish a missing identifier from a malformed one. UTM parameters can support your own source analysis; they cannot replace Google’s required matching data.

Normalize before hashing. Follow the selected route’s current rules for email and phone formatting, SHA-256 and encoding. Phone numbers need the appropriate international format. Document whether the connector or your code performs each transformation, so an already hashed value is not hashed again. Data Manager formatting requirements

ID лида обозначает запись бизнеса. Идентификатор клика помогает Google связать результат с рекламным взаимодействием. ID транзакции различает события конверсии. ID запроса нужен для проверки обработки отправки. Эти роли нельзя подменять друг другом.

Для enhanced conversions for leads Google использует собственные данные рекламодателя, полученные от клиента, например разрешённый email, вместе с доступными идентификаторами Google. Документированный сценарий с тегом сайта связывает сведения при обращении с импортируемым результатом. Продолжайте передавать доступные GCLID; для реализации без тега, собирающего пользовательские данные, Google указывает обязательность GCLID. Сам хеш не гарантирует сопоставления. Enhanced conversions for leads

В первой версии схемы мастерской рассмотрите GCLID и разрешённые email или телефон, полученные от клиента. Если собраны GBRAID или WBRAID, сохраняйте их в отдельных исходных полях и проверяйте поддержку выбранным маршрутом. Текущий справочник API описывает и другие варианты идентификаторов; их использование требует отдельной проверки цели и реализации. Требования к идентификаторам

Не придумывайте click ID, не помещайте UTM-метку в поле GCLID и не относите все заказы одного клиента к его самому раннему рекламному клику. Сохраняйте происхождение данных и различайте отсутствующее и некорректное значение. UTM помогают внутреннему анализу источника, но не заменяют обязательные данные сопоставления Google.

Сначала нормализуйте данные, затем хешируйте. Соблюдайте актуальные правила выбранного маршрута для email, телефона, SHA-256 и кодирования. Для телефона нужен подходящий международный формат. Зафиксируйте, какой шаг выполняет коннектор, а какой ваш код, чтобы готовый хеш не хешировался повторно. Форматирование данных Data Manager

Four identifiers with different jobs

Proposed traceability model

  1. Lead ID: Business record in CRM
  2. Click ID: Advertising match
  3. Transaction ID: One conversion event
  4. Request ID: Processing of a delivery

A retry keeps the event identity. Another delivery attempt is not another order.

Четыре разных идентификатора

Предлагаемая модель прослеживаемости

  1. ID лида: Запись в CRM
  2. Click ID: Сопоставление с рекламой
  3. Transaction ID: Одно событие конверсии
  4. Request ID: Проверка обработки отправки

Повтор сохраняет идентичность события. Новая попытка не означает новый заказ.

5. Write the field map before building the export5. Составьте карту полей до разработки выгрузки

Use an internal event record with an explicit schema version. The following is a proposed design, not a ready-to-upload template.

Internal field Meaning and control
lead_id, order_id Opaque links to source records; no customer contact data in IDs
milestone, event_id Agreed outcome and stable event identity
occurred_at When the business milestone actually happened
destination_account, action_id Approved Google destination and conversion action
matching_data Only permitted identifiers supported by the selected route
value, currency, value_basis Numeric value, currency and business definition
consent_evidence_ref Internal reference to the applicable permission evidence
version, attempt_id, request_id Business revision, delivery attempt and provider receipt

For Data Manager API JSON, map occurrence time to eventTimestamp, event identity to transactionId, and the numeric conversion-action ID to productDestinationId. Use RFC 3339 timestamps. Monetary values use major currency units, not micros. API field mappings

Google’s current offline workflow guide marks eventSource as required; include it with a supported value reflecting the actual source. Although transactionId is optional in the API, this proposed implementation makes a stable ID mandatory for traceability and correction. The rest of the payload must satisfy the chosen route’s requirements. Offline event contract

The generic REST schema lists eventSource as optional; validate against the specific workflow and API version. Generic Event schema

Example: fictional order demo-order-204 becomes paid after a visit at 2026-10-05T17:40:00+02:00. The reporting rule uses 120.00 EUR of service value after discounts, excluding indirect tax. The corresponding UTC instant is 15:40. Neither queue time nor upload time replaces that occurrence time. This amount is illustrative revenue on a declared basis, not profit.

Используйте внутреннюю запись события с явной версией схемы. Ниже предложена модель, а не готовый шаблон для загрузки.

Внутреннее поле Значение и контроль
lead_id, order_id Непрозрачные ссылки на исходные записи; без контактов клиента в ID
milestone, event_id Согласованный результат и стабильный идентификатор события
occurred_at Время фактического наступления бизнес-результата
destination_account, action_id Утверждённый аккаунт Google и действие-конверсия
matching_data Только разрешённые идентификаторы, поддерживаемые маршрутом
value, currency, value_basis Число, валюта и бизнес-определение ценности
consent_evidence_ref Внутренняя ссылка на подтверждение применимого разрешения
version, attempt_id, request_id Ревизия результата, попытка доставки и квитанция провайдера

В JSON Data Manager API время события соответствует eventTimestamp, его идентичность — transactionId, а числовой ID действия-конверсии — productDestinationId. Время передаётся в RFC 3339. Денежная ценность выражается в основных единицах валюты, не в micros. Карта полей API

Текущее руководство Google по офлайн-сценарию отмечает eventSource как обязательное: передавайте поддерживаемое значение по реальному источнику. Хотя в API поле transactionId необязательно, в предлагаемой реализации стабильный ID обязателен для прослеживаемости и корректировок. Остальные поля должны отвечать требованиям выбранного маршрута. Контракт офлайн-события

В общей REST-схеме eventSource обозначено необязательным; проверяйте конкретный сценарий и версию API. Общая схема Event

Пример: вымышленный заказ demo-order-204 оплачен после визита в 2026-10-05T17:40:00+02:00. Правило отчёта использует 120,00 EUR стоимости услуги после скидки, без косвенного налога. Тот же момент в UTC — 15:40. Время постановки в очередь и время выгрузки не заменяют время результата. Сумма обозначает учебную выручку на согласованной базе, а не прибыль.

7. Separate occurrence time, import deadlines and latency7. Разведите время события, срок импорта и задержку

Maintain four timestamps: business occurrence, queue entry, accepted delivery and observed reporting. Preserve the original timezone or offset and test daylight-saving boundaries. If an event appears to precede its click, investigate the source clock and timezone; never move the business time just to pass validation.

Google states that ordinary offline conversions uploaded more than 90 days after the associated last click are not imported; the stated limit for enhanced conversions for leads is 63 days. These are outer import limits, not a promise of eligibility throughout that period. The action’s configured conversion window and selected workflow also matter. Offline import timing guidelines

Schedule delivery with headroom. If payment regularly occurs too late, consider a genuine earlier qualified milestone with its own meaning; do not backdate the payment. Keep the late payment in business reporting even when it is ineligible for Google import.

Храните четыре момента: наступление результата, постановка в очередь, принятая отправка и наблюдение в отчёте. Сохраняйте исходный часовой пояс или смещение UTC и проверяйте переходы сезонного времени. Если событие оказалось раньше клика, исследуйте часы источника и преобразование пояса; не переносите результат на другую дату ради успешной проверки.

Google указывает, что обычные офлайн-конверсии, загруженные позднее 90 дней после связанного последнего клика, не импортируются; для enhanced conversions for leads указан предел 63 дня. Это внешние пределы импорта, а не обещание пригодности любой записи внутри срока. Имеют значение настроенное окно конверсии и конкретный сценарий. Рекомендации по срокам импорта

Планируйте доставку с запасом времени. Если оплата регулярно наступает слишком поздно, рассмотрите настоящий более ранний этап квалификации с собственным определением; не задним числом меняйте дату оплаты. Поздний платёж остаётся в управленческом учёте, даже если его нельзя импортировать в Google.

8. Treat receipt, processing and attribution as separate checks8. Проверяйте приём, обработку и атрибуцию отдельно

Keep a delivery ledger linking each event version to its attempt, destination, payload checksum, response and diagnostics reference. A request receipt cannot prove a conversion appeared in an advertising report.

Data Manager API rejects the entire request for structural or required-field validation failures. Other checks happen asynchronously and can produce warnings or record-level failures. Correct client/configuration errors before retrying; use controlled backoff for transient server errors. API error model

Store the returned request ID and inspect diagnostics per destination until processing is terminal. Google documents processing that may take up to 24 hours, with some requests finishing in about 30 minutes. Inspect warnings as well as success, failure or partial success; a received record count includes failed records too. Data Manager diagnostics

Our proposed recovery rule: an unchanged retry retains the event identity, business time, value and version. A business correction gets a new revision and a reviewed correction path. Keep those queues separate. If an acknowledgement is lost, investigate the request and event records before producing a second business event.

Ведите журнал доставки: версия события, попытка, назначение, контрольная сумма отправки, ответ и ссылка на диагностику. Квитанция запроса не подтверждает появление конверсии в рекламном отчёте.

Data Manager API отклоняет запрос целиком при структурной ошибке или провале проверки обязательного поля. Другие проверки выполняются асинхронно и могут выявить предупреждения или ошибки отдельных записей. Перед повтором исправляйте ошибки данных и конфигурации; для временных серверных сбоев используйте управляемое увеличение интервала. Модель ошибок API

Сохраняйте возвращённый ID запроса и проверяйте диагностику каждого назначения до итогового состояния. Google описывает обработку продолжительностью до 24 часов; некоторые запросы завершаются примерно за 30 минут. Проверяйте предупреждения наряду с успехом, ошибкой или частичным успехом; количество принятых записей включает и неуспешные. Диагностика Data Manager

Предлагаемое правило восстановления: неизменённый повтор сохраняет ID события, бизнес-время, сумму и версию. Исправление бизнес-факта получает новую ревизию и проверенный маршрут корректировки. Разделяйте эти очереди. Если подтверждение потерялось, сначала исследуйте записи запроса и события, не создавая второй бизнес-результат.

9. Design corrections for the route you actually use9. Проектируйте корректировки для выбранного маршрута

With Data Manager API, an existing transaction ID in the same conversion action can identify an adjustment. A changed value replaces the previous value; it is not a refund delta. An unmatched ID can create a new conversion. Adjustments still need the required event fields and identifiers. Data Manager conversion adjustments

In the fictional example, a 30 EUR partial refund changes the chosen net value from 120 to 90 EUR. The proposed correction carries 90, the same event transaction ID and destination, and a new internal revision. It does not create a second paid order or send −30 as a replacement value.

Data Manager API currently cannot retract a conversion’s count. Restating value to zero leaves that count unchanged. If cancellation requires removing it, verify another supported, authorised workflow before choosing this architecture. API migration comparison

Serialize revisions for the same event and prevent an old delivery from overwriting a newer correction. Prove replay and out-of-order behaviour in acceptance tests; the presence of a transaction ID is not a universal exactly-once guarantee across actions or routes.

В Data Manager API существующий ID транзакции в том же действии-конверсии может обозначать корректировку. Новая ценность заменяет прежнюю, а не означает разницу возврата. Не найденный ID может создать новую конверсию. Для корректировки по-прежнему нужны обязательные поля события и идентификаторы. Корректировки в Data Manager

В учебном примере частичный возврат 30 EUR меняет выбранную итоговую ценность со 120 на 90 EUR. Предлагаемая корректировка содержит 90, прежний ID транзакции и назначение, а также новую внутреннюю ревизию. Она не создаёт второй оплаченный заказ и не передаёт −30 как новое итоговое значение.

Data Manager API сейчас не поддерживает retraction с удалением количества конверсий. При нулевой ценности количество сохраняется. Если отмена требует убрать конверсию из счёта, до выбора архитектуры проверьте другой поддерживаемый маршрут и полномочия для него. Сравнение API при миграции

Обрабатывайте ревизии одного события последовательно и не допускайте, чтобы запоздавшая отправка перезаписала более новое исправление. Повторы и нарушенный порядок нужно проверить при приёмке; наличие ID транзакции не гарантирует универсальный учёт «ровно один раз» между разными действиями и маршрутами.

10. Reconcile the pipeline before interpreting performance10. Сверьте цепочку до оценки эффективности

Create a reconciliation by outcome, destination, currency and event-date cohort. Account separately for source records, policy/identifier exclusions, queued records, attempts, successful processing, failures and reporting observations. Do not count retries as new outcomes. Assign one primary exclusion reason so the exclusion categories do not overlap.

A fictional weekly cohort contains 40 paid jobs. Four fail the project’s required-permission gate, three lack usable matching data, and two are beyond the selected route’s import limit. That leaves 31 eligible jobs. A proposed ledger might show 29 processed successfully and two failed. These invented figures illustrate accounting controls, not an observed import or match rate. Reported attributed conversions remain a separate check.

Google Ads commonly assigns conversions to the related impression/click date. Use suitable “by conv. time” columns when comparing conversion dates, and align account timezone, filters and action settings. Google describes typical reporting processing under 12 hours, with GBRAID/WBRAID-keyed conversions potentially taking up to 72 hours. These reporting timings and API diagnostic timings describe different stages, not an end-to-end SLA. Discrepancies and reporting delays

A difference can come from permission exclusions, missing matches, counting settings, attribution, timing or errors. Preserve those explanations instead of forcing the advertising total to equal all CRM sales. Attributed revenue also does not by itself establish incremental revenue or profit.

Стройте сверку по результату, назначению, валюте и группе событий одной даты. Отдельно учитывайте исходные записи, исключения по разрешению и идентификаторам, очередь, попытки, успешную обработку, ошибки и наблюдение в отчёте. Повтор доставки не является новым результатом. Назначайте одну основную причину исключения, чтобы группы исключений не пересекались.

В вымышленной неделе есть 40 оплаченных работ. Четыре не проходят обязательную проверку разрешения в проекте, у трёх нет пригодных данных сопоставления, две вышли за срок выбранного маршрута. Остаётся 31 подходящая запись. Предлагаемый журнал может показывать 29 успешно обработанных и две ошибочные. Эти придуманные числа объясняют контроль учёта, а не показывают реальный импорт или долю сопоставления. Атрибутированные конверсии в отчёте проверяют отдельно.

Google Ads обычно относит конверсии к дате связанного показа или клика. Для сравнения по дате результата используйте соответствующие столбцы «by conv. time» и согласуйте пояс аккаунта, фильтры и настройки действия. Google описывает обычную обработку для отчётности менее 12 часов, а для конверсий с GBRAID/WBRAID возможны 72 часа. Эти сроки и сроки диагностики API относятся к разным этапам и не образуют общего SLA. Расхождения и задержки отчётности

Разница может объясняться разрешениями, отсутствием сопоставления, правилами счёта, атрибуцией, временем или ошибками. Сохраняйте эти объяснения вместо попытки приравнять рекламный итог ко всем продажам CRM. Атрибутированная выручка сама по себе также не доказывает дополнительную выручку или прибыль.

Reconcile before assessing attribution

Entirely fictional teaching example

  1. 40 jobs: Paid outcomes in the CRM
  2. 9 exclusions: 4 permission · 3 ID · 2 timing
  3. 31 eligible: 40 − 9 = 31
  4. 29 + 2: 29 processed · 2 failed

Reported conversions need a separate check. 29 processed does not guarantee 29 attributed.

Сверка до оценки атрибуции

Полностью вымышленный учебный пример

  1. 40 работ: Оплачено по данным CRM
  2. 9 исключений: 4 разрешение · 3 ID · 2 срок
  3. 31 подходит: 40 − 9 = 31
  4. 29 + 2: 29 обработаны · 2 ошибки

Конверсии в отчёте: отдельная проверка. 29 обработанных не гарантируют 29 атрибутированных.

11. Accept a small, explicit set of cases11. Примите небольшой и явный набор сценариев

Start with local synthetic fixtures and schema checks. Google’s validateOnly option validates a submitted request without ingesting it; submitting even a validation request transmits its payload to Google. Use it only with authorised data and access. A validation pass cannot prove attribution. Request validation option

Test Expected result to prove
Qualified lead and later paid outcome Distinct actions preserve the agreed stages
Exact replay No additional business outcome; ledger explains attempts
Incorrect account/action Rejected or blocked with a useful destination error
Missing required identifier Held locally or rejected; no fabricated substitute
Denied or withdrawn required permission Export follows the approved suppression rule
Late event and timezone boundary True time retained; eligibility handled explicitly
Lost response and temporary failure Recovery preserves identity and exposes uncertainty
Value change from 120 to 90 EUR Same outcome, corrected value, no new paid job
Full cancellation Verified route-specific behaviour; count limitation disclosed
Two writers or out-of-order correction Older state cannot silently replace the accepted revision

For each case, record expected result, observed result, evidence, date, configuration version and owner. Mark untested or blocked cases honestly. A controlled real-data pilot, if later authorised, needs a genuine eligible advertising interaction; synthetic IDs cannot prove Google matching. Agree the monitoring period around actual processing and sales-cycle delays.

Начните с локальных синтетических примеров и проверки схемы. Опция Google validateOnly проверяет отправленный запрос без импорта событий; даже такой запрос передаёт его содержимое в Google. Используйте её только с разрешёнными данными и доступом. Успешная валидация не доказывает атрибуцию. Опция проверки запроса

Проверка Ожидаемый результат, который нужно доказать
Квалификация и последующая оплата Разные действия сохраняют согласованные этапы
Точный повтор Нет нового бизнес-результата; журнал объясняет попытки
Неверный аккаунт или действие Отказ либо блокировка с понятной ошибкой назначения
Нет обязательного идентификатора Локальная остановка либо отказ; значение не выдумывается
Отказ или отзыв обязательного разрешения Выгрузка соблюдает утверждённое правило исключения
Поздний результат и граница часового пояса Сохранено настоящее время, пригодность обработана явно
Потерянный ответ и временный сбой Восстановление сохраняет идентичность и показывает неопределённость
Изменение со 120 на 90 EUR Тот же результат с новой ценностью, без нового заказа
Полная отмена Проверено поведение маршрута, ограничение количества раскрыто
Два отправителя или нарушенный порядок Старая версия не подменяет принятую ревизию незаметно

Для каждого случая запишите ожидание, наблюдаемый результат, доказательство, дату, версию конфигурации и ответственного. Честно отмечайте непроверенные и заблокированные случаи. Если позже будет разрешён небольшой пилот с реальными данными, для него нужно настоящее подходящее рекламное взаимодействие; синтетический ID не докажет сопоставление Google. Срок наблюдения должен учитывать обработку и реальную длительность продажи.

12. Define what must be verified in SABSUS12. Укажите, что требуется проверить в SABSUS

Treat the SABSUS side as a proposed implementation until its current contract and end-to-end evidence establish the required operations. A Google entry in an integration list, CRM access or a workflow feature does not prove offline-conversion export.

Ask the implementer to demonstrate:

  • The authoritative lead, appointment, completed-job, payment and refund records
  • Persistent storage of allowed matching data, consent evidence and timezone-aware timestamps
  • A supported export route, destination mapping and authorised access
  • Stable event identity, replay control, versioned corrections and failure handling
  • Google request/import receipts, diagnostics and a reconciled reporting sample
  • Who monitors failures, who approves corrections and how sending is stopped safely

A controlled file or warehouse export may be a useful proposal when the source can produce the required fields. It still requires verification and permission to share data. If a required operation is missing, record the gap, owner and acceptance condition. Keep using trustworthy internal CRM reports while the connection is unresolved.

This article makes no claim that SABSUS already performs native Data Manager ingestion, automatic retries, consent enforcement or Google conversion corrections.

Считайте часть SABSUS проектом реализации, пока актуальный контракт и сквозные доказательства не подтвердят нужные операции. Наличие Google в перечне интеграций, доступа к CRM или функций автоматизации не доказывает выгрузку офлайн-конверсий.

Попросите исполнителя показать:

  • Достоверные записи лида, записи на визит, выполненной работы, оплаты и возврата
  • Сохранение разрешённых данных сопоставления, доказательств согласия и времени с поясом
  • Поддерживаемый маршрут выгрузки, карту назначения и разрешённый доступ
  • Стабильные ID событий, контроль повторов, ревизии исправлений и обработку ошибок
  • Квитанции запросов или импорта Google, диагностику и сверенный пример отчёта
  • Ответственного за сбои, порядок утверждения корректировок и безопасной остановки отправки

Контролируемая выгрузка в файл или хранилище может быть полезным предложением, если источник способен выдать нужные поля. Для неё всё равно требуются проверка и разрешение на передачу. Если операция отсутствует, укажите пробел, ответственного и условие приёмки. Пока подключение не подтверждено, опирайтесь на достоверные внутренние отчёты CRM.

Эта статья не утверждает, что SABSUS уже выполняет нативный импорт в Data Manager, автоматические повторы, контроль согласия или корректировки конверсий Google.

13. Approve reporting use before changing bidding13. Разрешите использование отчёта до изменения ставок

Close acceptance with a one-page decision: which outcome is trustworthy, which destination receives it, known exclusions, typical observed delay, correction limitations, evidence links and incident owner. Approve only the use supported by evidence.

Secondary actions normally support observation, but a secondary action in a custom goal can still be used for bidding. Check the campaign’s actual goals as well as the primary/secondary label. Primary and secondary actions

Move an accepted outcome into bidding only through a separately approved change with a baseline and monitoring plan. Import success does not guarantee better acquisition cost. The immediate success criterion is narrower and testable: the team can explain which genuine CRM outcomes were eligible, what Google processed, what reporting shows and what still remains uncertain.

Завершите приёмку коротким решением: какой результат достоверен, куда он передаётся, какие исключения известны, какая задержка наблюдается, как ограничены исправления, где лежат доказательства и кто отвечает за сбои. Разрешайте только тот способ использования, который подтверждён.

Secondary-действия обычно предназначены для наблюдения, но такое действие внутри custom goal может участвовать в управлении ставками. Проверяйте фактические цели кампании вместе с признаком primary или secondary. Основные и дополнительные действия-конверсии

Перевод принятого результата в управление ставками оформляйте отдельным согласованным изменением с исходными показателями и планом наблюдения. Успешный импорт не гарантирует снижения стоимости привлечения. Ближайший критерий успеха конкретнее: команда может объяснить, какие настоящие результаты CRM подходили для передачи, что обработал Google, что видно в отчёте и где ещё остаётся неопределённость.