Connect with us

A/B тестирование

Сохранение намерений: почему A/B-тесты не так эффективны, как кажутся

Эндрю Чен, один из самых знаменитых экспертов по росту продуктов, рассказывает о консервации намерений и том, почему не всегда стоит полагаться на результаты A/B-экспериментов.

AppTractor

Опубликовано

/

     
     

Когда +10% на самом не +10%

Давайте попробуем понять этот занятный стартап-опыт. Вы проводите эксперимент, и он дает вам +10% в вашей воронке конверсии. Ваши доходы, установки, что-либо еще должны увеличиться на 10%, верно?

Неверно.

Обычно ваши ключевые метрики увеличиваются совсем немного, а может и вовсе не вырастают.

Почему так? Давайте назовем это «Сохранением намерений».

Разница между пользователями с высоким и низким уровнем намерений

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

Вот почему вы не можете добиться значительного улучшения с помощью A/B-тестов

Если вы работаете в компании, которая A/B-тестирует все, а затем объявляет о превосходных результатах – это, конечно, замечательно, но просто мысленно просуммируйте результаты всех этих A/B-тестов. А затем посмотрите на ваши ключевые показатели. Редко они коррелируют.

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

Относитесь скептически к внутренним тестам и внешним кейсам

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

Точно также скептически относитесь к сторонним компаниям, которых обещают увеличить ваш доход в X раз только за счет увеличения конверсии в рекламных объявлениях (или в чем-то еще). В этих вводящих в заблуждение тематических кейсах – которые часто представляют на конференциях – компании могут не только выбрать лучшие примеры, подчеркивающие их успех, но и метрики, на которые они оказали наибольшее влияние! Подходите осторожно к этому и не обманывайтесь.

Проследите рост до конечного показателя

Во-первых, поймите, что действительно блокирует ваших пользователей с высоким уровнем намерений. Это те, кто хотел бы пройти весь путь в воронке, но по каким-либо причинам не может этого сделать. Для Uber это были способы оплаты, качество приложения (особенно для Android!), восстановление забытого пароля и т.д. Если вы не можете оплатить поездку или не можете вернуться в свою учетную запись, то даже если вы используете приложение каждый день, вы можете переключиться на другое приложение, которое доставляет меньше неприятностей.

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

Убедитесь, что ваш роадмап отражает реальность

Когда дело доходит до вашей продуктовой дорожной карты, то вы, конечно, можете провести мозговой штурм и найти кучу +10%, но вам нужно добавить коэффициент дисконтирования в таблицы, чтобы отразить реальное положение дел. Нельзя это просто транслировать на все результаты.

Когда вы сосредотачиваетесь на людях с низким уровнем намерений, вам нужно проявить творческий подход, чтобы они смогли сформулировать свои намерения. Такие вещи, как возможность попробовать продукт, завести друзей в нем – это все шаги «активации», которые генерируют намерение. Вот отличное место для начала – очень релевантная статья о том, как получить больше внимания пользователей от команды роста Dropbox.

Сохранение намерений

Многие из вас уже сталкивались с «сохранением намерений», но теперь у вас есть название для этого!

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

Почему сосредоточение на привлечении пользователей убьет ваш мобильный стартап №1

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

A/B тестирование

Apple открыла возможность менять скриншоты в Search Ads

Вечером 29 мая Apple обновила интерфейс создания и редактирования кампании Search Ads, в который была добавлена опция выбора скриншотов, которые будут показываться в этой кампании.

AppTractor

Опубликовано

/

Автор:

Как пишет AppFollow, теперь для каждой кампании вы можете создать разные наборы креативов, которые будут показываться в объявлении.

Таким образом можно протестировать различные варианты скриншотов, и их конверсию у разных групп пользователей. Единственное ограничение — порядок скриншотов, он останется таким же, как на странице приложения. Apple дополнительно поясняет: если у вас есть набор скриншотов ABCD, возможные комбинации будут ABC, ABD, ACD, BCD, но не CBA. К примеру, можно загрузить альбомные и портретные скриншоты и протестировать, какие из них лучше всего конвертят в установку.

