ROPO эффект и ROPO аналитика: что это такое и как помогает бизнесу

Во времена локдауна многие проекты поняли, что существовать без присутствия в интернете просто невозможно и те, кто еще не сделал, начали активно делать свои сайты и интернет-магазины. На дворе уже 2024 год и локдаун позади. Аудитория вернулась к старым привычками: начала посещать оффлайн заведения, хотя и реже, чем прежде. В результате предприниматели часто стали сталкиваться с ситуацией, когда они закупают трафик в интернете, но, к сожалению digital-маркетологов, не все посетители сайта покупают товары и услуги на сайте, часть из них предпочитает идти в оффлайн и покупать так. Эта модель поведения напрямую подводит нас к аббревиатуре ROPO, которой посвящена данная статья.

ROPO (Research Online, Purchase Offline) — термин, который описывает поведение потребителей, которые исследуют товары в Интернете, сравнивают цены и читают отзывы, прежде чем совершить покупку в физическом магазине. Этот процесс показывает взаимодействие между онлайн-поиском и офлайн-покупками и является важным фактором в мультиканальных и омниканальных стратегиях маркетинга. ROPO-анализ помогает бизнесам понять, как их онлайн-присутствие влияет на офлайн-продажи и наоборот, и как можно оптимизировать маркетинговые кампании для увеличения общих продаж.

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

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

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

Также изучение этих эффектов даст вам полезные ответы на ряд вопросов:

• следует ли подключать онлайн-канал к офлайн-кампаниям;
• какова реальная рентабельность рекламных кампаний в интернете с учетом влияния на офлайн;
• какой % посетителей сайт покупает только в онлайне, какой только в оффлайне, а какой и там, и там;
• что мешает покупателям c ROPO изначально разместить заказ на сайте.

Также следует зеркально задать вопросы, чтобы понять эффект Showrooming-а.

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

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

Идентифицировать пользователей на сайте можно при помощи следующих технологий:

• личный кабинет;
• хранение информации в cookie-файле и аналогах;
• передача на сторону web-аналитики userID посетителя сайта;
• обогащение данных через DMP.

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

Внедрение этих решений позволит в единой базе данных (СУБД) собрать все транзакции пользователя по его идентификатору и понять, в каком момент времени и где была осуществлена транзакция.

Это приводит нас к возникновению следующих сценариев на стороне сайта/приложения:

• посещение сайта/приложения без идентификации;
• посещение сайта/приложения -> идентификация;
• посещение сайта/приложения -> покупка и идентификация.

А также наборов сценариев на стороне офлайн точки продаж:

• посещение магазина без покупки;
• посещение магазина и покупка без идентификации;
• посещение магазина и покупка с идентификацией.

При этом в случае с ROPO и Showrooming эффектами мы можем видеть совершенно разные комбинации их взаимодействий или рассматривать их изолированно. Получим вот такую жуткую картинку:

Внимательный читатель сразу же заметит: “Постойте, а где же сценарии, когда пользователь видел рекламу в онлайне и после этого сразу пошел в оффлайн и обратный сценарий?” Конечно, эти сценарии также имеют место быть, но для простоты погружения в предмет мы с вами их опустим, а иначе плохо кончим уже через один-два абзаца. Но давайте вернемся к сути и разберем, где, что и как нам нужно настраивать, чтобы прийти к промежуточной схеме СУБД.

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

Во-первых, нужно научиться сохранять на фронте сайта значение идентификаторов cookie-аналитических/коллтрекинговых и прочих используемых нами систем. Рассмотрим данную операцию на примере извлечения идентификатора Яндекс.Метрики. 

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

Ya._metrika.getCounters()[0].id

Теперь мы знаем номер счетчика метрики и можем узнать идентификатор cookie-файла, который нам присвоила данная Метрика. Для этого выполняем следующую команду: yaCounter11788682.getClientID(); 

Делаем и видим следующее:

И вот он заветный идентификатор 1568195667334917777. Это и есть ClientID Яндекс.Метрики, который был нам присвоен и который является основным ключом сопоставления всех наших последующих данных. Туже самую операцию вы можете делать но на стороне вашего сайта применительно к каждому посетителю сайта и узнавать номер его cookie-файла. И возникает вопрос: 

