Как проверить окно покупок в аудитории GA4

Для аудитории «частые покупатели за семь дней» уточните, какие семь дней имеются в виду. Человек мог совершить две покупки в начале месяца и больше не покупать: условие «в любые семь дней» это запомнит, а условие «за последние семь дней» при новой оценке даст другой результат.

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

Два определения для одного названия

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

Согласуем две версии задания для магазина:

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

Что сохранить из конструктора

Инструкция по созданию аудиторий GA4 описывает динамическое окно для события с параметром event_count и областью Across all sessions. Для нашего задания выберите purchase, порог event_count ≥ 2, включите Time Period и задайте семь дней.

Затем проверьте переключатель оценки. True at the user's last interaction относится к недавнему периоду; True at any point in time сохраняет факт выполнения условия в прошлом. Формулировки интерфейса могут различаться по языку — в рабочем задании запишите смысл и приложите снимок фактических настроек.

Срок участия Membership duration сохраните отдельно. Это число дней членства после добавления, как объясняет справка с примерами аудиторий. Значение «7 дней» в этом поле не создаёт условие «две покупки за последние семь дней».

Учебный пример: четыре подходящих истории или две

Все пользователи и покупки вымышлены. Считаем каждую покупку один раз, идентификаторы пользователей стабильны, история полная, дополнительных исключений нет. У всех есть контрольное взаимодействие 25 октября 2026 года в 13:00 по Минску — к нему привязана оценка.

Для локального расчёта используем семь календарных дат ресурса: 19–25 октября включительно. Это явное соглашение примера; обработку точной границы дня и часового пояса нужно отдельно принять в своём ресурсе. Примеры, на которых различаются две версии, находятся далеко от этой границы.

По статическому условию подходят A, B, E, F, по динамическому — B, F. Покупатель E особенно полезен для приёмки: у него есть и давняя пара покупок, и одна недавняя. Простая проверка «была ли покупка на этой неделе» ошибочно включит его в условие с порогом две.

Учебные данные. Сравнивается выполнение двух условий; числа не являются размером аудитории из реального GA4 или Google Ads.

Повторите проверку на коротком наборе

Код ниже проверяет заданную логику на номерах дней октября. Он не обращается к Analytics и не воспроизводит внутренний механизм членства в аудитории.

paths = {
    "A": [1, 3], "B": [20, 24], "C": [10, 22],
    "D": [], "E": [2, 4, 23], "F": [21, 23, 25],
}
recent, ever = set(), set()
for user, days in paths.items():
    if sum(19 <= d <= 25 for d in days) >= 2:
        recent.add(user)
    ordered = sorted(d for d in days if d <= 25)
    if any(b - a < 7 for a, b in zip(ordered, ordered[1:])):
        ever.add(user)
assert recent == {"B", "F"}
assert ever == {"A", "B", "E", "F"}
print(sorted(recent), sorted(ever))

В календарном соглашении примера даты 11 и 17 помещаются в семь дней, а 11 и 18 — уже нет. Такие пограничные случаи полезно добавить к приёмочному набору после согласования часового пояса. Проверяйте ожидаемые ID, а не только общую численность: одинаковое количество может скрыть замену одного пользователя другим.

Как принять настройку в рабочем процессе

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

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

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

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

Локальный набор помогает команде в Беларуси согласовать правило без передачи клиентских данных. Здесь не проверялись живой ресурс, скорость пересчёта, идентификация между устройствами и рекламный охват; доступность запуска и требования к данным нужно сверить в своём аккаунте. Результат приёмки — точное определение «недавних покупок» и истории, на которых его можно проверить.

Источники

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

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