Analytics becomes misleading when a click, a successful request, and a completed business action are all called a conversion. Ask the website agency to define what each event proves before adding tags.
Related service: Website and ecommerce development- 01Define the business action
- 02Choose the verified trigger
- 03Limit event fields
- 04Test normal and failure paths
- 05Compare with operational records
SECTION 01
Write the event meaning in ordinary language
Choose the decisions the business wants to make: whether visitors reach service details, start an inquiry, or successfully submit one. Give each event an exact meaning. Record which component emits it and what happens when the visitor refreshes, goes back, or retries. Avoid several unrelated implementations using the same event name differently.
Google Analytics documents event names and parameters, while MDN describes browser mechanisms for sending small analytics payloads. Sending a payload does not prove that the business task succeeded or that every report will contain it. The agency's deliverable should include a tested measurement design, not simply an installed analytics script.
SECTION 02
Illustrative example: a form records two successes
Imagine a service website sends a lead event when the button is clicked and again when the thank-you page loads. One accepted inquiry can appear as two conversions, and a rejected submission may still count once. The dashboard looks active while the underlying definition is wrong.
A corrected design distinguishes form start from accepted inquiry. It uses the backend result for the completion event and an appropriate reference or deduplication mechanism without exposing personal details. Test direct visits to the thank-you page and repeated requests. This hypothetical example shows why comparing analytics with a controlled set of synthetic inquiries is more useful than checking whether a graph increased.
SECTION 03
Commission verification and operating ownership
Ask the agency to demonstrate events for success, validation failure, network interruption, and consent refusal. Review the actual fields sent, not only the event count. Keep names, email addresses, message contents, and other unnecessary private information out of analytics. The business's responsible owner must approve collection and retention requirements.
Document known reporting limitations, such as browser restrictions and unavailable tracking, instead of promising perfect attribution. Check time zones and the distinction between test and production data. A smaller set of well-defined events is often more actionable than dozens of unexplained tags. Hand over the event dictionary, access ownership, test procedure, and change process so a later form redesign does not silently alter what the business believes it is measuring.
SECTION 04
Frequently asked questions
Should every click be a conversion?
No. Separate navigation or intent events from the completed actions relevant to the business.
Can analytics replace the inquiry database?
No. Operational records and analytics have different responsibilities and reliability assumptions.
Why might event counts differ from accepted requests?
Consent, browser behavior, delivery failures, test traffic, and duplicate rules can affect counts. Investigate definitions before assuming missing business records.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Set up eventsGoogle Analytics
- sendBeacon methodMDN Web Docs
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy