Настройка технического сетапа на iGaming вертикаль

Начинаем серию практических мануалов по разбору и подготовке запуска на iGaming вертикаль с помощью трекера AIO. Как обычно, у меня в гостях Макс Постоев. В сегодняшней статье разберем техподготовку к запуску. 

Главная задача мануала - показать на практике, как правильно настраивать трекер и запускать трафик в iGaming вертикали. 

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

То есть готовим техничку, создаем PWA, строим поток, подключаем оффер, прокидываем конверсии и только после этого получаем ссылку для запуска.

Технический сетап

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

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

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

Сервер брали на DigitalOcean, DNS настраивали через  Cloudflare, а домены покупали у подключенного доменного провайдера – NameSilo.

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

Сервер

Первым делом создаем в аккаунт DigitalOcean.

Регистрация стандартная: email, подтверждение аккаунта, платежный метод и баланс. После этого нам не нужно вручную поднимать сервер через консоль и настраивать его с нуля. Наша задача – получить API-токен, через который трекер сможет взаимодействовать с аккаунтом DigitalOcean.

Создаем API-токен

В DigitalOcean открываем раздел API и генерируем новый токен через Generate Token.

Есть два важных параметра, на которые необходимо обратить внимание при создании токена.

1. Срок его жизни.
2. Права доступа.

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

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

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

После этого генерируем токен, копируем его и переходим в раздел серверных провайдеров внутри трекера.

Добавляем DigitalOcean и вставляем API-токен.

На этом сама интеграция практически закончена.

На этом этапе возникает закономерный вопрос: зачем все это делается и что означает Droplet Size.

Если максимально упростить, сервер – это удаленный компьютер, который будет обрабатывать трафик.

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

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

Droplet Size – это конфигурация удаленного компьютера.

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

Например, вместо одного дорогого сервера можно поднять несколько небольших и развести трафик.

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

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

Следующий важный параметр – Регион сервера (Servers Region).

Сервер желательно размещать ближе к Гео, на которое идет трафик.

Если запускаем Европу, логично взять европейский сервер, например, в Амстердаме.

Если работаем с Азией – выбираем сервер, расположенный в Азии.

Это не значит, что без идеального совпадения Гео воронка перестанет работать, но чем короче путь между пользователем и сервером, тем лучше для скорости загрузки и общей стабильности.

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

Даем ему понятное название, выбираем monitoring user, сотрудника, которому будут приходить уведомления о состоянии сервера, в том числе в Telegram,  подтверждаем покупку – и система начинает автоматически разворачивать droplet.

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

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

После этого в DigitalOcean можно практически не заходить. Остается только следить за балансом аккаунта.

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

Cloudflare

Следующий элемент – DNS.

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

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

Cloudflare в этой схеме связывает домен с сервером.

Для базового использования достаточно обычного аккаунта Cloudflare. Сама интеграция строится через API.

После регистрации в Cloudflare переходим в настройки профиля и находим API-раздел. Для правильной интеграции нужен именно Global API Key.

Не кастомный токен с самостоятельно выбранными доступами, а Global API Key из профиля. Нажимаем View, подтверждаем действие кодом, который приходит на email, копируем ключ.

Дальше внутри трекера указываем email аккаунта Cloudflare и Global API Key.

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

Доменный провайдер и покупка домена

Теперь у нас есть сервер и DNS. Не хватает самого домена.

В системе можно подключать различные сервисы для покупки доменов. Например, Namecheap или NameSilo.

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

Здесь подход тот же: регистрируем аккаунт у доменного провайдера, находим API-ключ и добавляем его в интеграцию.

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

В документации ищем название сервиса, например NameSilo, и получаем пошаговый гайд по подключению.

После добавления API-ключа также запускаем тест интеграции.

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

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

Подключив провайдер, переходим в раздел доменов и нажимаем Buy Domain.

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

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

После выбора домена указываем аккаунт доменного провайдера, сервер, на который будет направлен трафик, и Cloudflare-интеграцию.

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

В интерфейсе можно видеть стоимость домена, состояние, статус мониторинга и текущую нагрузку.

А также настроить уведомления, в том числе в Telegram, на случай если с доменом что-то пойдет не так.

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

Если аккаунты уже зарегистрированы, API-ключи получены и баланс пополнен,процесс занимает около 15 минут.

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

После этого сервер и домен можно поднимать буквально в несколько действий.

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

Благодаря трекеру и интеграциям большая часть процессов автоматизирована.

Интеграция PWA

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

