Как мы строим UI для рекламных систем
8 мин
Вместо вступления
Ранее в нашем блоге мы писали, чем занимается компания IPONWEB — мы автоматизируем показ рекламы в интернете. Наши системы принимают решения не только на основе исторических данных, но и активно используют информацию, полученную в реальном времени. В случае DSP (Demand Side Platform — рекламная платформа для рекламодателей), рекламодатель (или его представитель) должен создать и загрузить рекламный баннер (креатив) в одном из форматов (картинка, видео, интерактивный баннер, картинка+текст и т.д.), выбрать аудиторию пользователей, которым этот баннер будет показан, определить сколько раз можно показать рекламу одному пользователю, в каких странах, на каких сайтах, на каких устройствах, и отразить это (и многое другое) в настройках таргетинга рекламной кампании, а также распределить рекламные бюджеты. Для SSP (Supply Side Platform — рекламная платформа для владельцев рекламных площадок) владелец сайта (мобильного приложения, билборда, телевизионного канала) должен определить рекламные места на своем ресурсе и указать, например, какие категории рекламы он готов на них показывать. Все эти настройки делаются вручную заблаговременно (не в момент показа рекламы) с помощью пользовательского интерфейса. В этой статье я расскажу про наш подход к построению таких интерфейсов при условии, что их много, они похожи друг на друга и при этом обладают индивидуальными особенностями.
Работал я как-то на одном заводе, где лепили всякую электронику, не шибко сложную, и иногда подпадавшую под определение «Интернет вещей». По большей части, всякие датчики для охранных систем: датчики дыма, шума, проникновения, огня и всякое другое. Ассортимент изделий был широчайший, партии иногда были меньше 500 штук, и едва ли не под каждое изделие приходилось делать отдельный Test Fixture — по сути, просто жестяная коробка, в которую изделие на тестах ставилось, прижималось крышкой, и снизу контактные иглы прижимались к контактным точкам на печатной плате, как-то так:
