Настраиваем динамические объявления «Яндекс.Директ»

Фантазия каждого маркетолога — оптимизированная контекстная реклама. Чтобы объявления быстро настраивались, максимально полно отвечали на запрос пользователя и показывались по низкочастотным запросам без конкуренции, а клики стоили копейки…

С динамическими объявлениями это не просто мечта, а почти реальность. По крайней мере, так говорят. А как на самом деле — давайте разберёмся.

Что это и зачем нужно?

В «Гугл Рекламе» давно есть возможность использовать динамический контент и в поисковых объявлениях, и в ремаркетинге. Как настроить динамический ремаркетинг в «Гугл Рекламе» писал мой коллега Павел Сербулов.

И — о, чудо! — теперь такая возможность появилась и у «Яндекса».

Что за динамические объявления? Они похожи на обычные, с той лишь разницей, что заголовок и целевую страницу в них подбирает робот в соответствие с запросом пользователя.

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

Важно

В официальной справке «Яндекса» сказано, что динамические объявления служат дополнением к обычным кампаниям. Можно создать только кампанию с динамическими объявлениями, но «Яндекс» не гарантирует её корректную работу.

Динамические объявления выглядят как обычные текстовые и содержат все атрибуты: быстрые ссылки, отображаемый URL, уточнения. Но заголовок в них может быть только один.

Преимущества динамических объявлений:

• они наиболее полно отвечают на запрос пользователя;
• могут охватить такое количество запросов, которое не покроют кампании, созданные вручную;
• показываются по запросам, которых нет в семантике по причине их более позднего появления, и низкочастотным запросам, которые в обычных кампаниях получили бы статус «мало показов».

Наш кейс

Мы решили проверить, действительно ли динамические объявления так эффективны, как о них говорят, и проверили новшество на интернет-магазине с большим ассортиментом.

Как мы настраивали динамические объявления в Яндекс.Директ

В первую очередь сделали фид и загрузили его в соответствующем разделе аккаунта.

Дальше сделали три рекламные кампании типа «Динамические объявления» на разные регионы.

Внутри каждой — общие группы («Овощи», «Ягоды», «Плодовые») и несколько групп под отдельные категории товаров («Лук», «Картофель»).

Важно

Выбрать источник данных (фид или сайт) нужно при создании группы объявлений. После сохранения настроек изменить условие уже нельзя.

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

Чтобы отслеживать условия нацеливания, по которым было показано динамическое объявление, не забыли добавить в UTM-метку параметр {adtarget_name}:

utm_source=yandex&utm_medium=cpc&utm_campaign={campaign_id}&utm_term={adtarget_name}_{adtarget_id}

Заголовок объявления писать не нужно — система сама его сгенерирует, сопоставив поисковый запрос пользователя и данные из фида.

Мы просто написали универсальные тексты объявлений, заполнили быстрые ссылки, уточнения и визитку.

Для каждой группы объявлений настроили фильтр на соответствующую категорию товаров фида и разрешили показывать только товары в наличии.

Особенности работы динамических объявлений

К сожалению, ни в отчёте «Яндекс.Директа», ни в «Яндекс.Метрике» нельзя увидеть полный текст динамических объявлений, по которым пользователи перешли на сайт. Чтобы узнать, какие заголовки система подставляет в объявления, нужно сформировать отчёт с помощью функции «Заказать отчёт».

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

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

В другом случае система выбрала из названия сорта «Огурец Лист F1» только слово «лист», согласно запросу пользователя «f1 f2 на весь лист», и подставила его в заголовок:

Иногда возникает ощущение, что «Яндекс.Директ» подбирает заголовки безо всякой логики.

Например, по запросу со словом «боливар» показалось объявление с заголовком «Помидор», хотя вело оно на страницу сорта помидоров Боливар. А на запрос «кабачок» в заголовок попало и название сорта:

Но в большинстве случаев объявления получаются складными:

Даже при наличии большого списка минус-слов в динамических кампаниях, мусорных запросов хватает:

Проанализировав результаты, мы поняли, что система подбирает соответствующий товар на сайте буквально к каждому слову в поисковом запросе.

К такому невозможно подготовиться. Чтобы как-то сократить поток нецелевого трафика, мы ежедневно анализировали поисковые запросы. Использовали отчёты «Яндекс.Директ», чтобы отсеять «мусор» уже на этапе показов объявлений.

Результат

За месяц со всех динамических кампаний мы получили 147 заказов, оплаченных онлайн. CTR динамических объявлений в 3 раза меньше обычных, что вполне понятно: заголовки, написанные вручную, выглядят красивее. Да и средняя позиция показа была ниже. Цена за целевое действие отличалась не сильно, а цена клика оказалась на 2 рубля меньше.

В результате динамические кампании сработали в плюс. Мы получили 3,44 рубля прибыли на каждый рубль затрат. Но рентабельность обычных кампаний всё равно на 30% выше.

Конверсии мы получили по запросам, неучтённым в классических кампаниях на поиске. Так что можно считать это дополнительной прибылью. Мы выжали из контекстной рекламы чуть больше, чем при использовании только обычных рекламных кампаний.

Вывод

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

В нашем эксперименте динамические кампании показали хороший результат. А что будет, если довести их до идеала, м-м-м…

[EPSB]Настроим эффективные рекламные кампании в «Директе» за вас[/EPSB]

Расскажите в комментариях, какие результаты от динамических объявлений получаете вы.

Пример настройки динамических объявлений в Яндекс.Директ

Что такое динамические объявления в Яндекс.Директ?

Динамические объявления – формат контекстной рекламы, который позволяет генерировать однотипные объявления (различающиеся между собой некоторыми частями, об этом ниже) для сайтов, содержащих в себе большое количество товаров или услуг.

Объявления данного формата никак не выделяются в поисковой выдаче, показываются как обычная реклама.

Пример динамического объявления

При создании таких объявлений нужно понимать, что автоматически формируются следующие его части:

• Заголовок.
• URL-адреса посадочных страниц.
• Отображаемые ссылки.
• Семантические фразы для посадочных страниц также генерируются на основе их содержимого.

Для чего нужны динамические объявления?

Данный формат упрощает процесс создания и настройки контекстной рекламы для сайтов, содержащих в себе большое количество товаров или услуг, в частности, для интернет-магазинов. Создание уникальных объявлений под тысячи товарных позиций – нецелесообразное занятие, когда есть инструмент автоматизации.

Также нужно учитывать тот факт, что в интернет-магазинах часто меняется ассортимент, и каждое такое изменение требует внесения правок в работающую кампанию Директа. При использовании динамических объявлений, изменения вносятся автоматически, например, если товар удален, его объявление также удаляется.

Кроме этого, динамические объявления помогают расширить охват или настроить ретаргетинг, тем самым дополнив собой другие форматы контекстной рекламы.

Для каких товаров и услуг можно создать динамические объявления?

Создать динамическую рекламу в Яндекс.Директ можно для любых товаров и услуг, которые не нарушают текущее законодательство РФ. Но стоит оговориться, есть ряд тематик, которые требуют сертификацию, регистрацию или лицензирование, вот часть из них:

• Азартные игры.
• Алкогольная продукция.
• Благотворительные фонды.
• Букмекеры.
• Деликатные тематики.
• И т.д.

Полный список тематик представлен в справке Яндекса. Если ваша тематика попадает в данный список, то создать динамические объявления не получится.

Как создавать динамические объявления по данным сайта?

1. Для создания кампании переходим в Яндекс.Директ – выбираем соответствующий тип:

Шаг — 1

2. Задаем кампании имя, настраиваем начало ее запуска и расписание показов объявлений.

Шаг — 2

3. Обязательно добавьте визитку организации, эта информация будет отображаться в сниппете.

4. Далее указываем счетчик Яндекс.Метрики. Это позволит анализировать работу кампании в дальнейшем, а также без счетчика не получится настроить автоматические стратегии управления кампанией.

5. Для автоматической корректировки ставок, следующим шагом предлагается указать ценность ключевых целей. Они добавляются и настраиваются в Яндекс.Метрике. Ценность конверсии – сумма, которую приносит одна конверсия. Целей может быть несколько, плюс у каждой из них указывается своя уникальная цена.

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

Выбор стратегии

7. В блоке корректировки ставок можно распределить бюджет в зависимости от типа аудитории (пол, возраст и т.д.), устройств (ПК, мобильный) и региона показа.

8. Минус-слова позволяют отсечь слова и словосочетания, по которым возможен показ данной рекламной кампании. Для коммерческих сайтов обычно исключают информационные запросы, бренды конкурентов (в зависимости от стратегии продвижения) и прочее.

9. В скрытых блоках не забываем отключать расширенный географический таргетинг, указать визитку компании (это увеличит CTR объявлений) и прочие настройки.

Настройка скрытых блоков

10. После настройки на первом экране, жмем «Продолжить».

11. В качестве источника выбираем «Сайт». Здесь есть нюансы, добавляемый ресурс должен соответствовать параметрам:

