Как устранить дубли конверсий в Adgora

Дублирование конверсий в кампании Adgora после постбэка: сравнение способов устранения

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

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

Определите критерии до сравнения решений

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

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

Сохраняйте данные, необходимые для сравнения результатов: исходное событие, его ID или ID транзакции, попытки отправки постбэка, ответы конечной точки и отчёт Adgora по конверсиям. Если какого-либо поля нет, зафиксируйте это, а не делайте предположение, что две записи относятся к одному действию. Краткий журнал тестирования полезнее расплывчатого вывода, что конверсий «кажется слишком много».

Проследите путь одной конверсии через постбэк

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

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

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

Зафиксируйте этапы в правильном порядке: исходное событие, формирование постбэка, попытка доставки, ответ конечной точки, сохранённая запись и отчёт Adgora. Такая последовательность даст команде конкретный сценарий для проверки и поможет избежать распространённой ошибки — обвинять кампанию, не проверив, не создала ли конечная точка две записи.

Сравните стратегии дедупликации

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

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

Правило временного окна — запасной вариант, если интеграция не передаёт постоянный ID события или транзакции. Оно позволяет считать совпадающие конверсии, совершённые за короткий промежуток времени, одним событием, но «произошли рядом по времени» не значит «это одно и то же событие». Клиент может выполнить два разных действия в пределах выбранного интервала. Выберите минимальный интервал, достаточный для устранения наблюдаемого дублирования, и проверьте, как правило влияет на допустимые повторные конверсии, прежде чем применять его повсеместно.

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

Проверьте поведение при повторных попытках и ответы

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

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

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

Проверьте решения на дубликатах и повторных событиях

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

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

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

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

Внедряйте изменения с планом отката

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

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

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

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

Вывод: по возможности используйте идентификатор события

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

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