NEWHR выпустили очередной отчет по исследованию рынка продуктовых и дата-аналитиков.

Из очевидно полезного — список задач и их регулярность (хорошо помогает от иллюзий “мы тут ML пилим 25/8”), зарплаты YoY по грейдам, длительность поиска работы в зависимости от локации.

Из любопытного — доля респондентов с опытом 6 и более лет всего 16%. Вполне себе маркер, на мой взгляд, насколько же молодая дисциплина у нас. Ну или насколько сеньоры тихушники, а то есть за ними такой грех.

Еще многие работают на двух работах. Тут для меня два момента — инди-командам редко когда нужен аналитик на фуллтайм, поэтому вполне можно вести несколько таких проектов. А во-вторых, это может быть еще одним подтверждением тренда, когда эксперты/сеньоры стараются разнообразить свою жизнь новыми продуктами и задачами, консультируя сторонние проекты.

В целом отчет проходной, на мой вкус — глубоких инсайтов нет, слишком широкое поле. Но мониторить настроения помогает.

Пока болтался в отпуске, попалась на глаза статья от X5 Tech про разметку событий. Какой трекер они выбрали, как называть события, какая логика организации параметров. То, что я называю “дизайном событий” и что вполне может занимать до трети рабочего времени аналитика на ранних этапах проекта (потом, конечно, существенно меньше).

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

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

Очень хочется свою документацию довести до схожего вида, ведь примерно половина уже есть. Мечты-мечты.

#datamodel

В канале GameDev Reports - by devtodev недавно было разбор исследования особенностей платящих пользователей, которое провела компания Mistplay. Исходный отчет и ссылка на русскоязычный разбор здесь.

В отчете много разного, от отношения к рекламе до платежных паттернов и построения персон. Есть достаточно любопытные цифры. Например, согласно отчету и пересказу, “81% мидкорных пользователей совершает первую покупку в течение первого месяца. 7% для этого нужен только 1 день”. Или что “мотиваторы для совершения покупок - это прогрессия (54%) и получение удовольствия (44%)”. Есть даже целая иерархия, зачем пользователи играют в мобильные игры, по убыванию от “провести время и развлечься” до “стать лучшим в чем-то”.

Тем не менее, в исследовании есть большая ложка методологического дегтя. Потому что исследование основано на изучении поведения 2к платящих пользователей из США и Канады, которые активно используют платформу Mistplay. Mistplay — платформа play-to-earn: пользователь через Mistplay устанавливает и запускает игру, играет и получает внутренние очки, которые потом может обналичить через Amazon gift card или другими путями (вот тут есть подробнее). Если я правильно понял схему, то пользователь получает немного виртуальных денег, разработчики — инсталлы, Mistplay — деньги за привлечение пользователей.

Мы же получаем искаженную выборку, так как далеко не все разработчики используют Mistplay (т. е. мы не знаем, по пользователям каких игр сделаны выводы). И платящие пользователи, пришедшие через Mistplay, не факт что репрезентативны относительно всей совокупности платящих. Это приводит к грустно-забавным казусам, когда к хорошо платящим относят пользователей с $100 суммарно заплаченного в Q4 2023. Или что пользователям платформы повышения лояльности неожиданно очень нравятся программы лояльности и разные формы кэшбэка.

В результате исследование получилось любопытным, но с некоторыми не очень очевидными искажениями, которые надо учитывать. С другой стороны, я теперь могу сравнить свои цифры с совсем внешним источником. Да и еще одна реализации механики кэшбека мне понравилась, не одними VIP-уровнями едиными, в конце концов.

Задачка по следам одного из неожиданных рабочих обсуждений.

У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни?

Мое решение дам завтра или через день.

#exercises

Комментарий по недавней задачке.

Обычно мы считаем в DAU количество пользователей, которые заходили в игру в определенный календарный день, день считается по UTC. Конечно, среди пользователей могут быть те, кто зашел и ничего не делал (не заходил в бой / не сделал корлуп), но это уже вторично.

На PC-проектах, в отличие от мобильных игр, сессия пользователя явно ограничена, так как есть событие логаута. Поэтому иногда на PC-проектах считают DAU по тем, кто залогинился в определенные сутки, и тем, кто сделал логаут (их логин был в предыдущие сутки). Или кто отыграл больше 50% сессии в новые сутки, а не просто логаут сделал. Собственно, именно это и было неожиданным для нас.

