Проверять связку полей, а не красивое имя
Покупатель видит в отчёте знакомое название онлайн-кинотеатра. Это удобная подпись, но она не удостоверяет источник каждого показа. Название может быть сокращено, переименовано или ошибочно подставлено посредником. Для расследования нужен исходный идентификатор и сведения о среде, из которой поступила возможность показа.
В объекте App спецификации OpenRTB различаются внутренний идентификатор биржи, идентификатор приложения в магазине `bundle` и ссылка магазина `storeurl`. Формат bundle зависит от магазина: это не всегда строка, похожая на название пакета Android. Поэтому автоматически требовать один формат от всех CTV-магазинов неправильно.
Даже согласованные поля не доказывают подлинность. Злоумышленник способен скопировать достоверное название и идентификатор. Задача первоначальной проверки скромнее: выявить противоречия и понять, какие дополнительные подтверждения запросить. Вывод о мошенничестве требует совокупности свидетельств.
Пройти цепочку от магазина к продавцу
Откройте указанную карточку приложения и проверьте магазин, идентификатор, разработчика и поддерживаемую среду. Затем установите сайт разработчика, связанный с этой карточкой. Не подставляйте домен только потому, что его название похоже на бренд приложения.
Для декларации разрешённых продавцов используется app-ads.txt. Документ расширяет подход ads.txt на приложения, включая CTV. Получите актуальный файл на подтверждённом домене разработчика. Затем сверьте пару полей из закупки, домен рекламной системы и идентификатор аккаунта продавца, с парой в строке файла. Сохраните время проверки: текущий файл может отличаться от того, который действовал в день закупки.
Документация Google for Developers иллюстрирует связь app-ads.txt с сайтом разработчика. Она приведена как технический пример, не как рекомендация запускать Google-рекламу в России и не как универсальная инструкция для всех телевизионных магазинов. Для каждого магазина проверяйте его собственную схему идентификации.
Разобрать три учебных расхождения
В вымышленном журнале строка А содержит согласованные магазин и идентификатор, но на день проверки не удалось получить файл продавцов. Строка Б ведёт на карточку другого приложения. У строки В магазин и bundle согласованы, однако аккаунт продавца не найден в полученной декларации. Это три разные задачи, их нельзя объединить статусом «доказанный фрод».
По А нужно проверить доступность домена, историю получения и допустимость такого источника по условиям закупки. По Б сохранить исходный запрос и выяснить, ошибка ли это сопоставления отчёта или неверное заявление источника. По В сверить аккаунт, рекламную систему, домен разработчика и возможные предусмотренные схемой отношения продавцов.
Скачайте учебный журнал CSV. В нём нет реальных обвиняемых компаний: приложения и результаты условные. В рабочем журнале понадобятся ссылка на исходное событие, время, ответ партнёра и владелец решения по каждой строке.
Отсутствие нужного поля тоже важно. Если поставщик возвращает только общее название приложения, покупатель не сможет выполнить эту сверку. Тогда вопрос стоит о достаточности данных и приемлемости источника для конкретного задания, а не о вычисленной частоте подмены.
Сопоставить заявление с доставленным показом
Заявленный тип устройства и среда показа должны согласовываться с другими доступными свидетельствами. Но один необычный параметр устройства или адрес сети не даёт надёжного ответа. Серверная вставка рекламы и промежуточные сервисы меняют путь событий; при SSAI нельзя механически ожидать браузерную цепочку на телевизоре.
Попросите партнёров связать спорный запрос с фактической доставкой и доступными журналами площадки. Персональные и технически чувствительные сведения передают только в разрешённом объёме. Скриншот работающего приложения подтверждает его существование, но не доказывает, что конкретная оплаченная строка пришла из него.
Если часть инвентаря нельзя подтвердить, покажите её отдельным объёмом неизвестного происхождения. Нельзя автоматически объявить её валидной, но и записать всю в мошенническую было бы необоснованно. Согласуйте временное ограничение спорного пути, сохранив данные для расследования.
Закрыть проверку объяснением и действием
В российской CTV-закупке полезно заранее согласовать обязательные поля отчёта, срок ответа и порядок ограничения источника. При подтверждённой ошибке сопоставления нужен исправленный отчёт с версией и объяснением затронутого периода. При подтверждённом нарушении условий действуют по согласованной процедуре возврата или компенсации.
Для понимания роли прямого продавца и посредника есть разбор DIRECT и RESELLER. Сам по себе RESELLER не означает подмену приложения, а DIRECT не удостоверяет каждый показ. Первую проверку начните с нескольких крупнейших строк CTV-отчёта: можете ли вы восстановить для них магазин, приложение и разрешённого продавца.
