![[NERD-METHOD]](/brand/logos/short.svg){kind=small}
Роль [NERD-METHOD]
Аудит сайту, SendPulse і Meta, визначення подій, специфікація передачі даних та сценарії приймання.
Відокремити першу оплату підписки від доступу й продовження
Розібрали шлях сайт → бот → платіж. Уточнили причину відсутнього рекламного результату та підготували контракт трьох подій залучення.
Production-впровадження виправлень і безпечний Purchase не підтверджені.
Дата доказів: 2026-08-08
Початкова задача
У платній Telegram-спільноті перехід із сайту, створення контакту, початок оплати й надання доступу відбувалися в різних місцях. Потрібно було зрозуміти, чому рекламний результат відрізняється від технічних подій, і визначити достовірні сигнали придбання підписки.
Що змінив аудит
Пізніша перевірка 8 серпня 2026 показала, що рекламні ідентифікатори вже доходили до SendPulse у перевіреній вибірці. Гіпотеза повної втрати контексту на сайті не підтвердилася. Аудит відокремив обмеження рекламного акаунта, невідповідність джерела події налаштуванню результату та нестабільні ідентифікатори подій.
Як визначили події
Lead відповідає стійкій точці створення допустимого контакту. InitiateCheckout — реальному початку платіжного сценарію. Purchase має виникати після підтвердженої першої оплати зі стійким ID платіжного об’єкта. Надання доступу, відновлення та продовження мають окремий зміст і не підміняють першу покупку.
Що підготували
Специфікацію передачі рекламних полів і click context, карту сайту й бота, тригери подій та правила повторів. Описали пряму відправку й relay, умови вибору між ними та план перевірки меж платформ. Додатковий backend не оголошували обов’язковим без підтвердженої потреби.
Що доведено
Підтверджено частковий аудит наявних поверхонь і технічний пакет для впровадження. Окремий висновок аудиту: стійкий ID провайдера платежу в перевірених діях не встановлено, тому Purchase не можна вважати готовим до безпечної production-відправки. Новий реліз і зростання оплачених підписок не доведені.
Як приймати впровадження
Потрібно простежити один допустимий контакт і один підтверджений перший платіж до системи-отримувача; повтор того самого платежу не має створити нову покупку. Продовження й відновлення перевіряються окремо. Це критерії майбутнього впровадження, а не виконане приймання цього аудиту.
Обговорити задачу
Після brief погоджуємо обсяг, ціну та перевірки приймання.