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

Вступление

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

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

ROPO — одна сторона медали. Однако имеет место и обратная ситуация, когда человек сначала посетит оффлайн, а потом сделает заказ в онлайне — Showrooming.

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

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

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

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

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

Первые шаги на пути к расчету ROPO- и Showrooming-эффекта

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

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

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

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

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

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

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

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

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

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

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

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

Настройка WEB-аналитики для ROPO и не только

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

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

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

Ya._metrika.getCounters().id

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

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

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

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

• передавать назад в Яндекс.Метрику данные о выполненных заказах (иначе мы будем оптимизироваться по входящим заказам/заявкам, а это неэффективно);
• связывать данный идентификатор с контактными данными пользователя, который он оставил в момент совершения заказа, а также с его 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 — номер вашего счетчика Метрики. В этом примере мы передаем по пользователю сразу четыре параметра: его VIP-статус, количество детей, возраст ребенка и 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-систему и смотрим, какие данные в ней есть по заявкам/транзакциям с сайта (с приложением почти все то же самое). В первую очередь нам интересны:

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

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

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

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

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

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

Сопоставление онлайн и оффлайн продаж на основе данных CRM

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

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

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

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

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

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

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

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

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

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

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

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

Как обогатить всех юзеров данными clientID Метрики

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

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

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

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

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

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

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

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

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

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