A form attempt, a saved enquiry and a qualified lead are different events. Tracking all three as the same conversion makes analytics look healthier while hiding submission failures and low-quality contacts. Instrument the point at which the application actually persists the enquiry, then evaluate business quality separately.
The contract to define first
In AptixLabs’ contact implementation, the submission attempt is diagnostic and generate_lead is emitted after a successful Firestore write. That ordering provides a useful implementation example, not a guarantee that every recorded event represents a unique prospect. Test activity, repeated submissions, consent and analytics delivery can all affect the reporting view.
A worked scenario
A synthetic visitor presses submit, encounters a database error and retries successfully. The expected diagnostic history contains attempts and one successful persistence outcome. A browser email composer opening or being blocked should not redefine whether the enquiry was saved in the application.
An implementation and review sequence
- Define attempt persistence and qualification separately
- Emit the success event only after confirmed persistence
- Reconcile test and repeated activity before interpreting results
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| Database write fails | No successful saved-enquiry event is emitted |
| The visitor retries successfully | The success follows the persisted record |
| A test submission is recorded | It is not counted as a new qualified customer |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Client-side analytics can be blocked or delayed. The persisted enquiry store and analytics report serve different purposes and should be reconciled without exposing personal messages in reporting tools.
Where our product work provides context
The inspected AptixLabs contact code stores the enquiry before logging generate_lead and keeps contact_submit_attempt separate. The application’s enquiry persistence and a visitor’s email composer are different mechanisms. This example describes the current source ordering; it does not independently verify email delivery or classify every analytics event as a prospect.
Use the result to make a decision
The practical output is straightforward: show successful persistence versus attempts and test-event reconciliation. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Onboarding should lead to a real first task.
SaaS integration landing page content
References and current platform requirements
Google Analytics: recommended events
The linked references provide platform or process context. The worked scenario and acceptance matrix are original examples; adapt them to the actual product, supported environment and documented responsibilities.
Discuss the workflow
Bring one acquisition path and its enquiry-quality evidence to discuss measurement improvements.
Explore the relevant AptixLabs service
When should a form emit generate_lead?
A form attempt, a saved enquiry and a qualified lead are different events. Client-side analytics can be blocked or delayed.
Which failure cases should be included in the review?
Include these explicit cases: Database write fails: no successful saved-enquiry event is emitted; The visitor retries successfully: the success follows the persisted record; A test submission is recorded: it is not counted as a new qualified customer.