SABSUS / ADVERTISING GUIDESABSUS / РУКОВОДСТВО ПО РЕКЛАМЕ
What to check before connecting 14 advertising platformsЧто проверять перед подключением 14 рекламных площадок
Verify an ad connection by account and operation: reports, drafts, paused creation, permissions, budget limits, conversions and provider-confirmed results.Проверьте рекламное подключение по кабинету и операциям: отчёты, черновики, создание на паузе, права, лимиты, конверсии и подтверждение результата площадкой.
What this guide helps you checkЧто поможет проверить эта инструкция
Before accepting an advertising connection, name the account, the operation you need and the evidence that will prove it works. A useful acceptance result is “campaigns can be read from this account, and a test campaign was created paused.” A single “connected” label leaves too much unanswered.
This guide gives business owners and implementation teams a practical acceptance matrix. It separates account access, reporting, draft preparation and actions that can affect advertising spend. The worked example uses paused test objects and authorises no live media spend. It is an illustrative test plan, not a report of a completed SABSUS customer integration.
Provider documentation checked on October 7, 2026. Repeat relevant checks when the account, permissions, API version or supported product changes.
До приёмки рекламного подключения зафиксируйте кабинет, нужную операцию и подтверждение её работы. Полезный итог проверки звучит так: «Из этого кабинета читаются кампании, тестовая кампания создана на паузе». Одного статуса «Подключено» для рабочего решения недостаточно.
Эта инструкция даёт владельцу бизнеса и команде внедрения практическую матрицу приёмки. Она разделяет доступ к кабинету, отчётность, подготовку черновиков и действия, способные повлиять на рекламные расходы. Учебный пример использует тестовые объекты на паузе без разрешения на реальные расходы. Это авторский план проверки, а не результат внедрения у клиента SABSUS.
Документация площадок проверена 7 октября 2026 года. Повторяйте нужные проверки при изменении кабинета, прав, версии API или рекламного продукта.
1. Establish what the list of 14 platforms means1. Определите, что означает список из 14 площадок
The SABSUS Ads registry contains Meta, Google, TikTok, Microsoft, LinkedIn, Pinterest, Snapchat, Reddit, Amazon, Spotify, X, Apple, Yelp and ChatGPT. Facebook and Instagram belong to the Meta entry. Apple appears as one provider in the registry. That entry does not establish App Store or Maps support in a particular SABSUS connection: each advertising product and its available operations must be verified separately. The SABSUS Ads product page describes this coverage and its platform-dependent conditions.
Treat the registry as the starting inventory. It does not establish that all fourteen providers have equally complete live connections, identical campaign formats or the same permissions in your project. Record readiness separately for each selected account and operation.
In SABSUS, the connection model distinguishes the selected account, API verification and capability families: accounts, campaigns, groups, ads, creatives, reporting, conversions and audiences. Those distinctions are useful for acceptance. A broad capability such as “campaigns” still needs operation-level checks: reading, creating paused, enabling and changing a budget have different consequences.
Active publishing also depends on the account permissions, campaign readiness and the service setting that enables live operations for that provider. SABSUS separates preparation from active launch and requires an explicit paid-spend confirmation in the published workflow. Check those gates in the actual account. SABSUS Ads workflow.
The matrix below is an acceptance method. It does not award a live-verified status to any provider on the strength of its registry entry or a capability flag.
В реестре SABSUS Ads перечислены Meta, Google, TikTok, Microsoft, LinkedIn, Pinterest, Snapchat, Reddit, Amazon, Spotify, X, Apple, Yelp и ChatGPT. Facebook и Instagram входят в Meta. В реестре Apple указана как один провайдер. Наличие этой записи не подтверждает поддержку App Store или Maps в конкретном подключении SABSUS: каждый рекламный продукт и доступные операции проверяются отдельно. Страница SABSUS Ads описывает этот охват и условия, зависящие от площадки.
Используйте реестр как исходный список. Он не подтверждает четырнадцать одинаково полно работающих live-подключений, одинаковые форматы кампаний или одинаковые права в вашем проекте. Готовность фиксируется отдельно для выбранного кабинета и операции.
В модели подключения SABSUS разделены выбранный кабинет, проверка API и группы возможностей: кабинеты, кампании, группы, объявления, креативы, отчёты, конверсии и аудитории. Это полезные точки приёмки. Но даже возможность «Кампании» требует отдельных проверок чтения, создания на паузе, включения и изменения бюджета: последствия у этих действий разные.
Для активной публикации также нужны права кабинета, готовность кампании и настройка сервиса, разрешающая рабочие операции этого провайдера. В опубликованном процессе SABSUS подготовка отделена от активного запуска, который требует отдельного подтверждения рекламных расходов. Проверьте эти условия в фактическом кабинете. Рабочий процесс SABSUS Ads.
Приведённая ниже матрица описывает метод приёмки. Ни одному провайдеру не присваивается статус работающего live-подключения на основании записи в реестре или флага доступной возможности.
2. Require five different kinds of evidence2. Запросите пять разных подтверждений
| Evidence level | What to establish | What to retain |
|---|---|---|
| Registry | The product lists the provider and intended advertising product | Provider, product or placement and the supported scenario being assessed |
| Authorisation | The provider recognises the connection with the required permissions | Grant owner, access type, scope and expiry or renewal conditions; no secret values |
| Selected account | Requests target the intended business and advertising account | Account ID, business owner, currency, timezone and environment |
| Operation verified | The product performed the requested operation through the intended route | Operation, timestamp, request or job reference and observed response |
| Provider result confirmed | The provider returned the expected final result or it was independently read back | External object ID, final status, relevant fields and any item-level errors |
For a read operation, the final evidence is a fresh provider response for the correct account and query. For a change, it normally includes reading the external object back. An asynchronous job needs its completion result; an initial acknowledgement only establishes that processing began.
Keep technical acceptance, advertising approval and delivery separate. An external campaign can exist while paused, under review or ineligible to serve. None of those states proves impressions, spend or sales.
| Уровень подтверждения | Что нужно установить | Что сохранить |
|---|---|---|
| Реестр | Продукт перечисляет провайдера и нужный рекламный продукт | Провайдер, продукт или размещение, проверяемый сценарий |
| Авторизация | Площадка признаёт подключение с нужными разрешениями | Владелец доступа, его тип, права, срок действия или условия продления; без секретов |
| Выбранный кабинет | Запросы направлены нужному бизнесу и в нужный кабинет | ID кабинета, владелец, валюта, часовой пояс и среда |
| Операция проверена | Продукт выполнил заданную операцию по нужному маршруту | Операция, время, идентификатор запроса или задания, полученный ответ |
| Результат подтверждён площадкой | Получен ожидаемый конечный результат либо объект повторно прочитан | Внешний ID, итоговый статус, нужные поля и ошибки отдельных элементов |
Для чтения конечным подтверждением служит свежий ответ площадки по правильному кабинету и запросу. Для изменения обычно требуется повторное чтение внешнего объекта. Асинхронной операции нужен итог задания: первоначальная квитанция подтверждает только начало обработки.
Разделяйте техническую приёмку, модерацию и показы. Внешняя кампания может существовать на паузе, проходить проверку или иметь ограничения. Ни одно из этих состояний не доказывает показы, расходы или продажи.
Five levels of connection evidence
Each level requires evidence
Evidence levels: provider registry, authorisation, correct account, tested operation and confirmed outcome.
- RegistryThe product lists the provider
- AuthorisationThe required permissions are granted
- Selected accountBusiness, ID and environment verified
- Tested operationOne specific action has been tested
- Confirmed resultOutcome received and state checked
A 14-provider registry does not complete the checks.
This is an acceptance plan, not a live test result.
Пять уровней проверки подключения
Каждому уровню нужно подтверждение
Уровни доказательств: провайдер в реестре, авторизация, правильный кабинет, конкретная проверенная операция и подтверждённый результат.
- РеестрПровайдер указан в продукте
- АвторизацияПредоставлены нужные права
- Выбранный кабинетПодтверждены бизнес, ID и среда
- Проверенная операцияИспытано конкретное действие
- Подтверждённый результатПолучен итог и прочитано состояние
Реестр из 14 площадок не закрывает остальные уровни.
Это план приёмки, не результат live-теста.
3. Use an operation matrix for every account3. Заполняйте матрицу операций для каждого кабинета
Use explicit statuses: passed in test, passed in production, blocked, not tested or not required. Add a reason, evidence link, date and owner. Reserve “passed in production” for the actual production route and account; a sandbox result has its own value and boundary.
| Operation | Minimum acceptance evidence | Important boundary |
|---|---|---|
| Reporting | A fresh report for a stated period, timezone, filters and account; compare with the provider's equivalent report | Empty, delayed or unavailable data stays labelled as such |
| Local draft | Save and reopen the same draft with its intended fields intact | This verifies local preparation; an external campaign ID is not expected |
| Create paused | External IDs and a fresh read showing the required objects in non-serving states | Confirm the initial state before creation; do not activate briefly to test it |
| Publish or enable | Separate approval, correct external objects and the provider's resulting review and delivery status | Creation alone does not prove launch; keep this outside a no-spend test |
| Pause | Provider-confirmed state of the intended object, including relevant parent and child settings | Setting an already paused object to paused does not demonstrate stopping live delivery |
| Budget change | Read back the amount, currency, period, budget owner and affected campaigns | Check shared budgets and the provider's spending rules before relying on a ceiling |
| Assets and creatives | External asset ID, required metadata, processing result and intended association with the ad | Upload, processing and advertising-policy approval are separate checks |
| Conversions | Documented source and destination, event mapping, delivery result and provider diagnostics | Ingestion, matching, attribution and the business outcome remain separate |
| Audiences | Correct destination, permissions, processing result and documented eligibility for the intended use | Accepted data may still be unavailable for targeting; avoid real customer lists in a basic test |
For reporting, compare like with like. Match attribution settings, date basis, currency and timezone before investigating a discrepancy. Agree a justified tolerance based on the provider's reporting behaviour; do not invent a universal percentage.
For assets, conversions and audiences, make data approval explicit. A reporting connection does not provide permission to upload a customer list. Use platform-supported test fixtures or non-personal sample material where appropriate. Do not send invented purchases into production conversion reporting just to get a green check.
Используйте понятные статусы: проверено в тестовой среде, проверено в рабочей среде, заблокировано, не проверено, не требуется. Добавляйте причину, ссылку на подтверждение, дату и ответственного. Рабочую среду отмечайте только после проверки её фактического маршрута и кабинета; результат песочницы сохраняет своё значение и свои границы.
| Операция | Минимальное подтверждение для приёмки | Важная граница |
|---|---|---|
| Отчётность | Свежий отчёт за указанный период, с заданными часовым поясом, фильтрами и кабинетом; сверка с аналогичным отчётом площадки | Пустые, задержанные и недоступные данные сохраняют свой статус |
| Локальный черновик | Сохранение и повторное открытие того же черновика без потери нужных полей | Проверяется локальная подготовка; внешний ID кампании здесь не ожидается |
| Создание на паузе | Внешние ID и повторное чтение нужных объектов в состояниях без показов | Начальное состояние проверяется до создания; кратковременно включать рекламу для теста нельзя |
| Публикация или включение | Отдельное согласование, правильные внешние объекты, итоговые статусы модерации и доставки площадки | Создание не доказывает запуск; эта операция за пределами теста без расходов |
| Пауза | Подтверждённое площадкой состояние нужного объекта с учётом родительских и дочерних настроек | Повторная установка паузы уже остановленному объекту не проверяет прекращение реальных показов |
| Изменение бюджета | Повторное чтение суммы, валюты, периода, владельца бюджета и затрагиваемых кампаний | Проверьте общий бюджет и правила расходов площадки до использования лимита |
| Материалы и креативы | Внешний ID материала, нужные метаданные, результат обработки и правильная связь с объявлением | Загрузка, обработка и рекламная модерация проверяются отдельно |
| Конверсии | Описанные источник и получатель, соответствие событий, результат передачи и диагностика площадки | Приём, сопоставление, атрибуция и результат бизнеса остаются разными этапами |
| Аудитории | Правильный получатель, разрешения, результат обработки и допустимость нужного использования | Принятые данные ещё могут быть недоступны для таргетинга; базовый тест не требует реальной клиентской базы |
В отчётности сопоставляйте одинаковые показатели. До поиска расхождений выровняйте настройки атрибуции, правило отнесения к дате, валюту и часовой пояс. Допуск согласуйте с учётом особенностей отчётов площадки; универсальный процент расхождения здесь неуместен.
Для материалов, конверсий и аудиторий отдельно согласуйте передачу данных. Доступ к отчётам не разрешает загрузку клиентского списка. Используйте предусмотренные площадкой тестовые данные или неперсональные образцы, где это уместно. Не отправляйте вымышленные покупки в рабочую статистику конверсий ради зелёного статуса.
Accept capabilities separately
Three examples of different boundaries
Reading reports, paused creation and ad activation establish different capabilities; one result does not prove the others.
- ReportingPeriod, currency, freshness and errors.Reading does not authorise edits.
- Paused creationExternal IDs and safe initial states.Test-environment limits still apply.
- Production activationSeparate rights and spending approval.Eligibility and delivery checked separately.
Events, audiences and assets need their own checks.
Do not mark untested operations as successful.
Принимайте операции раздельно
Три примера разных границ
Чтение отчёта, создание на паузе и включение рекламы подтверждают разные возможности; результат одной операции не переносится на другие.
- ОтчётностьПериод, валюта, свежесть и ошибки.Чтение не разрешает изменения.
- Создание на паузеВнешние ID и безопасные статусы.Тестовая среда сохраняет свои ограничения.
- Рабочее включениеОтдельные права и согласование расходов.Допуск и доставка проверяются отдельно.
Конверсии, аудитории и материалы — отдельные проверки.
Не заполняйте непройденные строки как успешные.
4. Create a short account record before granting access4. Составьте краткую карточку кабинета до выдачи доступа
A teammate should be able to repeat the test without guessing which “Main account” you meant. Record:
- Ownership: the legal business, account administrator and authorised agency or partner; identify who retains access when the implementer leaves
- Destination: provider, exact advertising product, account ID and linked business assets required for the scenario
- Markets: advertiser's legal-entity country, target market and any product or category restrictions
- Technical context: test or production environment, application or connection identifier, API version and date checked
- Permission scope: reporting, campaign edits, creative uploads, conversions and audiences, each as needed
- Money and control: account currency, timezone, approved spending authority, budget type and person able to pause directly at the provider
- Evidence and maintenance: expected refresh interval, last successful retrieval, unresolved limitations, test owner and retest triggers
Use the smallest permission scope that supports the agreed work. Verify business ownership separately from an individual's ability to sign in. A contractor may have temporary access to an account the business does not control.
Separate the integration or subscription fee from the media budget. Record who may approve a higher limit; a successful connection does not authorise a new charge. For example, Google describes an average daily budget and separate spending limits. Use the provider's rules when defining the maximum exposure. Google budget and spending limits.
Keep passwords, private keys, access tokens and other credentials out of the record, screenshots and support correspondence. Authorise through the provider's supported secure flow and approved credential storage. The acceptance record needs identifiers and permissions, not their secret values.
Коллега должен повторить проверку без догадок, какой именно «Основной кабинет» вы имели в виду. Зафиксируйте:
- Владение: юридическое лицо, администратор кабинета и уполномоченное агентство или партнёр; кто сохранит доступ после ухода исполнителя
- Назначение: провайдер, точный рекламный продукт, ID кабинета и связанные бизнес-активы, необходимые сценарию
- Географию: страну юридического лица рекламодателя, рынок показа и ограничения продукта или категории
- Технический контекст: тестовую или рабочую среду, идентификатор приложения или подключения, версию API и дату проверки
- Права: чтение отчётов, изменения кампаний, загрузку материалов, конверсии и аудитории по отдельности и по необходимости
- Деньги и управление: валюту, часовой пояс, согласованные полномочия на расходы, тип бюджета и человека, способного поставить рекламу на паузу у провайдера
- Подтверждения и обслуживание: ожидаемую частоту обновления, последнее успешное получение данных, ограничения, ответственного за тест и основания для повторной проверки
Выдавайте минимальные права, достаточные для согласованной работы. Владение бизнес-аккаунтом проверяйте отдельно от возможности конкретного человека войти в него. У подрядчика может быть временный доступ к кабинету, который бизнес не контролирует.
Отделите стоимость интеграции или подписки от рекламного бюджета. Укажите, кто может согласовать увеличение лимита: успешное подключение не разрешает новое списание. Например, Google различает средний дневной бюджет и пределы расходов. Учитывайте правила провайдера при определении максимального риска расходов. Бюджет и пределы расходов Google.
Не помещайте пароли, закрытые ключи, токены и другие секреты в карточку, скриншоты или переписку с поддержкой. Используйте предусмотренный площадкой безопасный способ авторизации и согласованное хранение учётных данных. Для приёмки нужны идентификаторы и разрешения, а не секретные значения.
5. Check the exceptions that change the acceptance plan5. Проверьте исключения, влияющие на план приёмки
These examples explain why one universal “connect” checklist is insufficient. They describe provider requirements, not a claim that SABSUS has passed the corresponding tests.
Google: Current documentation distinguishes API access levels and permissible use for the Google Cloud project. Test access is limited to test accounts; production access and allowed functionality require their own checks. Record the current project access and API version rather than copying an old setup checklist. Google Ads API access levels.
LinkedIn: Reporting, advertising management, conversions and matched audiences involve distinct permissions or API products. Account roles also matter. Acceptance for campaign reads therefore cannot be extended automatically to conversion uploads or audience work. LinkedIn access and permissions.
Apple: Apple's current Platform API documentation covers both App Store and Maps advertising. Specify which product you are testing and verify its account, permissions and actual operation. The presence of an Apple credential form in an integration does not prove its Maps implementation. Apple also documents separate API roles and revocable third-party access. Apple Ads Platform API.
Yelp: The Ads API is a partner API with access disabled by default. Its documentation currently labels pause and resume as coming-soon or early-access features. Ask for evidence of the exact operation available to the partner and account; access to another Yelp API is insufficient. Yelp Ads API.
ChatGPT: OpenAI documents an Advertiser API for campaign management, conversion tracking and reporting. That establishes an API exists. It does not verify an integration's access, its implementation or the advertiser's eligibility. Check the specific ad account and the current legal-entity country rules. Advertiser API overview, Ads Manager availability.
Apply the same account-and-operation method to Meta, TikTok, Microsoft, Pinterest, Snapchat, Reddit, Amazon, Spotify and X. Do not copy one provider's passed results into another provider's row. In particular, a working OAuth sign-in proves neither a supported targeting catalogue nor a successful campaign launch.
Эти примеры объясняют, почему универсального чек-листа «подключить» недостаточно. Они описывают требования провайдеров, а не прохождение соответствующих тестов в SABSUS.
Google. Актуальная документация разделяет уровни доступа API и разрешённое использование для проекта Google Cloud. Test-доступ ограничен тестовыми кабинетами; рабочие кабинеты и разрешённые функции проверяются отдельно. Зафиксируйте текущий доступ проекта и версию API вместо копирования старой инструкции. Уровни доступа Google Ads API.
LinkedIn. Отчётность, управление рекламой, конверсии и Matched Audiences используют отдельные разрешения или продукты API. Имеют значение и роли в кабинете. Приёмка чтения кампаний поэтому не распространяется автоматически на загрузку конверсий и работу с аудиториями. Доступы и разрешения LinkedIn.
Apple. Текущая документация Apple Ads Platform API охватывает рекламу в App Store и Maps. Укажите проверяемый продукт и подтвердите его кабинет, права и фактическую операцию. Наличие формы учётных данных Apple в интеграции не доказывает реализацию Maps. Apple также описывает отдельные роли API и отзыв доступа стороннего провайдера. Apple Ads Platform API.
Yelp. Ads API относится к партнёрским API, доступ по умолчанию выключен. В текущей документации пауза и возобновление отмечены как будущие функции или ранний доступ. Запросите подтверждение конкретной операции для партнёра и кабинета; доступа к другому API Yelp недостаточно. Yelp Ads API.
ChatGPT. OpenAI документирует Advertiser API для управления кампаниями, конверсиями и отчётностью. Это подтверждает существование API. Доступ интеграции, её реализация и допустимость рекламодателя требуют проверки. Проверьте конкретный рекламный кабинет и актуальные условия по стране юридического лица. Обзор Advertiser API, доступность Ads Manager.
Применяйте такой же подход к Meta, TikTok, Microsoft, Pinterest, Snapchat, Reddit, Amazon, Spotify и X. Результат одного провайдера не переносится в строку другого. В частности, успешный вход через OAuth не подтверждает ни поддержку справочника таргетинга, ни успешный запуск кампании.
6. Run a useful acceptance test without buying impressions6. Проведите полезную приёмку без покупки показов
Consider a fictional team testing a Google Search connection. It wants to prepare a campaign, verify the selected account and create a paused object. Live publishing, real customer uploads and media spend are outside the test.
First establish that the integration supports the chosen test-account route. Google test accounts cannot serve ads or incur advertising charges, but they also do not provide serving metrics and cannot test every feature, including conversion uploads. A successful test there must retain its test-environment label. Google test accounts.
Use this sequence only where the implementation supports it:
- Write the test boundary. One named test account, one Search scenario, new test objects only and no live spend. Confirm that the chosen route cannot serve ads. If there is no supported safe route, stop at local-draft acceptance.
- Read the destination. Fetch the selected account and compare its ID and environment with the acceptance record. Do not rely on a friendly name alone.
- Save a local draft. Use a clearly labelled test name, an approved destination URL, sample ad text and the required Search fields. Reopen it and check for lost headlines, descriptions, keywords or settings.
- Create in a non-serving state. Where supported, request a paused campaign and the necessary subordinate objects with safe initial states. Retain the returned external IDs. A draft saved only inside the integration completes step 3, not this step.
- Read back from the provider. Confirm the account, IDs, names, relationships and paused states. Check the budget representation and units if a test budget is supported; a stored budget value does not authorise spending.
- Exercise one safe edit. Change the name of the paused test object, retrieve it again and verify the change. This establishes that particular edit, not every write operation.
- Check a failure path. Use the provider's validation mode or an isolated test fixture with one invalid field. The interface should expose the rejected field and preserve a truthful state. Do not deliberately submit invalid production ads.
- Close the record. Keep external IDs, relevant redacted responses, timestamps and unresolved rows. Confirm all test objects remain non-serving. Leave live publishing, production reporting, conversion uploads and audiences as not tested unless separately evidenced.
An optional second check can compare an existing production report using authorised read-only access. This adds no advertising spend and does not enable campaigns. It also requires separate production access; a test account cannot supply real historical performance.
The fictional result is narrow but useful: selected account confirmed, local draft passed, paused creation and a name edit passed in test. It provides no evidence of production delivery or real conversion transport. SABSUS fields for Google Search keywords and responsive search ad text help define what to inspect; their presence alone does not prove the provider accepted them.
Представим вымышленную команду, которая проверяет подключение Google Search. Ей нужно подготовить кампанию, подтвердить выбранный кабинет и создать объект на паузе. Публикация рабочей рекламы, загрузка реальных клиентов и рекламные расходы исключены из теста.
Сначала установите, поддерживает ли интеграция выбранный маршрут тестового кабинета. Тестовые кабинеты Google не показывают рекламу и не создают рекламных списаний. При этом они не дают статистику показов и не позволяют проверить все функции, включая загрузку конверсий. Успешный результат сохраняет пометку тестовой среды. Тестовые кабинеты Google.
Выполняйте последовательность только там, где её поддерживает реализация:
- Запишите границы. Один указанный тестовый кабинет, один поисковый сценарий, только новые тестовые объекты, никаких реальных расходов. Подтвердите, что выбранный маршрут исключает показы. Если безопасного поддерживаемого маршрута нет, остановитесь на приёмке локального черновика.
- Прочитайте получателя. Получите выбранный кабинет и сравните его ID и среду с карточкой. Названия кабинета недостаточно.
- Сохраните локальный черновик. Используйте явную тестовую метку, согласованный URL назначения, пробный текст и обязательные поля Search. Откройте черновик повторно и проверьте заголовки, описания, ключевые слова и настройки.
- Создайте объекты без показов. Если маршрут это поддерживает, запросите кампанию на паузе и необходимые подчинённые объекты с безопасными начальными статусами. Сохраните внешние ID. Черновик только внутри интеграции завершает шаг 3, но не этот шаг.
- Повторно прочитайте объекты у провайдера. Проверьте кабинет, ID, названия, связи и статусы паузы. Если тестовый бюджет поддерживается, проверьте его представление и единицы; сохранённая сумма не разрешает расходы.
- Выполните одно безопасное изменение. Переименуйте тестовый объект на паузе, прочитайте его повторно и проверьте результат. Это подтверждает конкретное редактирование, а не все операции записи.
- Проверьте обработку ошибки. Используйте режим валидации провайдера или изолированный тест с одним неверным полем. Интерфейс должен показать отклонённое поле и правдивый статус. Намеренно отправлять некорректные рабочие объявления не нужно.
- Закройте протокол. Сохраните внешние ID, нужные ответы без секретов, время и незакрытые строки. Подтвердите, что все тестовые объекты остаются без показов. Публикацию, рабочую отчётность, загрузку конверсий и аудитории оставьте непроверенными без отдельных подтверждений.
Дополнительной проверкой может стать сверка существующего рабочего отчёта через согласованный доступ только на чтение. Она не создаёт рекламных расходов и не включает кампании. Для неё нужен отдельный доступ к рабочей среде: тестовый кабинет не предоставит реальную историческую статистику.
Учебный итог ограничен, но полезен: кабинет подтверждён, локальный черновик прошёл проверку, создание на паузе и переименование проверены в тестовой среде. Подтверждений рабочих показов и реальной передачи конверсий здесь нет. Поля ключевых слов Google Search и текста адаптивного поискового объявления в SABSUS помогают определить предмет проверки; наличие полей не доказывает принятие значений провайдером.
7. Make failures visible before retrying7. Показывайте ошибки до повторной отправки
After a timeout, the external object may already exist. Search by the returned reference or the agreed unique test identifier before creating it again. Follow the provider's retry and idempotency rules; do not assume every endpoint deduplicates repeated requests.
A batch can also partially succeed. Google documents methods that commit valid operations while returning errors for failed items. Inspect the individual results and retry only what actually needs another attempt. Google partial failures.
For asynchronous work, keep “processing” visible until the final receipt is known. Yelp's Ads API illustrates why: it returns job references, and the job result can include a rejected business-level operation. A completed job wrapper does not guarantee every requested change succeeded. Yelp job receipts.
When reporting fails, show the last successful refresh time and the error. Preserve “not received,” “permission denied,” “unsupported” and “still processing” as different conditions. A missing spend value must not silently become zero, and an old report must not look freshly synchronised.
После тайм-аута внешний объект уже может существовать. До нового создания найдите его по полученному идентификатору или согласованной уникальной тестовой метке. Соблюдайте правила повторов и идемпотентности провайдера; нельзя считать, что любой endpoint автоматически удаляет дубли запросов.
В пакете операций возможен частичный успех. Google описывает методы, которые сохраняют корректные операции и возвращают ошибки для остальных. Проверяйте отдельные результаты и повторяйте только то, что действительно требует новой попытки. Частичные ошибки Google.
При асинхронной работе сохраняйте статус «Обрабатывается» до получения итоговой квитанции. Ads API Yelp показывает причину: API возвращает идентификаторы заданий, а итог может содержать отклонённую операцию для конкретного бизнеса. Завершение задания целиком не гарантирует успех каждого изменения. Квитанции заданий Yelp.
Если отчёт не загрузился, показывайте последнее успешное обновление и ошибку. Состояния «не получено», «нет прав», «не поддерживается» и «обрабатывается» должны различаться. Пропавшую сумму расходов нельзя незаметно заменить нулём, а старый отчёт представить свежей синхронизацией.
8. Verify offboarding and the evidence trail8. Проверьте отключение и историю подтверждений
Before relying on the connection, identify who can remove its access and how queued work and scheduled synchronisation are handled. If revocation is part of acceptance, approve the scope and use a dedicated test connection. Avoid disrupting a shared production grant.
After revocation, test a fresh read through that connection and check that the application reports lost access. Previously cached data should be visibly stale. Decide separately what historical data is retained or removed under the agreed policy. Revoking integration access should not be treated as confirmation that an already running campaign has stopped: check and control campaign status directly at the provider.
Ask what the available history actually records. The published SABSUS interface provides creation and update timestamps, the recorded updater and the channel's last-sync time. These fields can help locate a change. They do not, by themselves, establish a complete immutable audit trail with before-and-after values for every operation. Retain the specific evidence required for your acceptance decision. The guide to advertising action history and provider confirmation explains how to record a change and its outcome.
The same standard applies to conversion transport. A sample event journal or a CRM status cannot confirm delivery to an advertising provider. For Google Data Manager or another destination, require the configured route, destination account and provider-side receipt or diagnostics. This guide does not claim that SABSUS's Google Data Manager transport has been verified.
До рабочего использования выясните, кто может отозвать доступ подключения и что произойдёт с очередью задач и синхронизацией по расписанию. Если отзыв входит в приёмку, согласуйте его границы и используйте отдельное тестовое подключение. Не нарушайте работу общего рабочего доступа.
После отзыва выполните новое чтение через это подключение и убедитесь, что приложение сообщает о потере доступа. Ранее сохранённые данные должны быть явно помечены как устаревшие. Отдельно определите, что хранится или удаляется по согласованным правилам. Отзыв доступа интеграции не следует считать подтверждением остановки уже работающей кампании: её состояние проверяется и управляется у провайдера.
Выясните, что именно содержит доступная история. В опубликованном интерфейсе SABSUS предусмотрены время создания и обновления, указание обновившего пользователя и время последней синхронизации канала. Они помогают найти изменение. Сами по себе эти поля не подтверждают полный неизменяемый журнал со значениями до и после каждой операции. Сохраняйте конкретные подтверждения, необходимые для решения о приёмке. В инструкции по истории рекламных действий и подтверждению площадки разобрано, как фиксировать изменение и его итог.
Тот же стандарт применяется к передаче конверсий. Пример журнала событий или статус CRM не подтверждает доставку рекламному провайдеру. Для Google Data Manager или другого получателя нужны настроенный маршрут, кабинет назначения и квитанция либо диагностика на стороне площадки. Эта инструкция не заявляет, что транспорт SABSUS в Google Data Manager проверен.
9. Finish with a precise acceptance decision9. Завершите работу точным решением о приёмке
Use one short record for each provider and account:
- Provider, product, account, environment and date
- Operations accepted, with the evidence for each
- Operations blocked, not tested or unnecessary for the current scope
- Missing data and known reporting limitations
- Spending authority, direct pause route and named owner
- Revocation route and changes that require retesting
A useful handover might read: “Google Search, specified test account: local drafts, paused creation and name edits accepted. Production reports, publishing, stopping live delivery, conversion uploads and audiences remain untested. No live media spend authorised.” This is an illustrative acceptance statement, not a SABSUS test result.
If a required operation remains blocked, narrow the operating scope or resolve that blocker. A read-only connection can still be useful for reporting. It should remain read-only in the acceptance decision until the necessary write operations have been checked and authorised.
For goals, CRM definitions and campaign ownership, use the general SABSUS Ads setup guide. For Search campaign construction, use the Google Ads local-service guide. This checklist answers a different handover question: which operations are proven for this account today?
Оставьте по одной короткой записи для каждого провайдера и кабинета:
- Провайдер, продукт, кабинет, среда и дата
- Принятые операции с подтверждением каждой
- Операции, которые заблокированы, не проверены или не нужны в текущем объёме
- Пробелы в данных и известные ограничения отчётности
- Полномочия на расходы, прямой способ паузы и ответственный
- Способ отзыва доступа и изменения, требующие повторной проверки
Пример итоговой записи: «Google Search, указанный тестовый кабинет: приняты локальные черновики, создание на паузе и переименование. Рабочая отчётность, публикация, прекращение реальных показов, загрузка конверсий и аудитории не проверены. Реальные рекламные расходы не разрешены». Это учебная формулировка приёмки, а не результат теста SABSUS.
Если необходимая операция заблокирована, ограничьте рабочий сценарий или устраните препятствие. Подключение только на чтение может быть полезно для отчётности. В решении о приёмке оно сохраняет этот объём до проверки и разрешения необходимых операций записи.
Для целей, смысла этапов CRM и ответственности используйте общую инструкцию по настройке SABSUS Ads. Для построения поисковой кампании есть руководство по Google Ads для локального сервиса. Эта проверка отвечает на отдельный вопрос передачи в работу: какие операции доказанно работают в данном кабинете сегодня?