что такое proxy метрики
Как создать конкурентное преимущество для стартапа с помощью прокси-метрик?
Представьте, что вас только что назначали на пост директора популярного ресторана в Нью-Йорке, столкнувшегося с весьма значительной проблемой — клиенты всегда жалуются на уровень качества обслуживания. Сейчас вы ищете метрики, каковые бы отражали текущий уровень сервиса и каковые возможно было бы отслеживать на протяжении опытов с ресторанными операциями.
Какие конкретно показатели вы бы применяли?
Возможно опрашивать клиентов на выходе из заведения. Связываться с ними по телефону через день после визита. Либо кроме того попросить бухгалтера свести в таблицу сумму чаевых, выраженную в процентах от общего счета, и связать ее с каждым официантом.
Эти приемы трудятся, но неприятность содержится в том, что они предоставляют вам запоздалую данные о качестве обслуживания. К тому моменту, как вы соберете все нужные эти, улучшать клиентский опыт будет через чур поздно.
разливочный цехпоставщикпродавец src=https://media.lpgenerator.ru/uploads/2017/01/18/4_thumb600x312.jpg style=border: none; transform: rotate(0rad); width: 600px; height: 312px; /
Влияние задержки: пивоварняразливочный цехпоставщикпродавец
Просматривайте кроме этого: Как выяснить главную метрику роста вашего стартапа?
Из-за чего это неприемлемо?
Дабы растолковать вам значение задержки в контексте принятия своевременных ответов, мы разглядим случай, что случился в одной из бизнес-школ. Доктор наук маркетинга внес предложение студентам сыграть в популярную логистическую игру называющиеся «Beer game». Он поделил класс на 4 группы — по одной на любой главный этап цепочки пивного производства: пивоварня, разливочный цех, продавец и поставщик.
Это пошаговая игра, и любой движение 4 группы выбирали, сколько конкретно пива необходимо варить, разливать, поставлять и закупать. Доктор наук играл роль клиента и сказал продавцу, сколько бутылок он планирует купить.
В задержке кроется основная изюминка игры. Игроки принимают запрос от клиента, но для отправки заказов вниз по цепи поставок им нужно 2 семь дней. Сначала внешний спрос остается устойчивым, но после этого он неожиданно возрастает и опять стабилизируется на новом уровне. Продавец через чур продолжительно обдумывает запоздалую данные. После этого то же самое происходит с разливочным цехом и поставщиками.
И в конечном итоге, пивоварня приобретает высокие продажи за эту семь дней и фактически нулевые за следующую. К сожалению, в реальности подобные обстановки появляются неизменно. Таковой сценарий развития событий именуют эффектом кнута (bullwhip effect), по причине того, что маленькие трансформации на одном финише цепи поставок приводят к важным последствиям на ее втором финише.
маркетингпродажиудовлетворенность клиентов src=https://media.lpgenerator.ru/uploads/2017/01/18/5_thumb600x297.jpg style=border: none; transform: rotate(0rad); width: 600px; height: 297px; /
Для стартапов: продуктмаркетингпродажиудовлетворенность клиентов
Тот же принцип честен и для стартапов — лишь тут главными этапами цепи являются продукт, маркетинг, продажи и удовлетворенность клиентов. Руководствуясь запоздалым клиентским фидбеком, разработчики либо маркетинговая команда рискуют израсходовать большое количество времени и средств впустую.
Как вы имеете возможность решить эту проблему? Посредством так называемых прокси-метрик (proxy metrics). Возвращаясь к примеру с рестораном, если вы желаете оценить уровень качества работы персонала, вам легко необходимо измерить полноту чашек с водой. Попросите администратора прогуляться по последовательностям и подсчитать, сколько чашек на каждом столе заполнены меньше чем наполовину.
Эта метрика не совершенна, но она есть характерным показателем того, что столу уделяют внимание сходу пара официантов.
Прокси-метрики стоит применять по 4 главным обстоятельствам:
Успешные компании пользуются такими показателями неизменно. К примеру, Facebook понял, что люди, додающие минимум 7 друзей в течение первых 10 дней по окончании регистрации, становятся долговременными пользователями. Looker осознали, что чем продолжительнее их пользователи взаимодействуют с данными в течение free-trial периода, тем лучше они конвертируются в платящих клиентов.
А ThredUp — наибольший в мире консигнационный вебмагазин — узнал, что клиенты, каковые оформляют заказы как на сайте, так и в мобильном приложении, владеют более высоким LTV (lifetime value — пожизненная сокровище клиента).
Как выяснить прокси-метрики вашего бизнеса? Несложного ответа на данный вопрос нет. Поставьте перед собой цель, изучите эти, совершите регрессионный анализ и выполните обратное тестирование (backtest).
Для более сложного поведения наподобие «сетевых эффектов» (network effects) вам может потребоваться второй способ статистического моделирования.
Прокси-метрики являются замечательный актив, поскольку они разрешают компаниям применять наглядные показатели для прогнозирования итогового результата. Это значительно сокращает время проведения разных экспериментов и тестов, что разрешает вам найти верную стратегию роста намного стремительнее. Такое конкурентное преимущество имеет важное значение для любого стартапа.
Делайте бизнес на базе данных!
По данным: tomtunguz.com.
Случайные статьи:
Интернет маркетинг по новым технологиям ➤Поисковое продвижение сайта ➤Стратегия интернет маркетинга
Подборка похожих статей:
Как правило, все конкурентные преимущества стартапов возможно поделить на пять категорий: конкретно сам продукт, цена, позиционирование, функционирование…
Главные показатели эффективности (KPI) — незаменимый инструмент для команды, инвесторов и основателей стартапа. Они разрешают без предположений и лишних…
В то время, когда в последний раз вы уделяли внимание тому, что делает вашу клиентскую базу пригодной для маркетинговых кампаний? Поразмыслите о персонах…
Применение CMS либо CRM для email коммуникации с подписчиками на первый взгляд думается логичным и рентабельным. Но, в действительности, такое ответ в…
Как создать конкурентное преимущество для стартапа с помощью прокси-метрик?
Представьте, что вас только что назначали на должность директора популярного ресторана в Нью-Йорке, столкнувшегося с очень серьезной проблемой — клиенты постоянно жалуются на качество обслуживания. Теперь вы ищете метрики, которые бы отражали текущий уровень сервиса и которые можно было бы отслеживать в ходе экспериментов с ресторанными операциями. Какие показатели вы бы использовали?
Можно опрашивать клиентов на выходе из заведения. Связываться с ними по телефону на следующий день после визита. Или даже попросить бухгалтера свести в таблицу сумму чаевых, выраженную в процентах от общего счета, и связать ее с каждым официантом.
Эти приемы работают, но проблема заключается в том, что они предоставляют вам запоздалую информацию о качестве обслуживания. К тому моменту, как вы соберете все необходимые данные, улучшать клиентский опыт будет слишком поздно.
Влияние задержки: пивоварня > разливочный цех > поставщик > продавец
Почему это неприемлемо?
Чтобы объяснить вам значение задержки в контексте принятия оперативных решений, мы рассмотрим случай, который произошел в одной из бизнес-школ. Профессор маркетинга предложил студентам сыграть в популярную логистическую игру под названием «Beer game». Он поделил класс на 4 группы — по одной на каждый ключевой этап цепочки пивного производства: пивоварня, разливочный цех, поставщик и продавец. Это пошаговая игра, и каждый ход 4 группы выбирали, сколько конкретно пива нужно варить, разливать, поставлять и закупать. Профессор играл роль клиента и говорил продавцу, сколько бутылок он собирается купить.
В задержке кроется главная особенность игры. Игроки принимают запрос от клиента, но для отправки заказов вниз по цепи поставок им необходимо 2 недели. Вначале внешний спрос остается устойчивым, но затем он внезапно увеличивается и снова стабилизируется на новом уровне. Продавец слишком долго обдумывает запоздалую информацию. Затем то же самое происходит с поставщиками и разливочным цехом. И в конечном счете, пивоварня получает высокие продажи за эту неделю и практически нулевые за следующую. К сожалению, в реальном мире подобные ситуации возникают постоянно. Такой сценарий развития событий называют эффектом кнута (bullwhip effect), потому что небольшие изменения на одном конце цепи поставок приводят к серьезным последствиям на ее другом конце.
Для стартапов: продукт > маркетинг > продажи > удовлетворенность клиентов
Тот же принцип справедлив и для стартапов — только здесь ключевыми этапами цепи являются продукт, маркетинг, продажи и удовлетворенность клиентов. Руководствуясь запоздалым клиентским фидбеком, разработчики или маркетинговая команда рискуют потратить много времени и средств впустую.
Как вы можете решить эту проблему? С помощью так называемых прокси-метрик (proxy metrics). Возвращаясь к примеру с рестораном, если вы хотите оценить качество работы персонала, вам просто нужно измерить полноту стаканов с водой. Попросите администратора пройтись по рядам и подсчитать, сколько стаканов на каждом столе заполнены меньше чем наполовину. Эта метрика не идеальна, но она является характерным показателем того, что столу уделяют внимание сразу несколько официантов.
Прокси-метрики стоит использовать по 4 основным причинам:
Успешные компании пользуются такими показателями постоянно. К примеру, Facebook обнаружил, что люди, добавляющие минимум 7 друзей в течение первых 10 дней после регистрации, становятся долгосрочными пользователями. Looker поняли, что чем дольше их пользователи взаимодействуют с данными в течение free-trial периода, тем лучше они конвертируются в платящих клиентов. А ThredUp — крупнейший в мире консигнационный интернет-магазин — выяснил, что покупатели, которые оформляют заказы как на сайте, так и в мобильном приложении, обладают более высоким LTV (lifetime value — пожизненная ценность клиента).
Как определить прокси-метрики вашего бизнеса? Простого ответа на этот вопрос нет. Поставьте перед собой цель, изучите данные, проведите регрессионный анализ и выполните обратное тестирование (backtest). Для более сложного поведения вроде «сетевых эффектов» (network effects) вам может потребоваться другой метод статистического моделирования.
Прокси-метрики представляют собой мощный актив, так как они позволяют компаниям использовать наглядные показатели для прогнозирования итогового результата. Это существенно сокращает время проведения различных тестов и экспериментов, что позволяет вам отыскать правильную стратегию роста намного быстрее. Такое конкурентное преимущество имеет решающее значение для любого стартапа.
Сбор статистики MTProto Proxy
Предыстория
Сбор статистики
На официальной странице MTProto Proxy на Docker Hub указано что мы можем использовать команду docker exec mtproto-proxy curl http://localhost:2398/stats для получения статистики напрямую от MTProto Proxy который находится в контейнере, так что наш код будет выглядеть следующим образом.
total_special_connections указано на том же Docker Hub как число входящих подключений клиентов
Отображение статистики
Далее нам нужно в простой и удобной форме выводить текущее количество пользователей, мы будем выводить её в браузер.
Теперь перейдя по IP адресу нашего MTProto Proxy мы сможем увидеть текущее количество клиентов.
Визуализация и ведение статистики
Осталось собрать всё в докер образ
Развертка
Сначала нам нужно запустить контейнер с агентом Datadog
ВАЖНО для того чтобы мы могли слать агенту наши данные нужно установить значение true для переменной окружения DD_DOGSTATSD_NON_LOCAL_TRAFFIC
Далее с помощью команды docker inspect dd-agent нам нужно посмотреть IP контейнера чтобы слать ему данные
и запустить наш MTProto Proxy соединив его мостом с контейнером агента
И через пару минут мы уже можем построить график выбрав нужную метрику и источник (тег который указан при запуске контейнера с MTProto Proxy)
и отобразить на нём нашу статистику
Заключение
Для себя я открыл новые инструменты для удобной работы с данными, познакомился с их большим разнообразием и выбрал что-то подходящее на свой вкус.
Спасибо за уделенное внимание, предлагаю всем поделится мнением, замечаниями и предложениями в комментариях.
Как в Flo повысили долю успешных A/B-тестов на 30% через внедрение нового процесса работы с гипотезами
Эту статью вместе с GoPractice написал Дима Золотухин (Facebook, Telegram) – Head of Analytics в компании Flo. Дима занимается дата-аналитикой 8 лет, с 2017 года – в продуктовых компаниях.
Далее повествование ведется от лица Димы.
В Flo (мобильное приложение № 1 в сфере женского здоровья) мы увеличили долю успешных экспериментов на 30%. Для этого мы много инвестировали в то, чтобы наладить эффективный процесс по работе с гипотезами.
Одна из важных составляющих процесса – отсутствие монополии на формулирование гипотез, что приводит к тому, что вся команда участвует в создании гипотез, их приоритизации и тестировании.
В таком случае процесс работы с гипотезами важно знать и понимать всем членам команды, которые касаются продукта: продуктовым менеджерам, аналитикам, дизайнерам, UX-исследователям и даже разработчикам.
В этой статье мы обсудим, как правильно формулировать и приоритизировать гипотезы для последующего A/B тестирования.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
Еще больше ценных материалов и инсайтов — в телеграм-каналах GoPractice и GoPractice Insights. Добавляйтесь в чат Ask Kevin!, чтобы участвовать в обсуждениях с другими участниками нашего коммьюнити.
Шаблон построения гипотезы и ее компоненты
Гипотеза — утверждение, которое требует доказательства и потенциально может быть проверено с помощью эксперимента.
То есть у правильно сформулированной гипотезы есть как минимум четыре обязательных компонента.
Давайте разберем стандартную гипотезу по компонентам.
Шаблон гипотезы. Описание изменений
Самый удачный вариант для описания изменений — небольшой мокап, на котором любой участник команды быстро поймет, что конкретно для пользователя будет меняться. Это можно сделать как в специальных инструментах вроде Figma (если меняется UI) или Miro (если изменения касаются логики серверной части), так и нарисовав скетч от руки.
Из нашего опыта люди воспринимают и запоминают визуальную информацию намного лучше, чем текст.
Шаблон гипотезы. Сегмент пользователей
На этом этапе нам нужна только примерная оценка сегмента аудитории. Важно, чтобы это был именно определенный сегмент пользователей, обладающий общими задачами и/или паттернами поведения.
Благодаря сегментации аудитории всем участникам команды проще понимать пользователей продукта. Сегментацию вовсе не обязательно (скорее даже нежелательно) делать при помощи продвинутых ML-методов.
Например, мы в Flo делим пользователей на сегменты в зависимости от цели использования приложения. Цель использования мы уточняем на онбординге. Список сегментов (целей) мы определяли и подтверждали качественными исследованиями исходя из того, какую основную цель могут ставить перед собой пользователи в приложении.
Шаблон гипотезы. Ключевая метрика и иерархия метрик
В Flo мы опираемся на OKR компании при выборе метрик. KR на уровне компании представляют собой микс бизнесовых (монетизационных) и UX-метрик.
В итоге, мы изначально понимаем, какие именно показатели хотим улучшить. Это позволяет ограничить набор гипотез и выбирать только релевантные идеи.
Продуктовая команда не всегда может непосредственно и значимо влиять на верхнеуровневые бизнес-метрики. Кроме того, часто они составные. Пример — LTV пользователя, который в подписочных приложениях состоит из сложной воронки: конверсия в триальную подписку, далее конверсия в платеж и последующие конверсии в продление.
Поэтому мы много инвестируем в единую иерархию метрик в компании, которая поможет:
Такая систематизация сильно упрощает выбор метрики в команде. Двигаясь по иерархии метрик, участники лучше понимают, на что именно они могут повлиять, как это связано с топлайн метрикой.
Построение иерархии актуально не только для больших и сложных продуктов, но и для более простых. Ведь основная цель этого упражнения для команды — понять, кто и на что она может эффективно влиять.
Шаблон гипотезы. Прокси-метрики для оценки экспериментов
Довольно часто в экспериментах требуется оптимизировать долгосрочную метрику, например, долгосрочный retention, но ждать месяцы или даже годы у команды возможности нет. Измерять эффект быстрее, но с некоторыми погрешностями помогут прокси-метрики.
Сходство бинарных метрик можно оценивать с помощью коэффициента Жаккара. На иллюстрации видим, что метрика retained М1 (возврат во второй месяц после установки, отсчет с нуля) на 60% сходна с метрикой retained up to D7 (возврат между вторым и восьмым днем после установки). В первом случае нам надо ждать два месяца для того, чтобы получить оценку эффекта, во втором — восемь дней.
Не всегда очевидно, как работать с трейд-оффом между точностью и скоростью расчета. Принимать решение будет проще, если установить внутренний KPI по точности (сходству).
Шаблон гипотезы. Business vs. UX
В некоторых случаях оптимизация бизнес-метрик может вступать в противоречие с User Experience и общей ценностью продукта для пользователей. Например, если делать более агрессивную монетизацию.
Такие кейсы можно контролировать с помощью health-метрик, которые как раз отвечают за UX. Health-метрика, как правило, разнонаправлена с основной метрикой эксперимента (если это бизнес метрика), и главное — ее не «уронить».
Самый популярный пример health-метрики — Retention, но мы используем и другие метрики на разных уровнях иерархии. Например, часто смотрим “активацию” конкретной фичи приложения, чтобы быть уверенными, что изменения ее не обвалили.
Шаблон гипотезы. Масштаб изменения метрики
Мы пришли к одному из самых сложных вопросов — как определить потенциал изменения метрики.
На этапе приоритизации гипотез, как правило, сложно получить супер-достоверную оценку, поэтому надо стараться получить оценку примерную, которая может также быть подтверждена интуицией (об этом чуть позже).
Мы знаем сегмент аудитории, на которую должны повлиять изменения. Но откуда получить информацию об эффекте?
1. «Холодный расчет»
В некоторых случаях масштаб изменений можно просчитать. Например, перед запуском новой фичи можно опросить своих пользователей, насколько они заинтересованы в запуске новой Feature X. Исходя из этого, можно оценить интервал потенциальных конверсий и планируемый эффект.
2. История экспериментов
Историю экспериментов надо хранить как минимум для этого. Находим похожие эксперименты, которые, например, запускались на другой платформе/языке/стране или похожи по теоретическому масштабу изменений. Берем средний эффект. В крайнем случае можем посмотреть вообще все эксперименты с нужной нам метрикой и взять медиану, 75-й перцентиль или максимум изменения в зависимости от вашей уверенности в гипотезе.
3. Рыночное исследование
Иногда оценить эффект от изменения можно по косвенным признакам из рыночного исследования. Как правило, это касается гипотез с рынка, подсмотренных в каком-то виде у конкурентов или просто у других продуктов. В известных сервисах вроде AppAnnie мы можем посмотреть, какой эффект оказало обновление на верхнеуровневые метрики конкурентов. Желательно, чтобы это работало в обе стороны: берете гипотезу/фичу с рынка — обязательно посмотрите на ее влияние в том продукте, где она реализована.
4. Just Noticeable Difference (JND)
Мы можем предлагать что-то суперпрорывное и вообще ничего не понимать с точки зрения эффекта. Рекомендуем определить Just Noticeable Difference на каждом уровне иерархии метрик — масштаб изменений, который точно будет заметен на необходимом уровне. Тогда в случае запуска эксперимента вы всегда будете понимать, насколько он успешен.
Приоритизация гипотез для тестирования с помощью ICE
Мы научились формулировать гипотезы, но у нас их много, и нам надо понимать, как находить наиболее перспективные.
Мы пользуемся чек-листом из пяти пунктов, которые позволяют упростить выбор и найти хорошие гипотезы.
Итак, гипотеза хорошая, если:
Легко заметить, что некоторые пункты чек-листа могут противоречить друг другу и, по сути, являются утопией.
На помощь нам приходит методика приоритизации ICE, которая поможет выстроить бэклог из гипотез.
Чек-лист легко превращается в элементы ICE:
Мы в Flo используем Data Informed ICE: аналитики информируют команду о прогнозном Impact (влиянии изменения), но каждый принимает решение об оценке для ICE лично. Это позволяет привнести элемент продуктовой интуиции в процесс приоритизации и снижает разброс оценок, который бывает при отсутствии бейзлайна.
Запуск экспериментов (A/B тестов)
Получив бэклог из гипотез, мы идем далее по процессу:
Именно так работают продуктовые команды Flo. Внутри два взаимосвязанных, никогда не заканчивающихся процесса — работа с гипотезами и экспериментирование.
Документирование – важный этап процесса приоритизации и тестирования гипотез
Чтобы работа с гипотезами была действительно системной, надо их сохранять и документировать.
Сейчас приоритизацию мы храним и делаем в Google Sheets. Там же мы храним связь гипотез — сводную таблицу планируемых гипотез, которые влияют на одну Objective. Это не очень удобно. И мы в процессе поиска более удобного инструмента, который позволяет эффективно миксовать OKR, работу с гипотезами и результаты экспериментов.
С похожими проблемами столкнулись ребята из соседней статьи и разработали свой инструмент.
Результаты внедрения процесса работы с гипотезами
Мы работаем по описанному процессу уже несколько кварталов и можем отметить:
Сформулировать продуктовую гипотезу правильно не так уж просто, и приоритизация не дается с первого раза. Но если этот процесс настроить и правильно запустить, то скорость и качество развития вашего продукта значительно улучшатся за счет осознанности и эффективной командной работы.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
Еще больше ценных материалов и инсайтов — в телеграм-каналах GoPractice и GoPractice Insights. Добавляйтесь в чат Ask Kevin!, чтобы участвовать в обсуждениях с другими участниками нашего коммьюнити.
Эссе и образовательные симуляторы про продакт-менеджмент, продуктовую аналитику, маркетинг и рост
Универсальный stratum-прокси для измерения хешрейта
Задача
Для удовлетворения всех этих требований был написан свой велосипед.
Архитектура
Принцип работы stratum-прокси
Процесс подключения воркера к пулу через прокси
При первом подключении на воркер отправляется очень высокая сложность. Это необходимо, потому что воркер при переподключении продолжает выполнять прежнюю работу. В первом варианте прокси отправляла воркеру сложность 1.0 и тут же падала под валом запросов. Потом решили не отправлять никакой сложности, и воркер просто отправлял нам работу, которую мы вынуждены были отклонять. Получив несколько отбивок, воркер отключался, что тоже было неправильно. Поэтому пришли к решению отправлять большую сложность.
Переподключение к прокси происходит только после того, как завершилась авторизация на пуле. До этого момента мы не можем быть уверены в правильности переданных данных авторизации на пуле.
При разрыве подключения прокси ждет 1 минуту повторного подключения. Если оно не происходит, происходит отключение от пула, удаление соответствующих метрик и удаление воркера из внутренней базы.
Метрики, которые публикует прокси
Метрики доступны на HTTP endpoint /metrics по адресу прокси на порту, который определяется в настройках. Метрики включают в себя стандартные клиентские метрики Prometheus и специализированные метрики прокси. Набор метрик, описанный ниже, доступен для каждого соответствующего воркера и пула.
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
«, «worker»=» : «, «user»=» «, «hash»=» «, «pool»=»
Набор метрик прокси подобран таким образом, чтобы все метрики были взаимопроверяемыми и давали максимально точную информацию о майнинге. Теги метрик позволяют группировать принимаемые данные по конкретному воркеру, пользователю, пулу, алгоритму.
Расчет хешрейта прокси
Хешрейт каждого воркера считается отдельным потоком по стандартной формуле:
Регистрация на прокси
Регистрация на прокси происходит с помощью вызова REST-API функции по адресу http://
Если пул входит в список известных прокси, то для этого аккаунта будет сгенерировано уникальное имя, которое будет необходимо указывать при подключении к прокси. Пароль не генерируется и не используется. Корректным ответом на данный запрос будет:
Использовать его надо будет следующим образом: