Add Real-Time AI Lead Classification Architecture To Your Website

Step 1: Capture the submission and measurement context

The form sends its normal fields to a server-controlled endpoint. Depending on the form, these might include:

• name;
• business email;
• company;
• phone number;
• message;
• selected service or enquiry type;
• page URL or form ID.

The submission can also include measurement context that will be needed later, such as:

• a first-party submission ID;
• GA4 client_id;
• GA4 session_id;
• landing page and referrer;
• UTM parameters or stored attribution values;
• advertising click identifiers where their collection and use are permitted;
• the relevant consent state at the time of submission.

These identifiers allow a later validated event to be associated with the original visit. They should be captured deliberately and stored in fields designed for that purpose.

The raw form message should never be sent to GA4. Google Analytics policies prohibit sending information such as names, email addresses and phone numbers to Analytics. GA4 should receive the classification outcome and appropriate pseudonymous measurement identifiers, rather than the contents of the enquiry. See Google’s guidance on avoiding personally identifiable information in Analytics.

Step 2: Persist the enquiry before calling AI

This is the most important reliability rule in the architecture:

Store the submission successfully before asking an external model to classify it.

The initial record could be created in the website database, the CRM, a form platform or a dedicated lead store. At this point, its status might be:

classification_status: pending

lead_status: unvalidated

Once storage succeeds, the website can return a success response to the visitor. The AI call may begin immediately, although the visitor’s confirmation page no longer depends on its result.

This protects the enquiry from:

• model timeouts;
• provider outages;
• rate limits;
• invalid model responses;
• failures in GA4, the CRM or an automation platform.

It also creates a reliable record for retries and audits. If a downstream step fails, the system knows which submission remains incomplete.

Step 3: Minimise the payload sent to the classifier

The classifier only needs information that helps it determine intent.

For many contact forms, the message, selected enquiry type, company name and a limited amount of context may be sufficient. A phone number, full postal address, tracking identifiers and most hidden fields usually add little value to the classification.

A preprocessing step should build a separate payload for the model. For example:

{

  "form_type": "general_contact",

  "selected_topic": "other",

  "company": "Example GmbH",

  "message": "We are reviewing our GA4 and HubSpot setup and would like help fixing attribution.",

  "current_customer": false

}

The exact fields depend on the purpose, lawful basis and data-processing arrangements of the implementation. Under GDPR, data minimisation requires personal data to be adequate, relevant and limited to what is necessary. The AI provider also becomes part of the processing chain, so its contract, retention controls, processing locations and sub-processors need to be assessed. The relevant requirements are set out in the General Data Protection Regulation.

Provider claims should be checked at the product and account level. For example, the official OpenAI API documentation states that API data is excluded from model training unless the customer opts in. It also explains that abuse-monitoring logs may retain customer content for up to 30 days by default, while approved customers can access additional retention controls. See the current OpenAI API data controls.

Step 4: Request a structured classification

Free-form model responses create unnecessary failure points. A response such as “This appears to be a reasonably strong lead” still requires the application to interpret the wording.

The classifier should return a fixed data structure. For example:

{

  "classification": "sales_lead",

  "reason_code": "explicit_service_interest",

  "review_required": false

}

The allowed values should be constrained by a schema:

classification:

  sales_lead | support | partnership | spam | uncertain


reason_code:

  explicit_service_interest | product_question | existing_customer_help |

  commercial_proposal | irrelevant_solicitation | malicious_content |

  insufficient_information | conflicting_signals


review_required:

  true | false

Structured-output features can ensure that a response follows the supplied JSON schema and uses valid enum values. OpenAI documents this capability in its Structured Outputs guide.

Schema compliance solves the formatting problem. Classification quality still depends on the business definitions, prompt, examples, model and testing data.

Avoid treating a model-generated confidence percentage as an objective probability. A value such as confidence: 0.94 can look precise without being calibrated against your own lead history. It is safer to define observable decision rules, use an uncertain outcome and measure accuracy on labelled submissions.

Step 5: Apply deterministic business rules

The model proposes a classification. A policy layer decides what the system does with it.

Example rules could be:

IF classification = sales_lead

  THEN mark lead as qualified_by_ai

  AND create sales task

  AND enqueue validated conversion events


IF classification = support

  THEN route to support

  AND suppress sales conversion event


IF classification = partnership

  THEN route to partnerships

  AND suppress sales conversion event


IF classification = spam

  THEN quarantine submission

  AND suppress marketing conversion event


IF classification = uncertain OR review_required = true

  THEN queue for human review

  AND keep lead status unvalidated

The policy engine can also combine AI output with deterministic signals. Examples include:

• a honeypot field completed by a bot;
• an email domain on a known suppression list;
• an explicit “I am an existing customer” form selection;
• a product-specific form that has a narrower definition of intent;
• repeated identical submissions in a short time window.

