Мы все не раз слышали рассказы о том, как какой-то разработчик изменил надпись кнопки или экран приветствия, и внезапно обнаружил, что возвраты или покупки в приложении мгновенно выросли на какие-то сумасшедшие проценты.
Может быть, где-то и в вашем списке задач есть чекбокс «эксперименты с моей кнопкой покупки», который все еще стоит в листе ожидания, так как вы слишком заняты и у вас до него не доходят руки.
В 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, который вы можете создать, выполнив следующие действия:
- Перейдите на страницу console.firebase.google.com.
- Нажмите на Add project.
- Назовите свой проект Planet Tour, убедитесь, что ваш регион выбран, затем нажмите CREATE PROJECT .
- Нажмите «Add Firebase to your iOS app».
- Добавьте идентификатор пакета вашего проекта (com.razeware.Planet-Tour), дайте ему забавный псевдоним, оставьте поле App Store ID пустым, затем нажмите «REGISTER APP»
- На этом этапе ваш браузер позволит вам загрузить файл GoogleServices-info.plist.
- Откройте Planet Tour.xcworkspace в Xcode и перетащите этот файл в проект Planet Tour (выберите «Copy Items if Needed»).
- Затем вы можете просто нажать «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 в качестве новых значений по умолчанию для всех. И так ваши новые варианты рассылки станут доступны миру!