Пользователи привыкли к принципу одного устройства и одного интерфейса.
Эта тенденция отражается и в бизнесе: многофункциональные корпоративные системы и порталы, единые торговые и закупочные платформы и т.д. Интернет-реклама не осталась в стороне – разрабатываются сервисы, направленные на существенную оптимизацию работы рекламодателей и рекламных агентств.
И одним из серьезных технических вопросов при создании дашбордов и агрегаторов статистики остается работа с API — программным интерфейсом, через который происходит обмен данными между системами.
Существует ли API вашей мечты, как его создать и зачем он нужен? 
Реклама в Интернете проходит сразу по нескольким каналам и размещается на многих площадках для охвата как можно большей аудитории.
Управление кампанией осуществляется через интерфейсы различных рекламных систем (Яндекс.
Директ, Google AdWords, система размещения ВКонтакте и др.
).
Каждый раз для просмотра статистики нужно авторизоваться, переключиться, а если есть необходимость сравнить статистику с разных сайтов, то еще и агрегировать данные в таблицах Excel или вручную импортировать данные в Google Analytics. Realweb лучше всех знает о необходимости удобной и эффективной работы с данными интернет-рекламы: мы управляем сотнями клиентов с десятками тысяч кампаний, поэтому наглядное представление статистики является для нас критически важным фактором.
Для этого мы используем систему сбора рекламной статистики.
AdHands .
Это своего рода дашборд: информация по всем рекламным кампаниям агрегирована в едином интерфейсе.
Такой подход обеспечивает удобство, широкие аналитические возможности и точное понимание того, какая реклама эффективна, а какая нет. В случае с рекламой в Интернете оценить «выхлоп» от нее крайне сложно.
На дворе 21 век, господа! А для измерения эффективности рекламы в Интернете есть интересные функциональные инструменты, готовые работать через API со всеми сервисами.
AdHands – длинные руки онлайн-рекламы
AdHands — одно из таких решений.Это система, которая подключается к платформам интернет-рекламы (Яндекс.
Директ, Яндекс.
Маркет, Google Adwords, ВКонтакте, [email protected], DoubleClick Bid Manager, Яндекс.
Аукцион и др.
) через API. 
Мы долго думали о том, какой должна быть единая система управления рекламными кампаниями в Интернете.
В результате было решено разработать систему, способную решить сразу несколько проблем.
Первой и главной особенностью AdHands стал единый интерфейс доступа ко всей собранной статистике — это решение позволило исключить необходимость каждый раз авторизоваться и работать в разных графических интерфейсах.
В результате получается единая удобная панель, дашборд, на котором в доступной форме представлены все необходимые рекламные показатели.
Конечно, никакая статистика не имеет практической ценности, если она не агрегирована и не обработана должным образом.
В систему добавлена возможность автоматического расчета стоимости цели, заказа, звонка и расчета ROI. Введено медиапланирование – ценная функция для тех, кто управляет чужими бюджетами или имеет в компании строгую систему бизнес-планирования, в рамках которой необходимо заранее рассчитывать маркетинговый и рекламный бюджет. AdHands работает для конечного пользователя, делая его жизнь намного проще.
Однако при создании самой системы возникает ряд сложностей из-за того, что приходится взаимодействовать с различными внешними системами.
Работа с API – наведение мостов
Всем известно, насколько сложен мир программирования и разработки — несмотря на создание постоянных описаний стандартов и попытки достичь соглашения, каждый разработчик привносит в код что-то свое.В случае с API это иногда ставит в тупик разработчиков внешних систем, например AdHands. Расскажем подробнее о том, с чем мы столкнулись при использовании чужих API при создании нашей системы управления интернет-рекламой.
Работая со сторонними системами, мы разработали ряд критериев, по которым определяем, насколько удобна система, которую мы подключаем к AdHands. Грубо говоря, такая система должна быть в первую очередь удобной с точки зрения разработчика.
А если рассматривать конкретно, то важно, чтобы подключаемая система соответствовала нескольким параметрам.
- Стабильность системы – его доступность 99,9% времени года.
Наверное, нет необходимости объяснять, насколько это важно для системы, которая собирает и передает данные об онлайн-рекламных кампаниях, которые ежесекундно транслируются по всему Интернету.
- Наличие документации – абсолютно критическое требование.
Понять API без документации крайне сложно, особенно если приходится иметь дело с ошибками и нештатными ситуациями.
Нужно понимать, что API на самом деле представляет собой чужой код, и несмотря на стремление крупнейших онлайн-платформ к универсальности, счастливое будущее еще далеко и API должно сопровождаться подробной документацией разработки, как, например, как реализовано в Google AdWords и Яндекс.
Директ.
- Поддержка авторизации OAuth 2.0 – удобный и безопасный открытый протокол авторизации.
- Отзывчивая техническая поддержка система, конечно, не может быть требованием, но это желание – к сожалению, не всегда можно быстро получить квалифицированный ответ. А решение задач в таких системах, как AdHands, требует максимальной эффективности, чтобы не потерять лояльность клиентов.
- Понятность – Методы и функциональность API должны семантически соответствовать тому, что они делают. Например, метод «добавить пользователя» должен добавить пользователя без решения ряда других задач.
Определенные шаги в этом направлении уже сделаны, но до полного объединения пока так далеко, что оно кажется пока невозможным.
Работа с API – поговорим о проблемах
Разница в терминологии платформ API – разные системы могут не иметь объектов или иметь разные имена.Например, недавно в Яндекс.
Директе появилась сущность «группа объявлений», а долгое время до этого такая сущность была только в AdWords. Аналогичная ситуация возникает, например, с термином «креатив», который встречается в БайЯне и ДБМ, но на самом деле для разработчика творчество в этих двух системах — разные сущности.
Преодоление таких несоответствий требует времени и поэтому необходимо искать решение путем построения специальной архитектуры AdHands. Однако эта проблема не столь существенна, как другие.
Различия в структуре данных - проблема, возникающая из-за различий в структуре самих сайтов (опять же, например, может не быть групп объявлений).
Это важный вопрос для AdHands, потому что мы не копируем системные интерфейсы в одно приложение, а собираем данные, чтобы представить их пользователю.
Я не хочу каждый раз менять структуру страницы, подстраиваясь под системы.
Мы обходим проблему, сводя данные из разных источников в единую структуру.
Фактически мы создаем схожие по структуре иерархии и гибридные решения, когда сущность остается доступной при выборе одной системы и закрыта для других.
AdHands достигает единообразия и удобства интерфейса за счет абстрагирования сущностей.
Все разработчики по-разному подходят к документации: кто-то подробно документирует каждую переменную, кто-то описывает ее в общих чертах, а кто-то вообще отказывается от какой-либо документации.
При работе с API внешней системы наличие подробной документации — залог успеха.
Однако даже при наличии подробных мануалов и сообщества разработчиков возникают проблемы, среди которых главной является несоответствие документации реальному положению дел : Иногда случается, что документация, интерфейс программы и графический интерфейс пользователя расходятся.
Как правило, это связано с тем, что API меняется и дополняется довольно быстро, а документация обновляется медленнее, поэтому может найти устаревшие функции или не найти часть новых возможностей.
В идеале выпуск новой версии API происходит одновременно с выпуском документации.
По опыту Realweb можно сказать, что документации, не соответствующей действительности, практически нет. Однако здесь вступает в игру человеческий фактор, и иногда из-за отсутствия уведомлений и рассылок об изменениях становится известно не сразу.
Каждая система API периодически меняется и совершенствуется.
Постоянное изменение API само по себе является необходимым явлением — интерфейс ПО развивается вместе с системой.
Плохо, если внесены изменения, но, допустим, сигнатура методов не изменилась.
Было бы неплохо, если бы при обновлении API все библиотеки обновлялись по расписанию.
Несоответствие API и интерфейса – Проблема не очень распространенная.
Конечно, поставщик API понимает, что сущности как для интерфейса приложения, так и для пользовательского интерфейса должны быть одинаковыми.
Бывает, что API не предоставляет методов для некоторых элементов GUI. Если в интерфейсе программы отсутствуют какие-то сущности, приходится создавать псевдосущности — кучу, чтобы вписаться в универсальную структуру AdHands. Крайне редко, но все же случается, что API вообще нет .
Например, с такой ситуацией мы столкнулись при работе с системой размещения медийных баннеров Яндекса.
В таких случаях вам придется проанализировать интерфейс с помощью сканера и войти в систему как пользователь, используя комбинацию логина и пароля.
Здесь возникает главный камень преткновения, если меняется графический интерфейс пользователя — меняется макет, парсер возвращает ошибки.
Но, в основном, все современные системы предоставляют доступ через API. Но те, кто не готов предоставить адекватные библиотеки и документацию, рискуют остаться вне конкуренции.
Отсутствие удобной и универсальной авторизации OAuth 2.0. – проблема, которая продолжает возникать.
Как вы знаете, протокол авторизации OAuth 2.0 находится в стадии разработки.
Характеристики Впрочем, он уже вполне готов заменить OAuth. Это удобный протокол, который прост в использовании, лишен длинной цепочки запросов и сложных схем подписи.
Некоторые сайты и рекламные агрегаторы его пока не используют, видимо, ждут стабильной спецификации.
Это существенно усложняет процесс авторизации и аутентификации при запросе данных из внешних систем и передаче данных.
Например, БаЯн от Яндекса работает на токенизации по логину/паролю.
С точки зрения разработчика это не совсем безопасно, так как может нанести существенный ущерб, если база данных, в которой хранятся логины и пароли для доступа к BaYan, будет скомпрометирована.
Сегодня большинство крупных систем уже перешли на OAuth 2.0. Помимо того, что это безопасно, это еще и универсальный стандарт и гарантия быстрого подключения системы к AdHands. Отсутствие единого универсального протокола обмена данными - еще одна проблема.
Если бы он существовал, AdHands просто пересылал бы системные данные в единую панель управления.
Однако если такой протокол будет создан, на рынке появится множество компаний, готовых строить бизнес на инновациях, как это обычно бывает. А это может привести к непродуманным решениям, ставящим под угрозу серьезные системы в глазах конечного пользователя.
Кроме того, создание единого протокола не очень выгодно крупным сайтам, которые не готовы и не собираются отказываться от своих графических интерфейсов.
Другая проблема, на которую мы мало можем повлиять, — это Ограничения API — ограниченное количество запросов в день, которое задается рекламными системами.
Каждый метод API имеет свой лимит вызовов, который определяется ресурсоёмкостью и «тяжестью» метода.
В принципе, у Google AdWords и Яндекс.
Директ настолько большое количество запросов, что сложно почувствовать ограничение, но есть и проблемные сервисы, например Яндекс.
Маркет, использование методов которого иногда напоминает попытку получить талон к нужному врачу.
Платформы часто идут навстречу и расширяют границы, но при этом уделяется внимание и структуре самих систем-агрегаторов, которые могут не оптимально использовать запросы.
Конечно, это не полный список проблем и мелких препятствий, с которыми разработчикам AdHands приходится сталкиваться каждый день.
Мы всегда ищем компромиссы и не боимся использовать в своем коде решения, которые кому-то могут показаться не очень элегантными.
Это связано с большим количеством подключаемых систем и разнообразием их GUI и API. Пишем парсеры для систем без API, создаем ненужные сущности, вводим куски кода с проверками и реализуем новый функционал, не включенный в AdHands. Все эти решения могут повлиять на управляемость и простоту администрирования системы, а также на ее производительность.
Но при этом мы постоянно оптимизируем код, адаптируемся к системе лимитов и делаем все для удобства наших пользователей.
В последнее время наблюдается тенденция к унификации API крупных платформ.
Например, прототип API Яндекс.
Метрики в части отчетности Core копирует API Google Analytics. Надеемся, что другие API-провайдеры не будут жить своей жизнью, а присмотрятся к лучшим практикам и последуют не модному, но очень полезному тренду.
И совместными усилиями мы сделаем лучше для тех, ради кого все затевалось – для конечных пользователей, рекламных агентств и рекламодателей.
Большинство из них не знают об API и его проблемах; им нужно быстро, удобно и понятно.
Наша задача – обеспечить это.
Теги: #api #AdHands #api
-
Microsoft Запатентовала Интерфейс Iphone
19 Oct, 24 -
Nvidia Optimus Или Вторая Жизнь Hybrid Sli
19 Oct, 24 -
Что Не Так Со Светодиодными Лентами?
19 Oct, 24
