An event map makes analytics setup easier to accept: it connects each action to a precise trigger and a controlled check. The client can see what is being measured, and the developer knows when to send the event. The document stays with the team after implementation.
Below is a working example for a service website with one enquiry form. It is an educational specification, not DDRW measurement results. Our website analytics guide covers metrics, funnels and acquisition sources. This article has a narrower purpose: agree on five actions and verify a particular setup.
For implementation, the analytics and event setup package covers one existing website, one platform and up to five agreed events on existing elements.
Define the measurement boundary
Suppose a company receives website-development enquiries. Visitors can choose a service, open a form, submit an enquiry or follow a messenger link. The owner first identifies the questions: do visitors find the form, where does an error occur, and does an attempt reach confirmed storage?
Record the website address, analytics platform, counter or property, relevant pages and business owner. Separately record the conditions for diagnostic checks: browser, device, analytics consent state and how test activity will be kept out of business conclusions.
Five events are the scope of this example, not a universal minimum. If the website has no service selector, replace that row with another useful existing action. Building a new selector merely to populate a report is outside analytics setup.
Each event needs someone who owns its meaning. Marketing explains why it matters, the developer identifies the trigger, and the person accepting the work compares that trigger with website behaviour. A technical name alone cannot replace this agreement.
Complete the five-action map
The identifiers below are illustrative. Adapt them to the chosen platform and existing configuration, checking whether the same fact is already collected automatically or by another handler.
| Event | Send it when | Do not send it when | Controlled check |
|---|---|---|---|
service_select | The visitor changes the existing service selector | A default value is assigned on page load | Choose another service and check its code |
contact_open | A visitor action actually opens the form | A button is clicked but the form does not appear | Open the form and observe one call for that opening |
brief_error | A submission attempt displays an agreed error | Someone is merely typing in a field | Submit without the required contact and check the error category |
brief_saved | The application confirms that a new enquiry was stored | There is only a click, a pending request or a rejection | Submit a sample enquiry and verify the confirmed record |
messenger_click | The visitor activates the selected messenger link | The link merely enters the viewport | Activate the link and check the channel code |
An error category such as contact_missing is sufficient. Do not include the visitor's contact details or complete message. For the service, use a limited set of codes such as website and portal, rather than arbitrary form text.
Yandex Metrica can receive a custom goal through reachGoal. The identifier must match the appropriate goal in the counter. Calling the method sends an analytics signal; the website team still defines the business meaning behind it.
Separate an enquiry, a click and a later conversation
In this example, brief_saved means the website confirmed storage of an enquiry. It does not mean a manager has read it, the prospect is suitable or a contract has been signed. Those stages require records from the relevant business system and a separate integration scope.
messenger_click indicates an intention to use a contact channel. The visitor may never open the app, send a message, or may return later on another device. Adding these clicks to stored enquiries under a heading such as “received leads” requires an explicit explanation of what that total means.
An acceptance log can state: “The website stored the enquiry and the event appeared in diagnostics.” If the website confirms storage but the signal is missing, investigate collection. If the signal exists without a stored enquiry, review its trigger. Check the numbers together with their meaning.
Delivery to the team is another part of the journey. Our Telegram or CRM connection specification describes that part, keeping analytics acceptance and enquiry-delivery acceptance separate.
Check duplicates, back navigation and failures
Complete the normal journey once, then repeat it after navigating to another section. This matters especially on a website that changes screens without a full reload: the form may mount again while an old handler remains active. Two subscriptions can produce two signals for one action.
Check a double click, back navigation, closing and reopening the form, a validation error, a server rejection and another attempt after that rejection. Write down the expected count first. A second intentional form opening may be another event; a repeated confirmation of the same stored enquiry is not a new enquiry.
For GA4 pageviews, agree on a single measurement method as well. Google's page_view documentation describes the risk of duplicates when automatic and manual collection overlap. For History API navigation, inspect history measurement settings separately: changing only the initial configuration may not be enough.
A clean result in one journey does not prove that every possible duplicate has been eliminated. List the checked paths and known limitations in the acceptance record so that the checks can be repeated after the next website change.
Limit parameters and keep a verification record
This example needs only the service code, form location, error category and messenger channel. Names, phone numbers, email addresses, enquiry text and secret URL parameters are unnecessary. Google describes its restrictions on personally identifiable information, including information passed through page URLs and titles.
The owner should agree on the analytics notice or consent approach before implementation. A diagnostic check must not bypass a visitor's refusal, browser restrictions or blocking tools to make a report look complete. Record collection limits as conditions, rather than concealing a difference from administrative records.
The handoff can contain three sheets: the event map; a controlled-action log with date, environment and result; and instructions for finding the settings and reporting a problem. Diagnostic screenshots should not expose real contact details or access keys.
Completion has a concrete definition: every agreed event has a clear trigger, a controlled call shown in available diagnostics, and a check for extra calls in the described journey. Installing analytics does not promise more sales or replace assessment of enquiry quality.
What the DDRW package covers
Analytics and event setup covers one existing website and one platform: Yandex Metrica or Google Analytics 4. It includes up to five agreed events, an event map and a verification walkthrough. Access and implementation compatibility are agreed before work starts.
Ecommerce measurement, CRM, server-side tracking, BI dashboards, new forms and legal assessment of data-processing rules need a separate brief. Current prices and terms are on the service page. To start, prepare the website address and the actions whose meaning you want to see in a report.
