Передовой опыт по созданию единого источника достоверной информации (SSOT) для A/B-тестирования

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

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

Что такое ССОТ

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

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

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

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

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

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

Кому нужен SSOT для тестирования?

Команды экспериментаторов просматривают данные, сгенерированные на их аналитических платформах, CRM, тестовых платформах и т. д. Им необходимо создать SSOT для тестирования, чтобы уточнить, что хотят делать их команды. Рассмотрим пример.

Один из клиентов Kameleoon запустил кампанию по оптимизации функции поиска на своем веб-сайте. Они провели тесты на стороне сервера, которые включали отслеживание трафика на странице доступа.

Но они столкнулись с проблемой, с которой сталкиваются многие программы для экспериментов: данные в Google Analytics показывали одно количество посещений страниц, а их инструмент для экспериментов — другое. Разница составила более 9 процентов.

Будучи веб-сайтом электронной коммерции с более чем миллионом посетителей в месяц, решение о том, каким данным доверять, имело большое значение в отчетах компании о KPI. В то время как некоторые бренды среднего и крупного бизнеса могут игнорировать расхождения до 10% в статистике посетителей, расхождение в данных в 9% заставило нервничать группу экспериментаторов этой компании.

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

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

Рекомендации по устранению несоответствий тестовых данных и созданию SSOT

1. Прежде чем делать что-либо еще, проведите А/А-тест

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

В тесте A/A оба варианта одинаковы, но пользователи, которые их увидят, будут разными:

Как действовать

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

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

2. Отслеживайте посетителей и посещения одинаково во всех своих инструментах

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

В Google Analytics существует два способа окончания посещения:

• Срок действия по времени: здесь срок действия сеанса истекает через 30 минут бездействия или в полночь. Тогда как, например, в Kameleoon это после 30 минут бездействия.

• Изменение кампании . Если один и тот же посетитель приходит через одну кампанию, уходит через 2 минуты, а затем возвращается через другую кампанию через 2 минуты, Google Analytics засчитает два посещения. Некоторые инструменты A/B-тестирования увидят это как единое целое.

Как действовать

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

В GA вы можете изменить время ожидания сеансов и кампаний в настройках сеанса.

Почему? SSOT должны быть определены на организационном уровне. Таким образом, даже если ваша группа тестирования проводит весь день, работая с данными на вашей тестовой платформе, другим командам все равно может понадобиться ссылаться на данные из GA для других целей. Установите SSOT в качестве набора данных, на который ссылается самый широкий круг команд вашей организации.

3. Создайте фильтры браузера и версии в своем инструменте аналитики

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

Еще одна потенциальная проблема с отслеживанием заключается в том, что Google Analytics совместим со всеми версиями браузеров, в то время как инструменты A/B-тестирования обычно поддерживают полную совместимость только с несколькими последними версиями.

Как действовать

В Google Analytics создавайте настраиваемые фильтры на основе браузеров и версий браузеров, которые вам нужны, чтобы все платформы совпадали. Вы делаете это в

Например, в разделе «Просмотр» вы можете исключить более старую версию Google Chrome следующим образом:

4. Фильтруйте проблемный трафик во всех своих инструментах

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

Как действовать

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

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

• Продолжительность посещения > 120 минут
• Продолжительность посещения < 100 миллисекунд
• Количество событий (конверсии, клики, таргетинг, продукт, просмотр страницы и т. д.) > 10 000

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

Чтобы отфильтровать внутренний трафик в GA, перейдите в Панель администратора > Все фильтры и создайте новый фильтр. Установите тип фильтра на «неопределенный». Затем добавьте диапазоны внутренних IP-адресов, которые вы хотите исключить.

5. Избегайте блокировщиков рекламы

Многие посетители используют блокировщики рекламы, такие как Adblock, Ghostery и uBlock. Некоторые блокировщики рекламы также могут блокировать средства отслеживания на стороне клиента, в том числе события аналитики из инструментов для экспериментов.

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

Как действовать

Некоторые платформы могут предоставлять «локальные» URL-адреса запросов на отслеживание, которые позволяют им избежать блокировки блокировщиками рекламы. Здесь отслеживание происходит на стороне сервера, поэтому блокировка кода на стороне клиента, например блокировщиком рекламы, не останавливает законное отслеживание. Активируйте его на всех возможных платформах.

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

6. Установите свои инструменты на все те же страницы

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

Как действовать

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

Один из способов определить, что это не так, — разбить ваши данные по URL-адресам посещенных страниц. Это покажет вам все основные URL-адреса, по которым выполнялся эксперимент, чтобы вы могли определить те, по которым ваш инструмент тестирования не должен был загружаться. Вот как эта опция выглядит в Kameleoon:

Последние мысли

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

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

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

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

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