Проставление cm_id
Проставление cm_id создатель Brodskiy Ilya
1. Шаг 1: Есть ли шаблон на уровне кампании?
1.1. Есть. Он 3rd Party?
1.1.1. Нет. Есть в шаблоне валидный cm_id?
1.1.1.1. Нет. Пишем в шаблоне: ?метки клиента&cm_id=
1.1.1.2. Да. Оставляем все как есть.
1.1.2. Да, ничего не делаем.
1.2. Нет.
2. Шаг 2: Есть ли шаблон на уровне группы?
2.1. Есть. Он 3rd Party?
2.1.1. Нет. Есть в шаблоне валидный cm_id?
2.1.1.1. Нет. Пишем в шаблоне: ?метки клиента&cm_id=
2.1.1.2. Да. Оставляем все как есть.
2.1.2. Да, ничего не делаем.
2.2. Нет. Есть ли в группе Template Ad?
2.2.1. Есть. Есть ли шаблон на уровне группы?
2.2.1.1. Нет. Создаем шаблон на уровне группы ?cm_id=
2.2.1.2. Есть. Он 3rd Party?
2.2.1.2.1. Нет. Есть валидный cm_id?
2.2.1.2.2. Да, ничего не делаем.
2.2.2. Нет. Ничего не делаем
3. Шаг 3: Есть ли шаблон на уровне объявления?
3.1. Есть. Он 3rd Party?
3.1.1. Нет. Есть ли в шаблоне валидный cm_id?
3.1.1.1. Нет. Пишем в шаблоне: ?метки клиента&cm_id=
3.1.1.2. Да. Оставляем все как есть.
3.1.2. Да, Есть ли в URL валидный cm_id?
3.1.2.1. Есть. Оставляем все как есть.
3.1.2.2. Нет. Пишем cm_id в URL объявления. Если URL=rbc.ru?, то &cm_id, если URL=rbc.ru, то ?cm_id (пишем как в конечный URL, так и в мобильный конечный URL, если он есть)
3.2. Нет. Есть ли в URL (обычном и мобильном) валидный cm_id?
3.2.1. Нет. Смотрим есть ли в группе и кампании шаблон отслеживания?
3.2.1.1. Есть. Он 3rd Party?
3.2.1.1.1. Да. Пишем cm_id в URL объявления. Если URL=rbc.ru?, то &cm_id, если URL=rbc.ru, то ?cm_id (пишем как в конечный URL, так и в мобильный конечный URL, если он есть)
3.2.1.1.2. Нет. Должны были в шаблоне на уровне группы проставить метку в Шаге 2.
3.2.1.2. Нет. Создаем шаблон на уровне объявления ?cm_id
3.2.2. Есть. Оставляем все как есть.
4. Шаг 4: Есть ли шаблон в быстрых ссылках?
4.1. Есть. Он 3rd Party?
4.1.1. Нет. Есть в нем валидный cm_id?
4.1.1.1. Нет. Пишем ?метки клиента&cm_id=
4.1.1.2. Да. Оставляем все как есть.
4.1.2. Да. Пишем cm_id в URL объявления. Если URL=rbc.ru?, то &cm_id, если URL=rbc.ru, то ?cm_id (пишем как в конечный URL, так и в мобильный конечный URL, если он есть)
4.2. Нет. Есть ли в URL (обычном и мобильном) валидный cm_id?
4.2.1. Есть. Оставляем все как есть.
4.2.2. Нет. Создаем шаблон на уровне быстрой ссылки ?cm_id
Интеграция сквозной аналитики CoMagic: негативный опыт
В качестве product manager на проекте франшизы (по просьбе компании не указывается название) мы попробовали внедрить CoMagic в качестве инструмента сквозной аналитики. На этом кейсе покажем особенности, слепые зоны этой платформы; как и где могут теряться лиды.
Вводные. Стек технологий: Tilda + CoMagic + AmoCRM. Каждый объект партнерской сети находится на отдельном url — классическая удобная схема с точки зрения SEO и поведенческих факторов ЦА. Под каждый объект в отчете должна создаваться воронка с показателями: посещаемость (в разрезе источника), заявки (в разрезе источника), конверсия, CPA. На каждой странице присутствует минимум 3 лид-формы.
Подключение по API
Это франшиза, и новые объекты появляются регулярно. Сеть быстро растет. Поэтому постоянное подключение к CoMagic каждой лид-формы отдельно — слишком трудозатратно. Необходимо подключение по API, чтобы заявки автоматически сохранялись при создании любой новой страницы и лид-формы. Менеджеры CoMagic за отдельную плату предлагают только вариант с отдельным подключением лид-форм. Выбираем API только с самостоятельной интеграцией, используя манул CoMagic т.к. готового коннектора с «Тильдой» нет. Подключаем, правим с разработчиками конфликты. Например, «имя» обязательный параметр для отправки заявки в Comagic. Правим, что если нет имени, то вместо него подставляется телефон и заявка отправляется. И так далее по каждому расхождению с AMO по итоговому количеству заявок за период.
CoMagic никак не консультирует по API и не оказывает помощи в конфликтах данных.
Настройка источников заявок
После сохранения заявок в системе CoMagic начинаем настройки Рекламных кампаний (источники заявок). Отслеживание заявок с поискового трафика, любых внешних сайтов; картографических сервисов, конкретных сайтов, taplink — настраиваются более или менее точно. Проблемы начинаются c платными каналами.
Изначально пробуем настроить работу распознавания источников заявок по utm. Отдельные площадки привязываем к домену реферера или конкретной utm источника типа . Instagram и Facebook привязываем с чуть большей вариативностью:
Создаем дэшборд по объекту с помощью предустановленного виджета. Получаем конфликт посещений и обращений: на 12 обращений — 10 посещений с одной и той же страницы. Значения посещаемости не верны.
Через несколько писем с поддержкой оказывается, что для сбора посещаемости на url необходимо создать заранее отдельный сегмент и потом его привязать к дэшборду. Согласны с тем, что нецелесообразно захламлять сервера записями всех посещений по всем страницам, если нужны только отдельные посадочные. Сбивает столку, что первая сессия и менеджеры никак на этот функционал не указывают . Настраиваем все сегменты в разделе «Аналитика»-«Сегменты», в который будут попадать посетители, которые перешли на нужную страницу.
Итак, мы подцепили нужный сегмент (посещения) в дэшборд и создали рекламные кампании (источники трафика). Теперь надо подтянуть расходы на рекламу из Facebook.
Синхронизация с Facebook BM
В процессе настройки синхронизации расходов приходит понимание, что настройка по utm — ошибочная стратегия. Не понятно почему ее до сих пор рекомендуют менеджеры CoMagic. CoMagic не обладает достаточной функциональной гибкостью, чтобы подгружать расходы в отчеты и дэшборды, самостоятельно вручную или с помощью csv выгрузок из Facebook. Также при настройке отчетов по объекту надо учитывать сложное устройство кабинета Facebook. На один объект могут приходиться разные рекламные кампании с разных ID рекламных аккаунтов и даже с разных Facebook Business manager.
Скриншот структуры Facebook Business Manager
Убрали сегменты по utm и установили сегмент «Интегрированные рекламные кампании Facebook», как отдельный источник трафика. Это стало возможно после синхронизации админского профиля Facebook, управляющего действующей рекламной кампанией.
Процесс синхронизации является самым нестабильным во всей системе CoMagic. Каждый id рекламного аккаунта Facebook надо было синхронизировать отдельно, и по ходу синхронизации какие-то кампании отваливались. Без изменений на клиентской стороне, на платформе менялось описание ошибки в течение 3 недель.
Скриншот интерфейса CoMagic. Интеграция с внешними сервисами.
Проблему решили, но оказалось, что расходы по всем кампаниям не тянутся, т.к. при интеграции автоматически не добавилась в объявлениях необходимая метка cm_id. Метку пришлось добавлять во все объявления вручную, что, естественно, нарушило систему обучения Facebook и снизило количество заявок по всем кампаниям.
По итогу внедрения правки, приступаем к новой итерации сверки данных: Google.Analytics (посещаемость), Tilda (заявки), FB Business manager (Расходы). Находим еще 2 проблемы. CoMagic несмотря на успешную синхронизацию с формами FB (прямые лид-формы от FB), не может выводить информацию по ним в дэшбордах. Также в настройках виджета нельзя было поставить оператор «и», чтобы тянуть расходы из двух кампаний, а не одной.
Чтобы решить эти проблемы пришлось мигрировать все отчеты в новую версию Личного кабинета, о которой есть отдельная статья на vc. Здесь становится понятна ключевая проблема CoMagic: идет функциональное развитие именно нового кабинета, что тянет за собой меньший приоритет устранения багов на прошлом, конфликт функций, управление какими-то функциями в обоих кабинетах и т.д. В новом кабинете каждую неделю возникают проблемы:
- часть элементов интерфейса не кликабельна;
- конфликты в значениях данных, которые раньше были в порядке;
- проблемы с кэшем при обновлении страницы.
Помимо верхнеуровневых проблем с построением простой воронки по объекту, в CoMagic много мелких недочетов, которые приходится анализировать самостоятельно, т.к. саппорт не обладает техническим бэкграундом. Например, на платформе действует правило, которое считает равнозначными нижнее подчеркивание и дефис в урле, и поэтому объединяет данные по 2 разным страницам. Также на платформе есть объединение сессии вокруг одного пользователя, что удобно, чтобы видеть первый клик и вычленять повторные заявки.
Информация по заявкам тестового пользователя в CoMagic
При этом в дэшбордах эти заявки выводятся как разные — нельзя поставить фильтр на «качественные заявки».
В конце, немного про коммуникацию с CoMagic: очень много менеджеров, раздутый колл-центр, постоянная дезинформация, неправильные инструкции, постоянное перекидывание задач с менеджера на менеджера, при том факте, что «закрепленный менеджер», вроде как есть. Между ответами могут пройти недели. Сами менеджеры CoMagic допускают ошибки в настройке отчетов. Стоит подчеркнуть, что наша схема дэшбордов примитивна с точки зрения функционала платформы:
- строим посещаемость по сегменту к источнику заявок;
- строим заявки к источнику по интегрированным кампаниям;
- строим расходы по интегрированным кампаниям.
И это только попытка подключить один рекламный источник и классические лид-формы, а не заявки в мессенджерах, google.формы и т.д.
Из плюсов CoMagic: очень хороший потенциал платформы и быстрый баг-фикс. Несмотря на множество проблем, платформа тратила ресурс на их решение, хоть и иногда ломала что-то другое. Думаю, будет лучше, но через год, как протестят новый личный кабинет.
В CoMagic — новая сквозная аналитика. Как и почему мы полностью пересобрали свой продукт
Новые отчеты позволяют анализировать ROMI по ассоциированным каналам рекламы и смотреть расходы по 60 срезам маркетинговых данных. Все это дает понимание, сколько денег и на какие каналы продвижения нужно потратить, чтобы расти по выручке и окупать расходы на маркетинг.
Пришло время немножко все переписать
Когда у тебя есть работающая платформа, но стек ее технологий безнадежно устарел, самое сложное — признать, что проще написать новую, чем дорабатывать старую. Мы поняли, что иначе не сможем предоставить то качество продукта, которое позволит нам развивать рынок дальше.
Нам пришлось поменять хранилище данных, архитектуру продукта, встать по релизам на большой срок, провести множество исследований и привлечь внешних экспертов, сделать еще много чего, о чем вскоре обязательно расскажем. Зато теперь мы без угрызений совести можем представить обновленный продукт «Сквозная аналитика».
Что у нас получилось
1. Анализ рекламы по когортам посетителей
Главные принципы, которых мы придерживались, — это удобство, гибкость и скорость отчетов, нацеленных на анализ маркетинговых затрат. Все они отразились в новом отчете «Анализ рекламы».
Отчет имеет древовидную структуру, в нем представлены более 60 группировок срезов данных для анализа расходов на продвижение и сегментов посетителей. Он формируется в зависимости от когорты посетителей за период, выбранный в календаре отчета, и его можно строить по 8 моделям атрибуций (не считая ассоциированных конверсий). Теперь поясним, что все это значит.
Приведем пример
Вы запустили рекламу в первую неделю февраля, затем что-то переделали и запустили изменения со второй недели. В «Анализе рекламы» вы сможете сравнивать эти две недели в реальном времени по тому, как они участвуют в привлечении лидов, и прогнозировать отдачу от рекламы. Анализируя эти две недели февраля в мае, вы увидите все конверсии выбранной когорты, в том числе мартовские, апрельские и майские. Таким образом, вы можете увидеть, что при равных расходах, часах посещений и других характеристиках аудитории посетители первой недели быстрее конвертировались в продажу по последнему взаимодействию, но посетители второй недели привели больше продаж ассоциированно.
2. Анализ рекламы по различным разрезам данных
Главный вопрос, на который отвечает сквозная аналитика: какую рекламу я должен покупать, чтобы расти по выручке и окупать расходы на маркетинг?
Чтобы на него ответить, мы научились рассчитывать расходы для любых разрезов данных. Как уже было отмечено ранее, новый отчет можно строить по 60 различным параметрам. Например, посмотреть CPL в разрезе устройства, региона посетителя, страницы входа и страницы обращения — и все это одновременно, в одном окне!
Наши интеграции с рекламными системами и CRM будут без вашего участия загружать данные о расходах и выручке, а если вашей системы нет в списке готовых интеграций, у нас существует множество инструментов для загрузки этих данных.
Время для еще одного примера
Вы запустили новый продукт и сделали под него посадочную страницу. На продвижение продукта выделили бюджет. Вы сможете построить отчет с такими группировками (измерениями): «Посадочная страница» — «Источник» — «Рекламная кампания» — «Объявление» — «Страница обращения». На любом уровне этих измерений (на самом деле, любых измерений, которые вы добавите в отчет) будет рассчитываться CPL по настроенным моделям атрибуций для каждого события.
3. Группировки для анализа рекламы по содержанию тем в UTM-метках
Часто бизнес, который занимается продвижением нескольких продуктов или услуг, использует один общий бюджет на рекламную кампанию. В итоге маркетологам сложно понять, сколько денег они потратили на рекламу одного продукта, а сколько на рекламу другого. Или другой случай: бизнес для разных проектов пользуется услугами разных рекламных агентств, но какое из них работает эффективнее?
Чтобы ответить на эти вопросы, маркетологи «вшивают» сложносочиненную конструкцию в UTM-метки. В помощь специалистам мы предложили решение — группировки: по ним можно соотнести рекламные источники по содержанию тем, вшитых в UTM-campaign.
А тут место для двух примеров
Вы работаете в клинике, у вас пара десятков направлений в портфеле, и по каждому из них стоит KPI в лидах. У нас в отчете вы можете создать по группировке на каждое направление, где группировка будет формироваться по упоминанию направления в UTM-метках, названию рекламной кампании в коллтрекинге, названию группы объявлений и множеству других атрибутов источников. В разрезе этих направлений вы сможете анализировать, какие площадки лучше работают, сравнивать стоимость лида по направлениям, видеть, по какому направлению больший LTV у лидов, и просто сфокусированно работать с привлечением лидов на конкретное направление.
При корректной разметке utm именами подрядчиков, которые ведут ваши проекты, вы можете вывести эти имена в отчете как измерение (разрез данных). Это позволит сравнить эффективность работы каждого подрядчика по разным площадкам и таким метрикам, как конверсия из обращения в сделку, из первого этапа сделки в продажу, средний чек, LTV, и множеству других срезов и показателей.
4. Столбцы с собственными показателями
Когда нужные срезы данных собраны, на сцену может выйти другая проблема — правильный подсчет метрик. Мы сделали калькулируемые столбцы: в них можно вывести нужные вам метрики и даже задать собственные. То есть реализовать какую угодно формулу подсчета, не выгружая отчет в Excel, добавив в расчет CPL, ROMI или другой метрики нужный вам коэффициент. И все это с выбором модели атрибуции.
И еще пример
Один из главных инструментов маркетолога — воронки. Мы добавили возможность построить любую воронку. Допустим, такую для интернет-магазина по продажам межкомнатных дверей:
> посетители, пришедшие впервые на сайт
> посетители, которые были на страницах с межкомнатными дверьми
> посетители, которые обратились в отдел продаж
> посетители, которые прошли через замер
> продажи дверей конкретного производителя по первому взаимодействию
> продажи дверей конкретного производителя по последнему непрямому взаимодействию
А возможность создания в столбцах собственных формул позволит вам построить метрики со стоимостями каждого из этапов и конверсиями из этапа в этап.
5. Кастомные отчеты для каждого пользователя
При такой свободе выбора срезов данных становится сложно уследить за показателями и пересобирать отчеты. Мы это понимаем, поэтому создали возможность сохранять конкретные сборки отчетов, и теперь каждый пользователь нашего продукта может завести себе сколько угодно преднастроенных отчетов.
6. Качественный анализ
Цифры цифрами, но без качественного анализа никуда. Мы добавили возможность перехода в список обращений и сделок по клику на количество по любой модели атрибуций. Из отчета по сделкам вы можете перейти в карточку сделки в CRM-системе, а в отчете по обращениям прослушать звонок или прочитать чат. Это даст вам пищу для размышлений: соотносится ли содержание общения покупателя с содержанием креатива? Может, нужно переставить акценты в креативе, а может, поправить скрипт общения менеджера по продажам?
И это только начало!
Это наши первые шаги и первые изменения в продукте, у нас грандиозные планы на его развитие в новой реинкарнации. Хотите проанализировать ваш маркетинг по-новому? Заходите на сайт, оставляйте запрос на демо, и наш менеджер обязательно вам все расскажет и покажет.
4.7K открытий
14 комментариев
Написать комментарий.
Интересно посмотреть на отклик интерфейса не с 50 заявками, а с 1000.
Еще не понял что за календарь такой.
Развернуть ветку
Высокая скорость отклика нового личного кабинета — одна из его главных технических особенностей. Он быстро справится с обработкой данных на 1000 и куда большим числом заявок. Чуть позднее мы выпустим статью с разработчиками, в которой они расскажут, как нам удалось сделать один из самых быстрых интерфейсов на рынке. Но уже сейчас мы можем провести вам демо-тур вместе с нашим продуктологом, на котором вы в реальном времени убедитесь в отличной скорости работы нового продукта.
Развернуть ветку
от создателей «мы сделаем интеграцию с колтрегингом за час», а через месяц сами уже отказались, «да и ваще менеджер которые это обещал 2 недели назад уволился»
Развернуть ветку
Мы и в правду можем говорить о быстром внедрении при определенном наборе инструментов на стороне клиента. Не для всех есть нативное решение, но этот список постоянно пополняется.
Для всего остального у нас есть Отдел проектных решений. Его специалисты сделают интеграцию с неизвестными нам ранее системами, если это возможно. Каждый подобный случай нужно рассматривать отдельно.
Развернуть ветку
Комментарий удален модератором
Развернуть ветку
Новый интерфейс уже опубликован и доступен для наших пользователей. Демо-кабинет на сайте обновим в ближайшее время
Развернуть ветку
Подскажите, а по полу/возрасту с контекста можно будет анализировать данные в разрезе устройств, страницы, времени и т.д.?
Развернуть ветку
Такая задача лежит в беклоге)). Можно будет, но со временем. Кабинет будет постоянно развиваться и добавляться новые возможности.
Развернуть ветку
Вижу что есть интеграция с Facebook Ads. Вопрос: вы учитываете только постклик атрибуцию Facebook? Или сделали что-то интересное на основе Facebook Attribution?
Хотя вот тут ответ, что у вас совсем не сквозная аналитика . а только постклик. Ну и в фб не бывает CPC модели. https://www.comagic.ru/services/analytics/assets/img/1.gif
Развернуть ветку
Петр, в настоящий момент связки с facebook attribution нет. После того, как мы доведем до конца всё запланированное с новым интерфейсом, мы пойдем в обновление интеграций с FB и другими платформами. Возможно, что facebook attribution сможет дополнить наши отчеты.
Мы все же пошли дальше, чем last click 🙂
Для примера приведем несколько цепочек:
фб — яндекс директ — прямой заход (first click)
яндекс директ — фб (last click)
фб — яндекс директ — SEO — фб (first click) / (last click) // при этом total (1)
Чтобы детальнее разобраться, приходите использовать. Сможем разобрать все интересные случаи и познакомим с тем, что осталось за кадром.
По поводу второй части, давайте чуть разберемся с FB и CPC — https://www.facebook.com/business/help/683065845109838
И помогите немного с вашей формулировкой по поводу gif, что именно вас смутило?
Развернуть ветку
Эм. вы не в теме ) позовите того кто шарит у вас .
Мне ваще не интересна постклик атрибуция, так как её умеет делать абсолютно все.
Внимание! Мне нужна поствью атрибуция. именно она.
Показ на фб >>> запрос в яндексе >>> клик по выдаче яндекса.
Сейчас так в Рунете никто не умеет, так как нет конектора с facebook attribution.
Про CPC. Facebook Ads это медийная платформа, в ней кампания не может называться так, как на вашей гифке «Facebook post paid CPC», так как модель оплаты CPM, а модели PPC(CPC) там нет и никогда не было. вы дали ссылку на параметр из статы.
Чтобы аналитика была сквозной, вы должны уметь видеть рекламный показ у фб, гугла, майтаргета, и других платформ, а вы видите только клик (конкретно у фб).
Развернуть ветку
В этом раунде отвечает команда знатоков)). Петр, поствью аттрибуции у нас нет. Название кампании может быть любым, его задает сам пользователь, как ему удобно. В примере название подобрано без привязки к модели монетизации FB.
Развернуть ветку
Производительность наших отчетов мало зависит от “просто количества заявок”. Главное, какие дополнительные инструменты и их сочетание задействованы при анализе. Однако даже при beta-тестировании с самым “комплексным” клиентом мы производим положительное впечатление по скорости загрузки (а он использует вложенности, модели атрибуций, цели, подтягивает все расходы, добавил несколько своих столбцов). Для примера мы засняли для вас работу кабинета с данными более 1000 заявок. (Откройте гифку в новой вкладке для удобства просмотра).
По календарю: режим сравнения находится в бета-тестировании и в нем UX еще дорабатывается, поэтому такое отображение в обратном порядке временно. В рамках тестирования пробуем разные варианты. Весь функционал рботает корректно, а вот UX будет допиливаться. Из теста выйдет то, что будет самым удобным образом реализовано.
Развернуть ветку
А доход показан та тот же период, что указан сверху или это весь доход с посетителей за этот период?
Развернуть ветку
В отчете «Анализ рекламы» мы посчитаем доход (выручку), как вы и предполагаете во втором варианте, по когорте посетителей за выбранный период.
Пример: вы продвигались в апреле этого года с рекламной кампанией «улётный корпоративный летний отдых» на одной из площадок. Выбираете в отчете «Анализ рекламы» период «апрель» и смотрите, как эта реклама отработала на текущий момент — результаты могут быть так себе.
Но благодаря тому, что мы можем отобразить в отчете промежуточные этапы, провал такой рекламной кампании в 2020 году получилось бы увидеть не сейчас, а гораздо раньше, в мае-июне, когда по сравнению с другими активностями по конкретно этой рекламной кампании не было выручки, лидов, брони мероприятий и достижения других ключевых метрик
Посмотреть выручку по всем сделкам за выбранный период, как в вашем первом варианте, можно в другом нашем отчете — «Анализ сделок».
Мониторинг рекламных вставок
«Делать деньги без рекламы может только монетный двор».
Томас Бабингтон Маколей, британский историк, публицист и политический деятель
Реклама — неотъемлемая часть телевещания. С её помощью предприниматели продвигают свои товары и услуги, а средства массовой информации получают прибыль.
Продажа эфирного времени — существенная, а порой и единственная статья доходов для телеканалов. Так например, телекомпания NBC заработала 70 миллионов долларов на показе последнего эпизода «Друзей» в 2004 году: каждый 30-секундный рекламный блок стоил два миллиона долларов. Это был рекордный сбор и рекордная цена для развлекательного шоу. А минута рекламы во время трансляций матчей Чемпионата мира по футболу-2018 на «Первом канале» и «России 1» стоила 7,5 миллиона рублей. Но абсолютным рекордсменом принято считать рекламные блоки во время Супербоула, финальной игры за звание чемпиона НФЛ США в американском футболе: стоимость рекламного слота в 2021 году составляет около $5,5 млн.
Как мы видим, суммы внушительные, и это большая ответственность на плечах тех, кто предоставляет рекламу. Необходимо тщательно следить за технической реализацией вставки и контролировать качество процесса.
В этой статье мы рассмотрим, как реализуется вставка рекламы в транспортный поток и в потоки при адаптивном вещании в форматах HLS и MPEG-DASH, а также разберемся, как тем, кто предоставляет эфирное время для рекламы, избежать споров и судебных процессов с заказчиками.
Для выделения эфирного времени под рекламу в телевещании широко используются метки SCTE-35. По этим меткам специальное оборудование — сплайсер — врезает рекламу в поток. В процессе работы сплайсер непрерывно обращается к FTP-серверу, запрашивая актуальное расписание врезки и заранее подготовленные файлы рекламы. Когда расписание обновляется, сплайсер сверяет список хранящихся медиафайлов с запланированными к врезке и при необходимости скачивает недостающие файлы с FTP-сервера. Метки SCTE-35, приходящие в транспортном потоке, обозначают начало и окончание врезки.
Проблем с предоставлением рекламы может возникнуть довольно много. Все начинается с первоначальной вставки меток SCTE-35 в поток. На этом моменте необходимо точно выделить эфирное время для рекламы в потоке и вставить нужные метки. Некоторые пакеты в транспортном потоке могут быть утеряны, поэтому стандарт предусматривает повторение меток.
Синтаксис полезной нагрузки метки SCTE-35 называется splice_info_section (). Он сигнализирует об одной из шести команд. Команды Splice_schedule() и Splice_insert() предназначены для передачи информации о предстоящей вставке рекламы. Также существует ряд вспомогательных команд: Splice_null(), Bandwidth reservation(), Time_signal(), Private_command(). Однако, в основном для вставки рекламы используются команды splice_insert() и time_signal().
- Команда Splice_null() не передает какие-либо данные и используется для проверки отклика от устройств — получателей сообщений. Кроме того, периодическая вставка этой команды позволяет избежать срабатывания триггеров TR101290 — PID_error.
- Команда Bandwidth reservation() передает системе компрессии запрос на выделение дополнительной полосы пропускания, которая будет использоваться для передачи элементарного PID-потока с сообщениями SCTE-35.
- Команда Time_signal() используется для передачи меток точного времени, на основании которых устройства-получатели команды синхронизируют свои действия с устройствами-отправителями.
- Команда Private_command() может использоваться для передачи других данных, не оговоренных в спецификациях SCTE-104/35.
Рассмотрим одну из главных команд метки SCTE-35 в транспортном потоке — splice_insert():
Здесь стоит обратить внимание на элемент out_of_network_indicator. Значение «1» означает вход в рекламную вставку, значение «0» — выход. Эти элементы еще обозначаются как cue-out (выход из программы и вход в рекламный блок) и cue-in (выход из рекламного блока, возвращение в основной поток). В дальнейшем разберем эти элементы на примере.
Проблемы могут быть связаны и с непосредственно врезкой рекламы: в этом процессе довольно много нюансов, которые стоит учитывать.
Вот несколько примеров:
- Врезка рекламы сплайсером должна осуществляться точно в указанное время, описанное в метке SCTE-35, ни кадром раньше или позже;
- Рекламный блок не должен отличаться по своей структуре от основного потока (кодек/битрейт/GOP/громкость и т. д);
- Рекламный блок должен начинаться строго с I-кадра, иначе первый GOP рекламной вставки будет испорчен.
Мониторинг рекламных вставок в IPTV
Учитывая вышеописанные нюансы, а также помножив их на количество регионов, где используется местная реклама, возникает вопрос: как же уследить за качеством процесса?
Рассмотрим вставку рекламы на реальном потоке в системе мониторинга Boro.
График вставки рекламы
На графике видим три метки, предвещающие вставку рекламы. Затем начинается сама вставка, и эскизы потока создаются чаще. Рассмотрим более детально, что именно происходит в потоке в эти моменты.
Журнал событий в Boro
Первая метка указывает, что должна начаться реклама: , «out_of_network_indicator:true” (true означает 1, или cue-out, вход в рекламу) в конкретно указанное время: «pts_time»:»25:40:54.394”.
“auto_return»:true — означает, что из рекламного блока необходимо выполнить cue-in (выход из рекламы) автоматически по истечении 120 секунд («duration»:120”),
PID, по которому идут метки — «pid»:1015 .
Вторая и третья метка полностью дублируют информацию и идут с интервалом в 2 секунды. Дублирование производится на случай потери пакетов в потоке.
Далее идет непосредственно вставка рекламного блока уже на основании полученных меток: «action»:»start».
Спустя 120 секунд происходит выход из рекламного блока: «out_of_network_indicator»:false / «action»:»stop».
В рассмотренном примере вставка рекламы прошла без каких-либо проблем. Но если в метке содержатся ошибки, то система мониторинга проверяет целостность CRC. В случае несоответствия она сообщает об этом и выводит подробности в журнал событий для дальнейшего анализа. Кроме того, пользователи могут сформировать отчет об ошибках, чтобы предоставить его ответственным лицам.
Ошибки могут быть следующих типов:
- ошибка чтения бинарных данных в транспортном потоке или теге HLS. В параметрах передаются неверные значения, приведшие к ошибке;
- ошибка проверки CRC32 при чтении бинарных данных в транспортном потоке или теге HLS;
- несоответствие информации в бинарных данных тега и самом теге HLS плейлиста. Подробности представлены в параметрах в виде двух значений в формате tag_ и binary_.
Мониторинг рекламных вставок в OTT
ОТТ вещание открыло новые преимущества для вставки рекламы, но и принесло свои трудности.
С одной стороны, реклама стала персонализированной, так как каждое устройство устанавливает индивидуальную сессию, это позволяет показать зрителю то, что его потенциально интересует. Кроме того, в ОТТ вещании не требуется соответствие рекламного блока основному потоку, поскольку каждый сегмент ОТТ вещания декодируется устройством отдельно, и это упрощает сплайсинг рекламы.
С другой стороны, SCTE-35 метки могут находиться не только в транспортном потоке, но и в плейлисте. Т. е. метки дублируются, что в принципе проблемой не является, но и корректным вариантом потока такую ситуацию назвать нельзя. Метки в плейлисте тоже могут потеряться, но уже не из-за пропадания пакетов, а по другим причинам, например, оборудование могло не записать метку в плейлист при обновлении.
Boro отслеживает следующие события, происходящие с вещанием.
Вставка рекламного блока SCTE-35. Срабатывает, когда зонд определяет начало вставки рекламного блока (по информации из полученных меток SCTE-35). Состояние снимается, когда зонд определяет завершение рекламного блока. Это событие является основой для некоторых событий, которые определяют проблемы со вставкой рекламы.
Вставка превышает заданную длительность. Срабатывает, когда длительность рекламного блока превышает установленный период. Период отсчитывается с момента определения зондом начала рекламного блока по событию «Вставка рекламы».
Ошибка распознавания меток SCTE-35. Срабатывает, когда регистрируется ошибка распознавания меток вставки рекламы. В сообщении возвращаются подробности ошибки.
Вставка рекламного блока SCTE-35 отсутствует. Срабатывает, когда зонд в течение установленного времени не обнаруживает начало вставки рекламного блока в программу (по информации из полученных меток SCTE-35). Состояние снимается, когда зонд определяет начало рекламного блока. Триггер реализован на основе события «Вставка рекламного блока SCTE-35».
Метки SCTE-35 не найдены в плейлисте. Срабатывает, когда зонд не находит каких либо меток вставки в плейлисте в течение установленного времени. Триггер реализован на основе события «Метка SCTE-35 из OTT-плейлиста». Данное событие может быть полезно в ситуации когда мы уверены, что реклама должна быть за определенный промежуток времени, но по каким-либо причинам метки SCTE-35 в плейлисте отсутствуют и вставка рекламы не происходит. В этом случае необходимо искать причины потери меток в плейлисте.
Заключение
Мониторинг рекламных вставок — довольно непростая задача по множеству причин, но с ней можно справиться с помощью правильного инструмента.
Elecard Boro журналирует каждую метку вставки, найденную в потоке или в плейлисте. Что, вкупе с возможностью записи по приему метки и эскизами потока, позволяет провести детальное исследование произошедшего. Boro позволяет проверять целостность метки и возможности ее декодирования. А триггеры на отсутствие вставки рекламы или слишком длительной вставки, помогают своевременно выявить неполадки в работе системы врезки рекламы.
Автор
Вадим Блинов
Менеджер продукта Elecard CodecWorks c 2016 года. Опыт работы в сфере видеокодирования более 5 лет.