Таким образом, добавив новые скриншоты для своего приложения, можно сделать A/B-тест, создав несколько наборов креативов в рамках одной кампании, к примеру протестировать два варианта скриншотов, загрузив 10 изображений, по пять для каждого варианта.

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

Комментарии
Продолжить чтение

A/B тестирование

A/B-тестирование в Firebase: часть 2

Продолжаем изучать Remote Config и A/B-тестирование в Firebase и учимся делать ваших пользователей самыми счастливыми!

AppTractor

Опубликовано

/

Автор:

Расширенный пользовательский таргетинг

Давайте изменим механизмы, чтобы понять, что еще мы можем сделать с Firebase Remote Config вне A/B-теста.

В предыдущем уроке вы избежали международного кризиса, установив shouldWeIncludePluto в true для ваших пользователей в Скандинавии. Оказывается, однако, что такой настройки на основе страны недостаточны. Выбор того, планета ли Плутон, является глубоко личным, и многие люди со всего мира хорошо относятся к планетному статусу Плутона. Как мы можем настроить Planet Tour для всех?

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

Свойства пользователя в Google Analytics

Свойство пользователя в Google Analytics для Firebase – это просто свойство, связанное с конкретным пользователем.

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

В вашем случае вы будете использовать свойство likeSmallRocks, чтобы понять то, как пользователь относится к небольшим, холодным скалам на окраинах нашей солнечной системы. Затем вы будете использовать это свойство в сочетании с Remote Config, чтобы предоставить пользователям новый опыт на основе этого значения.

Хотя существуют разные способы определить, является ли пользователь поклонником маленьких отдаленных скальных пород, проще всего просто спросить их.

В верхней части PlanetsCollectionViewController.swift добавьте эту строку:

import Firebase

Затем добавьте следующее определение reuseIdentifier:

private let takenSurveyKey = "takenSurvey"

Наконец, добавьте следующее внутри расширения с помощью MARK: – Internal, прямо над функцией addFancyBackground ().

@objc func runUserSurvey() {
  let alertController = UIAlertController(title: "User survey",
    message: "How do you feel about small, remote, cold rocks in space?",
    preferredStyle: .actionSheet)

  let fanOfPluto = UIAlertAction(title: "They're planets, too!", style: .default) { _ in
      Analytics.setUserProperty("true", forName: "likesSmallRocks")
  }

  let notAFan = UIAlertAction(title: "Not worth my time", style: .default) { _ in
      Analytics.setUserProperty("false", forName: "likesSmallRocks")
  }

  alertController.addAction(fanOfPluto)
  alertController.addAction(notAFan)
  navigationController?.present(alertController, animated: true)

  UserDefaults.standard.set(true, forKey: takenSurveyKey)
}

Нужно отметить две вещи в опросе, который вы добавили – во-первых, после того, как вы получите ответ от пользователя, вы записываете его в новое свойство пользователя likesSmallRocks. Во-вторых, вы делаете заметку в UserDefaults этого пользователя, который уже принял участие в опросе, чтобы его не спрашивать каждый раз при посещении приложения.

Теперь, когда вы определили свое свойство пользователя в коде, вам необходимо выполнить второй шаг, который позволяет консоли Firebase знать, что это свойство существует, чтобы оно могло начать создавать отчеты на его основе. Лучше всего добавлять user property в консоль Firebase одновременно с добавлением ее в код. Откройте консоль Firebase и выберите «Google Analytics», затем «User Properties» .

Теперь будьте осторожны в следующем шаге – консоль Firebase не позволяет редактировать или удалять свойства пользователя после их создания! Выберите NEW USER PROPERTY и создайте новую запись, которая называется likeSmallRocks. Я рекомендую копировать и вставлять имя, чтобы убедиться, что оно точно соответствует. Дайте ему любое описание, которое вы хотели бы. Затем нажмите CREATE.

Вернитесь в PlanetsCollectionViewController.swift и в конце viewDidAppear(_:) и добавьте эти строки, чтобы убедиться, что вы запрашиваете это только один раз при установке приложения:

if !UserDefaults.standard.bool(forKey: takenSurveyKey) {
  runUserSurvey()
}

Если вы хотите немного упростить тестирование, добавьте этот код viewWillAppear(_:) выше customizeNavigationBar(), который добавит кнопку на панель навигации, чтобы запустить опрос в любое время, минуя проверку того, что вы уже видели это:

