Create the events in your plan, mark them as key events, and show that each one fires correctly.
Put the event list you made in lesson 3.3 beside your GA4 account. You'll create each event on it one line at a time, then watch each one fire on your own site. Most of the work is in the watching, because an event can look correct in the settings and still count the wrong things.
Priya runs a site that takes enquiries, WhatsApp contacts and trial class bookings. She set up her key events with care but never watched them fire. When she first checked, GA4 showed 41 enquiries in a week while her inbox had 19 for the same week (both invented figures for this example). Every enquiry had been counted twice. Her thank-you page event fired once through the website builder's own GA4 integration and again through a tag she had added in Google Tag Manager.
For a thank-you page, go to GA4 admin settings, open events and choose create event. A created event is built from conditions that match an event GA4 already collects. It counts only from the moment you create it, so last month's data and any other past data stay as they were. Name it something like generate_lead, and set the condition to a page_view event on a page whose address contains /thank-you. Copy the path from your own site exactly. If your page is /thankyou and you type /thank-you, the event will match nothing. If the event carries a value, add the value and currency parameters when you create it.
Button clicks, such as a WhatsApp button, are set up in Tag Manager. Make a link click trigger where the click URL contains the WhatsApp link address the button uses, then make a GA4 event tag, for example whatsapp_click, that fires on that trigger. Priya tracked her WhatsApp button this way. Preview the container in Tag Manager before you publish it.
Some booking tools and form tools send their own events to GA4. Find the exact event name on the tool's help page so you mark the right one.
A key event is an event that measures an action that's particularly important to your business. In admin settings, under data display, open events, and mark and manage each key event there by event name. Google's help page on key events shows the current steps. You can add a name before that event has happened for the first time, so you can do this straight away. Add only the events in your plan. 15 key events are about as useful as a report with 40 charts. Priya added three: generate_lead, whatsapp_click and her booking event.
Standard reports can take a day or more to show new events, so you test in real time with two tools. Tag Assistant is a Google tool that connects to your website and puts that browser tab into debug mode. It also lists which tags fired on each page and what they sent. DebugView, in GA4 admin settings, shows a live stream of events from browsers in debug mode, one event at a time with its parameters.
Connect Tag Assistant to your site and open DebugView. Use the site as a visitor would and carry out the real action behind each key event. Label your test entries clearly, with "TEST" in the message or a test name, and ask the people who handle enquiries to ignore and delete them. Priya sent her enquiry form with "TEST" in the message, tapped her WhatsApp button and booked a trial class under a test name, and she asked her admin to ignore and delete those entries. If the internal traffic filter you set up in lesson 3.2 hides your visits, run the tests from a phone on mobile data.
For each action, check three things in DebugView: the event name matches your plan exactly, the event appears once, and its parameters are present, including value and currency if you set them. Two identical events about a second apart usually mean the tag is installed twice.
Also check what happens when the action fails. Open the enquiry page and leave without submitting, or submit with a required field empty, and confirm that no key event fires. An event that fires on a failed action inflates every report that uses it. Once an event fires a single time with the right details, take a screenshot of DebugView or Tag Assistant and keep it as proof.
Four faults turn up most often. GA4 may be installed twice. A trigger may match more links than you meant. The thank-you path on the site may differ from the one you entered. A form tool may show a success message on the same page without loading a new one, in which case a page-based event never fires. Change one thing at a time and retest after each change.
Priya switched off the builder's GA4 integration and kept Tag Manager. She published the change, retested, and saw one event per enquiry.
After a day or two, open the standard events report and compare the generate_lead count with the enquiries you actually received over the same days.
A tracking log is a short document listing each event, what triggers it, where it is set up, its value, and the record and proof of its testing. Website redesigns often break tracking, and the log tells whoever repairs it what to rebuild and how to check it. Use these 8 columns:
event name key event (yes or no) what triggers it where it is set up (GA4 admin, Tag Manager or the website builder) value and how it was estimated date tested tested by link to the screenshot
Priya's log came to 3 rows and took her 15 minutes to write. Without it, the next person would spend a day working out her setup from scratch.
Once your own events fire cleanly and the log is written, you have the GA4 setup that every later module relies on, starting with the reports in module 4.
Make a tracking log that lists each key event, how it fires, and a screenshot from DebugView or Tag Assistant showing it fired once.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).