Events Instead of Pageviews

What the difference is

A pageview records that a page loaded. It says nothing about what happened next.

An event records that something occurred: a button pressed, a form sent, a number tapped, a file downloaded.

Which means pageviews measure arrival and events measure behaviour, and only one of those is connected to whether the business got any work.

A site with four thousand pageviews and no events is measuring traffic and nothing else.

The events worth having

• Form submission, which is the clearest enquiry signal.
• Phone number tapped, on mobile.
• Email address clicked.
• Directions or map opened, for a business with premises.
• Quote or price list downloaded.
• Booking started, where one exists.

The first two cover most of what a local business needs. The rest are useful where relevant and are not worth building before those two exist.

Why a phone tap matters most

For a trade, it is frequently the only measurable version of the main enquiry route.

Most enquiries arrive by phone, and a phone call is invisible to analytics unless the number was tapped on the site.

A tap is not a completed call, since somebody may tap and change their mind, and it is a strong statement of intent.

More importantly it is countable and it has a trend, which converts the main channel from an unknown into something you can watch.

A business whose phone taps rose fifty percent after a change has learned something no pageview figure would have told it.

A worked example

A trade business measuring only pageviews, with traffic broadly flat for two years.

They added two events: form submission and phone tap.

Within a quarter the picture was different from the one the traffic figure had suggested.

Pageviews were unchanged and phone taps had risen substantially, concentrated on three service pages added the previous year.

Those pages were sending people directly to the phone rather than around the site, which reduced pageviews per visit and increased enquiries.

By the only measure the business cared about, the site had improved considerably, and the metric they had been watching showed nothing.

Marking the important ones

Not every event is equally significant, and the reporting distinguishes them.

A form submission and a scroll to the bottom of a page are both events and only one represents an enquiry.

Marking the significant ones separately means the reporting can show them as outcomes rather than burying them in a list.

For a small business that list is short: form submission, phone tap, and possibly one more.

Marking too many is the common error, and it produces a report where everything is an outcome and nothing stands out.

Setting them up

Easier than it sounds, and there are three routes.

Some are collected automatically without any configuration, including outbound clicks, file downloads and scrolling, depending on the setup.

A tag manager handles the rest without touching the site, which is the tidiest arrangement and worth the hour of learning if you will do this more than once.

And some form plugins can send an event directly when a submission succeeds, which is the simplest route where it is available.

The phone tap requires identifying the link and firing an event when it is clicked, which a tag manager does in a few minutes.

Naming them consistently

A small discipline that saves considerable confusion later.

Events carry a name, and that name is what appears in every report afterwards.

Which means a naming decision made carelessly in ten minutes is one you live with for years, particularly once there are several.

Use lower case, use underscores rather than spaces, and use a consistent shape: the thing, then what happened. Something like form_submit and phone_tap.

What produces a mess is naming them descriptively in prose, so that a report lists Contact Form Submitted alongside phone-click and quoteRequest, which are three conventions in one list.

Write the names down somewhere alongside what each one means, since in a year nobody will remember what a particular event was recording.

The counter-case

Where events are not the priority.

A business receiving two enquiries a month, where counting them by hand is faster and more accurate than configuring anything.

A site with no interactive elements at all, where there is genuinely nothing to record beyond arrival.

And any business already tracking enquiries properly in a spreadsheet with sources, which is a better record than events produce and is not replaced by them.

Events are useful because they are automatic, and they are less complete than asking people, which remains the more reliable method.

Testing that they fire

The step that separates an event that exists from an event that works.

Open the real-time view in analytics, then use the site yourself: submit the form, tap the number, do whatever the event should record.

The event should appear within seconds, named as you configured it.

What frequently happens instead is nothing, because the form redirects before the event fires, or the trigger matched the wrong element, or a plugin update changed the button.

Which is why an untested event is a common and invisible failure: the report simply shows zero, and zero looks like nobody enquiring rather than like a broken configuration.

Retesting after any site change takes two minutes and catches this before it costs a quarter of data.

What events cannot tell you

Worth being clear, since they are frequently over-trusted.

A form submission event does not know whether the enquiry was useful, from your area, or converted into anything.

A phone tap does not know whether the call connected or what was said.

Which means an event count is a measure of intent rather than of business, and it needs the enquiry record beside it to mean anything commercially.

The two together are considerably more informative than either alone: events show the trend, the record shows what came of it.

Where to start

1. Form submission, first.
2. Phone tap on mobile, second.
3. Mark both as significant in the reporting.
4. Test each by doing it yourself.
5. Note the date you started collecting.
6. Leave everything else until those two are working.

The fourth is the step people skip, and an event configured but not tested is frequently an event that never fires.

What to do with the resulting numbers is covered in counting enquiries instead of visits.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.