В нашем случае используется PWA. Рассмотрим на примере ZM Apps. Интеграция с PWA-сервисом уже доступна внутри трекера AIO, поэтому отдельно писать кастомную связку не требуется.

Переходим в PWA-сервис и создаем приложение. 

Работа с PWA-сервисом перед созданием потока.

Выбираем шаблон

Внутри PWA-сервиса есть библиотека шаблонов.

Выбираем готовый шаблон, открываем, проверяем и сохраняем. Это важный момент: цель текущего этапа – проверить техническую воронку, а не собрать идеальное ПВА.

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

Создаем поток в PWA

После создания приложения нужно настроить, как через него будет проходить пользователь. Для этого создается поток. Выбираем домен и созданную PWA, также определяем платформу: Android, iOS или cross-platform.

Отдельно на стороне PWA можно настраивать пиксель, клоаку и другие элементы, но в нашем сценарии большая часть этого будет работать на стороне трекера.

Поэтому лишние настройки можно не дублировать.

Следующий элемент опционален – прелендинг.

Можно построить воронку так: PWA – прелендинг – оффер.

А можно сразу: PWA – оффер.

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

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

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

Еще одна важная часть в ПВА – пуши.

Представим простую ситуацию. Пользователь установил нашу PWA, запустил, но не зарегистрировался. Для нас такой пользователь дошел до этапа install и остановился. 

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

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

То есть при правильном подходе пуши становятся дополнительным инструментом, увеличивающим профит.

Как выглядит сама iGaming-воронка

До настройки кампании важно понять воронку целиком.

В базовом варианте она выглядит так: Клик – Переход на оффер (ПВА страница в нашем случае) – Инсталл – Регистрация – FTD – ReDep.

• Клик – пользователь нажал на рекламное объявление и попал в воронку.

• Переход на оффер – пользователь попал на страницу оффера: страницу с ПВА, PlayMarket, AppStore.

• Инсталл – установка PWA/приложения.

• Регистрация – зарегистрировался в приложении или PWA

• FTD – сделал первый депозит.

• ReDep – сделал повторные депозиты

Дальше можно добавлять дополнительные события для отслеживания: PWA Open, подписка на push, quality deposit и другие KPI.

Трекер позволяет видеть конверсию между этапами. Например, сколько визитов превратилось в install, сколько install дали registration и сколько регистраций дошли до FTD.

Именно на этой воронке в дальнейшем будет строиться аналитика. Если одна кампания дает хорошие регистрации, но проваливается на депозитах, это уже сигнал.

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

Кампания и поток в трекере

Теперь переходим к созданию потока.

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

Для текущего примера использовался простой PWA-flow.

Внутри цепочки есть несколько основных элементов:

Source – Filter – PWA – Landing (опционально) – Оффер.

Разберем их по порядку.

Source (Источник)

Source – это рекламный источник, откуда приходит пользователь.

Именно сюда позже будет вставлена готовая трекинговая ссылка. Примеры сорсов: Meta, Google, TikTok, Taboola или так далее. Мы показываем работу с Meta.

Mode (Режим фильтрации)

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

В результате показатели воронки искажаются: число визитов увеличивается, коэффициенты установок/регистраций/депозитов падают. 

Принимать решения по таким данным равносильно спилу ветки, на которой сидишь. Именно для этого перед целевой страницей ставится один из трех режимов:

Filter

Стандартный режим. Система фильтрует входящий трафик и пропускает на целевую страницу только релевантных пользователей.

Money

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

Например, вы сами заходите через VPN и хотите проверить, что происходит после клика. Обычный фильтр может вас отсечь. В таком случае временно включаем Money и проходим воронку вручную.

White

Весь трафик отправляется на условно безопасную белую страницу, например, 404. Используется в случаях, когда необходимо остановить трафик.

Для обычной рабочей кампании выбираем стандартный Filter.

Выбираем Traffic Source (Источник трафика)

Дальше указываем источник. Для разных источников у системы есть свои наборы паттернов и отпечатков поведения. Если запускаем Meta – выбираем Meta.

Если нужного источника нет, можно использовать General, который работает как универсальный вариант. В показанном сетапе выбираем Meta.

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

Filter Level (уровень фильтрации)

Следующий параметр – уровень фильтра.

Для Гео с большим количеством мусорного трафика имеет смысл использовать более строгий уровень. 

Например, в части Tier-3 Гео может быть значительно больше ботов, VPN, автоматических запросов, краулеров и другого нецелевого трафика.

Для Tier-1 ситуация обычно спокойнее.