Keeping these rules outside the prompt makes them visible, testable and easier to change.

Step 6: Update the CRM and marketing systems

Once the policy engine accepts the submission as a valid sales lead, it can create the downstream signals.

CRM

The CRM record can store fields such as:

lead_classification: sales_lead

classification_method: ai_realtime

classification_model_version: [internal version]

classification_reason: explicit_service_interest

classification_timestamp: [timestamp]

review_status: not_required

These fields provide operational context and make later quality analysis possible. A sales representative can still correct the status. That correction becomes valuable evaluation data for the classifier.

GA4

The server can send a validated event such as generate_lead or a carefully named custom event using GA4 Measurement Protocol. For a web stream, the request uses the measurement ID and API secret, while the payload uses the website’s client_id. Parameters such as session_id and engagement_time_msec affect how the activity appears in reporting. Google also recommends that events intended to join client-side activity arrive within 48 hours of the original event. See the current GA4 Measurement Protocol sending guide and protocol reference.

Only analytics-safe fields should be included. A useful payload may contain the classification method, form type and lead category. It should exclude the person’s name, email, phone number and message.

Advertising platforms

Each advertising platform has its own conversion requirements. A validated GA4 event can be imported into Google Ads, or the implementation can use a platform’s server-side conversion mechanism where appropriate.

Sending the event is one part of the setup. The conversion action must also be configured as the campaign’s optimization goal before automated bidding uses it as a primary signal.

The original form submission may still be recorded internally as a separate operational event. The validated lead event should represent the outcome the advertising system is expected to optimize toward.

Step 7: Design the failure paths

A production architecture needs explicit outcomes for every dependency.

Idempotency is especially important. A retry should complete the missing operation without creating a second CRM record or a second conversion.

The system should therefore store the state of each destination separately:

submission_saved: true

classification_complete: true

crm_synced: true

ga4_event_sent: false

ads_event_sent: false

This is more reliable than a single status such as complete, because it shows exactly where the workflow stopped.

Step 8: Test the classifier before it controls conversions

Begin with a labelled set of historical submissions. Each example should have a business-approved category.

Test the architecture on:

• clear sales enquiries;
• vague messages;
• existing-customer support requests;
• job applications;
• agency and vendor pitches;
• guest-post requests;
• multilingual submissions;
• obvious and subtle spam;
• messages containing prompt-injection instructions;
• messages that combine two intents.

Measure the results by class, because overall accuracy can hide the error that matters most. A classifier can appear accurate when spam represents most of the sample while still rejecting valuable sales enquiries.

For conversion tracking, two measures are especially useful:

• Sales-lead precision: Of all submissions classified as sales_lead, how many were genuine sales enquiries?
• Sales-lead recall: Of all genuine sales enquiries, how many did the classifier identify?

A false positive pollutes campaign optimization. A false negative can hide a real lead from measurement or routing. The business should decide which risk deserves stricter controls.

A sensible rollout can run the classifier in observation mode first. Record what it would have decided, compare those decisions with human outcomes and activate automated routing only after the results meet agreed thresholds.

What to monitor after launch

Classification performance will change as forms, campaigns, products and spam patterns change. Monitor:

• volume by classification;
• percentage sent to uncertain;
• false-positive and false-negative rates from reviewed samples;
• model latency and timeout rate;
• retry volume;
• cost per classified submission;
• disagreement between AI classification and eventual CRM status;
• conversion volume before and after validation;
• campaign performance using the new optimization signal.

Store an internal classifier version alongside every decision. When the prompt, taxonomy, model or rules change, increment that version. This makes it possible to compare performance across changes and investigate unusual results.

When real-time architecture is the right choice

Real-time classification is most useful when the classification needs to trigger an immediate operational or measurement action. Examples include instant sales alerts, lead routing, rapid follow-up and same-session conversion signalling.

An asynchronous batch or delayed workflow may be simpler when submissions are reviewed later, immediate routing has little commercial value or the business wants CRM enrichment before deciding lead quality.

The choice depends on the required speed, submission volume, available infrastructure and acceptable operational complexity. Both approaches can produce a validated lead signal. The real-time version earns its additional complexity when a decision within seconds creates practical value.

The architecture separates capture from interpretation

A contact form records what a visitor submitted. The business still has to decide what that submission means.

AI can make that interpretation quickly enough to improve routing and conversion measurement. Its output should sit inside a controlled architecture: the enquiry is stored first, the model returns a constrained classification, deterministic rules decide the action and each downstream system receives only the data it needs.

That turns AI lead classification from a prompt attached to a form into a reliable measurement process.

If your current tracking sends every contact form submission to GA4 and advertising platforms as a conversion, TrackFunnels can review the journey from form capture to CRM qualification and campaign optimization.

Request a Tracking Reliability Review →