Продления подписок: заказы, события и атрибуция рекламы

Я начинаю с трёх вопросов. Прошёл ли платёж? Какого типа был заказ? Какое решение примет платформа-получатель на основе этого события?

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

Что такое продление в данных заказов Shopify?

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

SubscriptionContract в Shopify отдаёт originOrder, заказ, с которого контракт начался, и orders, связанные с ним заказы. Успешный SubscriptionBillingAttempt создаёт заказ; у попыток есть ключи идемпотентности, которые не дают создать заказ дважды. Источники: контракт, попытка списания.

Прежде чем присвоить метку продления, я сравниваю первый заказ, более поздние заказы контракта и данные о списании и платеже. Доступ к контрактам ограничен правами: Shopify документирует read_own_subscription_contracts или соответствующее право на запись для контракта. Я не исхожу из того, что посторонняя интеграция отслеживания может читать каждый контракт.

Если нужных данных нет, я прошу выгрузку от человека с нужным доступом или документированное сопоставление из системы подписок и оставляю категорию unknown. Я не стал бы превращать тег заказа, метку источника, наличие selling plan или старый клик в универсальный признак продления, не проверив сопоставление.

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

Как отделить первые заказы от продлений?

Тип заказа и историю клиента я храню в разных полях. Классификация привязана к заказу из события, поэтому последующее изменение статуса клиента не переписывает смысл более ранней покупки.

Гипотетический пример. Метки ниже относятся к предлагаемой внутренней схеме: это не поля Shopify и не завершённая клиентская работа. Ни одно событие из этого примера не отправлялось на рекламную платформу.

Данные по заказу	Внутренний тип заказа	Классификация клиента	Допустимость как покупки
Оплаченный первый заказ; более ранних подходящих покупок в согласованной истории нет	subscription_start	new	Допустим по согласованному правилу для выручки
Оплаченный первый заказ; клиент уже покупал раньше	subscription_start	returning	Продажа, но не первая покупка клиента
Более поздний заказ по контракту; есть данные об успешном повторном списании и платеже	subscription_renewal	returning	Допустимая выручка от продления; включение в привлечение решается отдельно
Неудачная попытка списания; завершённого оплаченного заказа нет	Нового оплаченного заказа нет	Без изменений	Покупки за неудачную попытку нет
Данные о подписке неполные	unknown	unknown, если история тоже неполная	Придержать до классификации или сообщить о неопределённости

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

Должно ли продление быть покупкой в GA4?

Если план измерения охватывает всю подходящую оплаченную выручку, я включил бы оплаченные продления как purchase и классифицировал бы их отдельно. Если план охватывает только первые заказы, я задокументировал бы это исключение, чтобы никто не принял итог за всю выручку Shopify.

В руководстве Google по ecommerce описана структура purchase, включая transaction_id, value, currency и items. Для каждого отдельного оплаченного заказа я использую отдельный ключ транзакции, а для копий этого заказа повторяю тот же ключ. Если для более поздних продлений взять ключ исходного заказа, отдельные покупки могут схлопнуться: GA4 документирует дедупликацию purchase по ID транзакции для веб-потоков. Источники: ecommerce, ID транзакций.

Предлагаемому мной параметру order_type для отчётов в GA4 нужен пользовательский параметр (custom dimension) с областью «событие». Это моя схема, а не готовое измерение продлений в GA4. Источник: пользовательские параметры.

Автоматическому повторному списанию нужен проверенный путь сбора; я не исходил бы из того, что событие чекаута в браузере его учитывает. Measurement Protocol от Google может передавать серверные и офлайн-взаимодействия, но Google описывает его как дополнение к сбору через gtag, Tag Manager или Firebase. События, отправленные только через него, могут получить неполную отчётность. Вместо того чтобы выдумывать сессию чекаута или новый рекламный клик для повторного списания, я проверил бы требования протокола для нужного случая.

Должно ли продление быть Purchase в Meta?

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

В документации Meta по серверным событиям автоматические продления подписки прямо приведены как пример action_source: system_generated. Там же сказано, что все источники действия поддерживают оптимизацию рекламы. Это поле описывает, где произошло действие; оно не исключает продления из ставок. event_time должен описывать, когда событие произошло на самом деле. Meta отклоняет весь запрос, если любой event_time старше семи дней, поэтому отложенный фид продлений нужно отправлять в этом окне. Источник: параметры серверных событий.

Если браузер и сервер описывают одну и ту же покупку, для рекомендуемого метода дедупликации у них должны совпадать event ID и имя события. Более позднее продление считается другой покупкой, и ему нужен собственный идентификатор события. Источник: дедупликация.

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

Должно ли продление быть конверсией в Google Ads?

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

Google Ads документирует основные (primary) действия как входные данные для ставок, когда выбрана их стандартная цель. Дополнительные (secondary) действия обычно служат только для наблюдения в «All conversions»; пользовательская цель может использовать дополнительное действие для ставок. Помимо метки primary/secondary я проверяю и цели кампании. Источник: действия-конверсии.

Google документирует new_customer для тега Google Ads и customer_type для тега Analytics. Эти классификации зависят от заявленного окна истории покупок; это не универсальный флаг продления. Я сопоставляю свою проверенную историю клиента с выбранным маршрутом и сохраняю неопределённость, когда история неполная. Источник: параметры привлечения.

Я также проверяю, не описывают ли нативное действие purchase и импортированное из GA4 действие один и тот же заказ. Я бы не стал случайно делать оба сигналами ставок на привлечение. Этот выбор разобран в гайде по источникам конверсий Google Ads.

Что может пойти не так, даже когда события приходят?

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

Риск	Что я бы проверил
Продление отправлено как новый привлечённый клиент	Данные о контракте и платеже и правило истории покупок
Исходный клик скопирован на более поздние заказы	Время получения идентификатора, происхождение и окно атрибуции платформы
Один заказ отправлен дважды	Повторы отправителя, ключи транзакции и события, все маршруты доставки
Для разных продлений используется один ключ события	Сопоставление заказа и события, а не только суммарные итоги
Отправитель молча перестаёт работать	Проверки поступления в разрезе типа заказа, с назначенным получателем оповещения
Продление исключено из выручки без объяснения	Письменно зафиксированный объём покупок и категории сверки
Серверный маршрут обходит согласие или отправляет лишние данные	Проверки допустимости и правила платформы для данных

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

Ситуация про аудит продлений подписок описывает объём диагностики. Связанный кейс про 67 дней без покупок в GA4 фиксирует аудит, старые идентификаторы на продлениях и пробелы в данных о новых заказах. Перестройка не состоялась. Я не выдаю этот гайд за её реализацию и не заявляю о восстановленных покупках.

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

Что я проверил бы перед запуском?

Я бы сверил разрешённый тестовый набор по типу заказа, а затем проверил полученные события и охват конверсий в каждой платформе. Это предлагаемый план приёмки; для этого гайда я не проверял реальные продления в GA4, Meta или Google Ads.

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

Чек-лист аудита трекинга и термин «сверка заказов» объясняют виды подтверждающих данных. Tracking Health Check подходит как отдельная диагностика, если причина или объём работ неясны. Если задача уже сформулирована, я бы сразу оценил объём внедрения.