В качестве стартовой настройки рекомендуем использовать средний уровень – Medium.

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

Не нужно пытаться заранее найти «идеальную» жесткость. Стартуем со среднего значения, дальше смотрим по реальным данным.

Гео, язык, устройства и ОС

После фильтра указываем базовые параметры аудитории.

Страна – выбираем Гео оффера.

Система определяет страну пользователя по IP.

Пользователь с IP вне нужного гео может быть отфильтрован и не попасть в рабочую статистику. 

Язык – фильтр ориентируется по языку браузера.

Для стран с несколькими языками добавляем основные. 

Devices – выбираем устройства: desktop, smartphone, tablet.

Для PWA-связки нас в первую очередь интересует mobile.

Operating System – указываем нужные ОС: Android и iOS.

На этом базовая фильтрация готова.

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

Подключение PWA в поток

После фильтра выбираем PWA, которую создали ранее. с ZM Apps уже встроена в трекер, поэтому созданное приложение появляется в списке доступных PWA. 

Выбираем подготовленную ранее в ZM Apps Пва. Прелендинг, как уже обсуждали выше, можно оставить или удалить. И теперь остается финальный элемент – оффер.

Подключение оффера

Подключать оффер будем из партнерской программы Ace Partners.

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

Из этого потока мы получим ссылку на сторону рекламодателя. 

Создаем поток в партнерке

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

Внутри можно настроить домен, источник, метки, вариант landing/redirect, Гео, pixel и другие параметры.

Часть настроек сознательно можете пропускать, потому что их функции уже выполняются внутри трекера на стороне AIO.

Например, если фильтрация Гео уже работает в трекере, нет смысла настраивать тот же фильтр еще раз. То же самое касается настроек Пикселя.

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

Например, сразу registration form или бонусная механика с колесом фортуны.

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

Если хотите сравнить две механики, можно сделать сплит-тест и сравнить варианты по метрикам.

Если источником является Meta, важно подтягивать рекламные расходы.

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

В кампании включаем Cost Update Strategy и выбираем Meta Ads.

После подключения рекламного аккаунта система сможет регулярно подтягивать данные по расходам.И уже из этого можно считать экономику залива.

Настройка постбеков

Теперь доходим до самой важной части интеграции с партнерской программой – postback.

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

В нашем случае нас интересуют как минимум два события: Registration и FTD.

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

Когда сделал депозит – отправить еще одно.

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

У разных партнерских программ названия событий отличаются.

В Ace Partners:

• Новый лид = регистрация.

• Лид в холде = депозит, который еще находится в процессе проверки KPI. 

Также может существовать подтвержденный депозит – событие, по которому уже точно будет выплата. Если это нужно для аналитики, можно развести их на разные метрики. Например: FTD и Quality Deposit.

Но в базовом сетапе достаточно регистрации и FTD.

Создаем постбеки в трекере

В трекере переходим в раздел Conversions (Конверсии) 

и генерируем новый postback через генератор (зеленая кнопка в правом верхнем углу).

Выбираем событие регистрации. Далее задаем домен, оффер, валюту (при необходимости). 

После этого система генерирует готовую postback-ссылку. Копируем ее и вставляем в партнерской программе в поле postback для нового лида.

Но просто вставить URL недостаточно. Нужно правильно связать идентификаторы клика.

Чтобы партнерка понимала, какому конкретно пользователю соответствует событие, Click ID из трекера передается в один из sub-параметров партнерской программы.

В примере использовался SUB1.

В сгенерированной postback-ссылке заменяем placeholder Visit ID на соответствующий параметр партнерки – SUB1.

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

Следующая часть – выплата. Нам важно знать не только, что конверсия произошла, но и сколько денег она принесла. В postback есть revenue-placeholder. В партнерской программе смотрим документацию и находим макрос, который отвечает за Payout.

Подставляем его в postback вместо статического revenue.

Теперь при каждой конверсии трекер будет получать фактическую выплату из партнерки.

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

Например, один депозит оплачивается по $7, другой по $5.

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

Для FTD делаем ту же процедуру. Все повторяется, за исключением выбора типа конверсии.

Копируем ссылку и вставляем ее в партнерке в поле, соответствующее депозиту – в показанном примере это Лиды в холде.

Снова проверяем Click ID, SUB1 и Payout.

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

Настройка Оффера (Destination) в трекер

После настройки postback сохраняем поток в партнерке и копируем его итоговую ссылку.

