В каждой партнерке есть такая сущность, как оффер. Это почти отдельная личность, которая связывает между собой арбитражника и рекламодателя, пропуская через себя трафик. У этих сущностей есть особенности, из-за непонимания которых, многие мои клиенты теряют или некорректно обрабатывают трафик. Разбираться будем на примере вертикали крипты. Надеюсь, этот материал поможет разобраться и сведет подобные кейсы к минимуму.
Привет! Меня зовут Антон Резник и я тот человек, который взвалил на себя миссию пропагандировать здоровый подход к созданию партнерок. Как создатель сервиса AlterCPA, я каждый день вижу ошибки основателей, из-за которых их бизнесы проваливаются. Так что уже несколько месяцев я веду блог Как создать ПП и не разориться, в котором выдаю уникальную информацию. Не забудь подписаться :)
Вся механика работы с офферами и закованными в них воронками будет сводиться к тому как изначально выполнена интеграция партнерки с рекламодателем. Получаем клубок интеграция-офферы-воронки.
Распутываться будет правильным исходя из соотношения гео и языков, которые запрашивают практически все реклы. Грамотную структуру можно выстроить только если за точку отсчета взять язык целевой аудитории, соответственно язык лендинга, язык личного кабинета и язык операторов колл-центра, которые будут звонить. Именно вокруг языка и крутятся все эти сущности внутри партнерки.
Рассмотрим разные варианты и сценарии, чтобы понять как выстраивать структуру здорового человека и не терять трафик и профит.
Вариант простой воронки. 1 язык
Есть такая популярная в крипте воронка — Bitcoin Era. Она работает, в частности, в Венгрии и Италии, но только с англоязычной аудиторией, соответственно, к ней нужны лендинги на английском и англоговорящий КЦ.
Это классический пример воронки с любым количеством гео, но только с одним языком. И вот такое сочетание: куча гео — один язык, можно считать единой сущностью, единым оффером. Делать разбивку одно гео — один оффер можно, если очень хочется, но прямой необходимости в этом нет.
За каждым лидом закрепляется гео, по которому, исходя из предварительно внесенных данных, определяется, к примеру, размер выплаты или другие параметры.
Заносить это можно спокойно в один оффер. А язык можно передать сразу двумя способами:
1. Статично прописать язык при интеграции. Но нужно быть уверенным, что ситуация не изменится в будущем. При добавлении динамических языков, переделывать придется как интеграцию, так и все офферы, а это долго и муторно.
2. Прописать в интеграции макрос {lang} либо {langup}, если нужны заглавные буквы (EN, UA, KZ etc). На уровне оффера настраивается параметр lang с необходимым значением. По всем гео оффера язык будет тот, что зададут в параметрах оффера. Такой подход позволит при добавлении офферов с другими языками быстро подключить их в интеграцию и не заниматься переделыванием всей структуры.
Параметр с языком на уровне оффера:
Вариант сложный. 2+ языков
Здесь каноничным примером будет воронка BitcoinProfit, у которой есть Чехия с чешским языком и Германия с немецким. И вот эти воронки топорно объединять в один оффер нельзя категорически!
У Германии будет свой сайт и свой КЦ, а у Чехии свои. И работать они будут абсолютно независимо друг от друга, никак не пересекаясь.
Есть 2 разных способа провести интеграцию таких офферов и воронок
Решение 1. Разные офферы
Можно воронку из примера BitcoinProfit просто делить по языкам и создавать разные офферы, в каждый из которых будет включен только один язык.
Вариант настройки передачи языка лишь один: использование макроса. Он сам достает код языка из гео, мы отдыхаем. Выглядеть будет так же как и в простом варианте:
Преимущества решения:
- Простота настройки;
- Легкость использования сущности, так как нет загромождения информацией, лендингами и условиями.
Но есть и недостатки:
- Веб может перепутать оффер и залить не туда;
- Слишком много сущностей в системе.
Решение 2. Гибридный оффер
Внутрь одного оффера помещаем несколько воронок с разными языками. У гибрида, по сравнению с раздельно заведёнными офферами, есть дополнительная особенность — возможность наличия геозависимости параметров. Чаще всего — название воронки.
Иногда брокеры хотят, чтобы название воронки содержало гео или какую-то пометку, например BitcoinProfit_IT, BitcoinProfit_ES etc.
Нам нужно, чтобы оффер был один, но название воронки по каждому гео передавалось своё. Настраивается эта зависимость от гео легко. В поле интеграции, где должно быть название, прописывается макрос {ofpg:xxx}, где вместо xxx — любое угодное душе название параметра.
У самих офферов настраиваются параметры под нужные гео. В нашем случае параметра будет два:
- xxx BitcoinProfit_IT;
- xxx-es BitcoinProfit_ES.
Первый параметр (xxx) обязательно должен быть без указания гео, иначе ничего работать не будет.
Вариант настройки передачи языка также лишь один: использование макроса. Он сам достает код языка из гео, мы отдыхаем. Выглядеть будет так же как и в простом варианте:
Преимущества:
- Все в одном месте;
- Исключены «промахи» арбитражников.
Недостатки:
- Необходима сложная скрупулезная настройка;
- Перебор с информацией. Чтобы избежать хаоса, важно грамотно работать с неймингом сайтов, отчислений etc.
Само собой ПП, сделанные на моем AlterCPA получают все рекомендации по интеграции и избавлены от страданий.
Как никогда не надо создавать интеграцию
К примеру, есть воронка BitcoinUP. На нее можно лить англоговорящие Италию и Венгрию, а можно локальные языки этих стран. Англоговорящий BitcoinUP и локальный — абсолютно разные сущности, которые никогда нельзя объединять в одну. Придумать схему как их «подружить между собой» — нереально и придется в будущем переделывать интеграцию.
Неправильно созданная интеграция воронок с несколькими языками: цена ошибки
Перейти на гео-параметры крайне легко, поэтому не произойдёт ничего страшного, если их необходимость обнаружится не сразу. А вот с передачей языка всё гораздо сложнее.
Если имеем дело с действующей интеграцией, у которой стояла статика, а теперь стала нужна динамика (макрос) — здравствуй, головная боль. Начинается переделывание интеграции, перенастройка старых офферов, если статичный язык отличался от нативных языков офферов.
Уровень боли будет зависеть от того, сколько офферов работало по статичному параметру. Чем больше офферов — тем больнее. Но даже тут есть чем облегчить участь, используя утилиту, доступную для всех ПП на движке от AlterCPA. Она автоматизирует некоторые действия и значительно сократит время на исправление.
Изменение полей данных. Было:
Стало:
Вывод
Чтобы вся техничка внутри ПП работала правильно, необходимы корректные интеграции. Для этого не обойтись без структурного подхода к распределению воронок по офферам и использования нужного подхода передачи языка. Если интеграция настроена криво, то офферы в большинстве случаев не получится правильно встроить или придется использовать массу костылей.
Важные тезисы, которые, надеюсь, останутся с вами навсегда после этой статьи:
- Нужно заранее решить как корректнее передавать язык: статично или через макросы.
- Надо обратить внимание, понадобится ли гео-зависимость каким-либо параметрам.
- Ошибки по второму пункту не критичны, по первому — могут сделать больно и съесть массу времени на переделывание всей структуры интеграций, офферов и воронок.
Рекомендую прочитать пост «Бюджетное открытие партнерки», чтобы понимать кого нанимать, сколько и на что тратить, чтобы быстро и дешево запустить свой бизнес в арбитраже трафика.
