Как посчитать повторные покупки при гостевом оформлении

Заказы в магазине есть, а число повторных покупателей зависит от отчёта: CRM видит одного клиента, GA4 — несколько устройств, таблица заказов — несколько строк без аккаунта. Чтобы посчитать повторные покупки, сначала присвойте каждому подтверждённому заказу внутренний customer_key, а неизвестные связи оставьте неизвестными.

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

Сначала определите повторный заказ

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

Сразу разделите три сущности:

transaction_id в GA4 описан как уникальный идентификатор транзакции. Он подходит для связи события покупки с заказом, но не объединяет несколько заказов одного человека. В экспорте GA4 в BigQuery поля user_id и user_pseudo_id также имеют разный смысл: первое содержит назначенный бизнесом ID, второе — псевдонимный идентификатор пользователя приложения или сайта.

Почему счётчик пользователей расходится с CRM

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

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

Для управленческого отчёта полезно держать три состояния:

• подтверждённая связь с customer_key;
• заказ без достаточного идентификатора;
• спорная связь, отправленная на ручную проверку.

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

Соберите таблицу соответствий

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

Практический порядок сопоставления:

1. Используйте уже назначенный ID клиента из CRM или магазина.
2. Свяжите авторизованный аккаунт с этим ID через таблицу соответствий.
3. Для гостевого заказа применяйте только согласованное правило по подтверждённому контакту внутри защищённой системы.
4. Сохраняйте основание связи, дату и версию правила.
5. Оставляйте customer_key пустым, если доказательства недостаточны.

Google разрешает использовать User-ID для собственных идентификаторов и связывать активность между сеансами и устройствами. Документация требует исключить идентификаторы, по которым третья сторона может определить человека. Поэтому email и телефон не должны становиться открытым user_id; передавайте непрозрачный внутренний ключ и проверяйте собственные правила работы с данными.

Учебный пример: шесть заказов

После отбора оплаченных заказов получилась таблица:

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

Для C-01 первый заказ — O101, повторные — O102 и O103. Для C-02 первый — O104, повторный — O105. O106 не получает порядковый номер покупателя.

Итого:

Идентифицированные заказы: 5
Первые заказы: 2
Повторные заказы: 3
Доля повторных среди идентифицированных: 3 / 5 = 60%
Доля повторных среди всех заказов: 3 / 6 = 50%
Неизвестные: 1 / 6 = 16,7%

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

Как повторить расчёт в SQL

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

WITH eligible AS (
  SELECT
    order_id,
    paid_at,
    customer_key
  FROM orders
  WHERE status = 'paid'
    AND is_test = FALSE
),
numbered AS (
  SELECT
    *,
    CASE
      WHEN customer_key IS NULL THEN NULL
      ELSE ROW_NUMBER() OVER (
        PARTITION BY customer_key
        ORDER BY paid_at, order_id
      )
    END AS order_number
  FROM eligible
)
SELECT
  COUNT(*) AS all_orders,
  COUNTIF(customer_key IS NOT NULL) AS identified_orders,
  COUNTIF(customer_key IS NULL) AS unknown_orders,
  COUNTIF(order_number > 1) AS repeat_orders,
  SAFE_DIVIDE(
    COUNTIF(order_number > 1),
    COUNTIF(customer_key IS NOT NULL)
  ) AS repeat_order_share_identified
FROM numbered;

Сортировка содержит order_id, чтобы два заказа с одинаковым временем получили стабильный порядок. Для отмен и возвратов добавьте отдельное правило: например, пересчитывать показатель по итоговому статусу через 30 дней после заказа.

Проверьте результат на уровне строк

Перед дашбордом возьмите десять покупателей с двумя и более заказами и десять неизвестных заказов. Для каждой строки проверьте:

• заказ существует в учётной системе и имеет нужный статус;
• order_id не повторяется;
• customer_key ведёт к одному внутреннему профилю;
• основание связи сохранено и воспроизводится;
• дата первого заказа действительно раньше повторного;
• тестовые заказы, отмены и полные возвраты обработаны по принятому правилу.

Отдельно посчитайте конфликты: один аккаунт связан с несколькими customer_key, один заказ менял владельца, правило сопоставления обновилось задним числом. Такие случаи лучше исправлять в таблице соответствий, сохраняя историю изменения.

Где использовать GA4

User-ID помогает связать авторизованную активность на разных устройствах. В официальной справке Google указано, что BigQuery Export содержит и user_id, и user_pseudo_id. Это полезно для пути до покупки, но источником числа повторных оплаченных заказов всё равно должна быть система, где подтверждены заказ, покупатель и итоговый статус.

Если магазин не передаёт User-ID, user_pseudo_id можно использовать для диагностики конкретного браузера или установки. Вывод «новый покупатель» из нового псевдонимного ID слишком сильный: человек мог очистить cookie, сменить устройство или запретить хранение аналитики.

Настройку событий покупки, transaction_id, сумм и возвратов сверяйте с руководством по электронной торговле в GA4 и Яндекс Метрике. Когда устойчивый customer_key готов, следующий шаг — когортный анализ удержания: сгруппируйте покупателей по первой оплате и дайте каждой когорте одинаковое время на повтор.

Критерий готовности

Расчёт готов, когда каждый включённый заказ имеет уникальный order_id, известные покупатели связаны с одним внутренним customer_key, неизвестные показаны отдельно, первый и повторный заказ определяются одним правилом, а показатель сопровождается долей неидентифицированных строк. Тогда изменение repeat rate можно обсуждать как поведение покупателей, а не как побочный эффект новых cookie, аккаунтов или правил CRM.

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5
• Источник 6
• Источник 7

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.