Лучше использовать HTTPS. HTTP технически может работать, но без сертификата пользователь увидит предупреждение о небезопасном ресурсе и с большой вероятностью закроет страницу. 

В трекере открываем настройки, переходим к рекламодателям (Advertiser) и создаем нового на основе готового шаблона партнерки - или выбираем из списка уже имеющихся.

В шаблоне можно заранее прописать передачу Click ID в SUB1. При необходимости добавляются дополнительные sub-параметры. Например, в SUB2 можно передавать Campaign Name.

Тогда уже в партнерке вы сможете видеть не только Click ID, но и название кампании.

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

Теперь переходим к Офферу (Destinations). Создаем новый.

Выбираем создание через рекламодателя

В открывшемся списке находим созданный ранее – Ace Partners.  

В окне вставляем ссылку оффера из партнерки, задаем название, Гео, язык и теги.

Оффер готов.

Финальная сборка кампании

К этому моменту у нас уже есть сервер, домен, Cloudflare, PWA, фильтр, оффер, postback регистрации, postback FTD, revenue, Click ID и cost update.

Теперь остается собрать финальную ссылку для рекламного источника.

Открываем кампанию и вызываем Link Generator.  

В качестве Source выбираем Facebook/Meta*.

Дальше указываем необходимые параметры источника: token, pixel и events.

События можно маппить под удобные Meta-events.

Например:

• Registration – Lead;
• FTD – Purchase;
• Install – отдельный event.

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

Нажимаем Generate Link.

Получаем готовую ссылку. 

Эта ссылка уже содержит всю собранную нами логику: фильтрацию, PWA, оффер, партнерку, postback, передачу конверсий, cost и события.

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

С учетом объяснений Макса такая процедура заняла 40 минут. Если понимаете процесс, такой сетап можно собрать примерно за 20–30 минут.

Проверка воронки с телефона

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

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

Для теста используется сгенерированная tracking link.

Перед проверкой важно помнить про фильтр. Если тестируете связку через VPN или нестандартное соединение, фильтр может вас отсечь.

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

Шаг 1. Открываем ссылку в браузере

С телефона открываем ссылку из трекера.

Она ведет нас на PWA.

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

Шаг 2. Устанавливаем PWA

На iOS PWA добавляется на главный экран через меню Share.

На практике этот момент тоже показали в эфире:

Поделиться – Добавить на экран “Домой”.

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

Шаг 3. Разрешаем push

При первом запуске разрешаем уведомления.

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

Шаг 4. Переходим на оффер

После открытия PWA пользователь попадает дальше по настроенной цепочке.

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

Шаг 5. Делаем тестовую регистрацию

Вводим тестовые данные и отправляем регистрацию. После этого пользователь оказывается на стороне рекламодателя. Теперь возвращаемся в трекер и проверяем, пришло ли событие.

Проверка постбеков

После обновления статистики регистрация появилась в системе.

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

После этого открываем партнерскую программу и проверяем лид.

Одновременно в трекер прилетел install. При реальном депозите тем же способом должен отобразиться FTD.

Почему важно проверять всю воронку вручную

Один из самых частых технических косяков – это считать, что «раз мы все настроили, значит оно работает».

Но ошибка может возникнуть на любом этапе: домен не связан с сервером, DNS не обновился, PWA ведет не туда, Click ID не передается, SUB указан неправильно, postback использует не тот макрос, payout не передается, конверсия приходит без нужной кампании, HTTPS не работает или фильтр режет реального пользователя.

Поэтому перед тратой бюджета лучше один раз пройти воронку руками.

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

Минимум: визит – инсталл – регистрация. Если есть возможность протестировать депозит – еще лучше.

Итог

На первый взгляд техническая часть iGaming выглядит перегруженной : серверы, DNS, домены, API, PWA, партнерка, postback, sub-параметры, косты и пиксели.

Но если разобрать процесс на последовательные действия, становится понятно, что большая часть сетапа делается один раз:

• Один раз подключили DigitalOcean.
• Один раз подключили Cloudflare.
• Один раз добавили доменного провайдера.

После этого новые серверы и домены можно поднимать уже внутри системы.

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

выбрать оффер – собрать PWA – собрать flow – настроить postback – сгенерировать ссылку – проверить – запустить трафик.

Причем ценность такого сетапа не только в скорости запуска. Главное – в том, что вся воронка собирается в одном месте.

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

И уже после этого принимаете решения не по ощущениям, а по цифрам.

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

Спасибо что дочитали до конца! С вами были Денис Денисенко и Макс Постоев!