impact.com і PartnerStack: два предметні пілоти

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

Результат інструкції — комплект приймання impact.com і PartnerStack: вимоги, два сценарії випробувань, реєстр звіряння та рішення. Офіційні джерела перевірено 25 жовтня 2026 року. Іменний кейс Canva нижче опублікував постачальник; магазин, сервіс і заповнені робочі листи — навчальні приклади, не результати клієнтів. Доступ акаунта, допустимість країни й продукту та склад договору підтверджуються окремо.

Почніть із подій, які потрібно вміти пояснити

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

Якщо найближче завдання — підготувати пропозицію для CPA-мережі, першим варіантом може бути наша AffiliateCore: зареєструйтеся рекламодавцем і підготуйте пропозицію. Ресурси кабінету передбачають чернетки оферів та перегляд записів конверсій. Робочі таблиці цієї інструкції залишаються вашими документами. Ми не заявляємо інтеграцію AffiliateCore з двома розглянутими постачальниками, автоматичний облік підписок, реєстрацію угод або імпорт їхніх партнерів.

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

Порівнюйте моделі даних, а не лише назви

impact.com: дія та виправлення. Конверсія з призначеним партнером стає action. Поки дія pending, її можна змінити або скасувати до locking date; фіксація визначає остаточне зобов’язання щодо комісії. Тому строк повернення та крайній момент виправлення — ключові частини приймання. Перевіряйте дати власних умов, не підставляйте універсальну кількість днів. impact.com: action life cycle

impact.com: ланцюжки подій. Chained actions пов’язують батьківську й наступні події спільним customer ID. Батьківська подія має потрапити до системи першою; для наявної конфігурації ввімкнення ланцюжка може потребувати підтримки. Це документований спосіб перевірити зв’язок пробного періоду з оплатою або продовженням, але не доказ повноти подій вашого білінгу. impact.com: chained actions

PartnerStack: продажі за участю партнера. Реєстрація угод залежить від плану й вмикається для груп партнерів. Документація описує ручне підтвердження угод Closed Won, заявлених партнером, і створення клієнта для комісій від наступних транзакцій. Сумісність CRM підтверджують у постачальника. Стадія угоди, картка клієнта та оплачена транзакція — різні об’єкти. PartnerStack: deal submission

PartnerStack: перевірка комісій. До формування рахунку доступні підтвердження, відхилення та відкладення перевірки комісії. Придатні комісії New можуть автоматично підтверджуватися під час формування рахунку. Уже підтверджену комісію не можна просто перевести в інший статус на цьому екрані; описаний шлях виправлення пов’язаний із рахунком. Плануйте звіряння до цієї межі. PartnerStack: commission review

Відмінності підказують порядок демонстрації: в impact.com спочатку перевірити виправлення замовлень, у PartnerStack — роботу партнера з угодою. Це порядок перевірки, а не висновок, що інший продукт не підходить для того самого процесу. Обов’язковий маршрут мають пройти обидва кандидати. Каталоги, розміри маркетплейсів і логотипи використовуйте для пошуку варіантів, але не як доказ доступних вам партнерів або продажів.

Публічний кейс: перетворити різні партнерства на перевірні правила

impact.com описує налаштовувані договори Canva після початку співпраці у вересні 2019 року. Дата публікації недоступна; незалежний аудит і построкові докази скасувань недоступні. Наша редакційна методика — перетворити кожний потрібний варіант договору на подію, правило атрибуції та порядок обробки винятку. Рекомендація і продаж за участю партнера можуть стосуватися одного клієнта: пілот має пояснити, кому призначено результат і чому. Проведіть той самий синтетичний запис за заздалегідь погодженим правилом і збережіть обґрунтування. Знайомий логотип клієнта не замінює цієї перевірки. Наступні тестові записи — наші навчальні розробки, не реконструкція програми Canva. Використовуйте кейс для постановки запитань, а не приймання платформи чи оголошення переможця. impact.com — Canva

Картка вимоги повинна допускати негативний результат

Для кожної обов’язкової функції скопіюйте шаблон: «Бізнес-подія: ___. Вихідна система та ID: ___. Очікуваний партнер: ___. Очікуваний статус результату: ___. Очікуваний статус комісії: ___. Строк і часовий пояс: ___. Доказ: ___. Залежність від плану або налаштування: ___. Відповідальний: ___. Підсумок: пройдено / не пройдено / не продемонстровано». Не змішуйте бізнес-статус із термінологією постачальника.

