GA4 conversion tracking becomes useful when the event name tells the truth about what happened. A contact-button click shows an intention. A submission attempt shows that someone tried to send a form. A confirmed enquiry shows that the receiving application accepted a request. A qualified lead requires a later business decision. Treating those four actions as interchangeable makes an attractive report difficult to trust.
For most enquiry-led websites, start with one carefully defined success event, keep diagnostic interactions separate, and test the complete path from the browser action to the report. This guide gives Canadian business owners and implementation teams a practical specification, failure rules and a synthetic QA exercise. All worked examples are fictional. They describe a generic business enquiry form, not a patient journey or a tested client implementation.
The focus is the meaning and evidence behind each event. Container permissions, tag-release procedures and a property-wide analytics audit are separate jobs. First decide what your numbers should mean; then give the implementation team an acceptance test that can demonstrate whether the tracking meets that definition.
What “GA4 conversion tracking” means today
Google distinguishes an event, a key event and a conversion. An event records an interaction. Marking an event as a key event identifies an action important to the business. A conversion can be created from Analytics events for measurement shared with Google Ads; Google’s explanation includes the event-to-key-event-to-conversion path. Some conversion-management features are still subject to property availability. Check the current Google explanation of key events and conversions before writing instructions around a particular screen.
Those labels do not validate the underlying action. Marking a telephone click as a key event does not establish that a call connected. Creating an advertising conversion from a booking-button click does not establish that an appointment exists. The configuration gives an event reporting significance; the trigger and its evidence determine its meaning.
Write a plain-language definition beside every important event. “An enquiry was accepted by our receiving application” is more useful than “the conversion tag fired.” It gives sales, marketing and development a shared boundary. It also makes a reporting limitation visible: accepted does not necessarily mean genuine, contactable, qualified or sold.
Choose the first business question before choosing the key event. If the question is how many requests reached intake, a confirmed submission can answer it. If the question is how many sales opportunities passed review, keep that outcome separate. Summing both stages counts progress through a process, not a population of unique leads.
Separate five levels of evidence
A useful event model is a ladder of evidence. Each level permits a stronger statement, but only when its own condition is met. The following names are a proposed specification for a fictional general-enquiry flow. Custom names are examples, not Google-mandated events.
| Stage | Event or record | Required evidence | What it does not establish |
|---|---|---|---|
| Contact intent | contact_click, custom | A deliberate activation of a contact control | A sent message or connected call |
| Submission attempt | enquiry_attempt, custom | A submit action handled by the application | Acceptance by the receiving system |
| Confirmed enquiry | generate_lead, recommended | An authoritative acknowledgement of an accepted enquiry | Qualification or revenue |
| Qualified outcome | qualify_lead, recommended; source record first | A recorded decision against agreed criteria | A customer or completed sale |
| Customer outcome | close_convert_lead, recommended; source record first | A recorded transition meeting the business’s customer definition | That every earlier interaction was a new customer |
We plan and run B2B marketing across search, ads, content and email for Canadian companies.
Google’s recommended-event reference defines the lead-generation, qualification and customer-conversion events. Using those names preserves familiar semantics. Whether a later outcome should be sent to GA4 is a separate permission, privacy and integration decision. A CRM can hold the outcome even when there is no approved analytics export.
Define the unit at each stage. In this guide, a confirmed enquiry is one accepted submission occurrence. It is not one person, one session or one sales opportunity. Two independently accepted requests from the same person can be two submission occurrences while sales eventually merges them into one opportunity. That difference is legitimate when the report labels it clearly.
A small business can begin with fewer events than this table. Keep only interactions that answer a decision or help diagnose failure. Counting every hover, field focus and button state creates maintenance work without automatically improving the explanation of lost enquiries.
Write the success contract before the trigger
Complete a short event specification with the person responsible for the receiving application. Identify exactly what “accepted” means. Does the application persist the request in an intake queue? Does it acknowledge only a temporary transfer? Does it return an error inside an otherwise successful HTTP response? These are application questions that a page URL cannot answer.
For the fictional flow used here, generate_lead is eligible only after the application confirms that it has accepted and stored a general enquiry. The acknowledgement includes a stable internal occurrence key. That key supports deduplication within the business’s own systems and is excluded from the GA4 payload.
Keep these requirements together in the specification:
- The business meaning, counting unit and accountable role.
- The positive acknowledgement that qualifies as success.
- The exact event name and small permitted parameter set.
- The pages and contexts where collection is permitted.
- The rule for retries, missing keys and repeat notifications.
- The expected browser, collection and reporting evidence.
- The specification version and date from which it applies.
A user-facing success message can be supporting evidence, but it should reflect the application’s confirmed state. A generic success animation shown immediately after a click is weaker evidence. An HTTP status of 200 is also insufficient if the response body says that validation failed. Test the application’s explicit acceptance signal, not an assumption about its interface.
Distinguish intake acceptance from downstream delivery
Suppose a fictional application stores an enquiry and then emails the sales team. The email fails, but the enquiry remains in a monitored queue. Under an intake-acceptance definition, the enquiry succeeded and the notification failed. Reclassifying it as a failed submission would hide a real request. Record the notification problem in the operational system and route it for repair.
If the only intake mechanism is email and there is no durable receiving record, document the weaker evidence. Do not silently claim stored acceptance. Agree whether the available acknowledgement is sufficient for the report’s purpose, or change the application so the business can establish receipt reliably.
Likewise, a booking request awaiting approval is different from a confirmed booking. Name and describe the measurable state honestly. The event design should follow the service’s actual transaction, including pending states, rather than the wording of a prominent button.
Make attempts and failures useful without inflating leads
The companion specification uses enquiry_attempt for a handled submit action and enquiry_failure for a diagnostic state showing a failed or unconfirmed attempt. A person who tries again after correcting an error creates another attempt. That helps answer a usability question, but it means attempts are not unique visitors.
Use a short controlled failure vocabulary. input_invalid means the application rejected the submitted input. rejected means the receiving service refused the request. unconfirmed means the response never established whether acceptance occurred. These fictional categories deliberately avoid user-entered error text, field values and technical messages containing request details.
A timeout deserves particular care. It can mean the server did not receive the request, or that it accepted the request but the acknowledgement did not reach the browser. Record uncertainty. If an approved status check later confirms the same occurrence, one success may become eligible. Do not immediately send a second request with a new identity simply to make the tracking look complete.
Keep diagnostic failures out of the success total. Review their rate against a defined denominator, such as handled attempts during the same observation window. A rise can justify investigating a form problem; it does not establish how many customers were lost or what revenue would have followed.
How automatic form events fit
Google’s enhanced measurement can collect form_start on a user’s first form interaction in a session and form_submit on submission. Its enhanced-measurement documentation also lists form identifiers, destination and button-text parameters. Those signals are useful to inspect, but your application tests must determine whether they correspond to accepted enquiries.
Do not automatically rename every form_submit to generate_lead. A site may contain search, newsletter, account and contact forms, each with a different business purpose. A successful newsletter subscription is not necessarily a sales enquiry. Select the intended form and prove its success condition.
Choose one canonical source for the success event. If the application already emits it, a second rule based on a thank-you page can double the count. You may keep a separate form-interaction diagnostic, but reports should identify the accepted-enquiry event explicitly instead of adding both signals together.
Keep the payload small and understandable
For the fictional form, an eligible success payload has four custom parameters: method=web_form, form_key=general_enquiry, confirmation_source= and spec_version=v1. These are fixed vocabulary values. They explain how the event was established without carrying the submitted message or a customer identifier.
The form key identifies an interface, not a person or a request. Use the same value across repeat uses of that form. A new random form key for each submission would destroy its usefulness as a grouping field. Keep internal receipt and deduplication keys outside the analytics payload.
A parameter dictionary should state the type, permitted values, business purpose, applicable events and destination for every field. An allowlist is easier to review than a rule that copies an entire form object and removes a few obvious fields. Unknown values should be rejected or withheld for correction, not accepted merely because they fit within a character limit.
Do not assign invented monetary values to enquiries to make a report appear complete. If a business later adopts an estimated lead value, document its basis, currency, effective date and distinction from realised revenue. Google’s event reference requires a currency when a value is supplied. The companion example omits both because no supported valuation has been established.
Current naming rules and relevant limits
Use consistent lower-case names with underscores as an editorial convention. Google’s event naming rules require names to start with a letter, allow letters, numbers and underscores, and prohibit reserved names and prefixes for new custom events. Names are case-sensitive, so a capitalisation change can split a series.
| Item | Documented limit | Practical implication |
|---|---|---|
| Event name | 40 characters | Keep stable names short |
| Event parameters | 25 per event | Use a reviewed payload budget |
| Parameter name | 40 characters | Avoid long generated labels |
| Most parameter values | 100 characters | Prefer controlled short values |
| Configured key events | 30 per property | Reserve significance for meaningful outcomes |
| Event-scoped custom dimensions | 50 per property | Register only useful breakdowns |
The collection limits include exceptions for certain page-related parameter lengths and distinguish web streams from the 500-distinct-event limit per app user. Do not apply that app limit to a website. The separate configuration limits cover key events and custom definitions. These are selected standard-property limits; consult the relevant documentation for Analytics 360.
Sending a custom parameter and making it available as a reporting dimension are separate steps. Plan the required event-scoped definitions before evaluating breakdowns. Google’s custom-dimensions guidance explains the reporting setup and warns against unnecessary high-cardinality dimensions. A unique receipt key is unsuitable for the simple grouping questions this guide addresses.
Set a privacy boundary before collection
The proposed payload excludes personal information, submitted message text, health information, patient identifiers and raw CRM records. It also excludes hashes of contact details. The business may need such information to answer an enquiry, but that does not make it necessary or appropriate in an analytics event.
Google’s guidance on avoiding personally identifiable information highlights URLs, page titles, user-entered fields and campaign parameters as possible leakage paths. Reviewing only the four custom parameters is insufficient. Check the complete outgoing request and the surrounding automatic collection, including the form destination, referrer, link text and search terms where relevant.
Use fixed interface labels rather than user-supplied content. Remove sensitive values before any analytics transmission. A thank-you URL containing an email address or appointment detail is unsafe even if the lead event itself looks clean. Best-effort redaction is an additional control, not permission to design sensitive values into URLs.
Why a generic label is not enough for a clinic
A neutral label can still sit beside a revealing page title, URL or authenticated journey. Do not assume that changing a parameter to general_enquiry makes a healthcare flow appropriate for GA4. Keep patient and health-related workflows outside this example and have the organisation’s responsible privacy and technical reviewers determine the permitted boundary.
Google’s healthcare guidance discusses restrictions for HIPAA-regulated organisations; it does not certify compliance with Canadian requirements. This guide makes no legal-compliance claim. A safer measurement plan can rely on aggregate operational counts within an approved business system without exporting patient activity.
Canada Create’s guide to online booking for clinics covers the booking journey and the difference between a booking click and a completed booking. The present specification adds an evidence test for a generic enquiry. It is not an instruction to instrument a patient portal or transfer appointment details.
Record the applicable collection permission
Consent behaviour belongs in the event contract because it affects which actions are observable. Google’s consent-mode overview distinguishes basic mode, where tags are blocked before consent, from advanced mode, which can send cookieless pings. Do not assume every denied-consent configuration produces identical network behaviour.
The fictional companion uses a deliberately narrow rule: its analytics candidate is withheld unless a supplied collection-permission flag is true. This flag is a test input, not a working consent-management platform. The harness makes no network requests in either state. A real implementation must connect the approved permission rule to its actual consent and privacy controls.
Do not weaken those controls to reconcile a report. A request can exist in the intake system while no corresponding observable analytics event is available. Record that as a coverage limitation. The business outcome and its eligibility for analytics collection are different facts.
Deduplicate the occurrence, not the visitor
Deduplication means recognising repeated evidence of the same business occurrence. It does not mean limiting every visitor to one enquiry. If someone deliberately sends two different requests, suppressing the second because it happened in the same session may erase a legitimate occurrence.
For the fictional specification, the business application assigns a stable internal key when it accepts a submission. The measurement boundary uses the pair of event name and occurrence key to recognise a repeated success notification. A later qualification transition has its own business-stage key. Neither key is exported to GA4.
Place the duplicate check at the shared decision point used by all emitters. Two independent browser and server paths cannot reliably deduplicate each other if each keeps a separate memory of what it sent. Assign one path responsibility for the event, or use a shared suppression mechanism with a documented retention and replay policy. Do not assume that adding a parameter called event_id makes arbitrary GA4 lead events automatically unique. Google documents transaction-ID deduplication for web purchase events; that specific ecommerce behaviour is not a documented general-purpose lead-event guarantee.
Write explicit retry and failure rules
- Repeated acceptance callback: the same occurrence remains one success, even if a component renders again.
- Double click: the application should recognise a repeated request where appropriate; the analytics rule must still check the acceptance key.
- Thank-you reload: viewing the page again creates no new enquiry without a new accepted occurrence.
- Missing occurrence key: withhold the success candidate and raise a local diagnostic; do not invent a fresh key for each callback.
- Unknown acknowledgement: withhold success until the receiving system establishes the outcome.
- Independent second enquiry: a new accepted occurrence key can produce a second success.
- Collection not permitted: withhold the analytics candidate; do not queue it for automatic replay after permission changes.
Decide when the occurrence becomes ineligible for another emission and how long the suppression record lasts. The retention period should cover the application’s legitimate retry and callback behaviour without becoming an indefinite customer-tracking store. The sample harness remembers keys for created and withheld candidates only within one sequence. It blocks a later callback for the same withheld occurrence even if permission changes, while allowing a genuinely new eligible occurrence. That memory does not survive a reload or another process; it is not a durable production deduplication service.
There is also a delivery trade-off. If the sender records “sent” before a network failure, a retry may be suppressed even though Analytics never received the event. If it records “sent” after an uncertain response, a retry may create a duplicate. A browser-only design cannot claim exactly-once delivery simply because it uses a local flag. Document the chosen behaviour and reconcile aggregate gaps.
Business acceptance must not depend on Analytics being reachable. The enquiry should remain available to the team even when a browser blocks analytics or a collection request fails. Analytics is an observation channel; it should not decide whether a customer’s request survives.
Counting method is a reporting choice
GA4 supports counting a key event once per event or once per session. Google illustrates that repeated occurrences within a session can therefore produce different key-event totals, and counting-method changes apply prospectively. See its counting-method documentation.
For an accepted-submission metric, once per event is the proposed choice after duplicate suppression, because two accepted requests can matter. Once per session can answer a different question about sessions containing the action. It does not repair duplicate source events or make the two reporting units equivalent. Record the chosen method beside the event definition so another analyst can interpret the total.
Handle calls, booking links and external forms honestly
A telephone-link activation can be a useful diagnostic. Its meaning stops at activation: a device might open a dialler, abandon the action or complete a call outside the website’s visibility. Label the metric contact clicks unless a separate permitted source establishes a connected conversation or accepted enquiry.
The same rule applies to email links. Opening an email application is not evidence that a message was sent or received. A team that needs actual email-enquiry counts should define them in the receiving system. Avoid merging a website intent signal with an inbox outcome solely because both relate to contact.
For an external booking portal or embedded form, ask which system can confirm the outcome. A parent page may only observe the outbound link. A redirect back to a public thank-you page may be accessible without a booking. The success rule needs documented provider evidence or a verified application acknowledgement, including a safe duplicate rule.
If that evidence is unavailable, keep the measurable click and label completion as unobserved. Do not fill the gap using an assumed click-to-booking percentage. Nor does a cross-domain configuration, by itself, prove that the external system accepted a request. Attribution continuity and business confirmation solve different problems. Google also notes that enhanced-measurement outbound clicks are suppressed for configured cross-domain destinations. Its cross-domain guidance requires compatible tagging across the domains. Verify the particular click signal you rely on; do not assume every external link produces the automatic click event.
Use the browser-to-report worksheet to state where observation stops. “Outbound activation verified; destination acceptance unavailable” is a useful finding. It directs the next technical investigation without overstating what today’s report can support.
Keep qualification tied to a recorded business decision
Qualification should depend on agreed criteria, applied in the business system. A fictional equipment-service business might require an in-scope request, a serviceable location and a confirmed willingness to discuss the work. The particular criteria are an example, not a universal lead-scoring standard.
Do not infer qualification from a long session, repeated page views or a form’s completion. Those behaviours may inform a separate hypothesis about interest. They do not prove that a person meets the sales team’s criteria. Name the accountable role and record the reason for the decision within the approved business system.
The companion defines qualification as the first recorded transition into the qualified state for an opportunity under a specified criteria version. Re-saving the same state does not create a new qualification. A later disqualification or reopening stays in the source history; it does not erase the fact that the earlier transition happened.
If reporting needs the number currently qualified, calculate the current-state population from the business system. If it needs new qualifications during a period, count qualifying transitions according to the contract. These two questions should not share an unexplained column labelled “qualified leads.”
The example’s outcome export is disabled by default. It can be modelled locally without sending CRM data anywhere. A future integration needs its own assessment of permitted identifiers, timing, attribution, security and duplicate handling. Do not forward a whole CRM record or a free-text qualification explanation as a shortcut.
Accepted submissions, valid enquiries, qualified opportunities and customers should appear as separate measures when they have different units. A report showing all stages can help locate friction. Adding them together cannot reveal a meaningful total of people or customers.
Test the browser-to-report chain in separate layers
A good QA log distinguishes expected behaviour, observed evidence and untested steps. “Passed” should identify the layer that passed. A correct local event object is useful evidence about your logic, but it cannot prove a network request reached the right property or appeared in a processed report.
| Layer | What to record | What a pass establishes |
|---|---|---|
| Application | Fictional test action and accepted, rejected or unconfirmed state | The tested business condition occurred |
| Local candidate | Event name, approved parameters, permission gate and duplicate decision | The event contract was applied |
| Collection | Sanitised outgoing evidence and intended destination | A collection attempt was made as configured |
| DebugView or Realtime | Matching event and permitted parameters in the test window | Analytics exposed the collected event in that view |
| Processed report | Report, date range, filters, counting method and selected event | The intended reporting interpretation is supported for that test |
Prepare the expected result before operating the form. Include ordinary success, rejected input, uncertain response, repeat callback, reload, independent second request and collection not permitted. Add keyboard submission and mobile behaviour to the later browser tests because the same visible form can expose different action paths.
Use synthetic records and a reviewed test environment. Avoid copying real enquiries into screenshots or exported network logs. A sanitised evidence reference can point to an internally controlled test record; a public companion should retain only fictional identifiers and non-sensitive expected results.
Distinguish immediate visibility from reporting readiness
Google’s DebugView documentation explains how to inspect collected events with debug mode enabled and notes visibility limitations when privacy controls or analytics-cookie consent prevent it. An empty view is a diagnostic observation, not automatic proof that the form failed.
During an authorised test, confirm the intended test device, event spelling and parameter values. Then verify reporting separately. An internal or developer traffic filter may deliberately prevent a test event from contributing to ordinary reports; note the filter and agree a controlled reporting test instead of changing controls casually.
Google states that data processing can take 24–48 hours and reports may change during processing. Google also gives a 24–48 hour wait before newly configured custom dimensions become available for reporting. Record the time checked and mark a pending processed-report observation as pending. Do not repeatedly fire the success event just to force a chart to update.
Choose a report filtered to the specific accepted-enquiry event. Confirm the reporting timezone and date boundary, especially for an enquiry near midnight. Record whether the number is an event count, a key-event count, a session measure or a user measure. A mismatch between different units is not fixed by changing a trigger.
Google also describes modelled key events that estimate activity not directly observable. That guidance also says channel-attribution data can change for up to 12 days after a conversion is recorded, so the initial processing window is not a guarantee of final attribution. Where modelling applies, the report is not a row-by-row receipt ledger. Use it for its stated analytical purpose and keep operational acceptance records as the authority for handling actual enquiries.
A fictional reconciliation exercise
Consider a deliberately small fictional batch with 12 handled attempts. Eight were accepted, two were rejected for invalid input, one was refused by the receiving service and one remained unconfirmed. The arithmetic is 8 + 2 + 1 + 1 = 12. This is invented teaching data, not a benchmark, campaign result or live GA4 observation.
Of the eight accepted occurrences, six were eligible for the fictional analytics gate and two were withheld. The six eligible occurrences produced nine success callbacks because three acknowledgements repeated. Deduplication reduces those nine callbacks to six local success candidates. The extra callbacks are duplicate evidence, not extra enquiries.
For this arithmetic exercise only, each of the eight accepted occurrences maps to one distinct opportunity, with no merges.
| Measure | Calculation | Interpretation |
|---|---|---|
| Accepted-attempt share | 8 ÷ 12 = 66.7% | Share of handled attempts accepted |
| Eligible share of accepted occurrences | 6 ÷ 8 = 75% | Coverage under this fictional collection gate |
| Duplicate callback share | 3 ÷ 9 = 33.3% | Extra callbacks within the eligible success-callback set |
| First qualified transitions | 3 ÷ 8 = 37.5% | Qualified share of the same accepted cohort after the chosen review window |
The business system might show three first qualified transitions within those eight opportunities after the chosen review window. If real submissions merge into opportunities, use a matched opportunity cohort or count accepted occurrences linked to a qualified outcome; do not divide unlike units and label the result a qualification rate. That does not imply three qualification events were sent to GA4. It also does not justify subtracting three from eight to label the rest permanently unqualified: some may still be awaiting review.
Suppose a future collection test observed only five of the six eligible candidates. The unexplained gap would be one eligible occurrence, or 16.7% of six, pending investigation. That sentence is a hypothetical diagnostic branch, not a completed test. Investigate collection and reporting evidence before deciding whether the cause is blocking, filtering, timing or an implementation defect.
Never divide a later month’s qualification transitions by an unrelated month’s submissions and present the result as a cohort conversion rate. Match the underlying set and allow an explicit outcome window. When a denominator is zero, report “not applicable” rather than zero per cent. Missing evidence is also different from a measured zero.
For broader commercial interpretation, the existing PPC ROI guide provides campaign context. This enquiry specification establishes the measurement unit that such analysis needs; it does not estimate profitability from clicks or attach a universal financial return to the fictional batch.
Use the event specification and QA companions
Download the GA4 lead tracking kit (ZIP). The 14-file kit contains editable templates, fictional examples, a source register and a network-free synthetic QA harness.
The companion set contains blank CSV templates, fictional completed examples, a parameter dictionary, a JSON contract, synthetic fixtures and a network-free JavaScript harness. Their purpose is to make definitions and expected outcomes reviewable. Start with event-specification.blank.csv and browser-to-report.blank.csv; keep the files labelled fictional as separate teaching examples.
- Complete the event specification. Copy the blank CSV and define one intended success event first. Fill in the business meaning, evidence, counting unit, allowed parameters, duplicate rule and accountable role.
- Review the dictionary. Replace example interface labels with approved fixed values. Exclude personal, health and free-text data, including values that might arrive through automatic page or form collection.
- Work through the fictional cases. Compare each expected local decision with the contract. Include negative cases; a success-only test cannot demonstrate the failure boundary.
- Run the synthetic harness offline. With Node.js available, run
node synthetic-qa.jsin the companion directory. The script embeds 38 test cases, makes no network calls and requires no Analytics credentials. - Use the browser-to-report blank log later. After an implementation is authorised, enter actual observations separately for application, collection, DebugView and reporting. Keep untouched steps marked “not run.”
The provided synthetic log records checks of the fictional local rules and arithmetic. Its collection, DebugView and processed-report observations remain “not run.” The blank versions contain headers or empty event arrays so a team can start its own specification without mistaking teaching data for business records.
The JSON contract describes permitted event candidates; it is not a deployable Google tag configuration. The harness intentionally uses an in-memory duplicate set and Boolean permission inputs. A working integration needs the real application’s acceptance contract, durable duplicate strategy where appropriate, and approved consent controls.
Keep the example and blank files separate when sharing them with colleagues. Import CSV files as UTF-8 and preserve identifiers as text. Do not paste customer records into a public QA file. A test-case identifier should identify the test, not a person.
Maintain the definition when the journey changes
Event quality can deteriorate when a form vendor changes, a confirmation page is redesigned or an intake process gains a new approval step. Review the contract whenever the business meaning or the acceptance evidence changes. A cosmetic button edit may need a regression check; a new success condition needs an explicit version decision.
Record the previous definition, new definition, effective date and expected reporting impact. If success previously meant “submit clicked” and now means “accepted by the application,” the resulting drop may reflect better measurement. Do not present the break as a sudden deterioration in customer demand without examining the definition change.
Retain a small set of regression cases: valid acceptance, failed input, uncertain response, repeated callback, direct thank-you visit, missing occurrence key, blocked collection and later qualification. Re-run the affected cases after a change. Container-wide ownership and property-wide assurance remain separate reviews with their own scope.
For a release decision, require a traceable success definition, a reviewed payload, documented duplicate and failure behaviour, and evidence for each claimed test layer. If processed reporting is still pending, say so. If a provider cannot confirm completion, keep the metric at the observable intent stage until that gap is resolved.
Common questions about GA4 lead tracking
Can a thank-you page count as a lead?
It can be supporting evidence when the application exposes it only after verified acceptance and repeat visits cannot create extra successes. A freely accessible page or a reloadable URL alone is weak proof. Prefer a confirmed application outcome with a defined occurrence key and duplicate rule.
Should every contact action be a key event?
Only if its importance and interpretation are intentional. Keep clicks and attempts available for diagnosis, and choose meaningful outcomes for the main enquiry measure. Marking all stages as key events can make an unfiltered total misleading because the same journey contributes several different actions.
Why do GA4 and the CRM disagree?
Start by comparing units and coverage. The CRM may count merged opportunities while GA4 counts eligible submission events. Permission, blocking, repeats, filters, timezones and processing can also matter. Reconcile a controlled test before deciding that either total should equal the other.
Does the companion prove my website works?
No. It checks fictional rules and expected arithmetic without account access or live transmission. It supplies a repeatable specification and a log for future authorised tests. Your browser behaviour, receiving system, Analytics collection and processed reports still require their own evidence.
Platform documentation and linked destinations were checked on 8 October 2026. Recheck the cited guidance when implementing, especially terminology, limits and reporting behaviour.
Discuss your enquiry-tracking requirements with Canada Create.