• Иметь хотя бы одну страницу, содержащую полный список товарных позиций (пример, http://www.site.ru/смартфоны/xiaomi) со ссылками на них.
• Список товарных позиций должен быть статичным, т.е. прогружаемый сразу со страницей (скрипты с отложенной загрузкой должны быть отключены).
• Каждый товар размещается на отдельной посадочной странице, которая содержит заголовок, описание и т.д.
• Все тексты заголовков и описаний должны быть проверены на ошибки, т.к. именно они будут отображаться в некоторых частях динамических объявлений. Не лишним будет учесть размер заголовка и описания в объявлении в 56 символ и 81, соответственно.
• По структуре, на сайте должен быть корректно заполненный каталог, разбитый по категориям. Обращаем внимание, что все категории должны быть заполнены хотя бы одной товарной позицией, в противном случае объявления не создадутся.

Создание кампании

12. Выставляем регион показа, указываем минус-слова. Жмем «Продолжить».

13. На этом этапе предлагается приступить к настройке самих объявлений.

Этап настройки объявлений

14. Заголовок объявления генерируется автоматически на основе данных страницы и изменить его нельзя. Здесь важно учесть тот факт, что тайтл полностью отображается в сниппете, если его длина менее 56 знаков (пробел также считается символом), при превышении длины, в конце ставится троеточия. Для максимального эффекта от динамических объявлений, рекомендуется учесть этот момент и не превышать порог длины заголовка при создании страницы.

15. Текст объявления (длина 81 символ) будет одинаковым у всех объявлений данной кампании, это нужно учесть, включив в него какие-то общие формулировки, подходящие под все товарные позиции. Для снижения количества отказов, рекомендуется настраивать выцеливание по условиям, например, для категории «Смартфоны» один текст объявлений, для «Телевизоры», соответственно, другой. При этом обязательно следите за тем, чтобы текст совпадал с информацией на сайте.

В качестве привлечения внимания, рекомендуется указывать дополнительные преимущества, бесплатную доставку и прочее. Также инструмент позволяет проводить A/B-тестирования.

16. После заполняем уточнения, виртуальную визитку и быстрые ссылки. Данные элементы увеличивают размер объявления и повышают его CTR.

17. Сохраняем объявление.

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

• Структура сайта должна соответствовать требованиям, перечисленным выше.
• URL должен содержать ссылку на страницу, которая в свою очередь, должна ссылаться на товарные позиции.
• Параметр URL предназначен для указания страницы категории, которая должна содержать прямые ссылки на товарные позиции.
• Параметр «Домен» – ссылка на домен рекламируемого сайта.
• «Ссылка на товар — содержит» указывает на товарную позицию или категорию на сайте.

Как создавать динамические объявления на основе фида?

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

Создание фида

Яндекс делит типы бизнесов на категории, в зависимости от которых создаются файлы-фида в формате XML или CSV. К слову, фид, подготовленный для Яндекс.Маркета подходит для запуска динамических объявлений в Директе.

Приведем пример для универсального типа фида, который формируется в CSV формате.

Т.к. это CSV файл, то первая строка должна содержать название всех столбцов. На последующих строках размещаются данные товарных позиций, при этом для разделения столбцов внутри них, используется запятая. Файл должен быть создан в кодировке UTF-8. Вот какие элементы могут входить в файл (* — обязательный элемент):

• ID* – идентификатор товара.
• URL* – ссылка на рекламируемую страницу.
• Image – ссылка на картинку товара. Используется в смарт-баннерах, является обязательным элементом в этом случае.
• Title – название товара.
• Description – его описание.
• Price – цена.
• Currency – если указана цена, то этот элемент является обязательным. Обозначает код валюты.
• Old Price – старая цена, при этом она должна быть выше актуальной.

Полный список типов фидов, а также правил их создания можно посмотреть в справке Яндекс.Директ.

После создания фида, его необходимо загрузить в рекламный кабинет. Платформа позволяет указать до 50 фидов.

1. На экране настройки аудиторий, в качестве источника указываем «Фид»/

Выбираем фид в качестве источника

2. Выбираем фид, если требуется – добавляем новый: указываем его имя и тип бизнеса. Сам файл можно разместить в корне вашего магазина и с помощью ссылки загрузить его в Директ. Если требуется загрузить файл напрямую с компьютера, то выбираем соответствующий вариант.

Загрузка фида

3. Все остальные настройки производятся по аналогии с предыдущей, где в роли источника выступал сайт.

4. Система позволяет настраивать фильтры для фида, например, определять ставки для конкретно взятой категории товаров. Каждая из категорий бизнеса имеет свои правила отбора.

Почему не формируются объявления по фиду?

• Файл фида должен соответствовать требованиям.
• При наличии фильтра по производителям, файл должен содержать атрибут «vendor», а значение товара должно соответствовать тому, что указывается в фильтре настроек.
• Категории не могут быть пустыми, в них должен присутствовать хотя бы один товар. Т.е., если задан фильтр с параметром «categoryId», то эта категория должна содержать товар.

Рекомендуется автоматизировать создание файла фида, чтобы при изменении структуры сайта, это отображалось в кампании объявлений.

Плюсы и минусы динамических объявлений

К плюсам, несомненно, относятся:

• Практически полная автоматизация создания кампании: не требуется собирать семантическое ядро, создавать объявления под каждый товар и т.д.
• Кампания с динамическими объявлениями отлично работает в режиме автоматических стратегий, умеет находить НЧ-фразы, снижая при этом стоимость клика.
• Каждое объявление показывается по целевым запросам с учетом названия товара. При этом заголовок часто совпадает с запросом пользователя, что положительно влияет на CTR.
• Есть возможность тонкой настройки таргета как на весь сайт, так и на отдельно взятые категории товаров.
• Относительно простая настройка кампании.

Минусы динамических объявлений:

• Если не проработать список минус-слов, то часто будут попадаться «мусорные» запросы, часто информационные. В некоторых случаях, будет целесообразным запустить кампанию с текстово-графическими объявлениями, собрать из нее минус-слова, и уже на основе этих данных создавать динамические объявления. Кроме этого, рекомендуется постоянно мониторить запросы, по которым приходят посетители, расширяя список стоп-слов.
• Если в качестве источника данных выбирается сайт, то данные краулер собирает несколько дней, зависит от размера сайта.

Динамические объявления в Яндекс.Директ являются отличным вариантом запуска контекстной рекламы. Но без проработки минус-слов могут показывать плохие результаты.

Динамические объявления ↯ блог компании New Point

Динамические объявления — инструмент, который призван облегчить работу интернет-маркетологов. Так ли это на самом деле? Для каких целей стоит их использовать? Как провести настройку? Что ж, New Point готов дать ответы на все вопросы.

По версии «Яндекса», динамические объявления — это объявления, формируемые автоматически на основе контента сайта или фида.

С точки зрения пользователя они неотличимы от обычной рекламы. Вся «магия» происходит для рекламодателя, с которого снимается часть работы. 

Так, робот рекламной системы принимает запрос и ищет совпадения с ключами обычной кампании. Если совпадений нет, а в фиде или на сайте присутствует искомый продукт, робот сам создает объявление и демонстрирует его пользователю. 

Динамические объявления встречаются в выдаче «Яндекса» и на поисковых площадках рекламной сети в любых рекламных блоках на любых позициях. Реклама на основе фида также может отображаться в товарной галерее над результатами выдачи поиска. 

Казалось бы, зачем тогда нужны обычные объявления? В справке «Яндекс» есть указание на то, что динамические объявления могут быть лишь дополнением к обычным объявлениям. Без стандартной кампании «Яндекс» не может гарантировать эффективную работу инструмента. 

Динамические объявления значительно упрощают работу над проектами, требующими создание схожих объявлений. 

Например, для создания полноценной рекламы интернет-магазина придется создать огромное количество карточек, при этом любое изменение ассортимента необходимо сопровождать изменениями в кампании — отключении старых или подключении новых объявлений. 

Также подключение динамических компаний позволяет решить ряд других задач:

• Расширить семантику. При помощи динамических объявлений можно тестировать новые ключи, которые впоследствии будут перенесены в основную кампанию.
• Расширить охват. Динамические объявления позволяют работать с низкочастотными запросами.
• Настроить ретаргетинг. В динамических кампаниях можно повышать корректировки на пользователях, совершающих целевые действия на сайте.
• Отследить пользователей по атрибуции первого перехода. С помощью динамических объявлений можно выделить ту часть аудитории, которая отреагировала на рекламу и впервые посетила сайт. 

Динамические объявления — отличная альтернатива текстово-графических объявлений проектов с частыми изменениями в номенклатуре. Кроме интернет-магазинов, динамические кампании могут помочь туристическим фирмам, сайтам продажи билетов, авто, недвижимости и т.д.

Для генерации можно использовать один из двух источников: сайт или фид. Для начала разберемся с особенностями настройки кампании по данным сайта.

Шаг 1 — проверка состояния сайта

Для начала стоит убедиться в том, что сайт готов к анализу поисковыми роботами:

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

Шаг 2 — настройка условий нацеливания

При генерации по сайту необходимо установить условия нацеливания, то есть выбрать товары, которые необходимо рекламировать.

Так, Вы можете сделать настройку на показ исключительно товаров по акции: «Заголовок страницы» → «Содержит» → «Акция». 

Шаг 3 — написание текстов объявлений

Динамическая кампания позволяет генерировать заголовки, URL, отображаемые ссылки и ключи по сайту, а вот с общим текстом стоит помочь. 

Сформулируйте текст, который можно будет использовать под каждый товар из группы.

При этом следуйте рекомендациям:

• Текст должен соответствовать информации на сайте.
• Указывается информация о специальных льготных предложениях.
• Используйте дополнения: визитки, уточнения, быстрые ссылки с описаниями. Так объявления будут заметнее.

Шаг 4 — выбор стратегии

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

Если же Вы предпочитаете ручное управление ставками, настроить их можно в блоке «Условия нацеливания». 

Шаг 5 — настройка корректировки ставок

Вы также можете сегментировать товары по ценовому признаку, выделив дорогостоящие продукты в отдельные группы. Это позволит Вам раздельно управлять ставками и бюджетами. 

Для этого проанализируйте статистику в «Мастер отчетов» и задайте корректировки ставок пропорционально отклонению от целевого CPA. Формула для расчета достаточно проста: 

Корректировка ставки на аудиторию = 1 — Целевой СРА / Фактический СРА.

На этом настройка завершается.

Алгоритм создания кампании по фидам отличается лишь вторым шагом — настройкой условий нацеливания.

Так, для фидов можно выбирать определенные категории товаров, ценовой диапазон, производителей и другие параметры. Для ряда проектов доступны отдельные виды фильтров:

• для отелей — по количеству звезд, бренду;
• для автомобилей — по маркам, моделям, типу кузовы, году выпуска, цвету;
• для путешествий — по пункту отправления и назначения.

Также небольшое различие в настройке происходить при выборе ручного управления ставками. При работе с фидами Вам необходимо перейти в «Настройки фильтра» и уже там назначать ставки для групп. 

Динамические объявления завоевали доверие маркетологов благодаря следующим преимуществам:

• Автоматическое создание. Не нужно создавать отдельное объявление под каждый товар — вся работа ложится на алгоритмы.
• Дополнительный результат. Точечно настроенные объявления соответствуют каждому запросу и повышают вовлеченность.
• Экономия времени. Кроме очевидной экономии при настройке, появляется дополнительная выгода — не нужно постоянно отслеживать актуальность объявлений и корректировать их.
• Привычный формат без ручного труда. Пользователь даже не поймет, что объявление сделано не человеком, а роботом. 

Однако не обошлось и без недостатков:

• Одинаковый текст. Для групп объявлений прописывается одинаковый текст, который не может подчеркивать уникальные выгоды каждого отдельного товара.
• Автоматический заголовок порой слишком сложный и плохо читаемый.
• Не подходят для рекламы продукции, подлежащей сертификации, регистрации или лицензированию. Также под ограничение попадают товары, требующие особенных предубеждений и возрастных ограничений.

Напоследок ответим на распространенные вопросы, связанные с настройкой и оптимизацией динамических кампаний.

Почему не формируются объявления по сайту?

Это может происходить по двум причинам: у Вас нарушены требования к структуре сайта или на момент генерации объявлений сайт был недоступен.

Решить проблему можно, обратившись к разделу «Результаты проверки» в «Яндекс.Метрика». В условиях нацеливания должны соблюдаться следующие ограничения:

• В поле «Домен» указано лишь полное имя домена.
• В поле «URL» содержится ссылка на страницу с товарами.
• В поле «Ссылка на товар» указана прямая ссылка на необходимый товар.

Почему не формируются объявления по фиду?

Возможно, Вы нарушили требования к фиду или неправильно задали правила отбора.

Проверьте несколько моментов:

• Если подключен фильтр «Только в наличии», в фиде должны иметься товары с атрибутом available = “true”.
• Если подключен фильтр по производителям, в фиде должны быть товары с элементом vendor.
• Если задан фильтр по параметру categoryId, в фиде должны присутствовать товары указанной категории. 

Почему обработка объявлений идет слишком долго?

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

Чтобы решить проблему, попробуйте сузить фильтры, введя новые условия. 

Почему у объявлений недостаточно показов?

Это может быть вызвано следующими причинами:

• Заданным условиям соответствует небольшое количество товаров.
• Ваши объявления не могут выиграть аукцион из-за низкой ставки.
• Под узкие условия ретаргетинга и подбора аудитории попадает малое количество пользователей.

Итак, динамические кампании — инструмент, который может существенно облегчить жизнь маркетолога. Вы сэкономите время на сборе семантики и настройке кампаний, привлечете больше трафика, охватите низкочастотные запросы. Однако для этого необходимо максимально точно задать настройки. Как это сделать, мы сегодня рассказали. Good luck! 

Общая оценка / 5. Всего проголосовало

Динамические объявления в Директе — что это, как настроить

Анастасия
Чирво, специалист по контекстной рекламе

Настраивать контекстную рекламу для бизнеса с большим ассортиментом — сложный и трудоемкий процесс. Много времени занимает создание кампании, а еще больше — последующая оптимизация. Для таких случаев есть динамические объявления — автоматизированные кампании в Директе. Зачем нужны такие объявления и как их настроить, разберем в этой статье

Динамические объявления в Директе — это инструмент, который автоматически создает много однотипных объявлений на основе фида или сайта. Формат работает так: специалист создает группу объявлений и указывает общий заголовок, система анализирует содержимое сайта или фида, а затем генерирует объявление для каждого товара. В объявления автоматически подставляются заголовок, посадочная страница и отображаемая ссылка.

Динамические объявления показываются на поиске Яндекса и в товарной галерее. В поисковой выдаче это обычные текстовые объявления: в них есть заголовок, текст и URL, также могут быть быстрые ссылки, расширения и визитка.

Если объявление попадает в галерею, оно становится текстово-графическим. Чтобы объявление появилось в товарной галерее, в фиде должны быть цена и картинка.

Чем динамические объявления отличаются от стандартных

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

Если вы одновременно запустите стандартную поисковую кампанию и динамическую, при одинаковых ключевых фразах приоритет будет у стандартной. Если ключевая фраза у обычного объявления шире, чем у динамического, система сама выберет наиболее эффективное из них. Ориентироваться при этом будет на статистику показов, кликов, цену клика и качество объявления.

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

К другим плюсам динамических объявлений:

• Расширяют охват поисковой рекламы и приносят дополнительный целевой трафик. Например, если на сайте появился новый раздел с товарами или группа товаров, можно быстро привлечь новых пользователей.
   
• Упрощают работу с рекламой и уменьшают время на ее настройку. Можно создать объявления для всех товаров или для отдельных категорий.
   
• Следят за поисковым спросом, учитывают его изменения и постоянно добавляют новые запросы, которые специалист не всегда может предусмотреть.
   
• Клики в кампаниях с динамическими объявлениями нередко дешевле, чем в обычных, потому что показы часто идут по низкочастотным фразам.

Есть и минусы:

• Заголовок в объявлениях слишком обобщенный, потому что пишется на группу объявлений. В обычных поисковых кампаниях можно написать заголовок под ключевую фразу.
   
• Динамические объявления не подойдут для одностраничных лендингов и товаров, которые нужно лицензировать и которым нужен дисклеймер или возрастные ограничения.
   
• Если много «мусорных» запросов, а кампания не оптимизирована, объявления будут показываться по нерелевантным поисковым запросам и сливать бюджет.

Давайте разберем, как запустить кампанию с динамическими объявлениями.

Создаем кампанию

Войдите в Директ, нажмите «Добавить кампанию» и в выпадающем списке выберите «Динамические объявления».

Дайте понятное название кампании и укажите счетчик Метрики. Без него не получится оценить эффективность кампаний и включить автостратегии.

Добавьте ключевые цели — эта настройка покажет системе, какие цели важны вашему бизнесу. Ключевые цели настраиваются в Яндекс.Метрике.

Укажите ценность конверсии — то, сколько вы хотите зарабатывать каждый раз, когда цель выполняется.

Выберите одну из четырех стратегий — на них система будет ориентироваться при оптимизации рекламы. Подробнее о стратегиях мы рассказали в статье.

Настройте расписание показов и нажмите «Продолжить».

Выбираем аудиторию

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

• На основе страниц сайта: пригодится, если нужно быстро запустить кампанию на поиске.
   
• С помощью фида для динамических объявлений — этот способ рекомендует Яндекс. Как правило, с фидом удобнее работать: так можно контролировать, что именно система будет использовать в объявлении.

Для фида настраиваются фильтры, для сайта — условия нацеливания.

Разберем первый способ.

Через сайт

Перед тем как настроить динамические объявления на поиске, сайт нужно детально проработать. Учитывайте следующие факторы:

• Есть хотя бы одна страница с перечнем всех товаров из категории. Например: site.ru/bytovye_pribory/utugi.
   
• У каждого товара указаны название и ссылка на отдельную страницу с подробным описанием.
   
• Названия товаров и их характеристик не содержат опечаток и ошибок.
   
• Все товары на сайте распределены по категориям, а в каждой категории больше одного товара.
   
• Желательно, чтобы на сайте работали фильтры: «В наличии», «Акция» и т. д. Это поможет системе создать корректные динамические объявления.

Теперь переходите к настройкам: выберите в качестве источника сайт и укажите его адрес.

Добавьте трекинговые параметры — UTM-метки, которые нужны для дальнейшей аналитики и оптимизации. Для динамических объявлений существует определенная UTM-метка, которая помогает отслеживать условия нацеливания:

utm_source=yandex&utm_medium=cpc&utm_campaign={campaign_id}&utm_term={adtarget_name}_{adtarget_id}

Настройте условия нацеливания: какие страницы будет использовать система при генерации объявлений. Можно выбрать все страницы или определенную категорию. Если выбраны все страницы, то ко всем объявлениям будет применяться одинаковая ставка.

Выберите регион, в котором будет показываться ваша реклама. Добавьте минус-слова и укажите корректировку ставок.

Теперь добавьте элементы объявления: текст объявления (не больше 81 знака), быстрые ссылки, уточнения и визитку — это увеличит размер объявления и повысит его CTR.

Готово! Теперь разберем, как настраивать динамические объявления с помощью фида.

Через фид

Выберите фид или добавьте новый: укажите его имя и тип бизнеса. Подробнее работу с фидами мы разобрали в статье.

Задайте трекинговые параметры и фильтр для товаров — какие категории использовать в этой группе объявлений.

Рекламодатель может настроить фильтры для фида, например задать ставки для конкретной категории товаров. У каждого типа бизнеса есть свои правила отбора: они определяют, какие товары использовать при генерации объявлений, а какие — исключить. Подробнее о правилах отбора читайте в справке Яндекса.

Теперь, как и в предыдущем способе, заполните карточку объявления.

Что нужно учитывать подготовке фида:

• Файл должен соответствовать требованиям Яндекса и типу бизнеса.
• Должны быть указаны все обязательные параметры и атрибуты.
• Элементы объявлений в фиде не повторяются и написаны без ошибок.
• Категории не могут быть пустыми, в них должен быть хотя бы один товар.

Как повысить эффективность динамических объявлений

Динамические объявления подходят для быстрого запуска рекламы и охвата низкочастотных ключевых фраз.

Понять, как отработала кампания можно с помощью отчета в Директе. Чтобы его получить, выберите в левом меню «Статистику» и нажмите «Заказ отчетов».

• Проанализируйте, по каким поисковым запросам показывались объявления, и заминусуйте «мусорные».
   
• Оцените, насколько страницы входа релевантны поисковым запросам, а заголовки — объявлениям.
   
• Соберите конверсионные ключевые фразы и добавьте их в обычную поисковую кампанию.

Запускаете рекламу для интернет-магазинов?

Все рекламные системы уже есть в eLama! А еще единый кошелек, инструменты для управления рекламой и закрывающие документы даже для Instagram и Facebook.

Как создать динамический заголовок

1. Давайте начнем добавлять различные форматы в качестве переменных, как показано ниже.
2. Теперь мы можем удалить один вызов и добавить переменную формата во вход «Mode».
3. Заголовок на этом этапе все еще статичен.Нам нужно превратить его в динамический, который изменяется в соответствии с типом данных API, который мы тестируем. Мы добавляем компонент переменной над операцией ввода-вывода, которая вернет соответствующее значение.
4. если (формат == 'xml') вернуть «приложение / xml»; иначе вернуть «application / json»; Для объяснения: переменная acceptHeader будет иметь значение application / xml, если форматом является xml, и application / json в противном случае (поскольку у нас есть только два разных формата, это будет application / json только для JSON. формат
5. Теперь мы можем, наконец, удалить «статический» заголовок и добавить «динамический» заголовок, изменив значение заголовка на «$ {acceptHeader}». Теперь тест будет выполнен два раза; один раз для «XML» и один раз для «JSON», чтобы заголовок имел правильное значение.

Lua — документация envoy 1.21.0-dev-351c0c

Обзор

HTTP-фильтр Lua позволяет запускать сценарии Lua во время обоих запросов. и потоки ответов. LuaJIT используется как среда выполнения. Из-за этого поддерживаемая версия Lua в основном 5.1 с некоторыми функциями 5.2. См. Документацию LuaJIT для более подробной информации.

Примечание

moonjit является продолжением разработки LuaJIT, которая поддерживает больше функций 5.2 и дополнительных архитектур.Envoy может быть построен с поддержкой Moonjit используя следующую опцию bazel: - // source / extensions / filters / common / lua: moonjit = 1 .

Дизайн фильтра и поддержки Lua на высоком уровне выглядит следующим образом:

• Все среды Lua относятся к одному рабочему потоку. Это означает, что нет действительно глобальных данных. Все глобальные объекты, созданные и заполненные во время загрузки, будут видны от каждого рабочего потока изолированно. Настоящая глобальная поддержка может быть добавлена ​​через API в будущем.

• Все скрипты выполняются как сопрограммы. Это означает, что они написаны в синхронном стиле даже хотя они могут выполнять сложные асинхронные задачи. Это значительно упрощает скрипты. написать. Вся сетевая / асинхронная обработка выполняется Envoy через набор API. Посланник будет приостановить выполнение сценария и возобновить его после завершения асинхронных задач.

• Не выполнять блокирующие операции из скриптов. Для производительности критически важно, чтобы API-интерфейсы Envoy используются для всех операций ввода-вывода.

В настоящее время поддерживаются функции высокого уровня

ПРИМЕЧАНИЕ: Ожидается, что этот список будет расширяться со временем по мере использования фильтра в производстве. Поверхность API специально уменьшена. Цель состоит в том, чтобы сделать скрипты предельно простыми и безопасно писать. Предполагается, что очень сложные или высокопроизводительные варианты использования используют собственный фильтр C ++. API.

• Проверка заголовков, тела и трейлеров при потоковой передаче в потоке запроса или ответе поток, или и то, и другое.

• Модификация жаток и прицепов.

• Блокировка и буферизация всего тела запроса / ответа для проверки.

• Выполнение исходящего асинхронного HTTP-вызова к вышестоящему хосту. Такой звонок можно совершить, пока буферизация данных тела, чтобы после завершения вызова заголовки восходящего потока могли быть изменены.

• Выполнение прямого ответа и пропуск дальнейшей итерации фильтра. Например, скрипт может сделать восходящий HTTP-вызов для аутентификации, а затем напрямую ответить 403 код ответа.

Конфигурация

Ниже приведен простой пример настройки HTTP-фильтра Lua, который содержит только inline_code:

 имя: envoy.filters.http.lua
typed_config:
  «@type»: type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
  inline_code: |
    - Вызывается по пути запроса.
    функция envoy_on_request (request_handle)
      -- Сделай что-нибудь.
    конец
    - Вызывается по пути ответа.
    функция envoy_on_response (response_handle)
      -- Сделай что-нибудь.конец
 

По умолчанию сценарий Lua, определенный в inline_code , будет рассматриваться как сценарий GLOBAL . Посланник будет выполнять его для каждого HTTP-запроса.

Конфигурация для каждого маршрута

HTTP-фильтр Lua также может быть отключен или переопределен для каждого маршрута путем предоставления Конфигурация LuaPerRoute на виртуальном хосте, маршруте или взвешенном кластере.

LuaPerRoute предоставляет два способа переопределения сценария Lua GLOBAL :

В качестве конкретного примера, учитывая следующую конфигурацию фильтра Lua:

 имя: посланник.filter.http.lua
typed_config:
  «@type»: type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
  inline_code: |
    функция envoy_on_request (request_handle)
      -- сделай что-нибудь
    конец
  source_codes:
    hello.lua:
      inline_string: |
        функция envoy_on_request (request_handle)
          request_handle: logInfo ("Hello World.")
        конец
    bye.lua:
      inline_string: |
        функция envoy_on_response (response_handle)
          response_handle: logInfo ("Пока, пока.")
        конец
 

HTTP-фильтр Lua может быть отключен на некотором виртуальном хосте, маршруте или взвешенном кластере с помощью Конфигурация LuaPerRoute как следовать:

 typed_per_filter_config:
  посланник.Filters.http.lua:
    «@type»: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuaPerRoute
    отключен: правда
 

Мы также можем ссылаться на сценарий Lua в конфигурации фильтра, указав имя в LuaPerRoute. Сценарий Lua GLOBAL будет переопределен указанным сценарием:

 typed_per_filter_config:
  envoy.filters.http.lua:
    «@type»: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuaPerRoute
    имя: hello.lua
 

Внимание

Имя GLOBAL зарезервировано для Lua.inline_code. Поэтому не используйте GLOBAL как имя для других скриптов Lua.

Или мы можем определить новый сценарий Lua в конфигурации LuaPerRoute напрямую, чтобы переопределить GLOBAL Скрипт Lua следующим образом:

 typed_per_filter_config:
  envoy.filters.http.lua:
    «@type»: type.googleapis.com/envoy.extensions.filters.http.lua.v3.LuaPerRoute
    исходный код:
      inline_string: |
        функция envoy_on_response (response_handle)
          response_handle: logInfo ("До свидания.")
        конец
 

Примеры скриптов

В этом разделе представлены некоторые конкретные примеры сценариев Lua в качестве более мягкого введения и быстрого Начните. Обратитесь к API дескриптора потока для подробнее о поддерживаемом API.

 - Вызывается по пути запроса.
функция envoy_on_request (request_handle)
  - Дождитесь всего тела запроса и добавьте заголовок запроса с размером тела.
  request_handle: headers (): add ("request_body_size", request_handle: body (): length ())
конец

- Вызывается по пути ответа.функция envoy_on_response (response_handle)
  - Дождитесь появления всего тела ответа и добавьте заголовок ответа с размером тела.
  response_handle: headers (): add ("response_body_size", response_handle: body (): length ())
  - Удалите заголовок ответа с именем 'foo'.
  response_handle: headers (): remove ("foo")
конец
 

 функция envoy_on_request (request_handle)
  - Сделайте HTTP-вызов вышестоящему хосту со следующими заголовками, телом и тайм-аутом.
  локальные заголовки, body = request_handle: httpCall (
  "lua_cluster",
  {
    [": method"] = "ОПУБЛИКОВАТЬ",
    [": путь"] = "/",
    [": авторитет"] = "lua_cluster"
  },
  "Привет, мир",
  5000)

  - Добавьте информацию из HTTP-вызова в заголовки, которые будут отправлены следующему
  - фильтр в цепочке фильтров.request_handle: headers (): add ("upstream_foo", заголовки ["foo"])
  request_handle: headers (): add ("upstream_body_size", #body)
конец
 

 функция envoy_on_request (request_handle)
  - Сделайте HTTP-вызов.
  локальные заголовки, body = request_handle: httpCall (
  "lua_cluster",
  {
    [": method"] = "ОПУБЛИКОВАТЬ",
    [": путь"] = "/",
    [": Authority"] = "lua_cluster",
    ["set-cookie"] = {"lang = lua; Path = /", "type = binding; Path = /"}
  },
  "Привет, мир",
  5000)

  - Ответить напрямую и установить заголовок из HTTP-вызова.Никаких дополнительных итераций фильтра
  -- происходит.
  request_handle: ответить (
    {[": status"] = "403",
     ["upstream_foo"] = заголовки ["foo"]},
    "Неа")
конец
 

 функция envoy_on_request (request_handle)
  - Журнал информации о запросе
  request_handle: logInfo ("Полномочия:" ..request_handle: заголовки (): get (": полномочия"))
  request_handle: logInfo ("Метод:" ..request_handle: headers (): get (": method"))
  request_handle: logInfo ("Путь:" ..request_handle: headers (): get (": path"))
конец

функция envoy_on_response (response_handle)
  - Код состояния ответа журнала
  response_handle: logInfo ("Статус:"..response_handle: headers (): get (": status"))
конец
 

Обычный вариант использования — переписать тело ответа восходящего потока, например: восходящий поток отправляет не-2xx ответ с данными JSON, но приложение требует отправки HTML-страницы в браузеры.

Есть два способа сделать это, первый — через body () API.

 функция envoy_on_response (response_handle)
  local content_length = response_handle: body (): setBytes ("  Не найдено  ")
  response_handle: headers (): replace ("длина содержимого", длина_ содержимого)
  response_handle: headers (): replace ("тип содержимого", "текст / html")
конец
 

Или через bodyChunks () API, который позволяет Envoy пропускать буферизацию данных ответа восходящего потока.

 функция envoy_on_response (response_handle)

  - Устанавливает длину содержимого.
  response_handle: headers (): replace ("длина содержимого", 28)
  response_handle: headers (): replace ("тип содержимого", "текст / html")

  местный последний
  для чанка в response_handle: bodyChunks () сделать
    - Очищает каждый полученный фрагмент.
    кусок: setBytes ("")
    последний = кусок
  конец

  last: setBytes ("  Не найдено  ")
конец
 

Полный пример

Полный пример использования Docker доступен в / examples / lua.

API обработки потока

Когда Envoy загружает сценарий в конфигурации, он ищет две глобальные функции, которые скрипт определяет:

 функция envoy_on_request (request_handle)
конец

функция envoy_on_response (response_handle)
конец
 

Сценарий может определять одну или обе эти функции. Во время пути запроса Envoy будет запустите envoy_on_request как сопрограмму, передав дескриптор API запроса. В течение путь ответа, Envoy будет запускать envoy_on_response как сопрограмму, передавая дескриптор в ответ API.

Внимание

Очень важно, чтобы все взаимодействия с Envoy происходили через переданный дескриптор потока. Поток дескриптор не должен быть назначен какой-либо глобальной переменной и не должен использоваться за пределами сопрограмма. Envoy откажет вашему скрипту, если дескриптор используется неправильно.

Поддерживаются следующие методы дескриптора потока:

кузов ()

 локальное тело = дескриптор: тело (always_wrap_body)
 

Возвращает тело потока. Этот вызов заставит Envoy приостановить выполнение скрипта до тех пор, пока все тело было получено в буфере.Обратите внимание, что вся буферизация должна соответствовать политики управления потоком. Envoy не будет буферизовать больше данных, чем разрешено соединением менеджер.

Необязательный логический аргумент always_wrap_body может использоваться, чтобы требовать, чтобы Envoy всегда возвращал body объект, даже если тело пусто. Поэтому мы можем модифицировать тело независимо от того, оригинальное тело существует или нет.

Возвращает буферный объект.

BodyChunks ()

 локальный итератор = дескриптор: bodyChunks ()
 

Возвращает итератор, который можно использовать для перебора всех полученных фрагментов тела по мере их поступления.Envoy приостановит выполнение скрипта между фрагментами, но не будет буферизовать их . Это может быть используется сценарием для проверки данных во время их потоковой передачи.

 для фрагмента в request_handle: bodyChunks () do
  request_handle: log (0, кусок: длина ())
конец
 

Каждый фрагмент, возвращаемый итератором, является буферным объектом.

прицепы ()

 местные трейлеры = ручка: трейлеры ()
 

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

Возвращает объект заголовка.

журнал * ()

 дескриптор: logTrace (сообщение)
handle: logDebug (сообщение)
handle: logInfo (сообщение)
handle: logWarn (сообщение)
handle: logErr (сообщение)
handle: logCritical (сообщение)
 

Регистрирует сообщение, используя ведение журнала приложения Envoy. сообщение — строка для регистрации.

httpCall ()

 локальных заголовков, тело = дескриптор: httpCall (кластер, заголовки, тело, тайм-аут, асинхронный)
 

Выполняет HTTP-вызов вышестоящему хосту. кластер — это строка, которая сопоставляется с настроенным кластером диспетчера кластера. заголовки представляет собой таблицу пар ключ / значение для отправки (значение может быть строкой или таблицей строк). Обратите внимание, что должны быть установлены заголовки : метод , : путь и : полномочия . body — необязательная строка тела данные для отправки. тайм-аут — целое число, определяющее тайм-аут вызова в миллисекундах.

асинхронный — логический флаг.Если для asynchronous установлено значение true, Envoy выполнит HTTP-запрос и продолжит, независимо от успеха или неудачи ответа. Если установлено значение false или не установлено, Envoy приостановит выполнение скрипта. пока вызов не завершится или не возникнет ошибка.

Возвращает заголовка , который представляет собой таблицу заголовков ответа. Возвращает тело , которое является строковым ответом тело. Может быть нулевым, если тела нет.

ответить ()

 дескриптор: ответить (заголовки, тело)
 

Ответьте немедленно и не продолжайте дальнейшую итерацию фильтра.Этот звонок действителен только в поток запросов . Кроме того, ответ возможен только в том случае, если заголовки запроса еще не были перешли к последующим фильтрам. Это означает, что следующий код Lua недействителен:

 функция envoy_on_request (request_handle)
  для чанка в request_handle: bodyChunks () сделать
    request_handle: ответить (
      {[": status"] = "100"},
      "Неа")
  конец
конец
 

заголовки — это таблица пар ключ / значение для отправки (значение может быть строкой или таблицей строк).Обратите внимание, что должен быть установлен заголовок : status . body — строка и предоставляет необязательный ответ тело. Может быть ноль.

соединение ()

 локальное соединение = дескриптор: соединение ()
 

Возвращает базовое соединение текущего запроса.

Возвращает объект подключения.

importPublicKey ()

 local pubkey = handle: importPublicKey (keyder, keyderLength)
 

Возвращает открытый ключ, который используется verifySignature для проверки цифровой подписи.

verifySignature ()

 локально нормально, ошибка = дескриптор: verifySignature (hashFunction, pubkey, signature, signatureLength, data, dataLength)
 

Проверьте подпись, используя предоставленные параметры. hashFunction — это переменная для используемой хеш-функции. для проверки подписи. Поддерживаются SHA1 , SHA224 , SHA256 , SHA384 и SHA512 . pubkey — открытый ключ. подпись — подпись, которая подлежит проверке.Подпись Длина длина подписи. данные — это контент, который будет хеширован. dataLength — длина данных.

Функция возвращает пару. Если первый элемент равен истинно , второй элемент будет пустым. что означает, что подпись проверена; в противном случае второй элемент сохранит сообщение об ошибке.

base64Escape ()

 local base64_encoded = handle: base64Escape ("входная строка")
 

Кодирует входную строку как base64.Это может быть полезно для экранирования двоичных данных.

метка времени ()

 timestamp = handle: timestamp (формат)
 

Функция отметки времени с высоким разрешением. Формат — необязательный параметр перечисления для указания формата временной метки. EnvoyTimestampResolution.MILLISECOND поддерживается Функция возвращает отметку времени в миллисекундах с начала эпохи по умолчанию, если формат не установлен.

API объекта информации о потоке

протокол ()

Возвращает строковое представление протокола HTTP. используется текущим запросом.Возможные значения: HTTP / 1.0 , HTTP / 1.1 , HTTP / 2 и HTTP / 3 * .

нижестоящий Локальный адрес ()

 streamInfo: downstreamLocalAddress ()
 

Возвращает строковое представление нисходящего удаленного адреса. используется текущим запросом.

downstreamDirectRemoteAddress ()

 streamInfo: downstreamDirectRemoteAddress ()
 

Возвращает строковое представление нисходящего напрямую подключенного адреса. используется текущим запросом.Это эквивалентно адресу физического подключения.

requiredServerName ()

 streamInfo: запрошенное имя_сервера ()
 

Возвращает строковое представление запрошенного имени сервера. (например, SNI в TLS) для текущего запроса, если он есть.

API объекта SSL-соединения

peerCertificatePresent ()

 если downstreamSslConnection: peerCertificatePresent (), то
  print ("сертификат партнера представлен")
конец
 

Возвращает логическое значение, указывающее, представлен ли сертификат однорангового узла.

peerCertificateValidated ()

, если downstreamSslConnection: peerCertificateVaidated (), то
  print ("сертификат партнера подтвержден")
конец
 

Возвращает bool, подтвержден ли сертификат однорангового узла.

uriSanLocalCertificate ()

 - Например, uriSanLocalCertificate содержит {"san1", "san2"}
локальные сертификаты = downstreamSslConnection: uriSanLocalCertificate ()

- Следующие отпечатки san1, san2
дескриптор: logTrace (table.concat (certs, ","))
 

Возвращает URI (в виде таблицы) в поле SAN локального сертификата.Возвращает пустую таблицу, если нет ни локального сертификата, ни поля SAN, ни записей URI SAN.

sha256PeerCertificateDigest ()

 ниже по потокуSslConnection: sha256PeerCertificateDigest ()
 

Возвращает дайджест SHA256 однорангового сертификата. Возвращает "" , если нет однорангового сертификата. что может произойти в соединениях TLS (не mTLS).

serialNumberPeerCertificate ()

 downstreamSslConnection: serialNumberPeerCertificate ()
 

Возвращает поле серийного номера однорангового сертификата.Возвращает "" , если однорангового узла нет. сертификат или без серийного номера.

эмитентPeerCertificate ()

 downstreamSslConnection: IssuingPeerCertificate ()
 

Возвращает поле эмитента однорангового сертификата в формате RFC 2253. Возвращает "" , если нет одноранговый сертификат или без эмитента.

subjectPeerCertificate ()

 downstreamSslConnection: subjectPeerCertificate ()
 

Вернуть поле темы однорангового сертификата в формате RFC 2253.Возвращает "" , если нет одноранговый сертификат или без темы.

uriSanPeerCertificate ()

 ниже по потокуSslConnection: uriSanPeerCertificate ()
 

Возвращает URI (в виде таблицы) в поле SAN однорангового сертификата. Возвращает пустую таблицу, если нет однорангового сертификата, или нет поля SAN, или нет записей URI SAN.

subjectLocalCertificate ()

 downstreamSslConnection: subjectLocalCertificate ()
 

Возвращает поле темы локального сертификата в формате RFC 2253.Возвращает "" , если нет местный сертификат или без темы.

urlEncodedPemEncodedPeerCertificate ()

 downstreamSslConnection: urlEncodedPemEncodedPeerCertificate ()
 

Возвращает представление однорангового сертификата в кодировке PEM в кодировке URL. Возвращает "" , если есть не является одноранговым сертификатом или происходит сбой кодирования.

urlEncodedPemEncodedPeerCertificateChain ()

 downstreamSslConnection: urlEncodedPemEncodedPeerCertificateChain ()
 

Возвращает представление в кодировке PEM в кодировке URL-адресов полной цепочки сертификатов однорангового узла, включая лист сертификат.Возвращает "" , если сертификат узла отсутствует или кодирование не выполнено.

dnsSansPeerCertificate ()

 нисходящегоSslConnection: dnsSansPeerCertificate ()
 

Возвращает записи DNS (в виде таблицы) в поле SAN однорангового сертификата. Возвращает пустой таблица, если нет однорангового сертификата, или нет поля SAN, или нет записей DNS SAN.

dnsSansLocalCertificate ()

 нисходящегоSslConnection: dnsSansLocalCertificate ()
 

Возвращает записи DNS (в виде таблицы) в поле SAN локального сертификата.Возвращает пустой таблица, если нет локального сертификата, поля SAN или записей DNS SAN.

validFromPeerCertificate ()

 downstreamSslConnection: validFromPeerCertificate ()
 

Возвращает время (отметка времени с начала эпохи в секундах), когда сертификат однорангового узла был выдан и должен считаться действительным с. Возвращает 0 , если сертификат узла отсутствует.

В Lua мы обычно используем os.time (os.date ("! * T")) , чтобы получить текущую отметку времени с начала эпохи в секундах.

expirationPeerCertificate ()

 downstreamSslConnection: validFromPeerCertificate ()
 

Возвращает время (отметка времени с начала эпохи в секундах), в течение которого сертификат однорангового узла истекает и не должен считаться действительным после. Возвращает 0 , если сертификат узла отсутствует.

В Lua мы обычно используем os.time (os.date ("! * T")) , чтобы получить текущую отметку времени с начала эпохи в секундах.

sessionId ()

 нисходящего потокаSslConnection: sessionId ()
 

Возвращает шестнадцатеричный идентификатор сеанса TLS, как определено в RFC 5246.

ciphersuiteId ()

 нисходящийSslConnection: ciphersuiteId ()
 

Возвращает стандартный идентификатор (в шестнадцатеричном формате) для шифров, используемых в установленном TLS-соединении. Возвращает «0xffff» , если нет текущего согласованного набора шифров.

ciphersuiteString ()

 downstreamSslConnection: ciphersuiteString ()
 

Возвращает имя OpenSSL для набора шифров, используемых в установленном TLS-соединении. Возврат "" , если нет текущего согласованного набора шифров.

tlsVersion ()

 ниже по потокуSslConnection: tlsVersion ()
 

Возвращает версию TLS (например, TLSv1.2, TLSv1.3), используемую в установленном TLS-соединении.

Выбор вариантов и просмотров страниц

Конечная точка select активирует одну или несколько кампаний Dynamic Yield по имени. Активация автоматически разрешает правила таргетинга и распределения тестовых групп и возвращает пользователю правильный вариант. Как правило, вы выполняете этот вызов как часть более крупной страницы и конвейера рендеринга контента.Вот подробное руководство о том, где и как использовать эту конечную точку.

👍

Страница — это страница с любым другим именем

Термин «просмотр страницы» в этом документе относится как к новым веб-страницам, отображаемым веб-сервером, изменению местоположения в одностраничном приложении, так и к новому экрану, отображаемому в мобильное приложение.

Общая привязка этих потоков заключается в том, что с точки зрения конечного пользователя они теперь переместились в новый контекст, вместо того, чтобы действовать или перемещаться в текущем представлении.

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

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

Хотя сообщение о просмотре страницы и выбор вариантов для кампании являются функционально разными действиями, их многое связывает. Когда страница отображается, независимо от того, отвечает ли сервер за создание полного HTML или только за возвращение полезной нагрузки только для данных для SPA или мобильного приложения, обычно выполняются аналогичные шаги для интеграции Dynamic Yield:

1. Определите все кампании, которые являются неотъемлемой частью содержимого страницы, например встроенные элементы, значения переменных и параметры конфигурации.Каждая кампания имеет уникальное имя селектора API , определенное в пользовательском интерфейсе администратора.

2. Позвоните по номеру , выберите , чтобы получить выбранные варианты для всех этих кампаний. Нам также необходимо сообщить об этом новом просмотре страницы. Поскольку контекст новой страницы передается в любом случае для выполнения надлежащего таргетинга кампании, вызов choose по умолчанию также неявно сообщает о новом просмотре страницы.

3. Теперь, когда у нас есть полезные данные выбранных вариантов, мы можем построить всю страницу и отрендерить ее.

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

Для этих типов контента вы можете дополнительно вызвать и выбрать для получения необходимых вариантов кампании, при этом не забудьте отключить неявный просмотр страниц в аргументах (см. Аргументы в примере кода ниже).

Если вы хотите сообщить только о просмотре страницы без соответствующих кампаний, вы также можете использовать конечную точку pageview . Это просто псевдоним для choose, , но без названия кампании, что допустимо.

Еще до того, как вы получите полное представление о том, какие кампании должны быть интегрированы в ваше приложение, лучше всего интегрировать вызов select во все типы страниц в вашем приложении с правильным контекстом страницы (подробнее ниже), не обращаясь пока к какой-либо кампании. .

А теперь самое интересное: вместе с человеком или людьми, ответственными за создание и управление кампаниями (будь то маркетологи, менеджеры по продукту, продавцы или другие заинтересованные стороны в вашей организации), определяет места в вашем приложении, где Dynamic Yield управляет кампании должны выполняться . Любая кампания, которую вы запускаете, имеет имя селектора API , которое вы будете использовать для получения выбранного варианта.

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

Давайте посмотрим на образец запроса. Контекст - это страница сведений о продукте (также известная как PDP) на воображаемом веб-сайте электронной коммерции sugoi-ne.com:

Вызов "select" с помощью cURL (режим только API) Вызов "select" с помощью cURL (веб-режим)

  curl --request POST \
  --url https: // dy-api.com / v2 / serve / user / choose \
  --header 'тип содержимого: приложение / json' \
  --header 'DY-API-Key: baadc6ba740a352c9106dc7857a7eb9c' \
  --данные '{
      "user": {"id": "yaexono4ohphania"},
      "session": {"custom": "iquahngaishe2koh"},
      "selector": {"names": ["Верхний баннер PDP", "Рекомендации PDP"]},
      "context": {
        "страница": {
          "тип": "ПРОДУКТ",
          "данные": ["7383723-010"],
          "location": "https://sugoi-ne.com/men-pants/p7383723-010",
          "реферер": "https: // sugoi-ne.com / men-брюки ",
          "locale": "en_US"
        },
        "устройство": {
          "userAgent": "Mozilla / 5.0 (X11; Linux x86_64) AppleWebKit / 537.36 (KHTML, например, Gecko) Chrome / 56.0.2924.87 Safari / 537.36",
          "ip": "54.100.200.255"
        },
        "pageAttributes": {"customPageAttribute": "someValue"}
      },
      "options": {"isImplicitPageview": true}
      
} '
  

  curl --request POST \
  --url https://dy-api.com/v2/serve/user/choose \
  --header 'тип содержимого: приложение / json' \
  --header 'DY-API-Key: baadc6ba740a352c9106dc7857a7eb9c' \
  --данные '{
      "Пользователь": {
        "диид": "-4350463893986789401",
        "dyid_server": "-4350463893986789401"
      },
      "сеанс": {"dy": "ohyr6v42l9zd4bpinnvp7urjjx9lrssw"},
      "selector": {"names": ["Верхний баннер PDP", "Рекомендации PDP"]},
      "context": {
        "страница": {
          "тип": "ПРОДУКТ",
          "данные": ["7383723-010"],
          "location": "https: // sugoi-ne.com / men-брюки / p7383723-010 ",
          "реферер": "https://sugoi-ne.com/men-pants",
          "locale": "en_US"
        },
        "устройство": {
          "userAgent": "Mozilla / 5.0 (X11; Linux x86_64) AppleWebKit / 537.36 (KHTML, например, Gecko) Chrome / 56.0.2924.87 Safari / 537.36",
          "ip": "54.100.200.255"
        },
        "pageAttributes": {"customPageAttribute": "someValue"}
      },
      "options": {"isImplicitPageview": true}
      
} '
  

Давайте разберемся:

• Содержимое атрибутов user и session различается в зависимости от режима реализации - это единственные различия между двумя приведенными выше фрагментами.Для получения дополнительной информации см. Основные понятия

  .

• Аргумент селектора содержит имя селектора API двух кампаний, которые являются частью каждой страницы продукта на веб-сайте: одна для содержимого верхнего баннера, а вторая для виджета рекомендаций. (В будущих версиях будут доступны дополнительные типы селекторов для выборки кампаний)

• Аргумент контекста состоит из трех частей:

  1. стр. :

     • тип страницы, например ГЛАВНАЯ СТРАНИЦА или ПРОДУКТ. Некоторые типы также требуют передачи дополнительных идентификаторов в свойстве data - для страницы продукта это артикул продукта. Для некоторых типов страниц может быть передано несколько идентификаторов, поэтому это свойство всегда указывается в виде массива. См. Ниже список типов контекста и соответствующих параметров data .

     • Расположение страницы и, необязательно, реферер , с которого пользователь перешел на эту страницу, если он известен. Для Интернета это должен быть канонический URL.Для приложений это логическое имя местоположения или экрана.

     • Локаль является необязательной и позволяет объектам рекомендаций поддерживать фиды продуктов с несколькими языками. См. Дополнительную информацию в базе знаний.

  2. устройство : Это необязательно и применяется к запросам, сделанным с клиентских устройств или от их имени. Это полезно как для таргетинга, так и для сбора данных на основе атрибутов устройства:

     • userAgent применим для клиентов на основе веб-браузера, независимо от того, вызывают ли они этот API напрямую или через сервер.Строка пользовательского агента обычно содержит не только название и версию браузера, но также операционную систему и марку мобильного устройства - все это можно использовать для таргетинга. Если этот аргумент не передан, шлюз проверяет, был ли выполнен вызов API с помощью HTTP-заголовка User-Agent , что имеет место, когда запрос выполняется непосредственно из браузера.

     • ip - это IPv4-адрес клиентского устройства, если он доступен. Это позволяет настраивать таргетинг на основе геолокации и погоды.Примечание: IP-адрес никогда не сохраняется на нашем конце , а сразу переводится в географическое положение. (поддержка IPv6 планируется в будущих версиях)

  3. Дополнительные атрибуты:

     • pageAttributes - это необязательный объект, позволяющий передавать любую пару "ключ-значение", которую вы хотите использовать для таргетинга в этой кампании. Это специальный метод для быстрого таргетинга на основе любого атрибута, известного вызывающей стороне API.Все, что вам нужно сделать, это передать эти атрибуты и установить для них правила таргетинга в пользовательском интерфейсе администратора. Обратите внимание, что эти данные не хранятся и поэтому не могут использоваться для создания групп аудитории.

     • Параметры используются для управления поведением этой конечной точки:
1- логический параметр isImplicitPageview поддерживается, и по умолчанию он равен true. Это означает, что в рамках этого вызова необходимо сообщить о просмотре страницы
. Если вы вызываете конечную точку за пределами отрисовки
новой страницы, установите для нее значение false.
2- Есть больше вариантов для [рекомендательных кампаний.] (Https://dy.dev/docs/creating-
Рекомендации-api-кампании)

👍

Использование специальных атрибутов страницы и адаптация пользовательских данных

Хотя pageAttributes отлично подходит как быстрый способ включения таргетинга по пользовательским данным, эта возможность имеет определенные ограничения. Эти атрибуты можно использовать только для определенных кампаний, для которых вы передали эти атрибуты.Если вы выберете с одинаковым названием кампании в нескольких местах, но нигде не передадите одни и те же атрибуты, таргетинг может работать не так, как вы ожидали.

Dynamic Yield также поддерживает внедрение собственных и сторонних данных в наш бэкэнд, которые затем можно использовать для создания аудитории и таргетинга. Последний вариант основан на строгой схеме и обычно требует дополнительной работы для настройки. Учить больше.

Дополнительным преимуществом является то, что вы получаете разделение задач . : вызовы, которые вы делаете по номеру и выбираете в различных местах вашей кодовой базы, не должны знать или передавать какие-либо атрибуты.Новые атрибуты всегда можно добавить и использовать через пользовательский интерфейс администратора без каких-либо изменений в коде вызова .

Вот ваши варианты для context.page.type и соответствующий аргумент data для каждого.

Ответственный орган

  {
  "выбор": [
    {
      "id": 5,
      "name": "Верхний баннер PDP",
      "type": "РЕШЕНИЕ",
      "solutionId": "aGVsbG8K",
      "варианты": [
        {
          "id": 52,
          "payload": {
            "type": "CUSTOM_JSON",
            "данные": {
              "ключ1": "значение1",
              "ключ2": "значение2"
            }
          }
        }
      ]
    },
    {
      "id": 24,
      "name": "Рекомендации PDP",
      "type": "RECS_DECISION",
      "solutionId": "d29ybGQK",
      "варианты": [
        {
          "id": 203,
          "payload": {
            "type": "RECS",
            "данные": {
              "слоты": [
                {
                  "slotId": "aGVsbG93b3JsZAo =",
                  "sku": "6323723",
                  "Данные продукта": {
                    "name": "Рубашка в клетку",
                    «цена»: 39.99,
                    "url": "https://website.com/men-pants/p6323723-020"
                  }
                },
                {
                  "slotId": "d2VsY29tZWR1ZAo =",
                  "sku": "5413764",
                  "Данные продукта": {
                    "name": "Брюки цвета хаки",
                    «цена»: 59,99,
                    "url": "https://website.com/men-pants/p5413764-010"
                  }
                }
              ]
            }
          }
        }
      ]
    }
  ]
}
  

Ответ всегда имеет формат JSON и кодировку UTF-8.

Успешный ответ (HTTP 200) возвращает массив из вариантов, содержит выбранные вариантов (один или несколько) для каждого имени кампании, переданного в запросе. С каждым вариантом идет его полезная нагрузка , , содержимое которой зависит от возвращаемого типа .

Обратите внимание, что кампании могут быть настроены в пользовательском интерфейсе администратора, чтобы выбрать более одного варианта из общего количества (также известного как выбор k-of-n). Следовательно, вариантов всегда возвращается в виде массива.

📘

Возврат нескольких вариантов для кампании

Это полезно, когда вы хотите визуализировать слайдер, показывающий, например, 3 лучших из 8 доступных баннеров. Другой пример - отображение списка из 3 специальных предложений из более длинного списка. Вариации в таких кампаниях обычно обновляются через фид вариантов, а не создаются вручную в пользовательском интерфейсе.

Для каждой возвращенной кампании сначала отметьте тип решения. Это также определяет тип полезной нагрузки внутри и может быть одним из следующих:

• РЕШЕНИЕ для пользовательских кампаний.В этом случае единственным поддерживаемым типом полезной нагрузки является CUSTOM_JSON, означает, что определение полезной нагрузки в пользовательском интерфейсе и ее анализ в вызывающей стороне полностью зависит от клиента. В этом случае важно сохранить уникальный DecisionId для отчета о кликах по визуализированному варианту.
Чтобы упростить создание вариантов пользовательского интерфейса и предотвратить опечатки, разработчики могут создавать шаблоны с несколькими встроенными типами переменных. Как говорится, друзья не позволяют друзьям, не являющимся разработчиками, снова и снова создавать JSON с нуля.

• RECS_DECISION для рекомендательных кампаний. В этом случае типом полезной нагрузки всегда является встроенный RECS, , как в примере ответа выше. В этом случае вы можете проигнорировать возвращенный идентификатор решения , , поскольку полезная нагрузка содержит идентификатор slotId для каждого рекомендованного элемента.

• NO_DECISION для любого типа кампании, для которой не было выполнено ни одно правило таргетинга, и в кампании нет опыта по умолчанию.Вы всегда должны быть готовы работать с этим типом, так как содержимое кампании может измениться в любое время через пользовательский интерфейс, и во многих случаях вполне допустимо вообще не возвращать никаких вариантов, полагаясь на жестко запрограммированное поведение по умолчанию. -в вместо этого. Для этого типа не существует идентификатора решения , или полезной нагрузки.

С типом полезной нагрузки CUSTOM_JSON все просто - это полностью зависит от вас. Пожалуйста, ознакомьтесь с примерами в руководстве.

Для типа RECS данные содержат массив объектов.Каждый из них является одним рекомендованным элементом или «слотом». Количество возвращаемых слотов определяется в пользовательском интерфейсе администратора.

Для каждого слота у вас есть его sku, плюс объект productData , содержащий все атрибуты продукта из фида, и slotId . Этот идентификатор представляет содержимое рекламного места в этом уникальном ответе с рекомендациями, и вам необходимо сохранить его для отчетов о кликах по этому конкретному слоту. Учитывая этот slotId, наш бэкэнд знает все подробности об этом слоте для целей отчетности, например, какая стратегия рекомендаций использовалась, был ли откат к другой стратегии и многое другое.

Сжатие заголовка - обзор

Подслушивание

Чтобы противостоять угрозе перехвата, носитель может быть зашифрован.Метод шифрования RTP-трафика - это Secure RTP (SRTP; RFC3711), который не шифрует заголовки IP, UDP или RTP, но шифрует полезную нагрузку RTP (сам «голос»). Преимущество SRTP в том, что заголовки RTP остаются незашифрованными, заключается в том, что протоколы сжатия заголовков (cRTP, 12 ROHC 13 ) и анализаторы протоколов (ищущие потерю пакетов RTP и (S) отчеты RTCP) могут по-прежнему работать с носителями, зашифрованными с помощью SRTP.

Недостатком SRTP является то, что существует примерно 13 несовместимых механизмов для установки ключей SRTP.Эти механизмы находятся на различных стадиях внедрения, принятия в отрасли и стандартизации. Таким образом, на данный момент маловероятно, что две системы с поддержкой SRTP от разных поставщиков будут иметь совместимый механизм ключей SRTP. Здесь представлен краткий обзор некоторых наиболее популярных механизмов ввода.

Один из популярных механизмов ключей SRTP, описания безопасности, требует безопасного канала сигнализации SIP (SIP поверх TLS) и раскрывает ключ SRTP каждому прокси-серверу SIP на пути установления вызова.Это означает, что пассивный злоумышленник, способный наблюдать за незашифрованной сигнализацией SIP и зашифрованным SRTP, сможет подслушивать вызов. S / MIME - это механизм сквозной безопасности SIP, который в описаниях безопасности можно было бы использовать в своих интересах, но S / MIME не был хорошо развернут, и из-за специфических особенностей SIP (в первую очередь, разветвления и перенацеливания) маловероятно что S / MIME будет развернут в обозримом будущем.

Мультимедийный Интернет-ключ (MIKEY) имеет примерно восемь несовместимых режимов; они позволяют устанавливать ключи SRTP. 4 Почти все эти режимы MIKEY более безопасны, чем описания безопасности, поскольку они не содержат ключ SRTP непосредственно в сообщении SIP, а скорее шифруют его с помощью закрытого ключа удаленной стороны или выполняют обмен Диффи-Хеллмана. Таким образом, для большинства режимов MIKEY злоумышленнику необходимо будет активно участвовать в обмене MIKEY и получить зашифрованный протокол SRTP для прослушивания мультимедиа.

Zimmermann Real-time Transport Protocol (ZRTP) 14 - еще один механизм обмена ключами SRTP, который использует обмен Диффи-Хеллмана для установки ключей SRTP и обнаруживает активного злоумышленника, заставляя пользователей (или их компьютеры) проверять короткий строка аутентификации друг с другом.Он предоставляет полезные свойства безопасности, включая идеальную прямую секретность и непрерывность ключей (что позволяет пользователям проверять строки аутентификации один раз и никогда больше), а также возможность работать через SBC.

В 2006 году IETF решила сократить количество стандартных механизмов обмена ключами IETF и выбрала DTLS-SRTP. DTLS-SRTP использует датаграмму TLS (механизм для запуска TLS по ненадежному протоколу, например UDP) по медиа-пути. Чтобы обнаружить активного злоумышленника, сертификаты TLS, которыми обмениваются по пути мультимедиа, должны совпадать с отпечатками подписанных сертификатов, отправленных по сигнальному пути SIP.Отпечатки сертификатов подписываются с использованием механизма идентификации SIP. 15

Недостатком SRTP является то, что агенту пользователя SIP необходимо (для некоторых механизмов управления ключами) или очень полезно (для других механизмов управления ключами) зашифровать свой сигнальный трафик SIP с помощью своего прокси-сервера SIP. Единственным стандартом для такого шифрования на сегодняшний день является SIP через TLS, который работает через TCP. На сегодняшний день многие производители избегают TCP на своих прокси-серверах SIP, потому что они обнаружили, что масштабирование SIP-over-TCP хуже, чем SIP-over-UDP.Ожидается, что, если это не удастся преодолеть, мы можем увидеть стандартизацию SIP-over-DTLS. Другой жизнеспособный вариант, особенно на некоторых рынках, - использовать IPsec ESP (инкапсулирующий полезную нагрузку) для защиты SIP.

Еще одним недостатком SRTP является то, что оборудование для диагностики и устранения неполадок не может прослушивать медиапоток. Это может показаться очевидным, но это может вызвать трудности, когда техническим специалистам необходимо прослушать и диагностировать эхо, усиление или другие аномалии, которые не могут быть диагностированы путем проверки заголовков SRTP (которые не зашифрованы), но могут быть диагностированы только путем прослушивания самого дешифрованного звука. .

Советы по Power Platform - динамические заголовки форм Power Apps

Хотите узнать, как управлять различными режимами формы в Power Apps? В этом выпуске Power Platform Quick Tips, я покажу вам, как управлять и использовать различные режимы формы при использовании собственных форм в Power Apps. Я также покажу вам, как применять их в различных динамических возможностях Power Apps.

• Я сосредоточился на заголовке в приложении для встреч по уходу за домашними животными, которое я создал в Power Apps.Я хочу, чтобы этот заголовок изменялся динамически в зависимости от режима формы, в котором мы находимся.
• Каждый раз, когда вы работаете с формами, особенно при работе с поведением по умолчанию в Power Apps, у вас есть один экран редактирования, который использует одну форму.
• Но тот же экран редактирования и ту же форму можно перезапустить в разных режимах. Вы можете запустить его в новом режиме, что означает вставку записи. Или вы можете запустить его в режиме редактирования, что означает, что он будет редактировать запись.
• В моем примере у меня есть приложение, в котором я могу добавить новую встречу или отредактировать существующую.Проблема в том, что в моем заголовке всегда написано «Добавить встречу», добавляю ли я новую или редактирую существующую. Я хочу сделать это более динамичным.
• Для этого мы можем щелкнуть заголовок и манипулировать им, чтобы возвращать разные результаты. Вы можете сделать это с помощью оператора «Если» (например, то, что вы сделали бы в Excel, если вам это знакомо).
• Не забудьте посмотреть мое видео ниже, чтобы увидеть точный код для этого. Но в основном я хочу сделать оператор «Если», говорящий, что если режим = новый, то приложение должно запустить «Добавить новую встречу» в заголовке.
• Если он не в новом режиме, а в режиме редактирования, я хочу, чтобы он возвращал что-то более динамичное. Я добавлю код для запуска заголовка как «Изменить встречу для».
• Я хочу, чтобы это предложение динамически заканчивалось на любой встрече, на которой я присутствую, поэтому я добавляю &. Я хочу, чтобы он извлек значение из того, что мы выбрали в галерее. После & я ввожу имя своей галереи, затем выбираю и возвращаю столбец с именем питомца. Итак, мой заголовок, например, будет гласить «Изменить встречу для места».
• Теперь, когда я взаимодействую с этим приложением, форма под заголовком остается прежней, но заголовок изменяется динамически для добавления или редактирования встречи.

Сегодня я установил текст заголовка в моем приложении для изменения в зависимости от того, в каком режиме находится моя форма при ее запуске. Код для этого был довольно прост, и вы можете увидеть это на моем видео.

Если у вас есть еще какие-нибудь советы в Power Platform, по которым вы хотели бы получить быстрый совет, обязательно добавьте его в раздел комментариев. Если вам нужны дополнительные тренинги по Power Apps, наша платформа обучения по требованию включает курсы Power Apps и Power Platform как часть нашей библиотеки из более чем 55 курсов. Отличное место для начала - это БЕСПЛАТНОЕ приложение в рамках дневного курса - верно, я сказал БЕСПЛАТНО. Нажмите ниже, чтобы подписаться на бесплатный курс сегодня!

примеров динамической вставки ключевых слов в Google AdWords

Динамическая вставка ключевых слов (DKI) - это функция, предлагаемая в Google Рекламе (ранее Google AdWords) и других рекламных сетях, которая позволяет настраивать объявление в соответствии с поисковым запросом пользователя.В этом кратком руководстве по динамической вставке ключевых слов вы узнаете:

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

Что такое динамическая вставка ключевых слов?

Динамическая вставка ключевых слов позволяет динамически вставлять ключевое слово AdWords в текст объявления на основе запроса пользователя.

Итак, если у меня есть группа объявлений для моего диванного магазина, которая включает такие ключевые слова, как:

• кушетки
• кушетки кожаные
• лучшие кожаные диваны
• и т. Д.

С помощью динамической вставки ключевых слов я могу показать людям, которые ищут "кушетки" слово кушетки, людям, которые ищут "кожаные диваны" эту фразу, и так далее в самом тексте объявления. DKI настраивает объявление на основе точного поискового запроса.

Вкратце: Динамическая вставка ключевых слов позволяет показывать поисковикам более релевантное объявление. , поскольку объявление динамически обновляется для включения реального поискового запроса пользователя.

Google определяет DKI так:

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

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

Обратите внимание на динамическую вставку ключевых слов, которая выделена. Три вещи на заметку:

• В скобках будет отображаться ключевое слово, если оно подходит. Так, если ключевое слово - «кожаный диван», заголовок объявления будет гласить «Отличные цены на кожаный диван».
• Вы контролируете использование заглавных букв - используя заглавные буквы в ключевом слове различными способами, вы можете контролировать способ отображения своих объявлений.
  • keyword = "кожаные диваны"
  • Keyword = "Кожаные диваны"
  • KeyWord = "Кожаные кушетки"
  • KEYWORD = "КОЖАНЫЕ КУХНИ"
• Если термин слишком длинный, будет вставлено слово или фраза после двоеточия - вы ограничены определенным количеством символов в каждой строке в объявлении PPC (25 для заголовка, 35 для строк описания).Итак, если пользователь ввел «кожаные диваны», а вы сосредоточили свои ставки AdWords на этом ключевом слове в этой группе объявлений, поисковая система отобразит ваше объявление следующим образом:

Важность динамической вставки ключевого слова

Динамическая вставка ключевых слов может быть ценным активом, но учтите: это также может доставить вам неприятности! Эта опция может значительно увеличить CTR при правильном использовании. Кроме того, при безответственном использовании на вас могут подать в суд.

Давайте посмотрим на некоторые плюсы и минусы, связанные с этой опцией:

Плюсы вставки ключевых слов

• Более конкретный таргетинг. Прелесть динамической вставки ключевых слов заключается в том, что она позволяет создавать объявления, содержащие текст, более конкретный, чем то, что вводил поисковик. Люди с гораздо большей вероятностью нажмут на заголовок, который более точно отражает то, чем они были. ищу.
• Полужирный текст - Google выделяет динамически вставляемые термины жирным шрифтом; это выделит ваше объявление, а также поможет повысить рейтинг кликов.

Минусы вставки ключевого слова

• Ключевые слова могут быть длинными. Согласно принципу, известному как длинный хвост поиска, по большинству запросов поиск выполняется редко, и если вы проводите всестороннее исследование ключевых слов, ваш список ключевых слов может это отразить. Некоторые из ваших ключевых слов могут быть длиннее других (вместо дивана вы можете использовать «кожаный диван» или «дешевые кожаные удобные диваны»). В этих случаях вы теряете ценность динамической вставки ключевых слов и запускаете общую замену для всех своих объявлений.
• Неуклюжие нарушения формулировок и товарных знаков - мы видели это в примере выше. Несмотря на то, что он умещается в 25 символов, если мы настроим широкий вариант соответствия для «диванов» и сопоставим объявление с «диван», мы получим следующее объявление:

Обратите внимание на неловко звучащий заголовок «Отличные цены на диван». Эти неудобные рекламные комбинации иногда будут поощрять клики из-за юмора, но шансы на конверсию чрезвычайно низки, что приводит к потере зря.В частности, eBay хорошо известен в индустрии поискового маркетинга тем, что злоупотребляет DKI, иногда создавая непреднамеренно юмористическую рекламу.

Динамическая вставка ключевых слов и нарушение товарных знаков

Еще хуже, что, если бы мы делали ставку на «Магазин диванов конкурентов Джо»?

Допустим, я установил заголовок как «Ключевое слово: отличные цены на диваны», а одним из ключевых слов в моей группе объявлений было «Магазин диванов Джо», что является названием магазина моего конкурента.

Несмотря на то, что делать ставки по этому ключевому слову разрешено, недопустимо для отображать в заголовке "Joe's Couch Store".DKI втянул меня в горячую воду с юридической точки зрения. Очевидно, это было не лучшее время для использования динамической вставки ключевых слов.

Итак, следующий естественный шаг в руководстве - рекомендовать вам, как правильно реализовать динамическую вставку ключевых слов .

Как использовать динамическую вставку ключевых слов

Короткий ответ - «умеренно». В приведенном выше примере мы видим потенциальные проблемы, связанные с чрезмерным использованием этой тактики. Вам необходимо знать точно, какие ключевые слова входят в ваши группы объявлений, прежде чем реализовывать эту опцию, и должны попытаться представить их как текст для этого объявления.Задайте себе вопрос:

• Есть ли в этом смысл?
• Неужели динамическая вставка ключевых слов заставляет меня говорить то, чего я обычно не хотел бы говорить?
• Совершаю ли я какие-либо нарушения прав на товарный знак или иным образом подвергаю опасности свой бизнес или свой бренд?

Подробнее о динамической вставке ключевых слов

Узнайте больше о правильном и неправильном использовании DKI с помощью следующих ресурсов:

Попробуйте наше программное обеспечение Google Реклама бесплатно

Динамическая вставка ключевых слов - это лишь одна часть более крупной стратегии оптимизации ключевых слов, которая должна включать оптимизацию ключевых слов с длинным хвостом, обнаружение минус-слов и тестирование рекламы, чтобы найти сообщения, которые действительно находят отклик у вашей клиентской базы, что приводит к высоким показателям CTR и Показатели качества.WordStream Advisor предоставляет интеллектуальные инструменты, в том числе 20-минутную информационную панель, которые помогут вам найти, организовать и использовать наиболее подходящие ключевые слова для ваших кампаний PPC.

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

Настроить поведение хостинга | Документация Firebase

С помощью Firebase Hosting вы можете настроить индивидуальное поведение хостинга для запросы на ваш сайт.

Что можно настроить для хостинга?

• Укажите, какие файлы в локальном каталоге проекта вы хотите развернуть. Хостинг Firebase. Научиться.

• Обслуживать настроенную страницу 404 / не найдено. Научиться.

• Настройте перенаправления для страниц, которые вы переместили или удалили. Научиться.

• Настроить , перезаписать для любой из этих целей:

  • Показывать одно и то же содержимое для нескольких URL.Научиться.

  • Выполнение функции или доступ к контейнеру Cloud Run с хостинга URL. Узнайте, как: функция или контейнер.

  • Создайте динамическую ссылку на личный домен. Научиться.

• Добавьте заголовков , чтобы передать дополнительную информацию о запросе или ответ, например, как браузеры должны обрабатывать страницу и ее содержимое (аутентификация, кеширование, кодирование и т. д.). Научиться.

• Настройка перезаписи интернационализации (i18n) для обслуживания определенного контента на основе в зависимости от языковых предпочтений и / или страны пользователя.Узнайте, как это сделать (на другой странице).

Где вы определяете конфигурацию хостинга?

Вы определяете конфигурацию хостинга Firebase в своем firebase.json файл. Firebase автоматически создает файл firebase.json в корне вашего проекта каталог при запуске firebase init команда.

  "хостинг": {
  "public": "public", // единственный обязательный атрибут для Хостинга
  "игнорировать": [
    "firebase.json",
    "** /. *",
    "** / node_modules / **"
  ]
}
  

  "хостинг": {
  "public": "public"

  // ...
}
  

  "хостинг": {
  "общедоступный": "dist / app"

  // ...
}
  

  "хостинг": {
  // ...

  "игнорировать": [
    "firebase.json", // файл конфигурации Firebase (файл, описанный на этой странице)
    "** /. *", // файлы с начальной точкой должны быть скрыты от системы
    "** / node_modules / **" // содержит зависимости, используемые для создания вашего сайта, но не для его запуска
  ]
}
  

  "хостинг": {
  // ...

  // Возвращает постоянное перенаправление на «/ bar» для запросов к «/ foo» (но не «/ foo / **»)
  "перенаправления": [{
    "источник": "/ foo",
    "пункт назначения": "/ бар",
    «тип»: 301
  }]
}
  

  "хостинг": {
  // ...

  // Добавляем атрибут "перенаправления" в "хостинг"
  "перенаправления": [{
    // Возвращает постоянное перенаправление на «/ bar» для запросов к «/ foo» (но не «/ foo / **»)
    "источник": "/ foo",
    "пункт назначения": "/ бар",
    «тип»: 301
  }, {
    // Возвращает постоянное перенаправление на «/ bar» для запросов к «/ foo» и «/ foo / **»
    "источник": "/ foo {, / **}"
    "пункт назначения": "/ бар"
    «тип»: 301
  }, {
    // Возвращает временное перенаправление для всех запросов к файлам или каталогам в каталоге firebase
    "источник": "/ firebase / **",
    "destination": "https: // firebase.google.com/ ",
    «тип»: 302
  }, {
    // Перенаправление на основе регулярного выражения, эквивалентное приведенному выше поведению
    "регулярное выражение": "/firebase/.*",
    "destination": "https://firebase.google.com/",
    «тип»: 302
  }]
}
  

"hosting": {
  // ...

  "перенаправления": [{
    "source": "/ blog /: post *", // захватывает весь сегмент URL, начинающийся с "post"
    "destination": "https://blog.myapp.com/:post", // включает весь сегмент URL, идентифицированный и зафиксированный значением "source"
    «тип»: 301
  }, {
    "source": "/ users /: id / profile", // захватывает только сегмент URL "id", но ничего после
    "destination": "/ users /: id / newProfile", // включает сегмент URL, идентифицированный и зафиксированный значением "source"
    «тип»: 301
  }]
}
 

"hosting": {
  // ...

  "перенаправления": [{
    "regex": "/ blog / (? P . +)", // если вы знакомы с PCRE, имейте в виду, что RE2 требует, чтобы именованные группы захвата начинались с? P
    "destination": "https://blog.myapp.com/:post", // включает весь сегмент URL, идентифицированный и зафиксированный значением `regex`
    «тип»: 301
  }, {
    "regex": "/ users / (\ d +) / profile", // использует директиву \ d только для сопоставления сегментов числового пути
    "destination": "/ users /: 1 / newProfile", // первая группа захвата, которую можно увидеть в значении `regex`, называется 1 и т. д.
    «тип»: 301
  }]
}
 

  "хостинг": {
  // ...

  // Обслуживает index.html для запросов к файлам или каталогам, которые не существуют
  "перезаписывает": [{
    "источник": "**",
    "пункт назначения": "/ index.html "
  }]
}
  

"hosting": {
// ...

// Добавляем атрибут "перезаписывает" в "хостинг"
"перезаписывает": [{
  // Обслуживает index.html для запросов к файлам или каталогам, которые не существуют
  "источник": "**",
  "пункт назначения": "/index.html"
}, {
  // Обслуживает index.html для запросов к "/ foo" и "/ foo / **"
  // Использование «/ foo / **» соответствует только таким путям, как «/ foo / xyz», но не «/ foo»
  "источник": "/ foo {, / **}",
  "пункт назначения": "/ index.html "
}, {
  // Перезапись на основе регулярных выражений, эквивалентная описанному выше поведению
  "регулярное выражение": "/foo(/.*)?",
  "пункт назначения": "/index.html"
}, {
  // Исключает указанные пути из перезаписи
  "источник": "! / @ (js | css) / **",
  "пункт назначения": "/index.html"
}]
}
 

  "хостинг": {
  // ...

  // Направляет все запросы со страницы `/ bigben` на выполнение функции` bigben`
  "перезаписывает": [{
    "источник": "/ bigben",
    "функция": "bigben"
  }]
}
  

  "хостинг": {
 // ...

 // Направляет все запросы со страницы `/ helloworld` на запуск и запуск контейнера` helloworld`
 "перезаписывает": [{
   "источник": "/ helloworld",
   "запустить": {
     "serviceId": "helloworld", // "имя службы" (с момента развертывания образа контейнера)
     "region": "us-central1" // необязательно (если опущено, по умолчанию используется us-central1)
   }
 }]
}
  

  "хостинг": {
  // ...

  // Применяет заголовок CORS для всех файлов шрифтов
  "заголовки": [{
    "источник": "** / *. @ (eot | otf | ttf | ttc | woff | font.css)",
    "заголовки": [{
      «ключ»: «Управление доступом-Разрешить-Происхождение»,
      "ценить": "*"
    }]
  }]
}
  

"hosting": {
  //...

  // Добавляем атрибут "заголовки" в "хостинг"
  "заголовки": [{
    // Применяет заголовок CORS для всех файлов шрифтов
    "источник": "** / *. @ (eot | otf | ttf | ttc | woff | font.css)",
    "заголовки": [{
      «ключ»: «Управление доступом-Разрешить-Происхождение»,
      "ценить": "*"
    }]
  }, {
    // Заменяет 1-часовой кеш браузера по умолчанию на 2-часовой кеш для всех файлов изображений
    "источник": "** / *. @ (jpg | jpeg | gif | png)",
    "заголовки": [{
      «ключ»: «Кэш-контроль»,
      "значение": "max-age = 7200"
    }]
  }, {
    // Перезапись на основе регулярных выражений, эквивалентная описанному выше поведению
    "регулярное выражение": ".+ / \ w + \. (jpg | jpeg | gif | png) $ ",
    "заголовки": [{
      «ключ»: «Кэш-контроль»,
      "значение": "max-age = 7200"
    }]
  }, {
    // Устанавливает заголовок кеша для 404 страниц для кеширования на 5 минут
    "источник": "404.html",
    "заголовки": [{
      «ключ»: «Кэш-контроль»,
      "значение": "max-age = 300"
    }]
  }]
}
 

  "хостинг": {
  // ...

  // Капли `.html` из загруженных URL
  "cleanUrls": правда
}
  

  "хостинг": {
  // ...

  // Удаляет завершающие слэши из URL
  "trailingSlash": ложь
}
  

  {
 "hosting": {  "public": "dist / app", // "public" - единственный обязательный атрибут для Хостинга  "игнорировать": [
 "база.json ",
 "** /. *",
 "** / node_modules / **"
 ],  "перенаправления": [{
 "источник": "/ foo",
 "пункт назначения": "/ бар",
 «тип»: 301
 }, {
 "источник": "/ firebase / **",
 "destination": "https://www.firebase.com",
 «тип»: 302
 }],  "перезаписывает": [{
 // Показывает одно и то же содержимое для нескольких URL
 "источник": "/ приложение / **",
 "пункт назначения": "/app/index.html"
 }, {
 // Настраивает личный домен для динамических ссылок
 "источник": "/ промо / **",
 "dynamicLinks": true
 }, {
 // Направляет запрос облачным функциям
 "источник": "/ bigben",
 "функция": "bigben"
 }, {
 // Направляет запрос контейнерному приложению Cloud Run
 "источник": "/ helloworld",
 "запустить": {
 "serviceId": "helloworld",
 "регион": "us-central1"
 }
 }],  "заголовки": [{
 "источник": "**/*.@ (eot | otf | ttf | ttc | woff | font.css) ",
 "заголовки": [{
 «ключ»: «Управление доступом-Разрешить-Происхождение»,
 "ценить": "*"
 }]
 }, {
 "источник": "** / *. @ (jpg | jpeg | gif | png)",
 "заголовки": [{
 «ключ»: «Кэш-контроль»,
 "значение": "max-age = 7200"
 }]
 }, {
 "источник": "404.