Заповнений приклад: «Замовлення O-104 повністю повернене; вихідне повернення R-104; початковий партнер P-A; збереженого продажу немає; комісія до виплати відсутня; виправлення отримане до договірної фіксації; докази — запис повернення та пов’язана дія платформи». Знімка зменшеного підсумку панелі недостатньо: він не показує виправлене замовлення. Потрібне вивантаження або картка, за якою другий співробітник відтворить звіряння того самого ID.

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

Сценарій 1: магазин перевіряє замовлення, повтори та повернення

Бриф і матеріали. Навчальний магазин продає звичайні настільні аксесуари через погоджених контентних партнерів. Підготуйте посібник із вибору, посадкову сторінку товару й окреме посилання партнера. Правило приймання — одна комісія за прийняте замовлення та документований порядок повного повернення. Підготуйте O-101 як звичайне замовлення, O-102 для повторної доставки, O-104 для повного повернення, O-109 із невідповідною валютою. Це синтетичні записи дозволеного тестового середовища, не покупці.

Шаблон реєстру: «ID замовлення | партнер | час події | час отримання | початкова сума та валюта | ID повернення | остаточна прийнята сума | ID запису платформи | рішення щодо комісії | причина». Для O-101 очікується один прийнятий продаж. Для O-102 повторно передайте подію та очікуйте один бізнес-результат. Для O-104 оформіть повне повернення й очікуйте скасування початкового результату. Для O-109 використайте невідповідну валюту: очікується розбір розбіжності, а не довільний перерахунок.

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

В impact.com покажіть дію pending та дату її фіксації, а потім виконайте повне скасування до цієї дати. Довідник розрізняє ідентифікатори action та комбінацію замовлення з типом події, описує зміни на рівні замовлення й позиції. Використовуйте набір ідентифікаторів, необхідний для налаштованого методу. Не можна навмання замінювати транзакцію від’ємною сумою. impact.com: action and conversion fields

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

Заповнений навчальний результат. O-101 залишається прийнятим. O-102 після повторної доставки вказує на вихідний бізнес-результат. O-104 пов’язаний із поверненням R-104 і більше не створює допустимої комісії за правилами прикладу. O-109 залишається нерозібраним із призначеним інженером: це не прийнятий продаж і не невдалий покупець. Такий запуск не проходить приймання, доки для O-109 немає документованого рішення. Доказом є пов’язані записи та причини, а не зменшений підсумок панелі.

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

Сценарій 2: B2B-сервіс перевіряє угоди та повторні оплати

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

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

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

API транзакцій вимагає один спосіб зазначення клієнта, суму в сотих частках указаної валюти та код валюти; також передбачено ідентифікатор підписки. Явно зіставте поля. Посібник webhook вимагає наявних клієнтських записів, правильного збігу ідентифікаторів і роботи розробника. Назва підтримуваного провайдера не підтверджує правильного налаштування вашого акаунта. Перевірте відсутній зв’язок із клієнтом: як виявляється помилка й відновлюється запис. PartnerStack: transaction API PartnerStack: payment webhooks

Демонстрація impact.com. Запитайте налаштовану батьківську подію, наприклад прийнятий пробний період, і наступний платіж із тим самим customer ID. Спочатку передайте батьківську подію. Потім у дозволеному тестовому процесі подайте дочірню подію без потрібного зв’язку: інженер має знайти розбіжність і показати підтримуване відновлення. Перевірте, що повернення продовження не стирає чинне початкове залучення. Документація допускає окреме скасування батьківських і дочірніх дій; уточніть фактичне налаштування. impact.com: chained actions

Заповнений навчальний ланцюжок підписки. ORG-DEMO закріплена за P-A після перевірки права на результат. D-DEMO залишається непідтвердженою до перевірки продажів; один пробний період за умовами прикладу не дає допустимої комісії. Клієнт C-DEMO та підписка S-DEMO пов’язані з першою перевіреною оплатою I-FIRST і продовженням I-RENEW. За повернення I-RENEW скасуйте право на комісію саме цього продовження, зберігши дійсну першу оплату та історію залучення. Окрема відкрита угода залишається відкритою з відповідальним. Скасування майбутнього продовження не дорівнює поверненню минулого рахунку.

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

Матриця приймання та робочий лист для копіювання

Заповніть однаковий лист для кожного кандидата й порівняйте докази. Статуси нижче — бізнес-очікування навчального пілота, не універсальні назви статусів платформ. Поруч запишіть фактичний статус екрана чи вивантаження. Відсутність результату означає «не продемонстровано», а не успіх. Лист можна використовувати тут без завантаження.

Завантажити робочий лист у текстовому форматі UTF-8