Помимо просто подсчета абсолютного количества логинов мы обычно испольузем еще какую-то дополнительную сегментацию пользователей — по уровню, по лиге, по количеству заплаченного, и т.д. Это полезно и для понимания стабильности аудитории, и для некоторых других расчетов, например среднего прихода/расхода игровых валют на пользователя в сегменте. В отличие от лайфтайма, тира стран или платформы это динамические параметры, которые могут меняться в течение дня. Поэтому мы берем то значение, которое было на момент логина пользователя.

Брать первые значения параметров достаточно очевидная идея, однако у нее есть свой минус — низкая чувствительность к тем, кто только-только начал играть. Так как пользователь за первый день может пройти N уровней, заплатить M денег и т.д. Но тут без компромиссов, видимо, не обойтись — нам важно видеть честное значение DAU (а не умножать количество пользователей на сегменты, в которых они побывали), и начало игры для нас менее важно, в отличие от более поздних периодов. Для молодых проектов, возможно, сегменты надо делать тоньше и/или старт анализировать отдельно.

В общем, учите, маги, санктуарий если дашборды на разных источниках не сходятся — возможно, дело не в данных.

#exercises

Немного около-геймдизайнерских размышлений. Недавно с главным ГД на одном из наших прототипов возник небольшой спор — стоит ли вводить механики ограничения активности игроков типа энергии.

Его агрументы простые — у нас в прототипе нет большого количества контента и если пользователей не ограничивать, они “пройдут игру” и не вернутся. Тем самым занизят нам тесты ретеншена. Мы видели и такие примеры, хотя ограничение пользователей всегда выглядит небезопасно — зачем нам выгонять пользователя из игры?

А я как раз в последние пару дней активно залипаю в Backpack brawl (чудовищно аддиктивная штука). Там геймплей понятен на втором-третьем раунде, дальше уже просто комбинаторика и решение меты, как и в ККИ. Да и в некоторых наших прототипах-шутерах контента было, насколько я помню, два-три юнита и одна карта, а ретеншен был весьма и весьма приятный. То есть, пользователи сразу видели, что контента нет, и все равно возвращались.

Собственно, можно насобирать референсы и подобрать множество аргументов "за” и “против", но в этой битве аналитики обычно проигрывают геймдизайнерам. Поэтому подобные тезисы должны ставиться под сомнение и разрешаться A/B-тестами. All others must bring data.

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

Уже совсем скоро будет конференция Aha (6 июня оффлайн, 30 мая онлайн-трек). Ее организуют Алексей Никушин и его команда МатеМаркетинга. А это, кажется, единственные, кто делает именно продуктово-аналитические, а не датасаентистиские конференции (кому нужна техничка — велкам на ODS-датафест, а за продакт-менеджментом надо идти на ProductSence или Epic Growth).

Если получится, попробую заглянуть. В прошлые года то просто не получалось, то программа не вызывала энтузиазма.

В этом же году очень симпатичный трек по экспериментам и A/B-тестам в частности. Посмотрите программу — и global control, и работа с метриками в экспериментах, и графы, и воршопы. Даже про GrowthBook расскажут, про который я давно слышал, но еще ни разу не смотрел.

Притом, как я понимаю, часть выступлений в оба дня будет доступна бесплатно в режиме live-трансляции. Так что как минимум стоит ее посмотреть.

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

Я рассказывал результаты последнего радикального изменения метагейма. Жаль, но ожидаемых изменений в метриках не случилось (без названий и значений, простите). Постмортемы написаны, внутренняя рефлексия аналитиков почти завершена. Команда уже работает над новыми идеями. Я тоже в скором времени перейду на другие прототипы.

Это были интересные несколько лет. Много экспериментов, качели от энтузиазма до разочарования в том, что и как делаешь, и обратно. Именно при работе над этим проектом я стал нащупывать, что мне важно в игровой продуктовой аналитике, как-то выстраивать собственную методологию. В принципе, в этом канале много отголосков идей и осознаний про это.

Что ж, завтра будет. Лучше. Устал от ощущения, что из года в год рисую звездочки на фюзеляже. И хочу, в конце концов, научиться отвечать на вопрос “почему пользователи играют в нашу игру”.

Сегодня день конференции Aha'24. Рассказывать ничего не буду (геймдевные темы обычно слишком узкие для таких конференций, да и в целом рынка аналитиков, где доминирует e-com и сервисы). Зато буду слушать и разговаривать. Если вы собираетесь прийти — давайте встретимся. Тем, кто не пойдет, напоминаю, что на конфе есть бесплатный онлайн-трек.

Моя любимая картинка, которая идеально подходит в тему:

Всем привет!

Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.

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

Посты для знакомства с каналом:

Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка

Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.

Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.

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

Антон Марцен очень точно сформулировал мысль, которая крутилась в моей голове после Aha’24:

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

Не знаю, насколько это релевантно геймдеву. Все-таки воронки (особенно на старте игры) и в целом прогрессия пользователя у нас более управляемая. А дерево бизнес-метрик у нас достаточно бедное и потому линейное. Поведенческие метрики могут быть сложнее, но пока непонятно, насколько.

Тем не менее, тренд есть и соотнести с ним свои задачи и работу может быть интересно.

У меня астрологи, видимо, объявили месяц статистики. Так что, пока я читаю и осмысляю (расскажу свои впечатления позже), вот вам немного геймдизайнерско-аналитической теории.

В недавнем деконстракте AFK Journey увидел ссылку на классификацию валют, которую предложил Javier Barnes из Tilting Point. Статья достаточно старая, но раньше мне почему-то не попадалась. Сокращенный пересказ на русском здесь. Javier Barnes описывает 11 типов валют, включая харду, софту, энергию, валюты ивентов, гильдий, режимов и т.д. Ключевое в его определении валют:

I’m defining ‘currency’ as an element that has no use value in and of itself, but rather its main purpose and value comes from its ability to be exchanged for something else which has an actual use value.

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

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

Аналитики сталкиваются с валютами как минимум в трех аспектах:

Во-первых, интерпретация поведения пользователей, как он оперирует валютами. Например, пользователь не тратит харду, потому что его субъективная оценка стоимости предмета/пака не соответствует выставленной цене. Или он получает слабый эффект за потраченные деньги. Или он не понимает, как ему получить валюту, чтобы что-то купить. Или что он предпочитать покупать.

Во-вторых, логирование валют. Это надо обсуждать с разработчиками, но в моем опыте они обычно разделяют валюты и предметы. Валюты стоит трекать отдельно платные и бесплатные, писать количество на руках в событиях старта/конца сессии, сколько и откуда получили, на что потратили и т. д. В идеале — курс валюты и/или стоимость контента в долларах, при аудите потом поможет да и в целом удобно.

В-третьих, причуды монетизации. Остатки на руках, эффективность методов вымывания (когда много раздали в акции и хотим заставить пользователей потратить излишки), профицитность игровой экономики, обесценивание валют при высоких скидках и прочие вещи на грани экономики и чорной магии. К слову, большое количество валют дает чуть больше контроля над экономикой, Javier Barnes об этом тоже говорит.

Сергей Матросов (X5 Tech, автор канала Не AБы какие тесты) опубликовал лонгрид про тест Манна-Уитни.

Статья действительно большая, я читал ее в несколько подходов и еще буду перечитывать. На мой взгляд, ее стоило бы разделить на две или три части, да и некоторые определения показались мне шероховатыми. Но это все вкусовщина, у Сергея была такая куча редакторов и итераций правок, что если я буду развивать эту тему, он меня проклянет и будет прав.

Первые две части посвящены эволюции критерия — от исходного поэлементного сравнения и вывода о равенстве распределений до сумм рангов и статистики W-Вилкоксона. Попутно есть ряд лирических отступлений про нулевую гипотезу и оценку значимости в симуляционном эксперименте.

Последняя треть статьи оказалась для меня одновременно самой сложной и самой интересной. Она посвящена практическому использованию критерия и особенности его реализации в Varioqub. Сергей делает разбор на кейсе Авито, одновременно вступая в полемику. Собственно, для лучшего понимания дискуссии стоить прочитать и статью Дмитрия Лунина.

Этот кейс очень близок к тому, с чем регулярно сталкиваемся мы в наших экспериментах — когда мы делаем изменения в стоимости/наполнении оффера, у нас есть и изменения конверсии, и большое количество неплатящих в обеих группах. Мы подобные эксперименты проверяем дедовским способом, простым как топор и вычислительно сложным — перестановочными тестами. Что ж, теперь есть что добавить в бэклог идей для R&D.

Помимо обсуждения критерия Вилкоксона-Манна-Уитни, в статье еще есть описание пары трюков про бакетизацию и преобразование данных (как они реализованы в Varioqub, но это непринципиально). И бонусом, уже в посте про статью, есть описание непараметрической меры центральной тенденции, оценки Hodges-Lehman’a. Новая для меня штука, любопытно.

#stats

У меня сейчас некоторое затишье (команды прототипов ушли в глубокое погружение), поэтому интересных кейсов и осмыслений поменьше. А я больше читаю да ползаю по сети.

Недавно попалась на глаза реклама канала Первый продуктовый. Канал вполне хорош, хотя его вайбы и стиль мне не близки. В рекламном посте была фраза, которая меня и зацепила.

…метрики тщеславия типа MAU, DAU и новых зарегистрированных пользователей

Я бы еще добавил NPS сюда. Очень точное определение. Красивые метрики, но абсолютно бесполезные для принятия решения, к тому же сильно зависят от ситуации и целей, о которых мало кто говорит вслух. Потому что можно потерять в количестве новых пользователей, но выиграть в окупаемости. Можно дешевым и нерелевантным трафиком вырастить DAU, но эти пользователи уйдут на следующий день. MAU может быть стабильным, но меняется структура платящих. И так далее.

Впрочем, вырвать из контекста или взломать можно любую метрику. Например, раздать всем стартерпак со скидкой в 99% за $0.99 и конверсия в платящих улетит к Плеядам. У меня так один из проектов как-то хотел пройти бенчмарки в тесте монетизации. Поэтому надо смотреть на совокупность метрик. Я вот активно использую группу метрик “Revenue + ARPU / ARPDAU + конверсия в платящих + средний чек + среднее количество платежей + доля платящих в DAU”. Иногда еще добавляю конверсию во второй платеж. Сравнил несколько когорт (например, по версиям игры) или проектов, и сразу видно различия в модели монетизации или проблемные зоны.

Я не люблю задачки вида “ползут три черепашки”, но они все же встречаются, даже в отлаженных системах трекинга. И заставляют извращаться с всяким манипулированием данными.

Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы трекинга платежей. В ней потерялись некоторые платежи. Надо найти и изучить потеряшек.

Из условий: есть только общий идентификатор пользователя и таймстампы транзакций в каждой выгрузке. Будем считать, что идентификаторов транзакций, SKU и прочих полезных данных нет. Данные выгружены в csv из разных баз, никакого SQL.

Для упрощения ситуации будем считать, что таймстампы одной транзакции в двух системах различаются незначительно (допустим, меньше 30 секунд). И что разница времени двух разных транзакций больше, чем разница во времени одной транзакции в двух системах. В реальности, конечно же, такие предположения еще нужно сделать и, по возможности, проверить.

Как будете решать такую задачку?

Я вижу два решения. Одно прям дубовое и прожорливое по ресурсам. Второе поизящнее и поэкономнее. И оба грязные. Впрочем, я вообще не уверен, что такие задачи можно чисто решать, честно говоря.

#exercises

Решение предыдущей задачки.

Первое решение, как я и говорил, дубовое и прожорливое. Основная идея — так как в pandas нет нечеткого джойна, делаем cross join, так, чтобы для каждой транзакции из консоли были все транзакции в нашей системе трекинга. Потом ищем дельту во времени между транзакциями и берем для каждой транзакции в сторе одну минимально близкую по времени в системе трекинга. Если такой нет (все транзакции в системе за пределами интервала [1, 30] секунд), то это транзакция и была потеряна.

Основная идея второго решения — выстроить все транзакции в один временной ряд, так как ожидаем, что пользователи делают платежи с большим интервалом, чем наша разница между двумя системами. И если после транзакции в консоли не было транзакции в нашей системе — то вот она, наша потерянная транзация.

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

Код можно посмотреть здесь.

UPD: в пандах таки есть merge_asof. Видимо, статья на SO была совсем древней, а я не посмотрел на ее дату :(

#exercises

Недавно что-то накатила грусть да хандра экзистенциальная. Решил вот побаловать себя товарами заморскими. My precioussss. Про первые две, думаю, напишу что-нибудь, когда прочитаю. А про Kohavi и так все понятно, он больше для коллекции.

Дочитал Game Analytics: Retention and Monetization in Free-to-Play Mobile Games by Russell Ovans. Книга вполне свежая, 2023 года издания. Автор — лид аналитики Eastside Games (Appmagic). Когда-то в 2007 году он основал игровую студию с играми в Fb, в 2010 он ее продал и ушел варить пиво. А в 2018 году вернулся в геймдев, чтобы поддержать свою пивоварню.

В книге 12 глав, каждая в среднем 20-25 страниц. Первые две главы погружают в аналитический быт — что такое монетизация, пайплайн работы, дизайн событий, основные метрики. Основные инструменты в книге и, как я понимаю, в работе — SQL, Tableau и иногда R. Притом примеры что на SQL, что на R — просто ужасные на мой вкус, синтаксис каменного века.

Третья глава посвящена дашбордам и, по большей части, как их делать в Tableau. Для сбора требований к дашбордам я бы рекомендовал посмотреть на фреймворк Романа Бунина, например.

Следующие четыре главы — смысловое ядро книги, так как касаются ретеншена, отвалов и монетизации. Ретеншен дается в его классическом виде retention rate, что хорошо (возвраты на строго конкретный день от инсталла, календарно). Фитить и предсказывать ретеншен предлагается степенной функцией вида r(day_n) = a * day_n ^ b, для когорты, а не поюзерно. Один из инструментов фитинга — внутренние инструменты Tableau.

С монетизацией похожая история (главы 5 и 6) — предлагается предсказывать ревеню на N день от инсталла аналогичной степенной функцией, плюс фитить регресию на исторических данных. Для чистоты данные следует нормировать (т. е. revenue_90 как 100%). Либо использовать для оценки LTV сочетание ретеншена и ARPDAU когорты на конкретный день от инсталла. Вообще, предлагаемый подход к аналитике монетизации странноватый и по идеям, и по определениям. Так, я нигде не нашел определение ARPU и сломался на фразе “if ARPDAU is defined as the running sum of cohort revenue divided by the running sum of cohort DAU”.

Глава про отвалы опирается на “марковскую цепь” и количество последовательных дней активности — то есть, предлагается оценивать, какова вероятность, что пользователь (не)вернется на какой-то следующий день. Для lifetime = 3 это граф с ребрами 0 - 1, 0 - 2, 0-3, 1 - 2, 1 - 3, 2 - 3 и отвалами 0 - churn, 1 - churn, 2 - churn. Впрочем, что делать с полученными цифрами не уточняется.

Следующие две главы посвящены A/B-тестам. Немного статистики (ЦПТ и сравнение средних, перестановочные тесты), немного примеров. После главы про дашборды это самые бесполезные главы, на мой взгляд.

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

Способы улучшения монетизации тоже не ноу-хау (я их так или иначе делал уже, например), но любопытные — посмотреть, какой монетизационный профиль пользователей в зависимости от размера и типа первого платежа. И региональные цены. Жаль только, что нет примеров и результатов применения этих методов, предлагается только использовать A/B-тесты для тестирования подходов.

Последняя глава посвящена идее ROAS и окупаемости кампаний, этакий заход в маркетинговую аналитику. Даже про AEO-кампании говорится и про k-фактор и его определение по бейслайну органики. Оценивать окупаемость предлагается по экстраполяции кривой LTV (которое опирается на ARPDAU и ретеншен). Про коэффициентные модели и метрики, про какое-то машинное обучение — ни слова.

В общем, книга получилась любопытная, но очень кустарная по ощущениям. Если вы только начинаете погружаться в продуктовую/игровую аналитику, она вас запутает и научит плохому, поэтому не рекомендую. Она интересна только с точки зрения “а как это делают в другой команде”, не более. Я лично остался разочарован.

#books

Простенькая задачка. Вполне подходит для собесов, но абсолютно реальная.

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

И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?

Правильного варианта, само собой, тут нет.

#exercises