Strategy provider что это

поставщик услуги ( service provider)

3.3 поставщик услуги ( service provider): Хозяйствующая единица, предлагающая одну и более услуг.

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

Словарь-справочник терминов нормативно-технической документации . academic.ru . 2015 .

• Поставщик услуг звена данных
• поставщик электрической энергии

Смотреть что такое «поставщик услуги ( service provider)» в других словарях:

• поставщик услуги («сервис-провайдер») — Объект, который использует физические платформы оператора связи для обеспечения абоненту доступа к различным услугам, включая услуги передачи данных, вещательного ТВ, видео по запросу и голосовые услуги (МСЭ Т Н.610). [http://www.iks… … Справочник технического переводчика
• поставщик услуги — hidrometeorologinių paslaugų teikėjas statusas Aprobuotas sritis hidrometeorologija apibrėžtis Juridinis ar fizinis asmuo, Europos Sąjungos valstybės narės ar kitos Europos ekonominės erdvės valstybės subjektas, turintis teisę vykdyti… … Lithuanian dictionary (lietuvių žodynas)
• service provider — hidrometeorologinių paslaugų teikėjas statusas Aprobuotas sritis hidrometeorologija apibrėžtis Juridinis ar fizinis asmuo, Europos Sąjungos valstybės narės ar kitos Europos ekonominės erdvės valstybės subjektas, turintis teisę vykdyti… … Lithuanian dictionary (lietuvių žodynas)
• поставщик — 4.47 поставщик (supplier): Организация или лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги. Примечание 1 «Поставщиком» может быть подрядчик, производитель, торговец или продавец. Примечание 2 Иногда… … Словарь-справочник терминов нормативно-технической документации
• поставщик услуг — 3.1.6 поставщик услуг (service provider): Сторона (например, внутренняя или внешняя организация, изготовитель и т.п.), которая связана обязательствами в рамках соглашения и несет ответственность за предоставление определенного технического… … Словарь-справочник терминов нормативно-технической документации
• SERVICE PROVIDER — поставщик сети, услуги, провайдер — компания, предоставляющая доступ в Интернет. Для конечных пользователей это может быть предоставление адреса электронной почты, доступ к телеконференциям, WWW и другим информационным ресурсам … Словарь электронного бизнеса
• поставщик услуг — (ITIL Service Strategy) Организация, поставляющая услуги одному или нескольким внутренним заказчикам или внешним заказчикам. Поставщик услуг часто используется как сокращение термина «поставщик ИТ услуг». См. тж. поставщик услуг типа… … Справочник технического переводчика
• поставщик услуг прикладного программного обеспечения — (ITIL Service Design) Внешний поставщик услуг, который предоставляет ИТ услуги с использованием приложений, развернутых на мощностях поставщика услуг. Пользователи получают доступ к приложениям посредством сетевого подключения к поставщику услуг … Справочник технического переводчика
• ГОСТ Р 54930-2012: Разработка стандартов на услуги. Рекомендации по учету нужд потребителя — Терминология ГОСТ Р 54930 2012: Разработка стандартов на услуги. Рекомендации по учету нужд потребителя оригинал документа: 3.15 альтернативный формат ( alternative format): Иной способ представления, который может сделать услуги доступными путем … Словарь-справочник терминов нормативно-технической документации
• поставщик услуг типа II — (ITIL Service Strategy) Внутренний поставщик услуг, предоставляющий общие ИТ услуги более чем одной бизнес подразделению. Поставкщик услуг типа II также называется «объединённый центр обслуживания». [Словарь терминов ITIL версия 1.0,… … Справочник технического переводчика

Как работает Android, часть 3

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

• Как работает Android, часть 1
• Как работает Android, часть 2
• Как работает Android, часть 3
• Как работает Android, часть 4
• .

Web vs desktop

Если задуматься об отличиях современных веб-приложений от «обычных» десктопных приложений, можно — среди недостатков — выделить несколько преимуществ веба:

• Веб-приложения переносимы между архитектурами и платформами, как и Java.
• Веб-приложения не требуют установки и всегда обновлены, как и Android Instant Apps.

Кроме того, веб-приложения существуют в виде страниц, которые могут ссылаться друг на друга — как в рамках одного сайта, так и между сайтами. При этом страница на одном сайте не обязана ограничиваться ссылкой только на главную страницу другого, она может ссылаться на конкретную страницу внутри другого сайта (это называется deep linking). Ссылаясь друг на друга, отдельные сайты объединяются в общую сеть, веб.

Несколько копий одной страницы — например, несколько профилей в социальной сети — могут быть одновременно открыты в нескольких вкладках браузера. Интерфейс браузера рассчитан на переключение между одновременными сессиями (вкладками), а не между отдельными сайтами — в рамках одной вкладки вы можете перемещаться по ссылкам (и вперёд-назад по истории) между разными страницами разных сайтов.

Всё это противопоставляется «десктопу», где каждое приложение работает отдельно и часто независимо от других — и в этом плане то, как устроены приложения в Android, гораздо ближе к вебу, чем к «традиционным» приложениям.

Activities & intents

Основной вид компонентов приложений под Android — это activity. Activity — это один «экран» приложения. Activity можно сравнить со страницей в вебе и с окном приложения в традиционном оконном интерфейсе.

Про окна

Собственно окна в Android тоже есть на более низком уровне — уровне window manager. Каждой activity обычно соответствует своё окно. Чаще всего окна activity развёрнуты на весь доступный экран, но:

• Во-первых, Android поддерживает мультиоконный режим — split-screen, picture-in-picture и даже freeform.
• Во-вторых, Android поддерживает подключение нескольких дисплеев.
• В-третьих, activity может намеренно занимать небольшую часть экрана ( Theme_Dialog ).

Например, в приложении для электронной почты (email client) могут быть такие activity, как Inbox Activity (список входящих писем), Email Activity (чтение одного письма), Compose Activity (написание письма) и Settings Activity (настройки).

Как и страницы одного сайта, activity одного приложения могут запускаться как друг из друга, так и независимо друг от друга (другими приложениями). Если в вебе на другую страницу обращаются по URL (ссылке), то в Android activity запускаются через intent’ы.

Intent — это сообщение, которое указывает системе, что нужно «сделать» (например, открыть данный URL, написать письмо на данный адрес, позвонить на данный номер телефона или сделать фотографию).

Приложение может создать такой intent и передать его системе, а система решает, какая activity (или другой компонент) будет его выполнять (handle). Эта activity запускается системой (в существующем процессе приложения или в новом, если он ещё не запущен), ей передаётся этот intent, и она его выполняет.

Стандартный способ создавать intent’ы — через соответствующий класс в Android Framework. Для работы с activity и intent’ами из командной строки в Android есть команда am — обёртка над стандартным классом Activity Manager:

# передаём -a ACTION -d DATA # открыть сайт $ am start -a android.intent.action.VIEW -d http://example.com # позвонить по телефону $ am start -a android.intent.action.CALL -d tel:+7-916-271-05-83

Intent’ы могут быть явными (explicit) и неявными (implicit). Явный intent указывает идентификатор конкретного компонента, который нужно запустить — чаще всего это используется, чтобы запустить из одной activity другую внутри одного приложения (при этом intent может даже не содержать другой полезной информации).

Неявный intent обязательно должен указывать действие, которое нужно сделать. Каждая activity (и другие компоненты) указывают в манифесте приложения, какие intent’ы они готовы обрабатывать (например, ACTION_VIEW для ссылок с доменом https://example.com ). Система выбирает подходящий компонент среди установленных и запускает его.

Если в системе есть несколько activity, которые готовы обработать intent, пользователю будет предоставлен выбор. Обычно это случается, когда установлено несколько аналогичных приложений, например несколько браузеров или фоторедакторов. Кроме того, приложение может явно попросить систему показать диалог выбора (на самом деле при этом переданный intent оборачивается в новый intent с ACTION_CHOOSER ) — это обычно используется для создания красивого диалога Share:

Кроме того, activity может вернуть результат в вызвавшую её activity. Например, activity в приложении-камере, которая умеет обрабатывать intent «сделать фотографию» ( ACTION_IMAGE_CAPTURE ) возвращает сделанную фотографию в ту activity, которая создала этот intent.

При этом приложению, содержащему исходную activity, не нужно разрешение на доступ к камере.

Таким образом, правильный способ приложению под Android сделать фотографию — это не потребовать разрешения на доступ к камере и использовать Camera API, а создать нужный intent и позволить системному приложению-камере сделать фото. Аналогично, вместо использования разрешения READ_EXTERNAL_STORAGE и прямого доступа к файлам пользователя стоит дать пользователю возможность выбрать файл в системном файловом менеджере (тогда исходному приложению будет разрешён доступ именно к этому файлу).

A unique aspect of the Android system design is that any app can start another app’s component. For example, if you want the user to capture a photo with the device camera, there’s probably another app that does that and your app can use it instead of developing an activity to capture a photo yourself. You don’t need to incorporate or even link to the code from the camera app. Instead, you can simply start the activity in the camera app that captures a photo. When complete, the photo is even returned to your app so you can use it. To the user, it seems as if the camera is actually a part of your app.

При этом «системное» приложение — не обязательно то, которое было предустановлено производителем (или автором сборки Android). Все установленные приложения, которые умеют обрабатывать данный intent, в этом смысле равны между собой. Пользователь может выбрать любое из них в качестве приложения по умолчанию для таких intent’ов, а может выбирать нужное каждый раз. Выбранное приложение становится «системным» в том смысле, что пользователь выбрал, чтобы именно оно выполняло все задачи (то есть intent’ы) такого типа, возникающие в системе.

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

Про лончер

Этой логике подчиняются даже такие «части системы», как, например, домашний экран (лончер, launcher). Лончер — это специальное приложение со своими activity (которые используют специальные флаги вроде excludeFromRecents и launchMode=»singleTask» ).

Нажатие кнопки «домой» создаёт intent категории HOME , который дальше проходит через обычный механизм обработки intent’ов — в том числе, если в системе установлено несколько лончеров и ни один не выбран в качестве лончера по умолчанию, система отобразит диалог выбора.

«Запуск» приложения из лончера тоже происходит через intent. Лончер создаёт явный intent категории LAUNCHER , который «обрабатывается» запуском основной activity приложения.

Приложение может иметь несколько activity, которые поддерживают такой intent, и отображаться в лончере несколько раз (при этом может понадобиться указать им разную taskAffinity ). Или не иметь ни одной и не отображаться в лончере вообще (но по-прежнему отображаться в полном списке установленных приложений в настройках). «Обычные» приложения так делают довольно редко; самый известный пример такого поведения — Google Play Services.

Многие операционные системы делятся на собственно операционную систему и приложения, установленные поверх, ничего друг о друге не знающие и не умеющие взаимодействовать. Система компонентов и intent’ов Android позволяет приложениям, по-прежнему абсолютно ничего друг о друге не зная, составлять для пользователя один интегрированный системный user experience — установленные приложения реализуют части одной большой системы, они составляют из себя систему. И это, с одной стороны, происходит прозрачно для пользователя, с другой — представляет неограниченные возможности для кастомизации.

По-моему, это очень красиво.

Tasks & back stack

Как я уже говорил, в браузере пользователь может переключаться не между сайтами, а между вкладками, история каждой из которых может содержать много страниц разных сайтов. Аналогично, в Android пользователь может переключаться между задачами (tasks), которые отображаются в виде карточек на recents screen. Каждая задача представляет собой back stack — несколько activity, «наложенных» друг на друга.

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

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

При запуске новой activity могут быть указаны специальные флаги, такие как singleTop , singleTask , singleInstance и CLEAR_TOP , которые модифицируют этот механизм. Например, приложения-браузеры обычно разрешают запуск только одной копии своей основной activity, и для переключения между открытыми страницами реализуют собственную систему вкладок. С другой стороны, Custom Tabs — пример activity в браузере (чаще всего Chrome), которая ведёт себя почти «как обычно», то есть показывает только одну страницу, но позволяет одновременно открывать несколько своих копий.

App lifecycle

Одно из основных ограничений встраиваемых и мобильных устройств — небольшое количество оперативной памяти (RAM). Если современные флагманские устройства уже оснащаются несколькими гигабайтами оперативной памяти, то в первом смартфоне на Android, HTC Dream (он же T-Mobile G1), вышедшем в сентябре 2008 года, её было всего 192 мегабайта.

Проблема ограниченной памяти дополнительно осложняется тем, что в мобильных устройствах, в отличие от «обычных» компьютеров, не используются swap-разделы (и swap-файлы) — в том числе и из-за низкой (по сравнению с SSD и HDD) скорости доступа к SD-картам и встроенной флеш-памяти, где они могли бы размещаться. Начиная с версии 4.4 KitKat, Android использует zRAM swap, то есть эффективно сжимает малоиспользуемые участки памяти. Тем не менее, проблема ограниченной памяти остаётся.

Если все процессы представляют собой для системы чёрный ящик, лучшая из возможных стратегия поведения в случае нехватки свободной памяти — принудительно завершать («убивать») какие-то процессы, что и делает Linux Out Of Memory (OOM) Killer. Но Android знает, что происходит в системе, ему известно, какие приложения и какие их компоненты запущены, что позволяет реализовать гораздо более «умную» схему освобождения памяти.

Во-первых, когда свободная память заканчивается, Android явно просит приложения освободить ненужную память (например, сбросить кэш), вызывая методы onTrimMemory / onLowMemory . Во-вторых, Android может эффективно проводить сборку мусора в фоновых приложениях, освобождая память, которую они больше не используют (на уровне Java), при этом не замедляя работу текущего приложения.

Но основной механизм освобождения памяти в Android — это завершение наименее используемых приложений. Система автоматически выбирает приложения, наименее важные для пользователя (например, те, из которых пользователь давно ушёл), даёт их компонентам шанс дополнительно освободить ресурсы, вызывая такие методы, как onDestroy , и завершает их, полностью освобождая используемую ими память и ресурсы.

Если пользователь возвращается в activity приложения, завершённого системой из-за нехватки памяти, эта activity запускается снова. При этом перезапуск происходит прозрачно для пользователя, поскольку activity сохраняет своё состояние при завершении ( onSaveInstanceState ) и восстанавливает его при последующем запуске. Реализованные в Android Framework виджеты используют этот механизм, чтобы автоматически сохранить состояние интерфейса (UI) при перезапуске — с точностью до введённого в EditText текста, положения курсора, позиции прокрутки (scroll) и т.д. Разработчик приложения может дополнительно реализовать сохранение и восстановление каких-то ещё данных, специфичных для этого приложения.

Подчеркну, что Android может перезапускать приложения не полностью, а покомпонентно, оставляя неиспользуемые части завершёнными — например, из двух копий одной activity одна может быть перезапущена, а другая остаться завершённой.

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

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

Services

Приложениям может потребоваться выполнять действия, не связанные напрямую ни с какой activity, в том числе, продолжать делать их в фоне, когда все activity этого приложения завершены. Например, приложение может скачивать из сети большой файл, обрабатывать фотографии, воспроизводить музыку, синхронизировать данные или просто поддерживать TCP-соединение с сервером для получения уведомлений.

Такую функциональность нельзя реализовывать, просто запуская отдельный поток — это было бы для системы чёрным ящиком; в том числе, процесс был бы завершён при завершении всех activity, независимо от состояния таких фоновых операций. Вместо этого Android предлагает использовать ещё один вид компонентов — сервис.

Сервис нужен, чтобы сообщить системе, что в процессе приложения выполняются действия, которые не являются частью activity этого приложения. Сам по себе сервис не означает создание отдельного потока или процесса — его точки входа (entry points) запускаются в основном потоке приложения. Обычно реализация сервиса запускает дополнительные потоки и управляет ими самостоятельно.

Сервисы во многом похожи на activity: они тоже запускаются с помощью intent’ов и могут быть завершены системой при нехватке памяти.

Запущенные сервисы могут быть в трёх состояниях:

• Foreground service — сервис, выполняющий действие, состояние которого важно для пользователя, например, загрузка файла или воспроизведение музыки. Такой сервис обязан отображать уведомление в системной шторке уведомлений (примеры: состояние загрузки, название текущей песни и управление воспроизведением). Система считает такой сервис примерно настолько же важным для пользователя, как и текущая activity, и завершит его только в крайнем случае.

• Background service — сервис, выполняющий фоновое действие, состояние которого не интересует пользователя (чаще всего, синхронизацию). Такие сервисы могут быть завершены при нехватке памяти с гораздо большей вероятностью. В старых версиях Android большое количество одновременно запущенных фоновых сервисов часто становилось причиной «тормозов»; начиная с версии 8.0 Oreo, Android серьёзно ограничивает использование фоновых сервисов, принудительно завершая их через несколько минут после того, как пользователь выходит из приложения.
• Bound service — сервис, обрабатывающий входящее Binder-подключение. Такие сервисы предоставляют какую-то функциональность для других приложений или системы (например, WallpaperService и Google Play Services). В этом случае система может автоматически запускать сервис при подключении к нему клиентов и останавливать его при их отключении.

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

• Доступность сети. Здесь приложение может указать, требуется ли этому сервису наличие сетевого подключения, и если да, то возможна ли работа в роуминге или при использовании лимитного (metered) подключения.
• Подключение к источнику питания, что позволяет сервисам выполняться, не «сажая батарею».
• Бездействие (idle), что позволяет сервисам выполняться, пока устройство не используется, не замедляя работу во время активного использования.
• Обновления контента — например, появление новой фотографии.
• Период и крайний срок запуска — например, очистка кэша может производиться ежедневно, а синхронизация событий в календаре — каждый час.

JobScheduler планирует выполнение (реализованное как вызов через Binder) зарегистрированных в нём сервисов в соответствии с указанными критериями. Поскольку JobScheduler — общесистемный механизм, он учитывает при планировке критерии зарегистрированных сервисов всех установленных приложений. Например, он может запускать сервисы по очереди, а не одновременно, чтобы предотвратить резкую нагрузку на устройство во время использования, и планировать периодическое выполнение нескольких сервисов небольшими группами (batch), чтобы предотвратить постоянное энергозатратное включение-выключение радиооборудования.

Про TCP-соединение

Как можно заметить, использование JobScheduler не может заменить собой одного из вариантов использования фоновых сервисов — поддержания TCP-соединения с сервером для получения push-уведомлений. Если бы Android предоставлял приложениям такую возможность, устройству пришлось бы держать все приложения, соединяющиеся со своими серверами, запущенными всё время, а это, конечно, невозможно.

Решение этой проблемы — специальные push-сервисы, самый известный из которых — Firebase Cloud Messaging от Google (бывший Google Cloud Messaging).

Клиентская часть FCM реализована в приложении Google Play Services. Это приложение, которое специальным образом исключается из обычных ограничений на фоновые сервисы, поддерживает одно соединение с серверами Google. Разработчик, желающий отправить своему приложению push-уведомление, пересылает его через серверную часть FCM, после чего приложение Play Services, получив сообщение, передаёт его приложению, которому оно предназначено.

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

Broadcast receivers & content providers

Кроме activity и сервисов, у приложений под Android есть два других вида компонентов, менее интересных для обсуждения — это broadcast receiver’ы и content provider’ы.

Broadcast receiver — компонент, позволяющий приложению принимать broadcast’ы, специальный вид сообщений от системы или других приложений. Исходно broadcast’ы, как следует из названия, в основном использовались для рассылки широковещательных сообщений всем подписавшимся приложениям — например, система посылает сообщение AIRPLANE_MODE_CHANGED при включении или отключении самолётного режима.

Сейчас вместо подписки на такие broadcast’ы, как NEW_PICTURE и NEW_VIDEO , приложения должны использовать JobScheduler. Broadcast’ы используются либо для более редких событий (таких как BOOT_COMPLETED ), либо с явными intent’ами, то есть именно в качестве сообщения от одного приложения к другому.

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

При этом приложение может хранить сами данные каким угодно образом, в том числе на устройстве в виде файлов, в настоящей базе данных (SQLite) или запрашивать их с сервера по сети. В этом смысле content provider — это унифицированный интерфейс для доступа к данным, независимо от формы их хранения.

Взаимодействие с content provider’ом во многом похоже на доступ к удалённой базе данных через REST API. Приложение-клиент запрашивает данные по URI (например, content://com.example.Dictionary.provider/words/42 ) через ContentResolver. Приложение-сервер определяет, к какому именно набору данных был сделан запрос, используя UriMatcher , и выполняет запрошенное действие (query, insert, update, delete).

Именно поверх content provider’ов реализован Storage Access Framework, позволяющий приложениям, хранящим файлы в облаке (например, Dropbox и Google Photos) предоставлять доступ к ним остальным приложениям, не занимая место на устройстве полной копией всех хранящихся в облаке файлов.

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

Strategy provider что это

Easy access to active management of crypto assets has been Sommelier’s mission from day one, and the recent launch of the first strategy is a major milestone in this journey. Now, the Sommelier team is extremely excited to announce the launch of Strategy Tokens with two new strategies coming to the platform.

Strategy Tokens enable anyone to get exposure to actively managed crypto asset portfolios just by holding a token. These tokens can be obtained on the most popular decentralized exchanges, making the onboarding process that much easier for those unfamiliar with the process of interacting with a smart contract to provide liquidity. While you hold these tokens, the smart contract algorithms for the associated strategies will do all the portfolio management. And when you’re ready to exit, all you have to do is sell the tokens.

Never before has it been this simple to access transparent, non-custodial, active crypto portfolio management. The simple act of holding a token gives users access to the most revolutionary development in DeFi to date. Retail investors can now put capital into sophisticated strategies that use custom machine learning algorithms to track many market signals to dynamically adjust strategy portfolios. These strategies are designed by world-class quantitative finance professionals and are back-tested and vetted, giving users peace of mind while their funds go to work.

ClearGate Capital’s forthcoming Trend Following Portfolio in BTC and ETH plus its Momentum Portfolio in BTC and ETH will be the first strategies to have tokens representing them. The ticker for the former will be ETHBTCTrend and the latter will be ETHBTCMom, and both will be available on Uniswap V3 in trading pairs with USDC. Each token represents a share in one of these actively managed strategies, and they’re fully liquid, so you can sell your share when it best suits you.

These ETH and BTC strategies are perfect for the launch of this new asset class because the tokens give users the ability to hodl strategies that are specifically designed to outperform static portfolios of those assets. The average hands-off crypto investor will now be able to sit back while ClearGate’s machine learning-powered strategies work to deliver better performance and lower risk through active, data-driven trading.

As more and more strategy providers bring strategies to Sommelier, users will be able to invest in the Strategy Tokens most suited to their investment objectives. Down the line, Strategy Tokens may even launch that aggregate Cellars into portfolios with different time horizons or risk tolerances, for instance. The possibilities are truly endless, and Sommelier’s natively multi-chain architecture makes it the ideal platform for launching the most sophisticated investment strategies in DeFi, for the benefit of all.

More articles

Sommelier January Update

Sommelier Upgrades Cellar Architecture to Enable the Most Powerful DeFi Strategies in the Market

Real Yield USD is Coming to Maximize Stablecoin Yield

Retrospective on 2022 and the Journey Ahead

FAQ — Patache Digital’s Steady Strategies

FAQ — Patache Digital’s Steady Strategies

Patache Digital: Risk Management Discussion

Strategy Deep Dive: Patache Digital

Strategy Provider Spotlight: Patache Digital

Strategy Provider Spotlight: Patache Digital

User Guide: How to Participate in Strategies on Sommelier

User Guide: How to Participate in Strategies on Sommelier

Sommelier Ambassador Program

Strategy Tokens: What Are They and How Do They Work?

6 Core Principles of Sommelier

10/10/22 — Deep Dive on Cleargate Backtesting

Strategy Provider Spotlight: Seven Seas

Deep Dive on Trend and Momentum Strategies

Deep Dive on Trend and Momentum Strategies

Strategy Provider Spotlight: ClearGate

Supporting Strategy Providers on Sommelier

Sommelier Protocol Team Weekly Update #11

ELI-5 Explanation of the Data Science behind Sommelier’s First Aave Cellar

Sommelier Protocol Team Weekly Update #10

The Data Science Behind Sommelier’s First Aave Cellar

Sommelier Protocol Design Documents

Sommelier Protocol Team Weekly Update #9

Sommelier Protocol Team Weekly Update #8

Sommelier Protocol Team Weekly Update #7

Twitter Spaces With Sommelier: How to Launch a Cellar on Sommelier

Twitter Spaces With Sommelier: How to Launch a Cellar on Sommelier

Twitter Spaces With Sommelier: Protocol Upgrade and Community Update

Sommelier Protocol Team Weekly Update #4

Sommelier Protocol Team Weekly Update #6

Twitter Spaces With Sommelier: SOMM Airdrop Proposal Data Analysis

Twitter Spaces With Sommelier: Community Update on the First Cellars to Launch

Twitter Spaces With Sommelier: Exploring NFT Cellars

Sommelier Protocol Team Weekly Update #1

Sommelier Protocol Team Weekly Update #2

Sommelier Protocol Team Weekly Update #3

Three Things You Need to Know About Sommelier Governance This Week

Sommelier On the Road: PROOF OF…REPUTATION

Introducing Ukpai Ugochi — Working on The Sommelier Cellars Rebalancer

Sommelier Announces 23MM Series A Mainnet Round to launch Automated DeFi via the Cosmos

Twitter Spaces With Sommelier: Mainnet Launch & Gravity Bridge

Twitter Spaces With Sommelier: Introducing SOMM Tokenomics

Twitter Spaces With Sommelier: Mysten Labs AMA With Evan Cheng

Introducing SIPS and Sommelier’s Governance Structure

Twitter Spaces With Sommelier: End of Year AMA 2021

Twitter Spaces With Sommelier: Intro to SIPS & Lisbon Blockchain Week

Twitter Spaces With the Sommeliers: Mainnet Update and Governance Launch

Sommelier Partners With Mysten Labs to Make Sommelier and All Cosmos Blockchains the Fastest Protocols on the Planet

Twitter Spaces With the Sommeliers: Sushi AMA With Joseph Delong

Introducing the Sommelier Network Mainnet and Ethereum Gravity Bridge

The Top Five Features of the Sommelier Protocol

Call for Validators: The Two Step Process for 2021

Two New Features Launched to Test Liquidity Management on Uniswap v3

Uniswap v3 Remove Smart Contract Incident Post Mortem for Sommelier

Call for Validators: Road to Sommelier Mainnet

Sommelier Liquidity AMA With Yenwen and Nick From Perpetual Protocol

Sommelier Liquidity AMA With Tascha Pan From Alpha Finance

Sommelier Liquidity AMA With Loi Luu From Kyber Network

Sommelier Liquidity AMA With Alex From Peanut

Sommelier Liquidity AMA With JP From THORChain

Sommelier Liquidity AMA With Alan Chiu From OMGX Network

Sommelier Liquidity AMA With Ari From Gelato Network

Sommelier Liquidity AMA With Sunny Aggarwal From Osmosis

A Fine Sommelier Explanation of Bollinger Bands With Kevin Kennis

Sommelier Liquidity AMA With Mona El Isa From Enzyme

Sommelier Liquidity AMA With Haxor From Method Finance

Sommelier Liquidity AMA With Tor From Secret Network

Liquidity Provider Insights With Zaki Manian — Ep. 7 — DeFi Automation Space on Uniswap v3 and Where Sommelier’s Heading

Sommelier Liquidity AMA With Geralt From CyberFi

A Pairings Tutorial of Two Sided Liquidity Addition with Sommelier

Liquidity Provider Insights with Zaki Manian — Ep. 6 — Liquidity Providers Need to Gear Up for a Multi-Chain World

Three New Summer Features for Liquidity Providers

Sommelier Liquidity AMA with Tom C and Max W from Charm

Sommelier Liquidity AMA with Dereek69 & Shalaquiana from BIOPset

Sommelier This Week — June 3rd 2021: The Road to Mainnet

Sommelier Liquidity AMA with Federico Landini from DefiLab

Sommelier Liquidity AMA with Michael Egorov from Curve

Liquidity Provider Insights with Zaki Manian — Ep. 5 — A Bright Light at the End of a Long, Tough Weekend for Bitcoin

Sommelier This Week — May 27th 2021: What Aspiring Sommelier Validators Need to Know on Last Week’s Protocol and App Progress

Liquidity Provider Insights with Zaki Manian (Special Edition) — Ep. 4 — New Pairings Release

Sommelier R&D AMA With Yaniv Tal From the Graph

Sommelier Liquidity AMA with MacLane Wilkison from NuCypher

The Eight Steps to Become a Liquidity Provider with Pairings

Sommelier NFT Awards — May 18th, 2021

Three Ways That Pairings by Sommelier Makes Uniswap v3 Easier for Liquidity Providers

Pairings By Sommelier: The FAQ

Zaki Manian Breaks Down What Liquidity Providers Need to Know Under Uniswap v3

Sommelier This Week — May 6th 2021: How This Week’s Protocol and App Progress Weaves Together to Make a Product

Sommelier Liquidity AMA with Dan Thomson from InsurAce

Sommelier Liquidity AMA with Dan Thomson from InsurAce

Sommelier This Week — April 29th 2021: Weeks Away From a Taste of the Sommelier App Experience and How the Dev Team Stays on Track

Zaki Manian Breaks Down a Phase Change Liquidity Providers Need to Know About Automated Market Makers

Introducing Jehan Tremback: Sommelier Core Developer and Althea Co-Founder that pushes the Limits of the Blockchain Bridge with Gravity

Sommelier This Week — April 22nd 2021: An Inside Look at Progress on Coordinating Sommelier Components That Contribute to the Chain

Sommelier This Week — April 15th 2021: Providing a Best-in-Class Experience for Uniswap Liquidity Providers

Sommelier Announces $1M R&D Grant from The Graph Foundation

Introducing LP Rewards: This Week With Cellframe

Introducing Deborah Simpier: Althea CEO and Sommelier Co-Founder Who Brought the Gravity Bridge to Life in The Cosmos

Sommelier This Week — April 8th 2021: What Uniswap v3 Means For Sommelier Architecture and Validators

Introducing Sommelier LP Rewards Program

Sommelier This Week — April 1st 2021: Gravity Bridge and Private Testnets

Blockchain startup decides to acquire a California winery and host NFT wine parties

Introducing Justin Kilpatrick: The Blockchain Bridge Wizard Who Maintains Gravity

Five Ways UniswapV3 changes the world for Liquidity Providers on the AMM

Introducing Jack Zampolin: On Becoming A Sommelier in The Cosmos

Sommelier: Welcome To The New CoProcessor For Ethereum

© 2023 Sommelier by Bajanss OÜ –Maakri 36-50, Tallinn, Estonia 10145

Mobile measurement partner (MMP)

A mobile measurement partner, or MMP, is a company that helps apps measure campaign performance across advertising marketing channels, media sources, and ad networks.

What is an MMP?

A mobile measurement partner is a platform provider that attributes, collects, and organizes app data to deliver a uniform assessment of campaign performance metrics.

Drawing an analogy from sports, an MMP acts as a trusted and impartial referee to rule on attribution.

It’s a mission-critical component in a mobile marketer’s tech stack. Being the only party with an unbiased view of the entire consumer journey, an MMP enables marketers to understand which media source deserves credit for driving a conversion. This empowers marketers to make informed decisions regarding budget allocation.

In other words, an MMP is a marketers’ best friend.

How does it work?

In basic terms, an MMP matches campaign engagements with installs and post-intall in-app actions.

This is done using a combination of device IDs for user level attribution, probabilistic modeling, or SKAdNetwork in iOS 14 for deterministic aggregated level attribution.

By implementing a software development kit (SDK), which is a piece of code that collects measurement and attribution data, the app enables the MMP to associate ad engagements with app installs and in-app events (such as game levels, registrations completed in a FinTech app, placed purchases etc).

What are the benefits of working with an MMP?

1. Improve app performance, ROAS and LTV – An MMP equips you with accurate and granular data, enables you to allocate your budgets, and optimize your app’s performance, ROAS, and LTV.
2. Scale marketing efforts – As you scale campaigns across several ad networks, all the tools you need to try out new networks are already set up.
3. Use budget more effectively – An impartial MMP can connect all the dots in your campaigns and pinpoint exactly where credit is due. This means you can allocate your budget into the campaigns that bring the most value.
4. Save time and resources – Let a universal SDK do the grind work, measure, and attribute all of your ad networks through a single SDK. Plus, you can save heaps of time analyzing countless dashboards and spreadsheets.
5. Single dashboard – See one view consolidating all your raw and aggregated data for both paid media sources and organic activities.

Who needs an MMP?

The short answer: Any marketer with an app.

The most essential growth hack in your marketing stack.

Mobile is the most data-rich marketing channel in existence. However, when it comes to assessing campaign performance, the sheer amount of media data that needs to be analyzed can be overwhelming and hard to gauge.

If you’re not working with an MMP, you’re probably spending countless resources and man hours trying to make sense of way too many dashboards and spreadsheets. And unless you’re a computer, this manual analysis is a recipe for errors and plenty of missed opportunities for optimizing lifetime value (LTV) and return on ad spend (ROAS).

But when managed by a reliable, unbiased provider, mobile attribution can pinpoint the value of specific channels, media sources, publishers, campaigns, and even creatives, while allowing you to constantly optimize your app’s performance and ensure strategic growth.

A mobile campaign can deliver great ROAS, but to achieve this, every consumer interaction must be analyzed and attributed properly.

As a result, the vast majority of marketers turn to MMPs to enhance their offering to advertisers, maximize LTV and understand exactly where they should, and shouldn’t, spend their budget.

SDK – the good, the bad and the ultimate solution

Mobile attribution begins and ends with SDKs. However, SDKs can also pose a few daunting challenges for mobile marketers, especially when partnering with multiple ad networks. As marketers scale their efforts, the delay, cost and manual labor associated with adding a new SDK for each new ad network, drains technical resources and negatively impacts app’s performance.

That is why MMPs offer a universal SDK. A more economical solution, a universal SDK connects advertisers to the entire mobile ecosystem of 1000s of ad networks, without having to rely on costly, time-intensive development resources.

How to choose an MMP?

There are four key factors to keep in mind when selecting a mission-critical solution such as your MMP:

1. Security and privacy

These three are nothing short of critical, and should be treated with extreme care in the form of comprehensive and ongoing due diligence processes, with any vendor that has access to your most valued asset – your customers’ data. Specifically, you have to make sure that your attribution partner is truly independent and unbiased, and isn’t trading your data as part of their business model.

2. Fraud prevention

Working with an established, mature platform that holds a significant market share, enables you to leverage exhaustive market intelligence when it comes to preventing fraud. Choose an MMP that is committed to maintaining a fraud-free ecosystem, that removes bad players from the platform to ensure its integrity, and that partners only with ad networks who take fraud prevention just as seriously.

3. Data accuracy and a comprehensive set of features

According to an internal study, 20%-50% of the marketing budgets of some MMPs’ clients are wasted because they lack deep granularity and multi-touch attribution (MTA).

Lack of granular data and MTA means you don’t really understand your customer journey, which will eventually lead to wrong decisions. Advanced capabilities such as deep-linking, real-time data, omni-channel LTV and cross-channel attribution, all deliver a wealth of invaluable, razor-sharp insights, that remain inaccessible or extremely difficult to maintain without the right MMP by your side.

4. Experience

Experience isn’t just nice to have. As with any integral component, partnering with a seasoned, trustworthy MMP is key. Mobile attribution technology is highly complex to set up and maintain, and requires major heavy lifting to build a robust, scalable, stable, and accurate platform.

To make things even more complex, attribution platforms are a sticky product by nature.

Any decision you make today will impact your business for many years to come, for better or worse. That’s why it’s imperative to always choose an MMP with outstanding reputation, a solid platform, a happy & loyal customer base, and the resources to fully support your growing business needs.

Looking for an MMP? Get your free assessment template today
Thanks for your download!

Recent privacy-driven developments that affect MMPs

Privacy has taken center stage in mobile app marketing and iOS in particular, impacting attribution models, campaign optimization, monetization methods, remarketing, fraud, and more.

On the one hand, measurement and attribution on iOS will fundamentally change, as the new AppTrackingTransparency (ATT) framework requires users to opt-in to allow third party advertisers to collect their user-level data. On the other hand, existing capabilities still apply to the much larger Android platform and the segment of opted-in iOS users.

What we do know for sure, is that the industry is clearly embracing innovative ways to adapt to the age of privacy (e.g. incrementality measurement solutions, predictive modeling, and web-to-app flows), and ensure that accurate measurability is not going anywhere.

Key takeaways

If you’re still not entirely convinced, here are the top 5 reasons for incorporating an MMP into your marketing arsenal:

1. Empowering you to make smarter, data-driven decisions. A mobile attribution equips you with authoritative, indisputable data, enables you to allocate your budgets, and optimize your app’s performance, ROAS, and LTV.

1. Universal SDK – One ring to rule them all. Don’t waste your precious time and resources. Let a universal SDK do the grind work, measure, and attribute all of your ad networks through a single SDK.

1. Stop paying double or triple for attribution. As you scale campaigns across several ad networks, instead of paying double or triple the cost, let an impartial MMP connect all the dots and pinpoint exactly where credit is due.

1. Single dashboard – One go-to performance overview. One dashboard, consolidating all your raw and aggregated data for both paid media sources and organic activities, will save you heaps of time while allowing you to get a holistic picture of your complete user funnel.

1. Leave mobile attribution to the experts. The mobile landscape is a fragmented jungle, and MMPs are best equipped to have the resources, expertise, and cross-network scale to meet your demand for marketing insights.

The bottom line: Partner with a reliable, unbiased MMP with a solid, secured and scalable attribution platform that will do the heavy lifting for you, so you can focus on pure marketing strategy and building a stronger, higher LTV user base.