Привет.
Решил поучаствовать во втором конкурсе статей. Участвовал в первом, несколько человек написало в личные сообщения и сказало спасибо, это очень приятно. Хочу продолжить.
В этот раз мы обсудим как правильно автоматизировать перенос затрат из источника трафика в трекер, я поделюсь особенностями, с которыми столкнулся лично, расскажу как без знаний программирования быстро разобраться с api бинома и различных источников трафика, покажу как работать с программой Postman, и быстро и без ошибок переносить запросы в любой из популярных языков программирования, который вы возможно знаете.
А даже если не знаете, то можете взять зеннопостер, сгенерировать для него нужные запросы, а остальную логику собрать из встроенных кубиков. Или написать подробное задание программисту-фрилансеру, тоже вариант.
Начнем с теории.
Зачем арбитражнику пробрасывать затраты из источника трафика в трекер? Очевидно, чтобы в одном месте, – в трекере, видеть всю реальную статистику по кампаниям, как общий оборот, полученный от работы кампаний, так и расходы на их поддержание.
Это позволяет проводить аналитику по различным “срезам”, часть которых недоступна в источнике трафика.
Например, если ваш трекер умеет определять процент ботов, пришедших с каждого паблишера по отдельности (а бином это делать умеет), то можно увидеть срез сколько стоит переход “живого пользователя” на ваш лендинг. В источнике трафика такой отчет обычно сделать просто невозможно.
Если вы работаете с рекламными сетями с оплатой за клик, то настроить проброс затрат элементарно, просто в настройках трекера надо ввести стоимость этого самого клика.
Но что делать, если вы платите за показы ваших креативов на сайтах рекламной сети? При большом количестве трафика в ваших кампаниях эти показы могут расти очень быстро, а кликов может быть меньше ожидаемого. И пока вы думаете, что мало кликов означает мало трафика у паблишеров, показы ваших креативов растут очень быстро, делая каждый ваш клик золотым.
Плюс к этому, если вы посмотрите статистику кампании в источнике, то увидите там общие затраты и возможность разбивки затрат по креативам, паблишерам или любым другим параметрам. Но в трекере у вас своя статистика по обороту в разрезе каждого паблишера, и чтобы понять какой из паблишеров идет в минус, а какой дает 200+% ROI надо эти две статистики объединить, сравнить и только потом уже делать выводы.
Вручную это делать очень проблематично, ведь нужно обновить затраты по каждому паблишеру в каждой кампании.
Если у вас всего одна-две кампаний, то можно потратить полчаса-час в день, обновляя каждого паблишера по одному, и стараясь нигде не ошибиться. Но что если у вас таких кампаний десять? или сто? А если вы хотите обновлять затраты не раз в день, а чаще? Нанимать армию рабов?
Нет, мы будем работать эффективнее, автоматизируем этот процесс. И это уже даже не будет вашим конкурентным преимуществом, наоборот, если у вас нет подобной автоматизации, то вы отстаете от своих конкурентов.
Некоторое время назад, написав свой первый скрипт по пробросу затрат из источника трафика в трекер, я столкнулся с некоторыми особенностями этого действия. Некоторые из них очевидны, некоторые нет. Поделюсь ими с вами.
1) Первая особенность – обновлять затраты в трекер можно только по одному параметру. При открутке показов в рекламной сети каждый клик имеет свою уникальную стоимость, которая зависит от многих параметров – стоимость показа на сайте паблишера, устройство пользователя,
ctr креатива и многие другие. Этими данными источники ни с кем не делятся (да и не к чему они нам), но предоставляют взамен усредненную статистику по различным параметрам. Можно выбрать любой из них, но рекомендую выбрать один из двух максимально полезных – или по id креатива, или по id рекламной площадки.
2) Второй момент – нагрузка на базу трекера.
Базы данных очень не любят подобную работу, ведь она требует большого количества мелких операций. Это можно сравнить с производительностью жесткого диска компьютера – чтобы записать тысячу мелких файлов потребуется больше времени, чем записать один большой файл с одинаковым общим размером.
Нагрузка на базу растет, ее производительность на это время уменьшается. Поэтому время обновления затрат это очень важный параметр, обновляйте затраты тогда, когда количество входящего на трекер трафика падает, например, рано утром. Но не у вас, а в стране или странах, где крутятся ваши кампании. С учетом разницы в часовых поясах.
3) Часовые пояса.
Помимо часовых поясов стран, в которых крутятся ваши кампании, не стоит забывать и о часовом поясе рекламной сети, в которой вы покупаете трафик. Очень часто это UTC, но бывают и исключения в ту или иную сторону. Плюс к этому добавляется разница с часовым поясом трекера.
Если например для удобства вы выставили в трекере часовую зону UTC+3, то это тоже стоит учитывать, так как когда в трекере начинаются новые сутки, в источнике трафика, работающем в часовой зоне UTC, те самые прошлые сутки еще будут идти три часа.
И если вы вдруг захотите обновить затраты за прошлый день ровно в 00.10, ваша сумма затрат будет отставать от реальной на те самые три часа (точнее на 2 часа 50 минут), и в итоге вы получите неверные данные.
4) Погрешность.
Как бы точно и часто вы не обновляли затраты в ваших кампаниях, всегда в результатах будет небольшая погрешность. И чем больше строк вы обновили (например – количество паблишеров), тем большей она может быть. Это нормально, с этим можно работать, но необходимо отслеживать процент погрешности, чтобы он был не очень высокий.
И вот вам закономерность для мотивации – чем больше общие затраты, тем меньше процент погрешности вы увидите. Лейте много трафика).
5) Проверка кампаний на апдейт затрат.
Чтобы впустую не нагружать базу данных трекера, прежде чем начать обновлять кампанию необходимо проверить ее параметры. Вы ведь не хотите обновлять затраты за вчерашний день в кампании, которая уже неделю как остановлена, да?
Кажется очень логичным, но скрипт этого не знает пока вы не укажете. В лучшем случае получите ошибку скрипта, если источник трафика вернет пустой ответ. В худшем – будете впустую нагружать базу.
Также надо проверять кампанию в источнике на минимальное количество кликов или затрат. У меня были случаи, когда свеже-запущенная кампания стояла без трафика, потратив за сутки меньше доллара. Мой скрипт конечно же начал обновлять ее затраты вместе с другими кампаниями.
Зачем нужно такое обновление, если там фактически нечего обновлять? Только лишняя нагрузка на базу. Поэтому была добавлена доп. проверка на минимальную сумму затрат. С такой проверкой первая часть пункта будет проверяться автоматически.
6) Проверка обновления данных.
Чтобы быть уверенным, что обновление затрат работает как надо, имеет смысл брать полученную сумму затрат в трекере после обновления, сравнивать ее с фактическими затратами в источнике данных и получать ту самую погрешность из п.4 Дополнительно можно брать затраты из трекера до обновления.
Например: было в трекере до обновления $10, после обновления затрат: $18.4. Фактические затраты в источнике трафика: $18.2. Погрешность: $0.2
Такой отчет желательно делать при каждом обновлении. Можно его отправлять в телеграм, можно в slack, можно на емейл, куда пожелаете.
7) Обновление стоимости клика.
Чтобы сократить разницу между затратами в трекере и фактическими в источнике в течение дня, удобно при каждом обновлении затрат также рассчитывать и обновлять среднюю стоимость клика по кампании.
В этому случае общее количество затрат в трекере за сутки получается очень близким к фактическим, а при самом обновлении затрат эта сумма только перераспределяется между разными паблишерами (или другим выбранным значением параметра обновления). Бином такое решение поддерживает. И это очень удобно.
8) Запуск обновления по расписанию.
Для установки расписания запуска скрипта есть три основных метода.
Первый – через службу cron прямо на сервере с трекером. Достаточно надежная вещь, но
надо лезть настраивать на сервер.
Второй – через aws lambda функции. Про настройку этого метода я писал статью на
прошлый конкурс. Удобно и бесплатно. Мой выбор.
Третий – настроить расписание на зеннопостер. Минус – держать компьютер с
зеннопостером постоянно включенным, не очень удобно, а выделять отдельный – нерентабельно.
С теорией закончили, переходим к практике.
Будем разбираться как работать с апи с помощью программы Postman.
Для начала с сайта https://www.postman.com/ скачаем и установим саму программу. Как скачивать и устанавливать показывать не буду. При установке она попросит зарегистрироваться, это тоже нужно сделать самостоятельно.
Базовый функционал программа предоставляет бесплатно, продвинутый – в платном премиум аккаунте, но для наших целей никуда платить не надо, вполне хватит базовой версии.
Итак, скачали, установили, запустили, будем разбираться с апи. Начнем с апи бинома, для примера возьмем их тестовый трекер по адресу https://demo.binom.org/.
Ссылки на апи можно найти в настройках в разделе апи https://demo.binom.org/?page=settings#tab=api.
Там же лежит апи кей. Он нам тоже еще пригодится. Открываем в новых вкладках обе версии апи.
Начнем со второй. Открываем страницу https://documenter.getpostman.com/view/4002000/RVu7Dnr4?version=latest, и что мы видим?
Уже знакомое лого Postman и кнопку Run in postman в правом верхнем углу. Нажимаем. Браузер предлагает нам открыть программу Postman.
Открываем. И видим что слева появился блок:
Этот блок в Postman называется коллекцией. Коллекция содержит сборник различных апи запросов, которые понимает трекер.
Нажимаем на стрелочку слева, и видим множество подгрупп, которые разделены на функциональные блоки.
Например, откроем блок Monitor, там видим один GET запрос monitor@get. Он, как можно догадаться по названию, отвечает за данные на странице monitor в трекере. Выдает информацию о текущем пользователе, параметрах сервера, его нагрузке итд.
Кликаем на него и он откроется в центральной панели.
Это переменные, которые используются для облегчения нашей работы. Вместо того, чтобы в каждый запрос вводить наши домен и ключ, достаточно ввести их лишь в одном месте. В переменном окружении.
Окружение настраивается в правом верхнем углу. Мы даже можем иметь несколько окружений, в каждом будут отдельные переменные с разными доменами и апи ключами. И переключаться между ними можно буквально в пару кликов.
Сейчас нас интересуют только два первых. Меняем значения в столбике Current Value на значения от тестового трекера Бином.
Вау. Сервер прислал нам ответ:
Если сравнить эти данные с теми, которые расположены на странице monitor трекера, то можно увидеть, что они совпадают, только в Postman они закодированы в специальный формат (json) для обмена данными между программами.
Точно также будут работать и все другие запросы из коллекции. Получить данные, создать новые, изменить, удалить – возможно все. Надо только найти нужный метод и ввести необходимые значения.
Теперь посмотрим апи бинома v1 на странице https://docs.binom.org/api.php#p3 Тут к сожалению нет кнопки Run in Postman, придется разбираться вручную.
Сразу видим ссылку Update costs, она нам и нужна, переходим.
Здесь мы видим ссылку, подставив данные в которую, можно обновить затраты нужной кампании за любой период.
У нас версия трекера 1.14, поэтому нас интересует ссылка для версии от 1.9
Копируем ее и переносим в Postman.
Программа ее распознала и сама выделила нужные поля в качестве переменных
Так как у нас доме и ключ уже хранятся в переменных, подставим их и сюда.
Но так как в переменной {{url}} у нас хранится адрес со ссылкой на файл arm.php, а здесь нам нужен только домен трекера, эта переменная нам не подойдет.
Надо создать или дополнительную переменную с доменом трекера, или прописать домен прямо в запрос. Пока остановимся на втором варианте. А переменную api_key подставим.
Теперь осталось только выставить параметры вашей кампании согласно описанию каждого параметра и нажать кнопку Send. Затраты в кампании обновятся.
Но даже если мы просто отправим данный запрос, мы получим ответ от трекера:
Он нам отвечает, что такого токена в кампании с id #1 не найдено, и поэтому кликов для обновления он не нашел. Но с реальными данными все работает, проверено.
И остался еще один момент, как эти заготовки перевести в скрипт на языке программирования? Можно конечно перенести все вручную, но зачем, если у Postman есть классная фича, которая этот процесс тоже автоматизирует. Надо просто нажать ссылку Code под кнопкой Send
Нажимаем. И видим окно, где выбранный запрос уже перенесен на десятки языков программирования.
Хотите – php, хотите go или python, C# или Nodejs. Выбирайте на свой вкус.
Та же схема работает и с большинством источников трафика.
Возьмем например PropellerAds. Быстрый поиск в гугле по запросу “Propellerads api” выдает ссылку на их api документацию: https://ssp-api.propellerads.com/v5/docs/
Api ключ можно получить в личном кабинете рекламодателя.
А дальше все тоже самое. Переносите запросы в Postman, тестируете вручную, проверяете что все работает, переносите запросы в код.
Дальше вам останется только прописать логику, которая будет получать данные кампаний из источников трафика и подставлять их в запросы на обновление затрат к трекеру.
Программирование – штука гибкая, как захотите так и будет работать. А на что обратить внимание вы уже в курсе.
Удачи!