← CasesMeasurement audit and architecture

Distinguish a first subscription payment from access and renewal

Audited the site → bot → payment journey, investigated missing advertising results and specified three acquisition signals.

Production fixes and a safe Purchase implementation are unproven.

Evidence as of: 2026-08-08
Contract diagram: Lead, payment start and confirmed first purchase; renewal and access remain separate.
Requirements diagram based on the 8 August 2026 audit. A new production Purchase implementation is unproven.
00

Role of [NERD-METHOD]

Audit of the website, SendPulse and Meta, event definitions, data-handoff specification and acceptance scenarios.

01

The original task

In a paid Telegram community, the website visit, contact creation, payment start and access grant happened in different places. The task was to understand why advertising results differed from technical events and define reliable signals of subscription acquisition.

02

What the audit changed

A later inspection on 8 August 2026 found that advertising identifiers already reached SendPulse in the inspected sample. The hypothesis that all context was lost on the website was not supported. The audit separated an advertising-account restriction, an event-source mismatch with the selected result and unstable event identifiers.

03

How we defined the events

Lead belongs at a stable eligible-contact creation point. InitiateCheckout belongs at the actual start of a payment journey. Purchase requires a confirmed first payment and a stable payment-object ID. An access grant, restoration and renewal carry different meanings and cannot stand in for a first purchase.

04

What we prepared

A specification for advertising fields and click context, a site-and-bot map, event triggers and repeat-delivery rules. It covers direct sending and relay options, when each is justified and how to test platform boundaries. An additional backend was not treated as mandatory without an established need.

05

What the evidence establishes

The evidence supports a partial audit of existing surfaces and a technical implementation package. A separate audit finding was that a stable provider payment ID was not established in the inspected actions. Purchase therefore cannot be considered safe for production sending. A new release and growth in paid subscriptions are unproven.

06

How implementation should be accepted

Trace one eligible contact and one confirmed first payment through to the receiving system; replaying the same payment must not create another purchase. Test renewals and restorations separately. These are criteria for future implementation, rather than completed acceptance of the audited system.

Discuss your task

We agree the scope, price and acceptance checks after your brief.

CONTACT / START WITH REALITY

Where does the journey break?

Three fields are enough for a first technical look: the problem, desired outcome and reply contact.

Open the full contact page→