Архитектура аккаунта

D
На сайте с 26.02.2017
Offline
17
1974

Практики пока нет, поэтому решил посоветоваться со специалистами какая архитектура аккаунта НА ПРАКТИКЕ более оптимальна для запуска и непосредственного удобства ведения рекламных кампаний

Первый вариант (Архитектура №1)

Здесь у заказчика имеются для продвижения условно 2 товара, но их на практике, естественно, может в десятки раз больше. Данная архитектура предполагает для КАЖДОГО товара отдельную рекламную кампанию в аккаунте - причем отдельно для ВЧ, отдельно для СЧ и отдельно для НЧ

Итого три рекламных кампаний. В итоге 2 товара х3 = 6 рекл. компаний (на практике будет в десятки раз больше в зависимости от кол-ва товаров). Естественно для каждой рекл. кампании будут свои ставки после тестового периода

[ATTACH]162389[/ATTACH]

Второй вариант (Архитектура №2)

Здесь все тоже самое, НО созданы рекламные кампании в аккаунте не отдельно для каждого товара, а отдельно для ВЧ, СЧ и НЧ.

Т.е. внутри РК для ВЧ собраны все ключевые слова для Товара №1 и товара №2 (на практике товаров будет в десятки раз больше) и аналогично для СЧ и НЧ....

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

[ATTACH]162397[/ATTACH]

Подскажите, что более приемлемо именно на практике. Есть ли иные, более робастные варианты для построения и ведения РК, а предложенные мною крайне не эффективны на практике и так лучше не делать?

jpg 162389.jpg
jpg 162397.jpg
burnfive
На сайте с 06.01.2016
Offline
37
#1

Все зависит от товара. Представьте товар - "запчасть для форд капри сальник коленвала" есть ли смысл делать под этот сальник целую кампанию?

Реклама Директ, Adwords, ВК, ОК, Target Mail, FB. Выгрузка рекламных кампаний из агентского аккаунта Яндекс Директ с гостевым доступом.
D
На сайте с 26.02.2017
Offline
17
#2
burnfive:
Все зависит от товара. Представьте товар - "запчасть для форд капри сальник коленвала" есть ли смысл делать под этот сальник целую кампанию?

Согласен, но пусть будет так, что для каждого товара нарыто скажем по 1000 ключей (ВЧ+СЧ+НЧ)

W
На сайте с 08.02.2017
Offline
169
#3

давайте от противного. зачем нужно выделять объявления в отдельную кампанию?

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

сам чаще всего работаю с магазинами от 10.000 SKU, средней ценой товара около 20 тысяч рублей, бью кампании по

Бренд + модель товара (сколько брендов, столько и кампаний)

Категория товара + бренд (или наоборот) (сколько категорий - столько и кампаний или наоборот: сколько брендов - столько и кампаний)

Категорийные общие сч/вч запросы (сколько категорий, столько и кампаний)

Комплексный аудит ИМ. Формирование УТП, анализ юзабилити, каналов продвижения. Контекстная реклама, настройка систем аналитики. Консультация - бесплатно, в ЛС
D
На сайте с 26.02.2017
Offline
17
#4
wicker:


Бренд + модель товара (сколько брендов, столько и кампаний)

Категория товара + бренд (или наоборот) (сколько категорий - столько и кампаний или наоборот: сколько брендов - столько и кампаний)

Категорийные общие сч/вч запросы (сколько категорий, столько и кампаний)

По логике у вас идейный прототип Архитектуры №1, НО без выноса ВЧ, СЧ и НЧ в разные РК.

Внутри вы делаете в аккаунте метки для групп ВЧ, СЧ и НЧ, чтобы удобнее к ним добираться для регулировки ставки.?

Как я понимаю для ВЧ, СЧ и НЧ естественно у вас разные ставки?

W
На сайте с 08.02.2017
Offline
169
#5

dokgor, в варианте Бренд + модель товара делить на ВЧ-НЧ смысла мало (в моей нише). Все рекламодатели грузят весь прайс, не обращая внимания на частотность.

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

тут - Категорийные общие сч/вч запросы ключи от 500 запросов, тоже делить на, например, до и от 1000 нет смысла.

в целом, считаю, что бить по ВЧ-СЧ-НЧ логично огромные ядра, собираемые мануально. если реклама на основе прайса/базы сайта - не всегда оправданно

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий