Аналитика и метрики для Marketplace

Аналитика и метрики для Marketplace

(00:10) И.П.: Всем привет! Это третий мастер-класс от меня, меня зовут Иван, и Алексея. Мы представляем сервис Vezetvsem.ru и рассказываем про Marketplace. Что это такое. В предыдущих двух мастер-классах мы рассмотрели в принципе что такое Marketplace, мы рассмотрели внутренний маркетинг Marketplace. Сейчас мы расскажем очень интересную и важную злободневную тему «Аналитика». Что это такое, какие, куда стоит обращать внимание, какими инструментами мы будем пользоваться. Я в этом мастер-классе окончательно перехожу в разряд задающего вопросы, основное слово Алексею. Итак, аналитика и важные метрики Marketplace. Вы покупаете трафик, а можете ли вы предугадывать поведение ваших пользователей. Итак, с чего стоит начать любому человеку, который решил заняться аналитикой в Marketplace?
А.К.: (01:00) Для начала возвращаемся к постулату, который мы уже неоднократно говорили в предыдущих уроках – это что такое вот Marketplace, то есть вы там научили заказчиков, перевозчиков, все, про них забыли. Теперь собственно говоря про вас, как создателя Marketplace, как с ним работать, как с него выжать, на нем заработать. Для начала, Marketplace, вы покупаете информацию и продаете. Ваша задача – купить ее дешевле и продать. Соответственно, у вас есть, мы не будем касаться истории, как купить информацию подешевле, потому что про это уже есть как бы много уроков, как где, откуда получить трафик да подешевле, вот. мы расскажем как внутри Marketplace ее собственно подороже продать и как ее обсчитать. Собственно говоря, какая цена нормальная для покупки информации, какая нет. И сразу предупрежу людей, который в очередной раз делают Marketplace, собираются его делать. Marketplace - это
И.П.: Ад
А.К.: Ад, да
И.П.: Давай уже это слово
А.К.: Это прям совсем-совсем ад, потому что здесь данных надо собирать, а потом их анализировать и считать огромное количество, огромное количество. То есть первый ваш этап – вы начинаете считать и мерять все. Все, что можно, а потом определите, нужно или не нужно, потому что главное нужны данные. Данные нужны сначала, много, желательно качественных. Собственно говоря, переходя
И.П.: Вот давай
А.К.: Ну да
И.П.: Давайте, смотрите, естественно, вы должны уметь считать внешние метрики, мы сейчас будем рассказывать больше про продуктовые, что важно для экономики продукта внутри, под капотом. Но естественно, все равно, вы должны понимать все, что касается трафика, как происходит ценообразование в «Яндекс.Директе», как грамотно настроить органическую выдачу, что такое стоимость привлеченного клиента на сайт, чем отличается привлеченный клиент от платящего клиента
А.К.: Три буквы вот эти, скажи, что это
И.П.: Sales Acquisition Cost, стоимость привлеченного клиента. Не проверяй меня. Но мы сейчас заглянем, так сказать, под капот, что же там происходит, как все это измерять и самое главное, зачем. И мы будем использовать другие метрики, а именно следующие. Давай, ARPU
А.К.: Да, ну начнем с таких более известных метрик, которые применяются не только в Marketplace, но и в саасовских продуктах. Здесь буквально несколько слов, а потом к тем метрикам, которые в саасовскихх продуктах-то и не найдешь. Собственно говоря, ARPU - это доход с каждого платящего клиента, да, то есть вот заказчик у нас выбирает исполнителя, бронирует транспорт, для нас платящий клиент. Сколько мы с него получаем? Да, это вот разные бывают чеки, разные категории грузов и возможно, не то что возможно, на это надо смотреть, и, возможно для начала выбрать какой-то чек, который позволяет экономику сводить на ноль или еще лучше уводить в плюс. Естеств…
И.П.: С первой же сделки
А.К.: Естественно, для частотных проектов, ну с первой же сделки это в отношении «Везет всем». Мы стараемся зарабатывать с первой же сделки.
И.П.: Ну да, мы ж предприниматели
А.К.: Есть такие Marketplace, такие там как «Убер», частотные. У них высокочастотные заказы идут от одного и того же исполнителя постоянно. И они, например, могут. Не обязательно заработать с первой сделки. Они могут заработать, выйти на ноль и заработать с 3, 4, 5 сделки клиента, да. Для этого используются LTV. Здесь надо предупредить, важно не столько само LTV (Live Time Value), сколько клиент приносит, сколько точнее клиент живет у вас там по времени, а именно такой показатель как Retention Revenue, то есть сколько клиент в последствии приносит-то денег вам. Потому что клиент может возвращаться часто, но очень многие как бы считают деньги, но забывают посчитать, что даже если клиент возвращается, у него есть расходы на обслуживание Sales Acquisition Cost это вот такое, еще три буквы такие. И это надо постоянно учитывать, потому что вот к примеру, «Везет всем», у нас помимо того, что мы платим на маркетинг за клиента, который приходит, у нас расходы на его обслуживание. Когда клиент у нас первый раз – это одни расходы, это затраты на телефонию, на смс-уведомления у нас есть бесплатно для клиента, да. То есть мы смотрим, как это все вкладывается в общую копилочку, и получается ли у нас заработать на нем. Здесь мы считаем ARPU да, то есть доход с этого клиента. И очень часто мы замечаем, что все считают только стоимость привлечения, то есть сколько вы потратили на Директ и все. А его обслуживание, эти расходы тоже надо приводить, иначе экономику вашего Marketplace будет тяжело свести. И когда клиент возвращается, он вроде бы вам повторно платит деньги, но вы тоже тратитесь на его обслуживание, возможно, меньше, а возможно, у вас происходит дополнительная мотивация для его возврата с учетом того, что вы даете скидки. Это вот да, тоже пример, да один из «Уберов». Который дает скидку нам, ну пропагандирует чаще пользоваться, раздавать эти промо-коды, бесплатные поездки. Но эта бесплатная поездка, ее надо закладывать в стоимость для вас, для Marketplace. Мы честно тоже используем поощрение в виде денежных бонусов на следующую поездку. И мы стараемся этот хвост, вот этих бонусных денег закладывать как бы в модель, собственно говоря, даже не как он часто возвращается, а именно сколько денег еще он может нам принести, поэтому у нас там есть определенное ограничение на использование этих бонусных денег, потому что мы бы, он бы приходил, приходил, а денег бы дополнительно не зарабатывали.
И.П.: Можно я добавлю на секунду. Просто еще есть такая проблема возвратных пользователей, это не только по Marketplace. Очень часто считают возвратных пользователей – это просто клиент к нам пришел купил, вернулся пришел купил, вернулся пришел купил, а путь пользователя не смотрят. Вот это я недавно столкнулся с одним проектом. Они говорят, вот у нас пользователи замечательные, он за три месяца сделал три покупки. А потом они посмотрели, оказались все три покупки с «Яндекс.Директа» с ключевых слов. То есть считайте возвратных пользователей, тех пользователей, которых вы в первый раз удовлетворили очень хорошо, ему понравилось, и он вернулся к вам. Прямой заход, брендовый, e-mail, то есть если он по ключевику «заказать газель» кликнул, а потом через полгода по ключевику «заказать автомобиль» кликнул, он как бы возвратный, но на самом деле вы как бы по факту два раза за него заплатили, не так вы и хороши, бренд, не запомнились вы ему, не обслужили. Окей, давай к следующему, ROI
А.К.: (07:10) Да-да. Здесь еще такой пример есть – это ретаргетинг.
И.П.: Да, да, да, согласен
А.К.: То есть не забывайте его еще считать. Из-за того, что пользователь у вас вернулся, надо понимать с ретаргетинга, ретагргетинг хорош, надо всегда отдавать должное, половина пользователей бы и так вернулась, если у вас настроены хоть какие-то e-mail уведомления да, без этого ретаргетинга. Поэтому ретаргетинг хорош, но его надо правильно считать, да, например, когда пользователь вернулся, надо еще заложить ретаргетинг и так накинуть два раза, потому что половина бы и так вернулась, без этого ретаргетинга. Еще ключевым проектом, таким вот есть момент один, который часто вот путают, ROI, внутренний ROI, ROI, ROI. На самом деле тут не столько там ROI, а доход по какой-то сделке, а вот правильно все-таки использовать ROI, то есть возврат на инвестиции, инвестиции, то есть там не рои конкретного человека, потому что сравнивать ROI особенно, когда вы работаете на масс-маркете разных групп пользователей с разных источников с разной моделью поведения, ну это не корректно
И.П.: Можно? Ну то есть, чтобы вы понимали. Глупо сравнивать ROI человека, которому нужно перевести шкаф в Сыктывкаре и человека, которому нужно перевезти самолет через всю Россию. Это не придуманные заказы, через нас как-то самолет реальный перевозили. Глупо сравнивать человека, которому нужно перевезти пять коров, и человека, который везет яхту из Москвы в Монако. Это разные истории.
А.К.: Да, да, это разные истории, приближаемся к вопросу сегментирования. Это все, все надо резать. Мы такую ошибку сами допускали в начале. Никаких усредненных данных, даже если эти усредненные данные есть, никогда не делайте выводы, на основании их, когда вы работаете на Marketplace. Это просто вообще вот, это запрет. Выводы будут неверные. Мы много раз это проверяли, никаких усредненных данных, всегда режем. Коротко заканчиваю, более такие понятные это средние собственно говоря ну Average Check, мы тут получается
И.П.: Execution — исполняемость
А.К.: Да, Execution — это исполняемость в нашем случае, то есть какой процент пользователей доводит сделку до конца и платит. Average Check – это получается повторяемся, доход с одного пользователя.
И.П.: Да, да
А.К.: Ну Average Check здесь это, ARPU это конкретно наш доход с одного пользователя, а Average Check – это здесь средний чек на перевозку, вот так мы у себя внутри проекта меряем, может быть кому-то тоже пригодится. И, собственно говоря, подробнее куда мы дальше поговорим, это качественные метрики внутри продукта. (09:37) Обязательно у вас на Marketplace, можно следующий слайд, Иван, переключить
И.П.: да, конечно
А.К.: Есть метрики, которые вы со временем определяете и понимаете, что от них зависит этот Retention Revenue, да, это исполняемость. Это очень тяжело, это боль, не всегда можно правильно их определить, можно всю жизнь прожить так и не определить их, просто наобум, что вот переносит на везет всем, какие
И.П.: вот у нас, какие есть. Чтобы вы понимали, у каждого Marketplace практически, в зависимости от каждого рынка вот эти метрики будут абсолютно свои. Мы сейчас расскажем, какие метрики есть внутри «Везет всем». Ну, наверно, с малой долей вероятности вы сможете их переложить к себе. Хотя, может и получится
А.К.: Да, да, здесь такой очень все кастомно, зависит от конкретного Marketplace, но подход один и тот же. Вот вы знаете, что должно влиять на исполняемость, тоне как, вы пытаетесь узнать сначала, что должно влиять на исполняемость. Потом из этих факторов, то есть производите факторный анализ. Из этих факторов пытаетесь создать какие-то искусственные метрики такие, производные метрики такие, которые будут исключительно внутри вашего проекта. Для, например, нашего Marketplace одни из таких метрик, то есть там с 20 метрик влияет на исполняемость, так, грубо говоря, даже. Эти метрики разнятся от категории, категории грузов
И.П.: И важность каждой метрики
А.К.: Да, еще важность
И.П.: То есть понимаете, у вас 20 метрик, у вас 10 категорий, и в каждой категории каждая отдельная метрика может иметь удельно разный вес на принятие решения заказчиком. Давай вот
А.К.: Такой вот кейс, мы особо не держим его в секрет, хотя поверьте, чтобы до него дойти, потребовалось уйма времени и денег. Ну, в принципе, он более-менее очевиден. Просто у нас есть его подтверждение. Есть заявки внутри города. Там важна скорость поступления ценовых предложений. А есть заявки по межгороду, и там важна экономия, которая возникает на ценах на эту заявку, то есть, когда внутри города нужна скорость, а когда она играет большую роль, там нужно много что, а когда она играет большую роль. А когда межгород, как бы важно лучшую цену дать, да, самую низкую по рынку, то есть вот пример, когда метрики разнятся, совершенно разные дают эффекты, и это все надо отслеживать. И когда вы это нашли, вам еще нужно создать инструмент, который будет все это отслеживать, собирать и желательно выводить в таком realtime режиме, чтобы вы успевали реагировать.
И.П.: (12:05) Окей, что мы делаем, если вот сходу у нас не получается, если мы… Дальше, следующие шаги, мои самые любимые.
А.К.: А сходу и не получится, ничего не получится сходу в Marketplace . вы начинаете резать. Каждый раз, когда вы пришли к какому-то умозаключению, скорее всего оно неправильно, и надо резать, резать, резать и получать подтверждение. Сейчас очень модно говорить разные модели атрибуции, пятое-десятое вот, и тут тоже вот сильно на это не останавливайтесь. Режьте внутри, режьте, режьте. Режьте. Поэтому если у вас Marketplace не срастается, не считается, не идет, начинайте его разрезать, где-то он идет и где-то он происходит. Мы сейчас на текущей стадии проекта очень сильно пытаемся резать, потому что мы как бы работаем по всей России, на самом деле мы режем сильно свой маркетинг внутри и концентрируемся на определенных точках, хотя остальное оно либо работает само, либо не работает. На все разрываться мы не можем. Как можно сегментировать? По географии: по городу, по межгороду, по регионам, по городам каким-то, по типу трафика, платный бесплатный, откуда он пришел, разное поведение людей, по типу клиентов там частные, коммерческие. По типу заказов, да, диван сильно отличается от перевозки коммерческого груза на 20 палет. По готовности клиента к покупке: есть люди, которые хотят просто узнать цену, а есть люди, которые уже готовы везти. У них разная модель поведения, у них разная готовность платить
И.П.: Ну вот самый такой большой кейс: у нас часто приходит человек и оставляет заявку на перевозку автомобиля. Но на самом деле, ему не надо везти этот автомобиль. Он хочет просто понять, сколько ему будет стоить купить автомобиль, он находится в Москве, а автомобиль в условном Пскове, сколько будет стоит доставить автомобиль из Пскова. Это плохой клиент? На самом деле, нет, потому что он все-таки потом, когда он купит автомобиль, он вернется, разместит повторную заявку и тогда уже поедет.
А.К.: (14:00) Да, и здесь вот кажется вроде, что все просто, надо одним дать цену, а другим дать возможность заказа, но приводит все к тому, что на практике это очень непросто. Мы сейчас тестируем эту модель, когда мы можем фильтровать пользователей по их готовности. И собственно говоря, еще кучу может быть вариантов по какому, как можно резать
И.П.: Единственное, что я хочу заметить, резать не так, что слой, слой, слой, а это у вас будет такая сеточка, да, нельзя просто порезать по географии. Вы должны порезать, у вас будет, представьте себе табличку в экселе, что у вас вот так вот идут столбики, и вот так вот идут столбики. И у вас один и то же, казалось бы, пользователь, который пришел с «Директа», который пришел по потребности в переезде, который внутри города Ростова-на-Дону, это могут быть два разных пользователя все равно, потому что одному из них нужен шкаф, а другому особняк, то есть готовьтесь к тому, что мыслить нужно будет не просто линейно, а вот такими кубами, если
А.К.: Ну да, да, можно
И.П.: Заказчик заказчику рознь, так сказать
А.К.: Да, и при этом, когда вы все разрезали там внутри все равно оказывается разное поведение, потому что когда вы работаете на масс-маркете таком большом, то есть если у вас Marketplace на узкоспециализированном рынке, считайте, вы счастливчик. Если вы работаете на масс-маркете, то здесь уже все усложняется как бы. И, собственно говоря, к чему мы сейчас пришли, идем, в проекте и уже внедряем это. Мы стараемся, даже когда мы всех порезали, поняли, от чего зависит исполняемость конкретного там заказа, мы все равно, вот он может не исполниться, можем неправильно предсказать. Мы сейчас стараемся предсказывать поведение пользователей, то есть мы знаем, мы сделали факторный анализ и вводим сейчас предиктивные модели, то есть условно мы каждые два часа анализируем заявку и меряем вероятность ее исполнения.
И.П.: (15:55) Можно на секундочку на шаг назад, просто вот для людей, как я, которые слабее в аналитике, то есть, что мы сделали? Мы знаем параметры заявки, мы знаем вес груза, откуда куда, мы знаем ценовые предложения наших перевозчиков, по какой-то два пришло, по какой-то 20. мы знаем экономию, то есть как отличается первое ценовое предложение от самого выгодного. И мы собрали огромный такой ряд факторов, в сумку такую, да, там их получается, ну безумное количество. Потом переложили на исторические данные, посмотрели какой фактор на что влияет, то есть что-то общее между очень похожими выигранными заявками, а если есть, то что, и как это сказывается, чтобы потом предсказывать. Это так называем, как раз что Леша говорит, предиктивная, ну или прогнозная модель.
А.К.: Да, да, то есть мы анализируем поведение пользователей и стараемся его корректировать по ходу пьесы нашей
И.П.: Например
А.К.: Потому что мы уже руками не можем все делать от увеличенного объема, а теперь как бы модель скоринговая обрабатывает заказчика, и мы например, знаем, что нашему операционисту службы поддержки необходимо просто сделать звонок клиенту, потому что клиент просто забыл уже. У него там и цены есть, и торги есть, все, клиент забыл, хотя перевозка горячая. Но клиент по каким-то причинам не получает от нас уведомление, еще что-то, у него там он там занят работой. Ему надо сделать один звонок, он принимает решение, все, заявка поехала, то есть как, но звонить по всем заявкам мы не можем, поэтому нам необходимо со временем приспосабливаться и точечно, точечно бить. И мы вот сейчас пробуем, внедряем, нельзя пока сказать, что это все стрельнуло, но упрощает жизнь, упрощает жизнь и позволяет масштабироваться дальше.
И.П.: (17:35) Да, то есть вообще в жизни это выглядит так: сидит человек из службы поддержки, и у него две заявки. По одной сказано, но это в идеале когда-нибудь в будущем, вот эта заявка едет, значит, он не дергается и надо звонить. А вот в этой заявке, судя по всему, не хватает чуть-чуть сбросить цену, потому что если чуть-чуть сбросить цену, то она поедет. И позвонить успокоить клиента, потому что это заявка, которая требует общения с человеком, чтобы он уверился, что мы действительно большой качественный Marketplace. Вот такой вот внутренний робот, значительно помогающий службе поддержки. Ну это вот предиктивные модели, переходим к инструментам. Как мы считаем, что мы делаем?
А.К.: Собственно говоря, что понятно. Теперь как мы делаем. Во-первых, метрики, как мы упоминали, у нас есть внешние и внутренние, продуктовые делятся на месячные, недельные, есть ежедневные, то есть Marketplace — это такая жизнь каждую секунду. И это надо контролировать. И для каждого временного промежутка мы используем свои инструменты соответственно. Плюс мы еще, у нас инструменты делятся по отделам: да, для маркетинга нужно одно, для службы поддержки другое, для разработчиков нужно третье, для аналитиков пятое, вот. И что очень важно? На данный момент мы не можем использовать сложные Enterprise решения, которые там стоят сотни тысяч долларов в год за подписку, да. Мы делаем такой микс. Мы делаем делаем свою разработку и делаем, берем открытые бесплатные инструменты, такие как «Яндекс.Метрика», GA (Google Analytics). И здесь один такой момент, который вот из практики вышел, обязательно должны быть дублирующие инструменты по сбору статистики, хранения и обработке, потому что все, что бесплатное, оно рано или поздно ломается, как-то не так считает, у нее есть расхождения, вы никому ничего предъявить не можете, потому что ну, оно ж бесплатное, что сделать.
И.П.: Как говорил Доктор Хаус: «Everybody lies».
А.К.: Да, а неправильные данные в Marketplace они приводят просто к неправильным решениям, и в итоге просто ничего никуда не едет, мы тоже прошли на своем опыте. Поэтому мы собираем, вот если переходить ближе к практике, мы собираем данные так, то есть первое - это сбор. Мы, естественно Google.Аналитика, «Яндекс.Метрика» все туда попадают. У нас есть так называемый стриминг. Мы еще все события на сайте, заходы пользователя, нажатия там кнопок, переходы, мы два стриминга делаем. Мы делаем стриминг себе в базу, то есть мы там по специальным кукинг мэтчингу собираем пользователей, скидываем себе в базу. Сразу предупрежу, с масштабированием проекта это превращается в многомиллионные, миллиардные таблиц и строк, которые надо иметь мощности обрабатывать. И еще мы сейчас тестируем в принципе довольные решения по стримингу OWOX, но OWOX стримит данные Google.Аналитики, то есть как работает Google.Аналитика, также будет работать OWOX. Не всегда устраивает, как собирает данные Google Аналитика, поэтому наше решение, там мы уже по своему собираем, но тем не менее, у нас есть 4 инструмента по сбору данных, которые мы параллельно все ведем, потому что мы видим обязательно какое-то расхождение, где-то что-то падает и пятое, десятое. Храним мы, где это все хранить? Храним мы в Google BigQuery. Очень удобный инструмент, всем советую. У него есть свои ограничения, ну зато он недорогой, позволяет легко масштабироваться. И плюс у нас есть своя БД, но честно, нам уже своей БД под наш размер
И.П.: База данных в смысле
А.К.: (20:57) База данных, да. Начинает не хватать на обработку, хранение, то есть хранить можем, а обрабатывать уже тяжеловато. И необходимо к каким-то технологиям хадуп переходить. Считаем и выводим результат, да. Соответственно, собрали, храните, а теперь это как-то надо вывести. Притом
И.П.: Чтобы было понятно всем, да, то есть это должно быть что-то настолько понятное, что даже человек, который пришел в службу поддержки, вторую неделю у нас сидит на телефоне, мы показываем какие-то данные и он может самостоятельно из них сделать вывод.
А.К.: Да, да, да. И здесь, ну здесь еще, кому их показываем, да то есть для ежедневных сделок, чуть назад. Для ежедневных, для еженедельных метрик мы вот там используем Pentaho, это такой инструмент. Инструмент от компании Toshiba, который вышел из внутренних разработок. Инструмент, есть бесплатная версия, есть платная версия там, ну мы там по определенным причинам используем платную версию, вот. Он такой, знаете, олдскульный Enterprise-кий, как вот в лучших таких западных тенденциях, вот. Но он, он понятно он позволяет делать алаб кубы, обрабатывать их, выводить. С выводом там у него есть проблемы, но принципе нам хватает, у него много есть аналогов, но вот мы почему-то остановились на нем. При этом мы еще используем связку Big Query SpreadSheet. Есть много отдонов, которые позволяют в Google Big Query подсоединить Google SpreadSheet, и импортировать данные в Google SpreadSheet. В том числе, такой отдон есть у OWOX, ну либо вы можете сами его написать и Google SpreadSheet использовать как один из вариантов Dashboard, то есть это Excell, в котором вы можете построить графики, то есть мы это тоже применяем особенно к месячным метрикам. И третье, мы дальше покажем скриншоты — это Grafana, есть у нее еще платный аналог табло, это инструмент такой Dashboard, который позволяет, на самом деле аналогов даже много, но просто самые известные. Это инструмент, который позволяет
И.П.: (22:51) Держать руку на пульсе, что происходит с твоим продуктом именно сейчас, то есть именно вся внутренняя продуктовая аналитика выводится. Так дальше покажем скриншоты. Ну, будем здесь заострять?
А.К.: Собственно говоря, что еще мы делаем? Это GA, при этом это расширенная екомерс, мы все советуем, что нужно читать справку по Google.Аналитике, использовать расширенную екоммерцию, хотя она сделана для интернет магазинов, но мы, вы легко ее можете легко перекроить под свой Marketplace. То есть у нас бренды — это перевозчики, у нас заказы, как бы покупки — это сделки на перевозку, то есть мы просто пронесли такие аналогии, и у нас такой хороший кейс, когда мы стандартные инструменты GA, то есть зачем было что-то делать свое, когда они все сделали, использовать в рамках своего Marketplace. При это GA позволяет хорошо вытаскивать аудитории, которые потому нужно делать луклайк аудитории, ретаргетинг, всякое пятое, десятое. «Яндекс.Метрика» старается успеть за GA, она более понятна маркетологам, вот они любят «Яндекс.Метрику». Еще для маркетологов мы используем Roistat. Тоже такой проект
И.П.: Сквозная модель
А.К.: На начальной стадии, на начальной стадии, мы советуем его использовать в своем Marketplace. Он хорошо, удобен, прост, понятен. Дальше начинаются особенности, специфики, его начинает не хватать и пятое десятое. А так, ребята молодцы. Собственно говоря, это вот пример вы видите каких-то метрик, ну это даже не ежесекундные метрики, это еженедельные метрики, которые вы видите по пример Dashboard, которые вы используете в Grafana. И счетчик покажи тоже, вот все метрики видно, понятно, рост, можно какие-то корреляции проводить здесь, что от чего зависит. То есть мы меряем здесь конкретно заказы по типам географии, да. Четко, понятно все. Есть у нас еще другие Dashboard, просто с большими классными цифрами. Ну это пример, как данные с Google BigQuery были импортированы в Google SpreadSheet. И сделаны понятные, хорошие графики. У всего этого есть определенные особенности технические по интеграции, но вот без этого всего никуда. В принципе, если что-то будет интересно более подробно рассказать про эту связку аналитики, мы, возможно, расскажем ее.
И.П.: (25:03) Да, есть кстати, отличное замечание от Алексея, если есть какие-то вопросы в принципе о Marketplace, либо еще лучше, если вы сами строите Marketplace, есть чем поделиться, ищите единомышленников, чтобы обсудить, найти решение каких-то проблем, на сайте Vezetvsem.ru, там по-моему везде есть наши контакты, либо пишите нам на e-mail: i.plastun@vezetvsem.ru, а у Алексея попроще: a.kozlov@vezetvsem.ru. Окей, наш третий мастер-класс заканчивается, мы показали, что такое продуктовая аналитика внутри Marketplace, рассказали, чем мы пользуемся. Алексей рассказал всю эту связку, как мы собираем данные, почему мы не можем верить одному источнику, как мы их показываем различным отделам, чтобы они все были понятны. Это действительно гигантская работа, которая позволит вам понять продукт и сделает ваш бизнес прозрачным, прежде всего для вас самого. Спасибо, еще увидимся!
А.К.: Пока