let retakeSurveyButton = UIBarButtonItem(barButtonSystemItem: .compose,
                                         target: self,
                                         action: #selector(runUserSurvey))
parent?.navigationItem.rightBarButtonItem = retakeSurveyButton

Создайте и запустите приложение. Теперь вас спросят, как вы относитесь к маленьким скалам в космосе. Не стесняйтесь и честно ответьте.

Настройка вашего приложения

Теперь вы можете начать настройку Remote Config на основе этого значения. Откройте консоль Firebase и выберите Remote Config. Если вы закончили предыдущий туториал, вы увидите свою запись для shouldWeIncludePluto. И если вы этого не сделали, создайте ее заново.

Если вам нужно создать, сначала нажмите «ADD YOUR FIRST PARAMETER». Затем введите значение параметра shouldWeIncludePluto для Parameter key и сохраните значение по умолчанию пустым (Default value). Затем нажмите ADD PARAMETER.

Нажмите значок карандаша рядом с надписью shouldWeIncludePluto, чтобы изменить его, затем выберите Add value for condition > Define new condition. Назовите новое условие «Small rock fans» и укажите это условие, если User property > likesSmallRocks | exactly matches | true.

Примечание. Не выбирайте оператор сравнения == в этом диалоговом окне – это используется только для чисел.

Нажмите CREATE CONDITION, затем установите для этого значения значение true и значение по умолчанию – false .

Примечание. Если вы не выполнили предыдущий туториал, то здесь не будет состояния «Pluto fans». Ничего страшного!

Нажмите UPDATE, затем PUBLISH CHANGES.

Теперь создайте и запустите приложение снова.

Если вы указали, что являетесь фанатом маленьких отдаленных планет, то теперь вы должны увидеть Плутон среди списка планет. Если вы этого не сделали, вы не увидите Плутон… если ваше устройство не думает, что оно находится в скандинавской стране, и в этом случае Плутон все еще там (при условии, что вы прошли предыдущий туториал и установили это условие).

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

Как насчет внесения некоторых более тонких изменений в призыв к действию для ваших поклонников Плутона? В вашем приложении есть переменная planetImageScaleFactor,  которая определяет, насколько близко размер изображений планеты соответствует фактическому размеру соответствующей планеты.

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

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

Вернитесь в Remote Config в консоли Firebase и создайте новую запись для planetImageScaleFactor. Дайте ему значение 0,2 для пользователей в состоянии «Small rock fans» и значение по умолчанию 0,45. Нажмите UPDATE, затем PUBLISH CHANGES.

Снова запустите Planet Tour. В зависимости от того, как вы относитесь к маленьким скалам, планеты, такие как Марс или Плутон, должны выглядеть пропорционально больше или меньше.

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

И вы можете выполнить некоторые A/B-тесты с этими параметрами, чтобы узнать, что делает пользователей вашего приложения самыми счастливыми!

Комментарии
Продолжить чтение

A/B тестирование

A/B-тестирование в Firebase: часть 1

Предлагаем вам руководство по A/B-тестированию в Firebase от Raywenderlich.com – из него вы узнаете, как проводить эксперименты и как оценивать результаты.

AppTractor

Опубликовано

/

Автор:

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

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

В Firebase Remote Config Tutorial для iOS мы показали вам, как использовать Remote Config для обновления определенных частей вашего приложения на лету и доставлять кастомизированный контент пользователям в разных странах.

В этом туториале мы рассмотрим, как использовать Firebase Remote Config для проведения A/B- тестирования, экспериментируя с разными значениями и просматривая результаты, чтобы узнать, какие параметры работают лучше всего. Мы рассмотрим это на примере и расскажем, как выполнить еще более расширенную настройку на основе свойств пользователя.

Начинаем

Загрузите приложение Planet Tour 2 Starter. Даже если у вас есть проект из предыдущего руководства по удаленной настройке, лучше начать с нового проекта, поскольку он был обновлен для iOS 11, Swift 4 и Firebase 4. Необходимые библиотеки, в CocoaPods, включены в него.

Откройте проект в Xcode, не забудьте открыть файл .xcworkspace вместо файла .xcodeproj.

Вам нужно будет создать проект Firebase для приложения и загрузить из консоли файл GoogleServices-info.plist, который вы можете создать, выполнив следующие действия:

  1. Перейдите на страницу console.firebase.google.com.
  2. Нажмите на Add project.
  3. Назовите свой проект Planet Tour, убедитесь, что ваш регион выбран, затем нажмите CREATE PROJECT .
  4. Нажмите “Add Firebase to your iOS app”.
  5. Добавьте идентификатор пакета вашего проекта (com.razeware.Planet-Tour), дайте ему забавный псевдоним, оставьте поле  App Store ID пустым, затем нажмите «REGISTER APP»
  6. На этом этапе ваш браузер позволит вам загрузить файл GoogleServices-info.plist.
  7. Откройте Planet Tour.xcworkspace в Xcode и перетащите этот файл в проект Planet Tour (выберите «Copy Items if Needed»).
  8. Затем вы можете просто нажать «CONTINUE» в следующих нескольких шагах мастера настройки. Мы уже сделали это для вас.

Соберите и запустите приложение; вы должны увидеть прекрасное путешествие по нашей солнечной системе. Нажмите на несколько планет, чтобы увидеть подробности о них.

Если вы новичок, просмотрите RCValues.swift, чтобы понять, как мы используем Remote Config в проекте. Затем вернитесь на главный экран и проверьте баннер внизу, где приложение просит вас подписаться на рассылку новостей.

Введение в A/B-тестирование на iOS

Руководители Planet Tour, Inc. обеспокоены тем, что людей, подписавшихся на рассылку Planet Tour, недостаточно. В конце концов, как вы можете построить успешный бизнес, если вы не можете отправлять сообщения о новых интересных турах по планетам?

У маркетологов есть теория. Вы можете увеличить число подписчиков, если измените ярлык кнопки «Subscribe» на «Continue». Пока вы этим еще занимаетесь, возможно, вам стоит попробовать изменить и текст баннера с Get our newsletter на Get more facts.

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

Ну, все не так очевидно. Как вы узнаете, какие изменения непосредственно ответственны за результаты, которые вы получили? Что произойдет, если какой-нибудь влиятельный блогер упомянет вашу рассылку в своем последнем посте? Или вы в конечном итоге запустите рекламную кампанию в другом приложении, тем самым привлекая аудиторию, более склонную в первую очередь как раз к подписке на такие информационные материалы?

Это факторы, которые вы не можете контролировать, и они могут привести вас к неправильным выводам.

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

Это именно то, что делает A/B-тестирование, и это очень распространенный способ выполнения таких экспериментов. Многие крупные компании создали собственную инфраструктуру для запуска и измерения этих тестов, но с помощью Firebase Remote Config вы можете сделать это поверх инфраструктуры Firebase, которая уже создана для вас.

Добавление Google Analytics в приложение

Одним из основных шагов при создании A/B-теста является указание Firebase на цель вашего эксперимента. Иногда это может быть задача высокого уровня, такая как увеличение удержания (retention) (сколько из ваших пользователей возвращается через несколько дней) или вовлечение пользователей (user engagement) (сколько времени ваши пользователи тратят на приложение каждый день). Но в других случаях это может быть очень конкретная цель, например, увеличение количества пользователей, посещающих ваш магазин или, в нашем случае, увеличение числа пользователей, которые подписываются на рассылку Planet Tour.

Разумеется, единственный способ, с помощью которого Firebase узнает, подписался ли ваш пользователь на рассылку – если вы расскажете об этом, и это то, что вы можете сделать, используя Google Analytics для Firebase (продукт, ранее известный как Firebase Analytics). Если вы не знакомы с концепцией мобильной аналитики, здесь есть большой учебник по этой теме.

Поэтому прежде, чем вы начнете создавать A/B-тест в своем приложении, добавим некоторую аналитику в ваше приложение, чтобы у вас было несколько целей, над которыми вы можете начать работать.

Добавление событий

Google Analytics для Firebase, как и большинство других решений для мобильной аналитики, представляет собой модель, основанную на событиях. Когда пользователи выполняют действия в вашем приложении, Google Analytics отправляет события на свои сервера. Спустя некоторое время они обрабатывают эти события и превращают их в осмысленные графики.

Откройте ContainerViewController.swift. Добавьте в верхнюю часть файла следующее:

import Firebase

Затем добавьте следующее в конец viewDidLoad():

Analytics.logEvent("mainPageLoaded", parameters: nil)

Это отправит событие с именем mainPageLoaded, когда ваш пользователь впервые запустит приложение и переместится на главный экран. Аргумент parameters – это словарь дополнительных пар ключ/значение, связанных с этим событием. Вам здесь они не нужны, так что это осталось nil.

Затем откройте GetNewsletterViewController.swift. Добавьте в верхнюю часть файла следующее:

import Firebase

Добавьте в конец viewDidLoad () следующее:

Analytics.logEvent("newsletterPageLoaded", parameters: nil)

Наконец, добавьте следующее в конец submitButtonWasPressed (_ :):

Analytics.logEvent("newsletterSubscribed", parameters: nil)

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

Прежде, чем запускать приложение, вам нужно включить режим отладки Firebase Analytics, который позволит вам увидеть результаты всех этих вызовов аналитики в консоли.

Для этого выберите Product\Scheme\Edit Scheme. В схеме Run выберите Arguments. Внутри Arguments Passed On Launch, щелкните символ «+» и введите аргумент -FIRAnalyticsDebugEnabled. Убедитесь, что вы включили тире в начале.

Когда вы закончите, у вас должно получиться следующее:

Закройте диалоговое окно, соберите и запустите проект. В консоли будет намного больше выходных данных. Вы должны увидеть записи, похожие на следующие:

[Firebase/Analytics][I-ACS023051] Logging event: origin, name, params: app, mainPageLoaded, {
    firebase_event_origin (_o) = app;
    firebase_screen_class (_sc) = WaitingViewController;
    firebase_screen_id (_si) = -5666061486001356881;
}

Когда вы нажмете Get our newsletter или Get more facts, это также будет занесено в вашу консоль:

[Firebase/Analytics][I-ACS023051] Logging event: origin, name, params: app, newsletterPageLoaded, {
    firebase_event_origin (_o) = app;
    firebase_screen_class (_sc) = ContainerViewController;
    firebase_screen_id (_si) = 8191694734847900543;
}

Аналогичное событие будет зарегистрировано при нажатии кнопки Subscribe.

Вы также почти в реальном времени можете увидеть, как эти результаты поступают в Firebase, перейдя в раздел DebugView консоли Firebase. Это позволит вам узнать о любых событиях, которые Firebase получает от устройств, на которых включен режим отладки.

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

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

На данный момент для событий, которые вы создали для A/B-тестирования, требуется около 24 часов для попадания в систему. Вы все равно можете продолжить изучение этого туториала, не ожидая так долго; просто имейте в виду, что вам может понадобиться выбрать другую цель, чем эти события.

Создание первого A/B-теста

Зайдем в секцию Remote Config консоли Firebase. Если вам предлагается выбрать проект, выберите проект Planet Tour, который вы создали.

Вместо создания нового параметра в этот момент щелкните вкладку A/B Testing в правой части страницы. Затем нажмите кнопку CREATE EXPERIMENT на появившейся панели.

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

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

Поскольку вы экспериментируете с текстовыми полями, вероятно, имеет смысл ограничить ваш эксперимент англоязычными пользователями. Нажмите кнопку AND, выберите Device language, а затем выберите English из второго раскрывающегося списка.

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

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

Когда все закончится, первая часть панели эксперимента должна выглядеть так.

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

Начнем с рассмотрения различных вариантов текста, который появляется в маленьком баннере внизу основного экрана. Это значение задается переменной в Remote Config subscribeBannerButton.

Нажмите ADD PARAMETER. Если вы использовали это приложение в предыдущем туториале Remote Config, вы, вероятно, увидите имена этих параметров в раскрывающемся списке, но вам не нужно их использовать; вы можете создавать новые! Поэтому введите subscribeBannerButton и выберите параметр Create parameter.

Теперь у вас есть возможность добавить разные значения subscribeBannerButton для разных вариантов эксперимента.

Для вашей контрольной группы оставьте значение по умолчанию (no value). Это даст возможность Remote Config использовать такое значение, как если бы пользователь не был в вашем эксперименте. В вашем случае это будет значение по умолчанию «Get our newsletter!», как указано в RCValues.swift. Как правило, лучше, если вы сохраните значения своих контрольных групп (no value) – это лучший способ сравнить ваши изменения с тем, что в настоящее время работает в вашем приложении.

Для следующего варианта задайте значение subscribeBannerButton строкой Get more facts!

Теперь ваша панель должна выглядеть примерно так.

Вы также можете поэкспериментировать с кнопкой, которая появляется в вашем GetNewsletterViewController – это параметр под названием subscribeVCButton. Нажмите ссылку ADD PARAMETER и создайте новый параметр с этим именем.

Вы можете внести это изменение в вариант A …

… но это оставляет вам проблему. Предположим, вы узнали, что вариант А лучше, чем ваша контрольная группа. Как бы вы узнали, произошли ли изменения из-за «Get more facts!» на главной странице или потому, что вы переименовали кнопку «Subscribe» на «Continue»? Вы этого никак не узнаете. По сути, всегда есть шанс, что Вариант А был бы еще лучше, если бы вы не изменили кнопку «Subscribe» .

Таким образом, лучшим вариантом было бы попробовать все различные комбинации в нескольких разных вариантах – это метод называется многовариантным тестированием и теперь вы должны запустить его простую версию. Оставьте subscribeVCButton установленным (no value) в варианте A.

Нажмите кнопку Add Variant, и на этот раз оставьте subscribeBannerButton установленным по умолчанию и дайте subscribeVCButton значение Continue. Затем нажмите «Add Variant» еще раз, задайте subscribeBannerButton значение «Get more facts!» и subscribeVCButton значение Continue.

Теперь панель эксперимента должна выглядеть так:

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

Предполагая, что прошло достаточно времени, события, которые вы создали в предыдущем разделе, попали в систему A/B-тестирования и в раскрывающемся списке вы должны увидеть новостную рассылку, указанную в качестве одной из ваших целей. Если она есть, выберите ее. Если ее еще нет, вам может потребоваться день или два, чтобы события распространились по системе. Если вам не хочется долго ждать, не стесняйтесь выбирать другую цель, например, удержание (День 1).

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

Вы закончили создание своего эксперимента! Нажмите REVIEW.

Тестирование вашего эксперимента

Вероятно, вы захотите протестировать свой эксперимент, прежде чем показать его миру. К счастью, Firebase позволяет легко протестировать все варианты экспериментов на одном устройстве. Для этого вам понадобится Instance ID токен, который является уникальным идентификатором, назначенным каждой копии вашего приложения.

Чтобы получить его, вернитесь в Planet Tour и откройте AppDelegate.swift. Затем добавьте следующее после вызова FirebaseApp.configure():

let idToken = InstanceID.instanceID().token()
print ("Your instance ID token is \(idToken ?? "n/a")")

Создайте и запустите приложение. Вы должны увидеть строку, как показано ниже, в консоли Xcode.

Если вы получаете n/a в ID, подождите несколько секунд и повторите попытку (извлечение токена является асинхронным. Я упрощаю процесс, предполагая, что ваше приложение уже загружено и кэширует один из этих токенов в предыдущем сеансе).

Вернитесь к своему эксперименту в Firebase Console и разверните раздел Details вашего эксперимента. Затем нажмите Manage test devices. В появившемся диалоговом окне скопируйте и вставьте строку с токеном идентификатора из консоли Xcode. Затем выберите вариант из раскрывающегося списка – мне нравится попробовать вариант C, потому что вы можете сразу проверить свои изменения.

Кликните ADD. Затем SAVE.

Закройте и перезапустите приложение. Поскольку ваше приложение имеет время кэширования Remote Config равное нулю, вы должны сразу увидеть свои новые значения.

Не стесняйтесь попробовать и другие варианты. Просто перейдите в диалоговое окно Manage test devices, выберите другой вариант из раскрывающегося списка, нажмите SAVE, и на вашем тестовом устройстве увидите другой вариант.

Запуск эксперимента

Когда вы проверили все ваши варианты и остались довольны тем, как каждый выглядит на ваших тестовых устройствах, вы можете начать эксперимент по-настоящему. Вернитесь в тестовую консоль Firebase, нажмите кнопку START EXPERIMENT, а затем нажмите START.

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

Понимание результатов вашего эксперимента

A/B-тестирование в Firebase не просто говорит вам, какой вариант имел самый высокий выхлоп в виде «пользователей, подписавшихся на рассылку». Оно также использует причудливую математику, известную как байесовская статистика, чтобы вы знали, вызваны ли эти различия изменениями, внесенными вами в приложение, или являются просто случайными. Это то, что мы обозначаем фразой «статистически значимый».

Чтобы эта математика работала, Firebase нужно попробовать эти разные варианты на довольно большом количестве пользователей. И хотя Planet Tour – прекрасное приложение, это все еще тестовое приложение с одним пользователем. Это означает, что для этого урока A/B-тестирование не сможет собрать достаточное количество данных, чтобы дать вам какие-либо значимые результаты, и вам, вероятно, останется экран, который выглядит следующим образом:

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

Здесь много статистики, но давайте рассмотрим самую важную.

Эта гигантская надпись сверху дает вам краткую сводку эксперимента. В данном случае она говорит вам, что вариант B является самым эффективным для достижения основной цели – подписки пользователей на вашу рассылку.

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

Например, вы можете видеть, что по результатам теста вариант А будет на 4% хуже или на 14% лучше, чем контрольная группа для событий newsletterSubscribed. Поскольку это довольно широкий диапазон, система не может точно сказать, что это изменение к лучшему, поэтому оно представлено в светло-сером цвете.

Прогнозируется, что вариант B будет на 10% или 29% лучше, чем контрольная группа: на столько процентов вырастут ваши шансы на то, что люди подпишутся на вашу рассылку. Так как это определенно изменение к лучшему, оно представлено в зеленом цвете со стрелкой вверх.

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

Два столбца справа – “сырые” данные эксперимента. На них, как правило, интересно смотреть, но я не получаю от них ничего стоящего.

Развертывание эксперимента

В зависимости от результатов вашего эксперимента вы можете захотеть применить один из своих вариантов и опубликовать его для мира. Если у вашего эксперимента есть явный победитель, вы должны увидеть кнопку «ROLL OUT THE LEADER».

Нажатие этой кнопки остановит эксперимент и откроет вам диалог, позволяющий публиковать все переменные из варианта победителя в Remote Config в качестве новых значений по умолчанию для всех. И так ваши новые варианты рассылки станут доступны миру!

Комментарии
Продолжить чтение

A/B тестирование

Подводные камни A/B-тестирования в социальных сетях

A/B-тестирование – это простая концепция, но его может быть сложно проводить, если у вашего продукта есть социальные взаимодействия. Благодаря им и эффектам высшего порядка, стандартный подход к тестированию может быть неверным.

Анна Гуляева

Опубликовано

/

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

В OkCupid меня часто просят провести A/B тесты для измерения влияния новой функции или изменения в дизайне на наших пользователей. Обычно A/B тестирование проводится так: пользователи случайным образом делятся на две группы, каждая из которых получает разную версию продукта, а затем исследуются различия в поведении этих групп.

В типичном A/B тесте вариант случайно выбирается для каждого отдельно взятого пользователя. Например, если мы меняем дизайн нашей страницы входа в систему, половина пользователей увидит новую страницу (тестовая группа), а половина – старую (контрольная группа). Такое распределение – это простой и мощный способ протестировать изменение пользовательского поведения при помощи новой функции.

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

Почему распределение пользователей может стать неудачным

Вся суть OkCupid заключается в общении пользователей друг с другом, поэтому мы часто хотим тестировать функции, созданные для того, чтобы сделать взаимодействие пользователей проще или интереснее. Однако запускать A/B тест для функций общения сложно на основании случайного распределения пользователей.

Приведу пример: допустим, мы создали функцию видеочата и до запуска хотим протестировать, нравится ли она людям. Я могу провести A/B-тест и случайным образом распределить эту функцию на половину пользователей… но с кем они будут общаться через эту функцию?

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

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

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

  • они могут не заинтересоваться неготовой функцией (“Я проигнорирую её на стадии тестирования”)
  • наоборот, они могут полюбить функцию (“Хочу общаться только по видео”), что усложнит контакт между контрольной и тестовой группами – тестовая группа ограничит себя маленькой частью сайта, а у контрольной группы будет масса неотвеченных сообщений.

Любой расклад приведет к предвзятым и неточным результатам эксперимента.

Эффекты высшего порядка

Другое ограничение подобного распределения – это то, что вы не можете измерить “эффекты высшего порядка” (также известные как сетевые эффекты или внешние эффекты). Они происходят, когда новая функция выходит за пределы тестовой группы и влияет на поведение в контрольной группе.

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

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

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

В этом случае эффект разлива замаскирует реальное изменение пользовательского поведения, потому что улучшение отражается и на контрольной группе. Эти эффекты также могут создавать иллюзию изменения, которая исчезнет, когда вы откроете доступ к функции для всех. Оказывается, что вы не можете доверять A/B-тестированию в социальных сетях.

Использование случайного распределения по сообществам

Альтернативой может стать использование случайного распределения по сообществам. В этом случае “сообщество” – это любая группа пользователей, взаимодействия которых направлены на других пользователей внутри группы. Data-команды в  LinkedIn и Instagram уже обсуждали свои кейсы A/B-тестирования, основанного на сообществах, но самое сложное здесь – понять, как определить сообщества для вашего конкретного продукта.

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

Для многих социальных сайтов и приложений пользовательские взаимодействия несложно объединить в граф. Каждый пользователь – это узел, а  грани соединяют узлы, между которыми было взаимодействие. Затем вы можете применить методы разделения графа, например, Normalized Cuts, чтобы разбить узлы на группы с большим количеством внутренних взаимодействий и небольшим количеством межгрупповых связей.

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

Определение географических сообществ

Определить географические регионы для эксперимента просто, да? Вы просто привязываете каждый город к каждому экспериментальному состоянию. Но оказалось, что сложно сказать, где город заканчивается.

Это становится еще более сложным, когда вы понимаете, что нет одного конкретного “рынка свиданий” для каждого города. Отдельные люди по-разному определяют свои географические границы. Люди на краю города могут общаться с людьми из ближайшего пригорода, но люди в этом пригороде могут общаться с людьми из пригорода, который находится чуть дальше, а пользователи оттуда могут общаться с людьми из другого города.

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

Вот общее содержание метода:

  1. Создайте граф, чтобы описать, сколько сообщений было отправлено между парами местоположений в качестве квадратной матрицы смежности A (num_Locations-by-num_Locations). Значение A [i, j] определяется количеством сообщений, отправленных между пользователями в местоположении i пользователям в местоположении j. Я не делал различий между отправителем или получателем сообщения, поэтому A симметрична.
  2. Вычислим векторный лапласиан графа L из матрицы смежности A и матрицы степени D как L = D – A. Матрица степени – это всего лишь диагональная матрица со степенью каждого узла на диагонали и нулями.
  3. Вычислите спектральное разложение матрицы L и вычислите её собственные значения. Каждое полностью изолированное множество узлов будет представлено собственным вектором с соответствующим собственным значением 0. Дальнейшая сегментация этих областей выполняется путем поиска паттернов в собственных векторах с k наименьшими ненулевыми собственными значениями. Значение k может варьироваться в зависимости от того, сколько регионов вы хотите сделать.

Я варьировал k в широком диапазоне от 5 до 250 и тестировал, насколько хорошо каждый набор регионов разделял сообщества пользователей, измеряя соотношение сообщений внутри региона с количеством сообщений между регионами. Оказалось, что для городов Канады и США оптимальным оказалось разделение на 36 регионов. После определения регионов мы оценили их разделенность на свежих данных, которые не участвовали в анализе сегментации и обнаружили, что примерно 95% взаимодействий (сообщения, лайки, просмотры профиля) произошли между пользователями внутри региона.

Заключение

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

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

A/B-тестирование – это простая концепция, но его может быть сложно проводить, если у вашего продукта есть социальные взаимодействия. Благодаря им и эффектам высшего порядка, стандартный подход к тестированию может быть неверным. Не существует одного подхода для всех продуктов. Поэтому моя финальная рекомендация – наймите специалистов по данным, которые любят экспериментировать.

 

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.