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

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

Конверсія може відобразитися двічі, навіть якщо відвідувач виконав дію лише один раз. Дублікат може з’явитися через повторний постбек, кінцеву точку, яка приймає ту саму подію кілька разів, або звіт, у якому одну подію враховано у двох місцях. Щоб з’ясувати, чому постбек надсилає конверсії двічі, простежте весь шлях і визначте, де саме вперше з’являється другий запис.

У цьому порівнянні розглянуто три способи запобігти дублюванню: дедуплікацію за ID події, перевірку ID транзакції та правила часового вікна. Оптимальний варіант залежить від того, які ідентифікатори надає інтеграція та чи можуть клієнти правомірно конвертуватися повторно. Надто широке правило дедуплікації може видалити справжні продажі або реєстрації.

Визначте критерії, перш ніж порівнювати способи

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

Визначте, що саме вважається дублікатом для вимірюваної дії. Якщо йдеться про одноразове оформлення замовлення, повторний запис того самого замовлення, найімовірніше, є дублікатом. Якщо це поновлення підписки, дві покупки одного клієнта в різний час можуть бути цілком правомірними. Визначайте це окремо для кожної події, а не лише для кампанії загалом.

Зберігайте дані, потрібні для порівняння результатів: вихідну подію, її ID або ID транзакції, спроби надсилання постбеку, відповіді кінцевої точки та звіт про конверсії Adgora. Якщо якогось поля немає, зафіксуйте це, а не припускайте, що два записи стосуються тієї самої дії. Невеликий журнал тестування корисніший за нечітке твердження, що конверсій «забагато».

Простежте шлях однієї конверсії через постбек

Виберіть одну конверсію зі звіту й простежте її шлях від початкової дії до звіту. Почніть із вихідної події — наприклад, підтвердження замовлення, надсилання форми або дії в застосунку. Зафіксуйте час і будь-який пов’язаний із нею ідентифікатор. Потім знайдіть відповідний вихідний постбек і запис на кінцевій точці-отримувачі.

Порівняйте ідентифікатори й часові мітки на кожному етапі. Якщо у джерелі є одна подія, а на кінцевій точці — два однакові записи, другий запис з’явився десь між доставленням постбеку та збереженням даних на кінцевій точці. Якщо на кінцевій точці один запис, а Adgora показує дві конверсії, перевіряйте звітність або імпорт даних, а не змінюйте дедуплікацію на кінцевій точці.

Знайдіть конкретне місце, де записи розходяться. Наприклад, подію оформлення замовлення могли надіслати і браузер, і сервер, або повторний запит міг надійти на кінцеву точку, яка зберігає кожен запит як новий. Це різні сценарії з різними способами усунення. Якщо обидва шляхи передають спільний ID події, зіставити їх буде простіше; якщо ні — можливо, його доведеться додати у джерелі.

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

Порівняйте стратегії дедуплікації

Дедуплікація конверсій за ID події зазвичай є найочевиднішим варіантом, якщо та сама конверсія може передавати один стабільний унікальний ідентифікатор від джерела до отримувача. Кінцева точка зберігає першу подію, а пізніший запит із тим самим ID вважає вже обробленим. Переконайтеся, що ID не змінюється під час повторних спроб і в різних шляхах передавання — через браузер або сервер, які можуть повідомити про ту саму дію.

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

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

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

Перевірте повторні спроби та обробку відповідей

Час очікування, що минув, не доводить, що постбек не доставлено. Кінцева точка могла зберегти подію, але не повернути чіткого підтвердження, через що відправник спробував надіслати її знову. З’ясуйте, як відправник обробляє тайм-аути, які коди відповіді запускають повторні спроби та чи надсилає кінцева точка відповідь лише після збереження події.

Перш ніж пов’язувати дублікати з повторними спробами, перевірте фактичні журнали запитів і відповідей. З’ясуйте кількість спроб, часові мітки, коди відповідей і те, чи містила кожна спроба той самий ID події. Потім перевірте задокументовану поведінку кінцевої точки саме в середовищі, яке використовуєте.

Тут важливо розрізняти два випадки. Якщо кожен повторний запит має той самий ID, але кінцева точка зберігає обидва, на стороні отримувача може знадобитися ідемпотентна обробка. Якщо повторні запити мають різні ID, хоча відповідають одній вихідній дії, з’ясуйте, де саме генеруються ці ID. Сама політика повторних спроб такої невідповідності не пояснює.

Перевірте виправлення на дублікати та повторні події

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

Для обох сценаріїв порівняйте журнал джерела, журнал доставлення, записи кінцевої точки та звіт Adgora. Виправлення можна вважати успішним, лише якщо воно прибирає повторну подію, не видаляючи дійсну другу подію. Якщо використовуєте правило часового вікна, перевірте повторну конверсію в межах запропонованого проміжку. Тест за його межами не покаже, чи не надто широке правило.

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

Якщо кампанії також відстежують дії в застосунках, переконайтеся, що тест відображає спосіб надсилання таких подій. Огляд криптореклами для кампаній із залученням встановлень застосунків може допомогти розібратися в контексті кампанії, але для перевірки дублювання все одно потрібно простежити конкретне встановлення або внутрішню подію застосунку через відповідний шлях постбеку.

Запроваджуйте зміни з планом відкату

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

Відстежуйте обидва аспекти проблеми. Зменшення кількості дублікатів — позитивний результат лише за умови, що правомірні конверсії збереглися. Слідкуйте за відсутніми записами, неочікуваним падінням кількості повторних покупок, зростанням помилок доставлення або розбіжностями між даними кінцевої точки та звітом Adgora. Якщо помітите будь-яку з цих ознак, призупиніть зміни й порівняйте відповідні ID подій або номери транзакцій.

До запуску визначте чітку умову для відкату. Наприклад, поверніть попередні налаштування, якщо відома тестова конверсія не реєструється або якщо з журналу кінцевої точки зникають правомірні повторні події. Не видаляйте старе правило, доки не перевірите нове на реальних даних кампанії.

Задокументуйте, що й коли змінилося та на які типи подій поширюється зміна. Це допоможе відрізнити виправлення постбеку від інших змін кампанії. Також наступна відповідальна особа зможе швидко відновити попередню поведінку, якщо кількість конверсій неочікувано зміниться.

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

Використовуйте стабільний унікальний ID події, якщо інтеграція його підтримує та він може пройти від вихідної події до кінцевої точки-отримувача. Так отримувач зможе безпосередньо розпізнати повторний запит, не вважаючи дублікатом кожну конверсію, що сталася приблизно в той самий час.

Якщо відповідного ID події немає, використовуйте ID транзакції для покупок, де номер замовлення надійний. Для інших подій правилом часового вікна можна скористатися як найвужчим доступним запасним варіантом, але перед запуском перевірте його на правомірних повторних конверсіях. Якщо ви з’ясовуєте, як усунути дублікати конверсій в Adgora, обирайте рішення, яке прибирає повторний запис і водночас зберігає другу справжню дію, а не просто зменшує загальну кількість конверсій.