РОБОЧИЙ ЛИСТ ПРИЙМАННЯ ПІЛОТА
Порожні поля — копіювати для кожного кандидата
Кандидат / версія налаштування: ___
Продукт / допустимий ринок / модель партнерства: ___
Власник / інженер / другий перевіряльник: ___
Тестове середовище / доказ ізоляції виплат: ___
Вихідна система / бізнес-ID / ID платформи: ___
ID клієнта / підписки / рахунку / повернення: ___
Очікуваний партнер / версія правила атрибуції: ___
Бізнес-статус до → після: ___
Очікування комісії / фактичний статус постачальника: ___
Час події / отримання / часовий пояс: ___
Строк перевірки / межа фіксації або рахунку: ___
Доказ / власник помилки / дата повторного тесту: ___
Підсумок: ПРОЙДЕНО / НЕ ПРОЙДЕНО / НЕ ПРОДЕМОНСТРОВАНО

МАТРИЦЯ — застосувати до обох кандидатів
ЗАМОВЛЕННЯ: прийнято → один простежуваний бізнес-результат.
ПОВТОР: та сама подія → немає додаткової допустимої комісії.
ПОВЕРНЕННЯ: повне до межі виправлення → вихідний результат недопустимий, причина збережена.
ПІЗНО: виправлення після межі → документована ескалація, без прихованого перезаписування історії.
ПРОБА: без перевіреної оплати → немає допустимої комісії за правилом пілота.
ОПЛАТА: перша перевірена → той самий клієнт, погоджений партнер, пов’язаний рахунок.
ПРОДОВЖЕННЯ: наступна оплата → та сама підписка, окремий ID рахунку/події.
ЗМІНА: підвищення/пониження рівня → записаний перехід, не нове залучення.
СКАСУВАННЯ: майбутні продовження вимкнені → немає майбутнього продажу, попередній дійсний рахунок збережено.
ПОВЕРНЕННЯ ПРОДОВЖЕННЯ: виправлено продовження, початкове залучення збережено.
НЕМАЄ ЗВ’ЯЗКУ: відсутній клієнт → видима помилка та підтримуване відновлення.
КОНФЛІКТ: два претенденти → рішення про право до підтвердження.

ЗАПОВНЕНИЙ НАВЧАЛЬНИЙ ПРИКЛАД — синтетичний, не тест постачальника
Кандидат: демонстрація A; налаштування DEMO-v1.
Джерело: навчальний реєстр білінгу; перевіряльник: роль контролю.
Зв’язки: C-DEMO / S-DEMO / I-RENEW / R-RENEW; партнер P-A.
До: продовження оплачено, комісія очікує перевірки.
Вхід: повне повернення R-RENEW до погодженої межі перевірки.
Очікування: продовження повернено, його комісія недопустима.
Зберегти: I-FIRST і початкове залучення.
Навчальне спостереження: пов’язане продовження виправлено, вихідний запис збережено.
Доказ: рядок навчального реєстру та пов’язаний демонстраційний запис.
Підсумок: ПРОЙДЕНО для цього рядка, не приймання платформи.
Відкрито: шлях пізнього виправлення не показано; власник — інженер.
Загальне рішення: СТОП до доказів пізнього виправлення та повторного тесту.

ЧЕКЛІСТ І РІШЕННЯ
[ ] Безпечний маршрут і виключення реальних виплат підтверджені.
[ ] Обидва кандидати отримали однакові записи та правила.
[ ] Кожний обов’язковий рядок має доказ і перевіряльника.
[ ] Немає допустимих дублів, утрачених зв’язків і непояснених скасувань.
[ ] Відкриті помилки видимі; записано строки та відповідального за ескалацію.
[ ] Вивантаження дозволяє незалежно повторити зіставлення.
ПРОЙДЕНО лише після успіху кожного обов’язкового рядка.
Розбіжність — НЕ ПРОЙДЕНО; СТОП розширенню за провалу чи відсутності демонстрації.
Після виправлення повторити проблемний запис і звичайний контроль.
Рішення / обмеження / наступний дозволений крок / перевіряльник / дата: ___

Вибирайте за доказами й обмежуйте наступний крок

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

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

Для окремого маршруту через CPA-мережу приходьте з визначенням події та умовами офера до кабінету рекламодавця AffiliateCore. До запуску підтвердьте придатний процес для продукту. Порівняння постачальників і реєстр пілота автоматично не переносяться. Сусіднє організаційне питання розібране в посібнику з передачі обов’язків програми; результат цієї статті — приймання конкретного продукту.