Стратегии измерения эффективности на каждом этапе воронки продаж.
Различные этапы воронки продаж по-разному подвержены проблемам с производительностью и, следовательно, требуют разных измерений и оптимизации:
В этом руководстве мы рассмотрим, как можно измерить различные этапы. Для этого мы рекомендуем вам просмотреть как лабораторные, так и полевые данные.
Лабораторные данные собираются путем локального выполнения тестов, например, с помощью Lighthouse и других инструментов. Это может позволить сравнить производительность веб-сайта с течением времени и с конкурентами в контролируемой, стабильной среде, но это может не отражать производительность, которую пользователи испытывают в реальной жизни.
Полевые данные собираются с помощью аналитики от реальных пользователей и, следовательно, отражают их опыт. Однако его нелегко сравнивать по времени или с конкурентами. Сетевые соединения и аппаратное обеспечение смартфонов со временем меняются, и разные целевые аудитории могут иметь разные устройства, что затрудняет сравнение с полевыми данными. См. также раздел «Оценка производительности в полевых условиях ».
Для получения полной картины необходимы оба источника данных. В следующих разделах показано, как собирать лабораторные и полевые данные для различных соответствующих показателей эффективности на протяжении всей воронки.
Открытие
Оптимизация для обнаружения означает оптимизацию для первой загрузки, которую получат новые пользователи, а также поисковые роботы и сканеры социальных сетей. Лабораторные данные для первой загрузки можно легко получить через Lighthouse , а полевые данные (по крайней мере, для Chrome) легко доступны через отчеты Chrome UX . Удобную комбинацию того и другого можно найти в PageSpeed Insights . Вам также следует самостоятельно отслеживать соответствующие показатели на местах: измерение этих показателей на устройствах реальных пользователей дает хорошее представление.
С точки зрения пользователя наиболее важными показателями являются:
- Первая содержательная отрисовка (FCP) : время, когда пользователь смотрит на пустой экран. В этот момент большинство пользователей отказываются, так как не видят прогресса.
- Первая значимая отрисовка (FMP) : когда пользователь начинает видеть основной контент, за которым он пришел. Часто это главное изображение, но для целевой страницы это может быть даже призыв к действию, например кнопка «Купить », поскольку пользователь может прийти на сайт с четким намерением (например, посредством целевой рекламной кампании).
- Задержка первого ввода (FID) : время, необходимое веб-сайту для реакции на первый ввод пользователя. Чрезмерный JavaScript и другие проблемы с загрузкой ресурсов могут заблокировать это, что приведет к неудачным нажатиям или щелчкам, ошибочным вводам и отказу от страницы.
Есть и другие показатели, на которые вы можете обратить внимание, но это хорошая основа. Кроме того, обязательно фиксируйте показатели отказов, конверсии и вовлеченность пользователей, чтобы вы могли соотнести их.
Вовлеченность и конверсия
После первой загрузки целевой страницы пользователь перейдет по вашему сайту, и мы надеемся, что это приведет к успешной конверсии.
На этом этапе важно иметь быструю и отзывчивую навигацию и взаимодействие. К сожалению, измерить весь поток событий навигации и взаимодействия в полевых условиях непросто, поскольку каждый пользователь проходит по странице по-разному. Поэтому мы рекомендуем измерять время, необходимое для достижения конверсии или подцелей конверсии (« Время к действию »), создавая сценарии и измеряя поток в лабораторных тестах, чтобы сравнить производительность с течением времени или с конкурентами.
Сделать это можно двумя удобными способами:
Веб-ПейджТест
WebPageTest предлагает очень гибкое решение для создания сценариев . Основная идея заключается в том, чтобы:
- Скажите WebPageTest перемещаться по страницам потока с помощью команды
navigate
. - При необходимости запишите нажатие кнопок с помощью команд
clickAndWait
и заполните текстовые поля с помощьюsetValue
. Для тестирования одностраничных приложений используйтеclickAndWait
вместо командnavigate
для всех шагов после первого, посколькуnavigate
будет выполнять полную загрузку вместо облегченной загрузки виртуальной страницы. - Обязательно объедините различные этапы потока анализа с помощью
combineSteps
, чтобы создать единый общий отчет о результатах для всего потока.
Такой сценарий может выглядеть так:
combineSteps
navigate https://www.store.google.com/landingpage
navigate https://www.store.google.com/productpage
clickAndWait innerText=Buy Now
navigate https://www.store.google.com/basket
navigate https://www.store.google.com/checkout
Имея такой сценарий, вы можете легко измерить и сравнить производительность с течением времени. Это даже можно автоматизировать с помощью API WebPageTest .
Кукловод
Еще один отличный вариант тестирования скриптов — через headless Chrome, которым можно управлять через Node API Puppeteer . Общая идея состоит в том, чтобы запустить браузер через Puppeteer, перейти на целевую страницу с помощью функции goto , внедрить JavaScript для заполнения полей или нажатия кнопок и пройти по воронке, выполняя дальнейшие вызовы goto по мере необходимости.
В качестве метрики продолжительность потока может быть измерена напрямую, но вы также можете суммировать значения FCP, FMP или TTI отдельных нагрузок потока. Тестирование производительности веб-сайта с помощью Puppeteer содержит обзор того, как получить показатели производительности с помощью Puppeteer. Очень упрощенный пример Node-скрипта может выглядеть так:
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
const start = performance.now();
await page.goto('https://www.store.google.com/landingpage');
await page.goto('https://www.store.google.com/productpage');
// click the buy button, which triggers overlay basket
await page.click('#buy_btn');
// wait until basket overlay is shown
await page.waitFor('#close_btn');
await page.goto('https://www.store.google.com/basket');
await page.goto('https://www.store.google.com/checkout');
console.log('Flow took ' + parseInt((performance.now() - start)/1000) + ' seconds');
await browser.close();
})();
Этот сценарий можно легко автоматизировать и даже сделать частью процесса сборки или бюджета производительности и регулярно контролировать.
Повторное участие
Пользователи будут возвращаться на ваш сайт через разные промежутки времени. В зависимости от прошедшего времени браузер может кэшировать меньше ресурсов веб-сайта, и ему потребуется больше сетевых запросов. Это затрудняет оценку различий в производительности при повторных посещениях в лабораторных тестах. Тем не менее, рекомендуется следить за этим, и отличным инструментом лабораторного тестирования повторных посещений является WebPageTest , у которого есть специальная опция для прямого повторного посещения:
Чтобы лучше оценить эффективность повторных посещений в полевых условиях, используйте выбранный вами аналитический пакет для сегментации показателей эффективности по типам пользователей. Вот пример такого отчета в Google Analytics:
Подобный отчет также покажет вам время загрузки страницы для новых и вернувшихся пользователей.
Резюме
В этом руководстве показано, как измерить первую загрузку, расход и повторную загрузку с помощью полевых и лабораторных испытаний. Обязательно оптимизируйте различные этапы воронки соответствующим образом, чтобы максимизировать обнаружение (первая загрузка), вовлечение (навигация и поток) и повторное вовлечение (повторная загрузка).