The report shows 40 conversions, but the team says it received only 25 inquiries. Before deciding who is wrong, establish what each is counting. A button click, a submission attempt and a saved inquiry are different events.
That distinction affects budget decisions. If the report counts an action that never completes, the campaign may be judged on results the business never receives. If the inquiry is saved but never reaches its owner, the problem lies further along the process.
We define the conversion as the real action we want, then check whether the implementation measures that action.
This article follows two related questions: whether the inquiry reached the business, and under what conditions it can be measured. That is why checking the form leads on to tracking, browsers and consent.
What does “sent the form” mean?
For a simple contact form, define success first: the data passes validation, the system accepts the submission and the team can find the record. The visitor’s confirmation should reflect what actually happened.
A project may connect a website, email service and CRM, the system used to manage customer conversations. Website acceptance does not prove that the email arrived or the CRM transfer succeeded. Check every relevant connection.
| Observed stage | What we know | What else needs to be checked |
|---|---|---|
| Button click | Someone attempted an action | Validation and successful submission |
| Inquiry accepted and saved | The system recorded the inquiry | Notification and pickup by the team |
| Event in the analysis tool | Measurement received a signal | Whether the signal matches the defined action |
| Qualified inquiry | The inquiry meets commercial criteria | Contact, proposal and subsequent progress |
Google Analytics documents the generate_lead event for generating an inquiry, for example through a form. The name does not verify the form: the team must define and implement the correct trigger. Recommended events in GA4
One inquiry. Three places to check.
An analytics event and an inquiry received by the team answer different questions.
FORM
- What does the user see?
- Validation and actual result
- Confirmation or error
REQUEST
- What does the team find?
- Retrievable record
- Notification and ownership
MEASUREMENT
- What reaches analytics?
- Defined signal
- Without unjustified duplication
Check all three against the same test submission.
Illustrative examples, not results from a NOT MORE. client.
A thank-you page confirms an action that has already succeeded
A confirmation page can explain the next step, the actual response interval and what the person can do in the meantime. It is also useful for certain measurement implementations.
But simply displaying that page must not create a new inquiry. What happens if the user reloads the page, returns from history or opens the link directly? The event chosen for a successful inquiry must be tied to actual success and protected against duplication in the implementation used.
Redirect only after success is confirmed. If the system reports an error, explain it and let the user recover without believing the message was received. A timer that always opens a thank-you page can hide the very failure we need to find.
An example of the difference that can be explained
Imagine a controlled test in which every attempt can be traced. The button is clicked 40 times. Ten attempts stop at validation, five encounter a submission error and 25 create accepted, saved inquiries. In this example, all 25 reach the team too.
| What we count in the test | Number |
|---|---|
| Button clicks | 40 |
| Validation failures | 10 |
| Submission errors | 5 |
| Inquiries accepted and saved | 25 |
If every click is reported as a successful inquiry, the count is 15 too high, or 60% above the 25 inquiries actually received. That is a measurement definition and implementation problem.
When we count the wrong step.
Fictional controlled test: every click has an identified outcome.
BUTTON CLICKS IN THE TEST
40
Validation failures
−10
Transmission errors
−5
Inquiries accepted and saved
=25
Reporting 40 inquiries instead of 25 overstates the total by 15, or 60%.
Illustrative examples, not results from a NOT MORE. client.
Real reports can differ for other reasons: reporting periods, time zones, filters, attribution or data collection conditions. Do not apply this example’s explanation to every discrepancy. Trace identifiable cases through the full journey.
Test what happens when something goes wrong
A single successful submission does not cover all relevant situations. The acceptance test should include behaviors that may occur in normal use.
| Situation | Expected result in the example |
|---|---|
| Valid data and successful submission | A saved inquiry, correct confirmation and the defined signal |
| Required field not completed | A clear explanation; no success signal |
| Submission service error | Visible error; no false confirmation |
| Double click or reload | Check that the same action is not duplicated |
| Inquiry saved, notification failed | The inquiry remains recoverable and there is a way to handle the error |
Repeat relevant cases on mobile and desktop. With external forms, booking systems or payments, check the handoff between systems. A booking may need an available slot confirmed; a payment can pass through several statuses. Define the conversion to match the actual process.
Where we check the signal and where we check the request
Debugging tools show which events are sent and what they contain. GA4 DebugView, for example, lets you inspect events from a device with debug mode enabled. DebugView Documentation
At the same time, verify the inquiry where it is saved and where the team handles it. An analytics event does not confirm email delivery. A received email does not confirm that an analytics event was sent only once.
Tests must respect collection conditions, including configured consent choices. Do not expect every inquiry to appear identically in every tool. Keep contact details out of event names and page URLs.
Tracking connects the action to the report
Tracking records relevant events and sends them to analytics or advertising tools: visits, form starts, confirmed inquiries and orders. What an event means, where it is sent from and the conditions under which it can be used all affect reporting.
A tag is a code component that participates in this measurement. Its installation is only part of the implementation. We need to know what action triggers it, what information it sends, to whom and with what permissions.
Tracking in the browser and tracking on the server
With client-side tracking, code runs in the visitor’s browser and sends events. In server-side tagging, an organization-controlled server receives and processes data before forwarding it to configured destinations. The browser may still be the original source. Google: introduction to server-side tagging
| Variant | Where the event starts | What to understand |
|---|---|---|
| Client-side | Browser code | Sending depends on the code running and on conditions in the browser |
| Browser plus tagging server | The browser sends to the server, which processes and forwards | The server adds control, but it has to receive the event |
| Server-to-server | The application or CRM confirms an action and transmits it through integration | Can report a confirmed result; the link to the visit and the ad has to be configured separately |
If the only source is a script that never ran, moving its destination to your own subdomain does not recreate the missing event. An integration triggered by a saved inquiry can instead rely on the application’s confirmation without waiting for a thank-you page to load. These are different architectures, even if both are described as “server tracking.”
Where does the event start?
Three schematic variants. The route is different; the result must be checked.
CLIENT-SIDE
- Browser
- Sent from the page
- Platform
BROWSER + SERVER
- Browser
- Tagging server
- Platform
SERVER-TO-SERVER
- Application/CRM
- Integration
- Platform
Permissions are respected throughout the path. The server does not automatically recreate an event that it does not receive.
GA4 Measurement Protocol allows systems to send events directly. Google describes it as a complement to existing collection; using it alone can produce partial reporting. Sending an event through an API does not automatically provide complete session, source and journey information.
Why we recommend evaluating a component on the server
For a project where promotion decisions depend on inquiries and sales, it is worth considering whether results confirmed in the CRM can feed measurement. Our recommendation starts from the concrete problem: what is missing, where information is lost and what decision would become better informed.
A well-designed implementation can validate data before sending it, control what goes to each destination and connect commercial events that happen after a visit. For example, it can distinguish a new inquiry from one later qualified by the team.
Weigh those benefits against setup, hosting, security, monitoring, maintenance and incident ownership. For a simple form, correcting the event and testing consent may solve the initial problem. A store or sales process involving several systems may gain more from a server component.
At NOT MORE., we justify this choice through a measurement plan and verification criteria. We do not promise that installing a service will recover every conversion or automatically increase ROAS.
Why browsers can show different parts of the same route
A cookie stores information in the browser, for purposes such as maintaining a session or recognizing a visit. “First-party” and “third-party” describe its context relative to the site. Being first-party does not automatically make a cookie necessary or exempt from consent; its purpose matters.
| Environment | Example of protection or setting | Possible effect on measurement |
|---|---|---|
| Safari / WebKit | Intelligent Tracking Prevention limits cross-site tracking and certain forms of storage | Identifier continuity and the linking of visits may be limited |
| Firefox | Total Cookie Protection keeps cookie storage separate for each site | The same third-party mechanism cannot freely track someone across sites |
| Chrome | Users can allow or block third-party cookies; they are blocked by default in Incognito | Behavior depends on settings and navigation mode |
These are examples from browser makers’ documentation, not a complete list of all versions and devices. WebKit, Firefox, Chrome
Avoid blanket claims that all cookies have disappeared, or that the same person will be recognized identically everywhere. Blocking extensions, deleted data, device changes, lost connections or leaving before an event is sent can all matter. Investigate them as possibilities rather than using them to explain every discrepancy.
Website consent does not force a browser to allow a blocked mechanism. Equally, a browser permitting a transmission does not establish permission to use the data for any purpose.
EU rules, Google policies and the consent banner have different roles
In Europe, assess both the rules on storing or accessing information on a device and, where applicable, personal data protection. Obtain consent before using cookies that require it; strictly necessary functions have exceptions. Explain the purposes clearly and make withdrawal easy. Your Europe: official guidance on cookies
Browser rules are technical decisions by browser makers. Google’s policies are conditions for using its products. European requirements form the legal framework. In implementation we treat them separately and verify how they apply with the project’s data protection officer or legal specialist.
For relevant measurement and advertising uses involving people in the European Economic Area, Google requires applicable consent and the corresponding signals. Romania is part of the EEA. The requirement concerns Google products and can apply even when the visitor uses a browser other than Chrome. Google requirements for EEA traffic
The CMP collects the choice. Consent Mode communicates it.
A CMP (consent management platform) manages the visitor’s interface and preferences. Consent Mode communicates the choice to Google tags and adapts their behavior. Installing a banner does not demonstrate that the connection between the two works.
In a Google server-side tagging setup, consent signals also need to reach the server component. Moving processing does not override the person’s preferences. Check how other providers’ integrations respect those preferences separately. Consent Mode in server-side Tag Manager
Consent Mode v2 includes separate signals, which we do not reduce to a single “accepted cookies”:
| Signal | What it covers |
|---|---|
| analytics_storage | Storage associated with statistical measurement |
| ad_storage | Storage associated with advertising |
| ad_user_data | Sending user data to Google for advertising purposes |
| ad_personalization | Use for ad personalization |
Set the initial state before operations controlled by those signals, then update it after the visitor chooses. Test what happens when they change their mind too. The signal names are technical; the visitor-facing explanation should be understandable. Configure Consent Mode
Basic and Advanced produce different behaviors
| Google implementation | Without relevant consent | After consent |
|---|---|---|
| Basic | Relevant tags are blocked and send no data to Google | Tags load and operate according to the stated preferences |
| Advanced | Tags load in the configured state and can send limited, cookieless signals for declined purposes | Behavior adapts to the permissions granted |
This summarizes Google’s mechanism; the exact data depends on the tag and setup. “Cookieless” does not mean “nothing is transmitted.” Assess Advanced mode against the project’s data, purposes and requirements. Its availability in a platform does not establish that an implementation is legally appropriate. Basic versus Advanced
The banner is only the start of the check.
The implementation must respect the visitor’s choice.
CHOICE
- What does the person allow?
- Accept or decline by purpose
- The option to change preferences
BEHAVIOR
- What rules do we apply?
- Consent signals passed to tags
- Preferences respected on the server too
VERIFICATION
- What data is actually sent?
- Network requests and transmitted data
- Result at each destination
Illustrative diagram. Consent Mode adjusts behavior; verify each implementation.
Events observed, modeled data and results in CRM
Some Google reports use modeling to estimate results where direct observation is incomplete. Availability depends on the product, setup, data volume and eligibility. Google Ads documents conversion modeling, while GA4 documents behavioral modeling separately. Enabling Consent Mode does not guarantee the same estimates for every account. Modeling conversions in Google Ads Behavioral modeling in GA4
Keep the roles distinct: the CRM confirms the inquiries it holds; analytics describes available events and journeys; advertising platforms attribute outcomes using their own rules and may include modeling. An estimate is not an extra identifiable inquiry the team should expect to find in its inbox.
So the purpose of verification is to explain the differences and check that each system is correct for its role. Forcing all the totals to match can hide exactly these differences in definition.
Multiple event sources need deduplication
If the same order or inquiry is sent through several routes, design deduplication so the destination recognizes one action. Agree identifiers and destination-specific rules, including retries. Google Ads documents unique transaction IDs for purchases; reusing an ID across different orders can cause undercounting. Transaction identifier in Google Ads
We do not assume that two integrations installed in parallel are automatically coordinated. We check the platform plugin, browser tags, server and CRM imports. A later qualified inquiry is a separate stage: define it as such, rather than mixing it with the initial inquiry.
Enhanced Conversions is a separate mechanism. It can supplement Google measurement with customer-provided data, hashed for matching. Hashing turns a value such as an email address into a calculated representation; it does not remove every connection to the person. This is different from hosting a tagging server. About Enhanced Conversions
The mechanism is not permission to send every form field. Check eligibility, notices, required consent and the fields allowed by the integration. Google restricts sensitive categories. Contact details belong only in the functions and fields intended for them, never in arbitrary event names or URLs. Google customer data policy
Another example: the inquiry exists, but the report sees less
Consider a second fictional test, separate from the 40-click example. There are 100 unique inquiries saved correctly in the same period, using a Basic implementation. Thirty lack the required consent for sending to the destination being assessed. Of the remaining 70, ten events fail because of an identified technical issue.
| Level in example | Number | What it means |
|---|---|---|
| Saved inquiries | 100 | Outcome confirmed in the business system |
| Inquiries with the necessary permissions for the destination | 70 | Subset of the 100 |
| Events observed at destination | 60 | Subset of the 70, before the technical fix |
These numbers should not be added together: they are nested levels of the same set. In this example we do not include modeling, attribution to ads or time differences. Percentages are invented for demonstration, not estimates of market consent rates.
A server integration could help recover the ten technically missing events only if it receives the confirmation, has the applicable permission and actually addresses the cause. Moving code to a server does not make the 30 without consent eligible. And an event arriving does not prove which ad caused the inquiry.
The inquiry exists. What can the report see?
Fictional Basic-mode example. These are subsets; do not add them together.
Starting set
100 Saved inquiries
Of the 100
70 With necessary permissions
Of the 70
60 Observed events
30 / without the necessary consent The server does not change permissions.
10 / technical problem We check the cause and the right fix.
Same period, unique inquiries. Excludes modeling and ad attribution; not market benchmarks.
What we also check for full implementation
Testing the form is followed by testing the measurement conditions. We choose the cases relevant to the architecture and check the result at the destination:
- The first visit, before any explicit choice: what is loaded, what is stored and what is transmitted according to the approved variant.
- Refusal, partial acceptance and acceptance: whether each purpose actually changes how the relevant tags behave.
- Consent withdrawal: whether subsequent operations respect the change, including on the server.
- Representative browsers and devices: whether differences can be explained and the form still works.
- Application confirmation, page reload and technical retries: whether a single business action is counted as intended.
- External forms, payments or booking systems: whether necessary, permitted context is preserved.
- Events for qualification, sale or cancellation: whether the stage, value, currency and date reflect the actual process.
Document what cannot be observed too. A good implementation distinguishes missing permission, technical limitations, configuration errors and reporting rules. Each calls for a different response.
What we hand over after verification
The team must be able to see what each event represents, when it triggers, where the request arrives and how an error is recognized. We document the cases tested and the remaining limits.
Then we agree on which result is used to evaluate and optimize the campaign. An intermediate action can be useful, but it must be labeled and interpreted as such. The link to qualified inquiries and sales is established separately, according to the available data and implementation.
At NOT MORE., measurement is part of campaign preparation. We check the journey again after relevant changes to forms, pages or integrations, so the report continues to describe the real process.
What you can ask for at the next check
- What exactly is the action we call a conversion?
- Can we follow a test submission through to its record and handling by the team?
- What happens in the report when the form fails or the page is reloaded?
Do the report and the received inquiries disagree?
Start with the definitions and a few test submissions. We can establish where the difference arises and what needs correcting before those figures guide the next budget decision.
Who implements measurement, and who monitors it after launch
NOT MORE. can define the measurement plan, configure tools, develop integrations and test the agreed journey, including server-side components where appropriate. Architecture follows the need, available data, resources and conditions of use. Browser and consent limitations remain relevant wherever part of the implementation runs.
Your team confirms the commercial meaning of each event, the data source and responsibilities for access and operation. Legal and data protection decisions are validated with the appropriate specialists; technical implementation follows those decisions. Where other providers are involved, we establish who repairs each part of the chain.
At handover, we test normal journeys, consent refusal, errors and duplication relevant to the setup. If we also provide monitoring, we specify the alerts and checks, their frequency and who responds. Reporting explains what is observed, what is missing and which conclusions the data supports. Correct implementation supports analysis; it does not promise complete visibility into every user.
Start with the problem you see, without a technical diagnosis
You do not need to identify the tag, integration or browser causing a discrepancy. Begin with what you observe: missing inquiries, different totals or an unclear confirmation. We define the checks and access required, then explain findings in relation to the business question. If a separate investigation or implementation is needed, we agree its scope and cost first. Technical complexity should become decisions you can evaluate.