Setting up goals for a service website means agreeing which action counts as an enquiry, then checking that the analytics counter measures that action. In one focused session you can build an event map and test a form. You will come away with goal names, trigger conditions and a test record that the developer and marketer understand in the same way.
Start with a website that actually accepts enquiries. Prepare access to your own Metrica counter, a list of forms and a way to find a saved submission. Only someone with the appropriate permissions should change settings or code. An event map is enough for an initial review; access to customers’ data is unnecessary.
Break the journey into observable actions
Take one journey: a person opens an article, visits a service page, opens the form and sends an enquiry. For each step, write down what you know for certain. Opening an article confirms a page view, not that it was read. Clicking a telephone number indicates an intention to call, not a completed conversation. A successful form response should correspond to a record accepted by the server.
Here, the server means the software on the website’s side that validates and saves the data. A browser can display an attractive confirmation even when that software fails. Agree the main goal’s definition with the developer: when is an enquiry considered accepted, and where is the evidence stored?
| Action | What is known | How to count it |
|---|---|---|
| Form opened | The visitor started the journey | Supporting event |
| Telephone clicked | A contact method was opened | Separate click goal |
| Submission saved | The website accepted an enquiry | Main form goal |
| Request qualified by a manager | The enquiry is relevant | Status in the sales system |
Do not add the rows together as a “lead count”. One person can perform every action. A sale, an accepted enquiry and a telephone click describe different stages. If the business receives most enquiries by telephone, it needs separate confirmation of calls, rather than a renamed click event.
Create an event dictionary before changing code
Create one row for each event you need. Record a clear name, technical identifier, precise condition, trigger location and test. Names such as “Goal 7” become difficult to work with a month later. “Enquiry accepted: all forms”, with a separate parameter identifying the form location, is more useful.
Example names for discussion: lead_accepted means an accepted enquiry, form_open means a form was opened, and phone_click records a telephone click. These are examples, not existing identifiers in your counter. Check the current goals before adding anything: the event may already exist and only its condition may need fixing.
Metrica supports an event-based goal, with events sent through the reachGoal method. Its setup is described in the official instructions. Choose a goal type that matches how the form actually works. Finding the method in the code does not prove it runs after a submission has been saved.
Keep only supporting events that help you make a decision. If you need to understand movement from a useful article to a service, measure that transition. Dozens of events for every mouse movement make a report more complicated without explaining why the manager never received an enquiry.
Which parameters are useful?
For a form review, its location, service type and submission page are usually enough. Agree allowed values, such as “contacts”, “service” and “article”. If the same location is called “modal” in one place and “popup” in another, comparisons will require manual cleanup. Record spelling and capitalisation in the table.
Do not send names, telephone numbers, email addresses or free-text enquiries in ordinary event parameters or UTM tags. Metrica’s privacy rules describe restrictions on identifying information and exceptions for specifically supported features. A basic goal map does not need personal information.
Connect the event to an accepted enquiry
Ask the developer to describe form handling in four steps: field validation, saving the enquiry, responding to the browser and notifying the manager. Establish what happens if email delivery fails after a successful save. The enquiry should remain accessible to its owner; notification delivery needs a separate check.
The main goal needs a confirmed acceptance point. Browser-side field validation does not establish that. If the form displays “thank you” before attempting to send its request, analytics may report success before the result is known. Ask for the processing order to be checked; simply moving the message is not a sufficient diagnosis.
Agree how repeat submissions are handled. A visitor may click twice, reload the confirmation or go back. An internal reference for the accepted enquiry helps match those actions to a single record. Duplicate protection depends on the implementation. Disabling the button is helpful for the interface, but does not replace server-side checks.
Run a test with a result defined in advance
Tell the manager about one test enquiry on your own website. Use your own contact details and an explicit “TEST” label. First check that the form will not trigger a payment, reservation or sequence of customer notifications. Prepare a test copy with the developer for more complex scenarios.
- Record the date, URL, device, browser, form and counter number. Note the analytics preferences selected for this session.
- Open the form and leave a required field empty. There should be neither an accepted-enquiry goal nor an enquiry record.
- Correct the field and submit the agreed test. Find the saved record and compare its time with the event.
- Check the manager notification and selected service. Record each result separately.
- Reload the confirmation and go back. Check whether the same enquiry is counted again.
- Repeat the necessary checks on a phone and for another form implementation, if the website uses one.
For the newer counter, Yandex documents a debug panel enabled with _ym_debug=2; an earlier version uses a different method. Follow the goal testing instructions for your version. Match the counter number and event name, then check the report. A screenshot of the form’s green success message is not enough.
If the test is missing, check whether your own visits are filtered, the report period, selected goal, counter loading and analytics preferences. A missing event does not prove that an enquiry was lost: first find the website’s record. Test the website separately with analytics declined; submitting an enquiry must not depend on the counter loading.
Failure cases for the developer to test
On a test copy, add server failure, slow response and repeated-click scenarios. Define the expected outcome for each beforehand. If saving fails, there is no accepted enquiry and no success goal. If a response is lost, establish whether the record was created before the connection broke. Repeating a request must not create uncontrolled copies of an enquiry.
This tests a particular implementation; it does not promise exact agreement between every system. Browser analytics may miss accepted enquiries because of visitor settings, blocking or a closed page. The business’s own records establish whether an enquiry was received. Metrica helps investigate the observable journey leading to it.
A completed example record
Form on a service page. Goal condition: the server confirmed a successful save. Test with an empty telephone field: no record exists, but lead_accepted appeared. Finding: the goal name does not match its current trigger condition. Task: fire the event after confirmed storage. Acceptance: an empty form produces only a validation error; a valid enquiry creates a record and an event; reloading the confirmation does not produce another event for the same enquiry.
The example does not require an estimate of lost revenue. It identifies a reproducible mismatch between an event and an action. After the fix, record the date the logic changed: figures before and after that date cannot be compared as though the goal definition had stayed the same.
Preserve referral sources without confusion
Create a UTM naming convention for external publications: platform, channel, campaign and specific content item. For an example post, you might agree on source “telegram”, medium “social”, campaign “site_check” and content “post_01”. These are tracking labels, not evidence that a publication actually happened.
Open the tagged link, follow all redirects and confirm that it reaches the intended page. Save permitted tags with the enquiry if your system supports that. See Metrica’s documentation for tag creation and processing rules. Describe internal transitions from articles to services using a separate event and referring page, retaining the original external attribution.
When you do not need a new analytics system
If the existing counter measures the required actions, start by checking names and conditions. Creating a second counter or buying a complex system will not repair a goal that fires before storage. With a small number of enquiries, first establish a submission log and a regular reconciliation with the manager. Automatically combining channels makes sense after agreeing exactly what is being combined.
Terms to use with your contractor
- Event: a signal describing a particular website action.
- Goal: the rule analytics uses to count a selected action.
- Event parameter: an additional characteristic, such as form location.
- Attribution: the rule connecting a result to a referral source.
- Duplicate: counting the same enquiry again, which must be distinguished from a new request by the same customer.
Keep the event map and test record alongside the form documentation. If necessary, discuss a discrepancy with us, including the form URL, expected behaviour and an anonymised test result.
Apply this to your own task
Create an event dictionary and test one form with successful, invalid and repeated-submission scenarios.
Event map and form test record: open the worksheet · Download the CSV to complete. Free access, without registration. Use it yourself or share it with your contractor.