Implement GA4 Event Tracking Without Google Tag Manager

Google Analytics 4 can track important website interactions without Google Tag Manager. In this approach, a developer installs or extends the Google tag directly in the website code, then sends GA4 events with gtag.js when defined actions occur. It can be appropriate when a site already uses direct tagging, has a controlled release process or does not need a separate tag-management layer.

The work is not simply adding JavaScript. A useful implementation begins with business decisions, translates them into measurable actions and establishes how the data will be tested and maintained. GO Labs can scope and deliver this work as part of an agreed technical brief, with outcomes dependent on the website, analytics configuration, consent model and selected tools.

1. Decide whether direct GA4 tracking is the right approach

Direct gtag.js implementation places tracking logic in the application or website code. Changes therefore follow the normal development, review and deployment process. That can provide clear technical ownership, but it may make future tracking changes dependent on developer availability.

Before proceeding, compare that trade-off with using a tag manager. Direct tracking is generally easier to govern when the required events are limited, the codebase is actively maintained and releases can be tested. A tag-management platform may be more suitable when marketers need frequent configuration changes across many advertising and analytics services.

2. Define requirements around decisions, not clicks

Start by listing the questions the organisation needs GA4 to answer. For an event website, these might include whether visitors begin an RSVP journey, complete registration, request venue information or select a programme. The measurement plan should distinguish a useful business action from a convenient interface interaction.

Review GA4 recommended events before creating custom names. Use lowercase, stable names with underscores, and define each event once. For every event, document its trigger, parameters, expected frequency, responsible owner and whether it may qualify as a key event. Avoid sending names, email addresses, telephone numbers or other personally identifiable information to GA4.

3. Confirm the Google tag foundation

Use the Google tag identifier for the intended GA4 property, load the Google tag script once and initialise it in the maintained site template. A bounded initialisation example is:

Google tag initialisation:
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag(‘js’, new Date());
gtag(‘config’, ‘G-EXAMPLE’);

Replace the example identifier, respect the site’s approved consent behaviour and confirm that another template or plugin is not loading the same configuration.

4. Map each interaction to an event trigger

Identify the exact point at which each event should fire. A registration-start event might occur when the user enters the registration flow, while a completion event should reflect a confirmed success state rather than a button click. Clicking submit is not proof that validation, payment or server processing succeeded.

Each direct event call follows the gtag.js event pattern: the event command, a defined event name and an optional object of parameters. Parameters might describe a form type, content category or journey stage when those values are useful, non-sensitive and consistently available. Do not create dynamic event names for every page or item; stable names with controlled parameters produce cleaner analysis.

5. Implement and validate direct events

Fire an event at the verified action, with documented parameters. For an agenda download, the maintained handler might call:

Direct event call:
gtag(‘event’, ‘agenda_download’,
{file_name: ‘event-agenda.pdf’});

A registration completion must wait for the asynchronous success response, not the submit click:

Confirmed asynchronous success:
if (response.ok &&
response.registration_id) {
gtag(‘event’, ‘registration_complete’,
{registration_type: selectedType});
}

Work one requirement end to end: define “confirmed registration”, place the call only after the server confirms success, specify the permitted registration_type parameter, prevent duplicate firing with the application’s success-state guard, validate the event and parameters in DebugView, then mark the received event as a GA4 key event if it represents the approved business outcome. Repeat and failed submissions must not create additional completions.

6. Configure key events in GA4

GA4 now uses key event for an event that is especially important to the organisation. The older term goal belongs to previous Google Analytics terminology. After an event is defined and received, an authorised GA4 administrator can mark it as a key event in the property interface. Interface labels and permissions can change, so confirm the current administration path in the property.

Do not mark every interaction as a key event. Reserve the designation for meaningful outcomes such as a validated enquiry or completed registration. If advertising conversion measurement is also required, scope that configuration separately; a GA4 key event and an advertising-platform conversion are related concepts but not automatically identical operational setups.

7. Test page views and single-page applications explicitly

For a single-page application, choose whether the Google tag’s enhanced measurement handles history changes or the application sends page views after each confirmed route change. Do not enable both without proving they cannot duplicate page_view events. Test the initial load, forward navigation, browser back, redirects and repeated renders in DebugView, then compare expected and observed page paths before release.

Also test consent states, blocked requests, failed form responses and duplicate success callbacks. Keep a dated acceptance record covering event names, parameters, key-event status and the exact release tested.

8. Address privacy and operational risks

Analytics requirements should be reviewed against the organisation’s privacy notices, consent approach, data-retention choices and applicable obligations. The appropriate configuration depends on the organisation and should be assessed by its authorised privacy or legal advisers where necessary. Tracking should respect the implemented consent state, and event parameters should be reviewed before launch.

Operational risks include duplicate tags, inconsistent naming, blocked scripts, browser restrictions, changing page components and unannounced form replacements. Include analytics checks in release acceptance criteria. Wider event planning in Singapore should also align registration journeys, guest communications and on-site operations with what the measurement plan actually represents.

9. Prepare a fallback and recovery plan

Define what happens if analytics requests fail or a release produces unreliable data. A fallback may involve disabling a problematic event call, reverting the relevant code release or temporarily excluding a known-bad date range from decision-making. GA4 should not be treated as the transactional system of record for registrations, payments or attendance.

Keep a versioned event specification and deployment log. When an event changes, record the date, reason and reporting impact so analysts can interpret trends without assuming the definition remained constant.

Questions to ask an implementation partner

• Which business decisions will each proposed event support?
• Are GA4 recommended events suitable before custom events are introduced?
• Where will each event fire, and what proves that the action succeeded?
• How will duplicate events and single-page navigation be handled?
• Which parameters are necessary, and how will sensitive data be excluded?
• How will consent states, browsers and failure cases be tested?
• Who can mark key events and approve production changes?
• What documentation, test evidence and handover will be delivered?
• How will future website releases be checked for tracking regressions?

A disciplined direct implementation keeps GA4 measurement understandable: define the decision, instrument the verified outcome, test the full journey and maintain an auditable specification after launch.