What is event tracking

The unit of measurement is the event: a named record describing that something happened, accompanied by parameters that spell it out. When someone presses the download button on a catalogue, the tool stores an event name and, alongside it, data such as the title of the document or the section of the site the press came from.

Three things that get confused daily are worth keeping apart. The analytics tool is where the data accumulates and gets read. The tag manager is the vehicle that ships the code without anyone touching the template. The data layer is the intermediate store that this vehicle reads values from. Event tracking is the decision that comes before all three: which actions deserve to be recorded, and under which name.

An event is not a conversion either. Every conversion is recorded as an event, yet most events describe behaviour with no direct commercial value, such as scrolling down the page or playing a video. Marking an event as a key action is a later and deliberate step, taken by someone with business judgement.

Google Analytics 4 sorts events into four groups. Automatically collected events are recorded by the mere fact that the tag is installed. Enhanced measurement events appear once that option is switched on in the data stream, and they cover scrolling, outbound clicks, site search, video and file downloads. Recommended events are implemented by the team, yet they carry names and parameters fixed by Google. Custom events are defined by whoever implements them, with complete freedom over the name.

The difference between the last two groups is the one that saves the most work. A recommended event, with its exact name and its expected parameters, unlocks reports that already exist in the interface: ecommerce or lead generation can be read without building anything. If the same occurrence is sent under an invented name, the data still enters the property, but no standard report recognises it and every analysis has to be assembled by hand.

The documented limits are the second common stumble. Each event takes 25 parameters. The event name and every parameter name cannot exceed 40 characters, and a parameter value is cut at 100, with exceptions for the page title, location and referrer. Web data streams have no cap on distinctly named events; app data streams do, at 500 per user. To read a custom parameter in the reports it has to be registered as a dimension, and there a standard property holds 50 at event scope, 25 at user scope and 10 at item scope, plus 50 custom metrics.

One very concrete decision depends on event tracking: where the team invests next quarter. Without events, analysis stops at pageviews and sessions, which say how many people came by but not what they did. With well named events you can answer whether the product configurator gets used, whether the long form is abandoned at the third field, or whether site search returns empty results.

It also decides what can be optimised in advertising. Bidding platforms need a quality signal in order to learn, and that signal comes from one specific event. If the platform is sent “button click” instead of “request submitted”, the algorithm optimises towards the wrong gesture and the cost per real customer rises without the dashboard giving it away.

And it determines what can be reconstructed later. An event that was not measured in March cannot be recovered in September, because no historical trace of that action remains. That is why the event list is decided before a site launches and not on the day someone asks for a report.

• Write a measurement plan before touching any code: a table with the event, the action it represents, its parameters and the person who will ask for it in a report.
• Check the list of recommended events first. If one exists for your case, use it with its exact name and its expected parameters.
• Set a naming convention in lower case with underscores, and apply it without exception across the whole property.
• Register as a custom dimension only the parameters someone is going to look at. The 50 event-scope slots run out sooner than it looks.
• Verify every new event in debug mode before publishing, and repeat the check on mobile.
• Review the full list every six months and archive whatever nobody consults any more.

• Measuring everything. Every event with no owner and no question behind it is noise that nobody later dares to delete.
• Reinventing names that already exist, which leaves the standard reports empty even though the data is inside.
• Going past 25 parameters per event or past 100 characters in a value. The data is dropped or trimmed silently.
• Putting personal data into a parameter, such as the email address or the phone number someone typed into a form.
• Accepting an event because it shows up in real time, without checking the next day that it arrives with its parameters complete.