VASUYASHII

First-party analytics implementation

Confirmed Website Lead Tracking: Implementation Case Study

VASUYASHII changed its website enquiry flow so a button press was no longer counted as a lead. The form now waits for a readable backend acknowledgement, treats rejected requests as failures, and emits generate_lead only when a new lead identifier is confirmed.

Evidence date
14 July 2026
Useful for
Service websites that use forms, WhatsApp, demos, and GA4
VASUYASHII contact page with project enquiry form and direct contact options
Current contact experience used by both direct and contextual service enquiries. The screenshot proves the interface, not a lead-volume outcome.

2

Form implementations

Homepage and dedicated contact-page variants use the same submission contract.

4

GA4 events verified

WhatsApp, demo, contact, and confirmed lead events appeared in Realtime.

1

Confirmed lead contract

generate_lead requires a backend-issued leadId.

0

PII fields sent to GA4

Analytics receives event context, not name, phone, email, or message values.

Context

What was being solved

The earlier enquiry implementation used an opaque no-cors request and emitted generate_lead from the raw submit interaction. That design could not read the backend response, so analytics could describe an attempted submission as a successful lead even when storage failed or the endpoint rejected the request.

The correction focused on evidence, not on adding more tracking. A valid lead needed a readable response, an accepted status, and a new backend identifier. Failures needed their own signal, and service context needed to remain useful without sending personal form values to analytics.

This is a first-party website engineering case study. It verifies the form and analytics contract. It does not claim that the change increased conversion rate, enquiry quality, sales, or revenue.

Constraints

The implementation had to solve more than the visible screen.

01

Opaque no-cors responses prevented the frontend from proving whether the backend accepted the enquiry.

02

A document-level submit listener could count validation failures, network failures, rejected requests, or duplicate attempts as leads.

03

Service and product CTAs needed to preserve context through the contact URL, form selection, stored lead, and analytics event.

04

GA4 needed useful funnel events without receiving names, phone numbers, email addresses, messages, or other PII.

Decisions

The choices that controlled the final implementation

01

Require a readable acknowledgement

The frontend sends URL-encoded lead data to the configured Google Apps Script endpoint and parses JSON. A non-2xx response, invalid JSON, or a result without ok: true is treated as a submission failure.

02

Confirm the new record before generate_lead

The form emits the internal lead-confirmed event only when the accepted response includes a leadId. Analytics listens for that confirmation instead of the raw submit event.

03

Track failure separately

Rejected or failed requests emit lead_submission_failed, allowing delivery problems to be diagnosed without inflating successful lead counts.

04

Carry non-PII service context

Declared service keys flow from CTA URLs into form preselection, backend lead context, and analytics parameters. The event excludes name, phone, email, and message values.

Delivered scope

What can be verified in the implementation

A shared submitEnquiry contract that validates HTTP status, JSON parsing, and ok: true acknowledgement.

Homepage and contact-page forms that show success only after the accepted backend response.

Confirmed lead and failed submission browser events with stable form, method, and service context.

Delegated GA4 tracking for whatsapp_click, demo_open, contact_click, generate_lead, and lead_submission_failed.

Contextual contact URLs that preselect the relevant service without exposing personal data in analytics.

A documented rule that generate_lead must never return to the raw document submit listener.

Validation

What was checked

  • Mocked browser checks covered accepted responses with leadId, rejected responses, invalid acknowledgements, and visible success and error states.
  • Targeted lint checks and the 706 of 706 production build passed when the reliability correction shipped.
  • whatsapp_click, demo_open, contact_click, and generate_lead appeared in GA4 Realtime during manual verification.
  • generate_lead was marked and verified as a GA4 key event.
  • Current source code keeps the submission contract in lib/enquiry.js and the confirmed event in both form implementations.

Claim boundaries

What this evidence does not prove

  • Realtime event visibility proves event delivery during the test session; it does not prove attribution accuracy across every browser or consent state.
  • No conversion-rate, lead-volume, lead-quality, sales, or revenue uplift is claimed.
  • The Google Apps Script endpoint must continue returning CORS-readable JSON with ok: true and a leadId for confirmed new records.
  • Ad blockers, consent choices, network conditions, and analytics configuration can affect event visibility independently of lead storage.

Evidence sources

Pages and references used

Continue the review

Related implementation guidance

Start with one verifiable workflow.

Share the current records, users, steps, exceptions, and desired decision. VASUYASHII will compare a ready product, integration, website, or focused custom build without assuming unsupported scope.

Discuss a focused first phase