Conversion tracking for B2B websites – GA4 events that actually matter

The GA4 events that matter on a B2B website are the ones that show a person asking to talk to you: a confirmed enquiry (`generate_lead`) and a short list of supporting signals – contact form submissions, email clicks, phone clicks and started chats. Mark only the qualified enquiry as a key event, send every event with the same small set of parameters, respect the visitor's consent choice, and hand a lead ID over to your CRM so you can later see which enquiries became real opportunities. Page views, scroll depth and session duration are useful context, but they are not conversions.

Why the default GA4 setup misleads B2B teams

A B2B site has relatively few enquiries spread over long sales cycles, and each one matters. The out-of-the-box setup works against that:

• Enhanced measurement form events are too broad. The automatic `form_submit` can fire for a newsletter box, a search field or a failed submission. Counting it as a conversion mixes serious enquiries with noise.
• Thank-you page views get double counted. A visitor who refreshes the page or bookmarks it creates another "conversion".
• No business context. GA4 does not know whether a submission was a quote request, a support question or a job application unless you tell it.
• Consent gaps. In the EU a meaningful share of visitors will decline analytics cookies, so GA4 will always show fewer leads than your inbox. That is expected, and it is why the CRM, not GA4, should be the source of truth for lead counts.

Since 2024 GA4 calls conversions key events; the word "conversion" is now used mainly in Google Ads. The idea is the same: a key event is an event you have decided is a business outcome.

A tracking plan with five events

Before anyone opens Google Tag Manager, write a one-page tracking plan: event name, when exactly it fires, its parameters and whether it is a key event. For most B2B company websites the following set is enough.

generate_lead – the key event

`generate_lead` is a recommended GA4 event, so it fits standard reports. Fire it once, after the server has accepted a valid sales enquiry – not when someone clicks the submit button. Useful parameters:

• `form_id` – which form (e.g. `quote_request`, `demo_request`)
• `lead_type` – quote, demo, partnership
• `page_type` – service page, article, pricing, contact page
• `lead_id` – a random, non-personal identifier generated by your backend

Do not attach an invented monetary value. If sales has not agreed a value per lead type, leave `value` out rather than reporting fictional revenue.

contact_form_submit

A custom event for every successful submission of any form, including support and general questions. It helps you see total demand and spot forms that suddenly stop working. It is not a key event, otherwise every sales enquiry would be counted twice.

email_click and phone_click

Fire on clicks of `mailto:` and `tel:` links, with a `link_location` parameter (header, footer, contact page, article body). These show intent, but you cannot see whether the email was sent or the call answered. Keep them as secondary events and review them next to `generate_lead`, not as replacements for it.

chat_started

Fire when the visitor sends the first message, not when the widget opens. Most chat tools expose a JavaScript callback for this; CSS click selectors tend to break with the next widget update.

Naming rules worth keeping: snake_case, names within GA4's 40-character limit, no personal data in names or parameters, and every parameter you want to report on registered as a custom dimension in the GA4 admin.

Implementation: dataLayer first, tags second

The most reliable pattern is to let your application tell the tag manager what happened. A typical flow for a Laravel or Vue-based site looks like this:

1. The visitor submits the quote form.
2. The frontend sends the data to the backend, which validates it and runs spam checks.
3. The backend stores the enquiry, generates a `lead_id` and returns success.
4. Only then does the frontend push `generate_lead` with `form_id`, `lead_type`, `page_type` and `lead_id` to the dataLayer.
5. A GA4 event tag in Google Tag Manager picks up the push and sends it, subject to consent.
6. The backend saves the same `lead_id` with the enquiry, together with the landing page and UTM parameters.

This keeps tracking honest: a failed submission or a bot blocked by validation never reaches GA4. It also keeps personal data out of analytics: Google's terms prohibit sending names, email addresses or phone numbers to GA4.

If your site is part of a wider rebuild, tracking should be planned together with page structure and content. That is how we approach it in our AI and SEO visibility work, and it fits with the points in our article on technical SEO for software development companies.

Consent Mode v2 in practice

For visitors in the EEA, Google expects Consent Mode v2 signals when you use its advertising features: `ad_storage`, `analytics_storage`, `ad_user_data` and `ad_personalization`. Two set-ups are possible:

• Basic mode – Google tags do not load at all until the visitor consents. Simple and conservative, but GA4 sees nothing from those who decline.
• Advanced mode – tags load with consent denied and send cookieless pings, which Google can use for modelling. Whether this is acceptable for your organisation is a legal decision, so involve your data protection officer.

Technical checks that catch most problems:

• the default consent state is set before any Google tag fires,
• the consent banner updates the state immediately after the visitor's choice,
• rejecting consent really stops cookies from being set (check in the browser's developer tools),
• Tag Assistant shows the expected consent state on each event.

Connecting GA4 with your CRM

GA4 tells you which pages and channels produced enquiries. Only the CRM can tell you which enquiries turned into qualified opportunities. Connect the two with a few deliberate steps:

• Store attribution with the lead. Save landing page, referrer, UTM parameters and, where consent allows, the Google Ads click ID with each enquiry in the CRM.
• Use the same `lead_id` in both systems. It lets you match a GA4 event to a CRM record without sharing personal data.
• Send lifecycle events back. GA4 has recommended lead events such as `qualify_lead` and `close_convert_lead`. When sales changes a lead's status, your backend can send the matching event through the Measurement Protocol, or you can import offline conversions into Google Ads.
• Report in one place. A simple monthly view – leads by source, qualified leads by source – answers the real question better than any dashboard of page metrics.

If your CRM cannot store this data or expose a status change through an API, that is usually the first thing to fix. We describe typical requirements in custom CRM development for B2B sales teams.

Common mistakes

• Marking five or six events as key events, so the headline number means nothing.
• Firing `generate_lead` on button click instead of after server confirmation.
• Sending form content, email addresses or free-text messages as parameters.
• Treating GA4 lead counts as exact while consent rejection is not taken into account.

Pre-launch checklist

1. Tracking plan written and agreed with sales and marketing.
2. Every form returns a clear success state that the frontend can react to.
3. Events verified in GA4 DebugView for each form, link type and chat.
4. Custom dimensions registered for `form_id`, `lead_type`, `page_type` and `link_location`.
5. Only `generate_lead` marked as a key event.
6. Consent behaviour tested for accept, reject and later change of mind.
7. `lead_id` and UTM data visible in the CRM for a test enquiry.

Next step

List every place on your site where a visitor can contact you – forms, email addresses, phone numbers, chat – and write down what should happen after each one. That list is the core of your tracking plan. If you would like a second pair of eyes on it, or help wiring the events into your application and CRM, get in touch with us.