Суть в том, что ClientID Яндекс.Метрики нам нужен в первую очередь для того, чтобы в момент целевого действия мы передавали данную информацию в нашу CMS или CRM (ту или и туда и туда) для того, чтобы у нас появилась возможность:

1. передавать назад в Яндекс.Метрику данные о выполненных заказах (иначе мы будем оптимизироваться по входящим заказам/заявкам, а это не эффективно)
2. мы связываем данный идентификатор с контактными данными пользователя, который он оставил в момент совершения заказа, а также с его userID

Постойте, а что такое userID? UserID — уникальный идентификатор пользователя в нашей учетной системе (у кого-то CMS, CRM, 1С или еще какой-то зверь). 

Во-вторых, именно UserID мы и должны передавать в веб-аналитическую систему. Но Яндекс.Метрика (или другая веб-аналитическая система) еще не знает userID нашего клиента. И как же это сделать? 

Для начало нужно понимать, что передавать этот идентификатор можно в разные моменты времени, а именно:

• во время посещения пользователем сайта;
  • в произвольный момент;
  • при инициализации счетчика;
• в произвольный момент через CSV-файл.

Сразу скажу о небольшом нюансе. Данный параметр привязывается к визитам посетителя на промежутке 90 дней до момента отправки данных в Метрику. То есть ретроспективное окно привязки — 90 дней.

Передача в произвольный момент будет выглядеть так:

ym(XXXXXX, 'userParams', {
    vip_status: true,
    child: 1,
    child_age: 13,
    UserID: 12345
});

Где XXXXXX это номер вашего счетчика Метрики. В этом примере мы передаем по пользователю сразу четыре параметра: его вип-статус, количество детелй, возраст ребенка и UserID.

При инициализации счетчика код будет выглядеть немного иначе (будет зависеть от параметров инициализации):

ym(XXXXXX, 'init', {
    clickmap: true,
    webvisor: true,
    userParams: {
        vip_status: true,
        child: 1,
        child_age: 13,
        UserID: 12345
    }
});

Помните, что параметры пользователя можно перезаписывать, то есть если вы узнаете, что у пользователей появился еще ребенок, то можно опять передать child, но уже со значением 2. Точно также передается принадлежности к любым другим параметрам для последующего создания сегментов в Яндекс.Метрике и изучения поведения пользователей в рамках конкретного сегмента.

Все что вам теперь остается, так как это сохранить значение clientID Яндекс.Метрики вместе с любой заявкой/транзакцией на вашем сайте, хранить и передавать данный параметр в вашу CRM для последующего использования в качестве ключа для сопоставления данных. 

* userID не всегда создается на стороне CMS, иногда он создается в CRM. Тут нужно смотреть конкретную схему. 

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

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

Теперь мы с вами идем в CRM систему и смотрим, какие данные в ней есть по заявкам/транзакциям с сайта (с приложением почти все тоже самое). В первую очередь нам с вами интересны:

• Дата и время создания сущности в CRM
• userID потенциального клиента
• идентификатор заявки/транзакции
• этап воронки, на котором находится заявка/транзакция
• clientID пользователя из Метрики (или другой(их) систем)
• Сумма сделки
• Персональные данные пользователя
• Источник заявки/транзакции

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

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

Зачем вообще мы об этом говорим? Все потому что, как только данная заявка становится реализованной, то мы должны иметь возможность передать эти данные в Веб-аналитику для того, чтобы мы с вами могли управлять рекламой именно от реализованных (в ряде случаев целевых) лидов/заявок/транзакций!!!

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

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

Ядром любой CRM системы является база данных (СУБД), которая имеет некоторую структуру. Чаще всего в рамках данной структуры существует две таблички:

• Табличка пользователей
• Табличка транзакций (продаж)=

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

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

• Покупает только онлайн
• Покупает только оффлайн
• Покупает онлайн и оффлайн

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

Это очень прикольная аналитика, особенно если смотреть на нее в динамике и наблюдать за тем, как по месяцам меняются эти данные и в процентах и в абсолютах.  Но это еще далеко не ROPO и Showrooming. 

ROPO по сути своей — сегмент пользователей, который вначале изучают товар в интернете, а потом покупают в оффлайне. Получается, что ROPO мы должны увидеть на оси времени в рамках изучения покупок конкретного пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете посмотреть другие полезные для вашего бизнеса статьи в нашем блоге