Enquiry analytics: measure the events that matter

Opening a form shows interest; starting it shows intent; confirmed delivery means the system accepted an enquiry. Qualification and sales happen later.

Name events accordingly. A “lead” triggered by every submit click overstates results when delivery fails.

A general delivery event can have form-specific subsets. Adding the subsets to the total double-counts the same outcome.

A server-side enquiry identifier helps reconcile delivery and handling without putting contacts into arbitrary analytics fields.

Source, campaign, page, language and form type often support service comparisons. Free-text messages and phone numbers are unnecessary for that purpose.

Check client-side navigation for missing or duplicated views. Analytics failures must not prevent form delivery.

Compare accepted forms, records in the work system and handling outcomes. A conversion decline may reflect traffic changes, technical failure or delayed responses.

Locate the gap between stages. Use agreed, labelled test enquiries and assess meaningful outcomes rather than clicks alone.

Consider one visitor: they read an article, open a form, start filling it out, press submit, receive delivery confirmation and are later qualified by a manager. Analytics records several stages; sales records one enquiry.

An “article → confirmed enquiry” funnel helps explain a journey within one visit. It does not add another enquiry to the aggregate delivery goal. If the person returns several days later, a Metrika composite goal will not join those visits: that requires a separate attribution model and actual enquiry records.

A phone or Telegram click does not establish that a conversation happened either. Track it as contact intent and reconcile it with actual calls or messages rather than automatically counting it as a sale.

A CRM or a restricted working spreadsheet can be a starting point if someone is responsible for maintaining it. Each enquiry needs a stable ID, time, source, requested service, current status and rejection reason. Contact details belong in the customer workflow; free-text messages are not needed in general event parameters.

Agree on status definitions. For example, “qualified” could mean a manager confirmed a real task, an appropriate client profile and a basis for further discussion. A signed agreement and a payment record different facts. Do not replace missing information with zeroes or treat every delivered form as a suitable customer.

Offline conversions come after these records and the identifiers needed for matching are in place. After an upload, check whether events matched visits as well as whether the file was accepted. An unmatched record calls for investigating the cause, not inventing a conversion.

Use one period and consistent rules for test submissions, duplicates and spam. Compare enquiries accepted by the server, records in the CRM or spreadsheet and Metrika events. These totals can differ because of tracking blockers or incomplete attribution; reconciliation should explain the difference rather than conceal it.

To calculate cost per qualified enquiry, divide channel spend by the number of enquiries meeting the agreed definition. State whether taxes are included and which costs count. For a long sales cycle, compare enquiries from one period with their later outcomes: a recent enquiry has not yet had time to become a contract.

After fixing a form, check empty and invalid fields, repeated submissions, an unavailable recipient system and a separately marked test enquiry. Then wait for a comparable flow of visitors. More traffic and more clicks alone do not establish better enquiry quality.