Why Human-in-the-Loop Tracking Still Matters in an Increasingly Automatic World
Automation is extremely valuable and yes, the veritable candy box of metrics and collected data points is truly something to be excited about. We live in a golden age and the Midas touch of data collection has an inherent danger. This danger is automation without supervision.
There is something wonderfully reassuring about a platform telling you that tracking has been installed automatically.
Tick the box.
Connect the account.
Enable enhanced measurement.
Press publish.
Congratulations. You now have data.
Whether it is the right data is, unfortunately, a slightly different question.
Modern analytics and advertising platforms have become extraordinarily good at automating data collection. Google Analytics paired with Google Tag Manager can automatically capture events such as page views, scrolls, outbound clicks, site searches, video engagement and file downloads through Enhanced Measurement, often without developers having to write additional tracking code.
That is genuinely useful. But automatic tracking has created an interesting misconception:
If the platform can automatically collect something, the tracking setup must automatically be correct.
Those are not the same thing.
Automatic tracking is very good at detecting technical activity. It is unfortunately not as good at understanding business meaning.
A human-in-the-loop tracking implementation therefore does not mean manually coding every event because we enjoy making our lives difficult. I need to be clear that at no point am I advocating for a large number of manual integration hours paired with complex funnel planning and journey mapping without the assistance of AI.
It means introducing deliberate human judgement into the design, implementation, validation and governance of measurement. And as websites, indexable online platforms , consent requirements, server-side tracking, advertising platforms and attribution systems become more sophisticated, that judgement cycle matters more rather than less. In my opinion.
Automatic tracking answers “what happened?”
Human-designed tracking answers “what did it mean?”
Imagine a visitor lands on a website.
They scroll.
They click a button.
They open a form.
They submit something.
Automatic tracking can potentially identify several of those interactions. A significant step forward from the gut-feel intuition of, “We believe it’s working, but we’re not entirely sure which part is driving the result.”This uncertainty remains one of the key reasons automated mapping has evolved to where it is today.
At its core lies the age-old marketing question: where is the best place to spend budget in order to generate the greatest possible return on investment (ROI)?
Now consider these questions:
Was the form actually submitted successfully?
Was it a sales enquiry or a newsletter signup?
Was it a job application?
Was it spam?
Did the button click initiate a process that later failed?
Was the visitor already a customer?
Was the event accidentally fired twice?
Was it triggered before consent was received?
Was the10,000 purchase actually 10,000, or did somebody forget that the value was being passed in Euro, Pound, Dollar, cents, pence or other ?
Was the transaction ID unique?
Was the user sent to another domain halfway through the journey?
Did the payment gateway return them as referral traffic?
Suddenly the reassuring little green tracking light is doing considerably less reassuring.
This is why technically designed measurement still matters.
Platforms can detect behaviour.
Humans still need to define meaning.
The difference between installing analytics and designing measurement
Installing analytics is relatively easy.Designing useful measurement requires understanding the organisation.
A sensible measurement implementation normally starts with business questions such as:
What constitutes a meaningful conversion?
What stages exist between initial interest and revenue?
Which interactions indicate genuine intent?
What information needs to be sent to advertising platforms?
What information absolutely must not be sent?
What consent is required?
How should users be identified across different domains or systems?
How will CRM outcomes eventually be reconciled with media activity?
Only then should someone start creating tags.
Unfortunately, measurement projects have historically had a tendency to begin the other way around:
“We have GA4 installed. What can we report on?”
Technically, quite a lot. Strategically, perhaps not what you actually needed.
Google itself separates GA4 events into automatically collected, enhanced measurement, recommended and custom events. Recommended and custom events require additional configuration because they represent behaviours that cannot simply be inferred reliably from a default installation.
Ecommerce is an even clearer example.
Google specifically notes that ecommerce events require additional context and therefore are not sent automatically.
Which makes sense.
Google can observe that somebody clicked something.
It cannot magically know that clicking that particular thing represents:
add_to_cart
with:
Product ID
Product name
Quantity
Currency
Price
Category
Promotion
Discount
Transaction information
unless somebody has deliberately designed how that information becomes available.
That somebody is still, regrettably for those hoping AI would remove all meetings from our lives, a human. Usually a slightly sarcastic one with a touch of technical short fuse syndrome.
Human-in-the-loop tracking does not mean anti-automation
This distinction is important. A human-in-the-loop measurement philosophy is not an argument for manually doing everything.
Quite the opposite. Good technical measurement uses automation aggressively.
Automatic events can reduce unnecessary implementation work.
Tag management systems simplify deployments.
Consent platforms automate consent signalling.
Server-side infrastructure can improve control and data quality.
Enhanced conversions can improve conversion measurement by supplementing existing conversion tags with hashed first-party customer data.
Server-side tagging can introduce an additional layer between the user's browser and marketing vendors, giving organisations more control over the data that is ultimately distributed. Google also highlights potential benefits including improved page performance, security and data quality.
Automation is extremely valuable and yes, the veritable candy box of metrics and collected data points is truly something to be excited about. We live in a golden age and the Midas touch of data collection has an inherent danger. This danger is automation without supervision.
We should be striving towards a better model of:
Human designs → technology automates → human validates → systems monitor → human intervenes when necessary.
It is the same human-in-the-loop principle increasingly being applied to AI. Use the machine for scale and keep judgement around the important bits.
Common Tracking Mistakes and Gotchas
This is where things become entertaining.
Or deeply irritating, depending on whether you discovered the problem before or after three months of campaign optimisation.
1. Tracking clicks instead of outcomes
One of the most common measurement mistakes is confusing an action with a successful result.
For example:
A user clicks Submit Enquiry.
A tracking tag fires.
Conversion recorded.
Unfortunately, the form validation then fails because the telephone number is invalid.
The user leaves.
Marketing reports a lead.
Sales never receives one.
The advertising platform optimises towards generating more people who are extremely good at pressing buttons.
This is technically perfect tracking of the wrong thing.
Whenever possible, conversion tracking should fire from a confirmed business outcome rather than merely the interaction that attempted to create it.
Examples include:
Successful form submission event
Thank-you state
Backend confirmation
Confirmed transaction
CRM record creation
Completed booking response
The principle is simple:
Track success, not intention to succeed.
2. Double firing
Few things make a dashboard look healthier than accidentally recording every conversion twice.
Unfortunately, finance departments tend not to recognise this particular growth strategy.
Duplicate events commonly happen when:
A hard-coded tag and GTM tag both exist.
A page reload re-triggers the event.
A single-page application fires route changes incorrectly.
Both browser-side and server-side tracking send the same event without appropriate deduplication.
A purchase confirmation page can be revisited.
Multiple GTM containers are installed.
The same platform integration exists through both a CMS plugin and manual implementation.
Google explicitly recommends using transaction IDs for ecommerce purchases so duplicate purchases can be identified and deduplicated.
There is even a particularly impressive gotcha of sending an empty transaction ID. This is not equivalent to having no transaction ID.
Google warns that sending transaction_id="" can cause purchases using that empty value to be deduplicated against each other.
One tiny empty field.
Potentially one very confusing revenue report.
3. Assuming an event appearing means the event is configured correctly
This catches people constantly.
An event appears in analytics.
Success!
Not necessarily.
For ecommerce tracking, Google notes that events with missing required parameters can still appear in Analytics, but they may be treated differently instead of functioning as the intended ecommerce event.
The same problem applies more broadly.
An event called:
lead_form_submit
might appear perfectly happily.
But perhaps it contains no:
Form type
Lead category
Product
Location
Campaign classification
Customer type
The event exists.
Its analytical value may be approximately that of knowing that “something happened somewhere” generally in a virtual galaxy far far away.
Parameters are where events become meaningful, (I am writing this here again for effect.) Parameters are where events become meaningful
Google's own documentation makes the same distinction: event parameters provide additional information describing the interaction being measured.
4. Naming events creatively
Creativity is wonderful.
Analytics taxonomies are generally not the best place for it.
Google recommends standard event names for many common actions.
So:
add_to_cart
is preferable to:
put_the_thing_in_the_basket or ADD_to_CarT or Add_TO_CArT
Even if the second ones have considerably more personality.
Google specifically warns that using an incorrect ecommerce event name such as add_to_basket instead of the recommended add_to_cart can prevent Analytics from recognising it as the standard recommended ecommerce event.
Before creating a custom event, therefore:
Check whether an automatically collected event already exists.
Then check enhanced measurement.
Then check Google's recommended events.
Only create a custom event when none of those adequately represents the interaction.
This improves compatibility with standard reports, integrations and future analysis.
It also prevents your analytics account becoming an archaeological dig through five years of enthusiastic event naming.
5. Currency and value errors
Nothing ruins an ROI calculation quite as efficiently as getting revenue wrong.
Common problems include:
Passing cents instead of whole currency units.
Passing revenue without currency.
Passing subtotal in one system and total order value in another.
Including VAT inconsistently.
Including delivery sometimes.
Excluding discounts.
Passing strings instead of numbers.
Google recommends setting the currency parameter whenever ecommerce value is sent.
These sound like small implementation details.
They are not.
Advertising algorithms increasingly optimise against value.
If the value being supplied is wrong, the machine may simply become extremely efficient at optimising towards incorrect economics.
Automation does not solve bad data. It accelerates it.
6. The payment gateway attribution problem
A particularly common ecommerce surprise occurs when users leave the main website to make payment.
They travel from:
yourwebsite.com
to:
paymentprovider.com
and then return.
Without the correct configuration, analytics can potentially interpret the returning visitor as arriving from the payment provider rather than from the marketing source that originally generated the customer.
Congratulations.
Your payment gateway is now apparently one of your strongest acquisition channels.
Cross-domain configuration and referral management exist specifically to solve these sorts of problems.
Google explains that cross-domain measurement allows activity across multiple domains to remain associated with the same user and session. Without it, different identifiers can be generated as the visitor moves between domains.
This matters for:
Booking engines
Payment providers
Separate ecommerce domains
Lead-generation microsites
Account portals
Third-party application systems
Whenever a user journey crosses domains, somebody should explicitly map that journey before implementation.
7. Consent that technically exists but technically doesn't work
Consent management is another area where installing a platform is very different from implementing it correctly.
A cookie banner appearing on the screen does not automatically mean every tracking technology underneath it is behaving appropriately.
Google Consent Mode, for example, requires both a default consent state and an updated consent state reflecting the user's selection. Google also warns that the consent update needs to happen correctly when the user's choice changes.
One implementation gotcha documented by Google involves changing consent immediately before a page reload.
If the browser navigates away too quickly, measurement associated with the updated consent state may not complete correctly, potentially resulting in incomplete reporting.
Again:
Tiny technical detail.
Large downstream measurement consequence.
Consent therefore needs testing as a technical state, not merely reviewing whether the banner looks lovely.
Test:
Before consent.
After analytics consent.
After advertising consent.
After rejecting consent.
After changing preferences.
Across page navigation.
Across returning sessions.
Across regions where applicable.
And ideally verify what is actually being transmitted rather than trusting that because the button says “Reject”, everything underneath has respectfully obeyed.
8. Automatically collected data that nobody actually wanted
Automatic measurement creates another subtle problem.
It can collect things simply because it can.
Google's Enhanced Measurement can automatically capture interactions such as scrolls, outbound clicks and file downloads.
Useful?
Potentially.
Useful in every business?
No.
A file download might represent:
A brochure download.
A price list.
A staff policy PDF.
A terms-and-conditions document.
A press release.
A menu.
A product specification.
Treating all downloads as equal creates an attractive metric with very little business meaning.
Automatic tracking should therefore be reviewed rather than merely enabled.
The question should not be:
“Can we track this?”
It should be:
“Will tracking this help somebody make a decision?”
9. Tracking personally identifiable information accidentally
The technical ability to capture information does not mean that information should be sent everywhere.
Google specifically requires organisations using Analytics to avoid sending personally identifiable information.
Modern websites contain enormous amounts of potentially sensitive information:
Email addresses
Telephone numbers
Names
Account identifiers
Search queries
Form fields
URLs containing query parameters
Poorly configured automatic tracking can accidentally expose some of this information through URLs, event parameters or page titles.
Enhanced conversions demonstrate the correct principle rather nicely.
First-party information used for enhanced conversion matching is hashed using SHA-256 before transmission under the supported implementation.
Human governance is therefore essential in deciding:
What information is collected.
Why it is collected.
Where it goes.
How long it is retained.
What consent applies.
Whether it is necessary.
10. Server-side tracking is not magic
Server-side tracking has become understandably popular.
It provides significant opportunities for improved control, performance and first-party data architecture.
But “server-side” should not be interpreted as:
The Tracking Place Where Nothing Can Go Wrong ™
Server-side architectures still require:
Event design.
Mapping.
Consent handling.
Deduplication.
Infrastructure monitoring.
Vendor configuration.
Testing.
Security.
Cost management.
Domain configuration.
Transformation rules.
Google explicitly recommends configuring server-side tagging with a first-party/custom domain and verifying that the setup works correctly.
Server-side tagging gives organisations greater control.
Control is valuable precisely because somebody must exercise it.
The data layer remains one of the most important pieces
For sophisticated measurement, one of the most valuable architectural ideas remains surprisingly unglamorous:
A structured data layer.
Instead of trying to infer important business information from whichever text happens to appear on the page, the website deliberately exposes structured information to the measurement layer.
For example, rather than scraping:
“Toyota Hilux 2.8 GD-6 4x4 Auto”
from a heading and hoping nobody redesigns the HTML next Tuesday, the application can deliberately expose:
Vehicle ID
Model
Derivative
Price
Category
Stock status
User state
The measurement implementation can then consume structured business data rather than reverse-engineering the front end.
This separation matters enormously.
Websites change.
Buttons move.
CSS selectors change.
Layouts are redesigned.
React components appear.
Forms are rebuilt.
A measurement implementation that depends entirely on visually scraping page elements can be surprisingly fragile.
A deliberate data layer creates a contract between:
Development.
Analytics.
Marketing.
Advertising platforms.
And business reporting.
It is less glamorous than clicking “Automatically detect”.
It is also considerably more dependable.
Human-in-the-loop means testing the complete journey
A tracking implementation should never be considered complete simply because the tag fired.
Testing should follow real journeys.
For a lead-generation website:
Arrive from a tagged marketing campaign.
Confirm acquisition information.
Navigate through relevant pages.
Open the form.
Test validation errors.
Successfully submit.
Confirm the event fires once.
Confirm expected parameters.
Confirm consent behaviour.
Confirm the lead appears downstream where expected.
For ecommerce:
Product impression.
Product detail.
Add to cart.
Remove from cart.
Checkout.
Payment.
Purchase.
Revenue.
Currency.
Transaction ID.
Refund.
Cross-domain behaviour.
Google provides DebugView specifically to allow teams to inspect events and user properties in real time while validating tracking implementations.
That is an important clue.
Even the platforms building automatic measurement tools provide debugging tools.
Because they know implementation still needs verification.
Tracking should also be monitored after launch
Possibly the biggest mistake in analytics is treating tracking as a project.
Implement.
Test.
Launch.
Forget.
Six months later somebody discovers that the lead form was rebuilt three months ago.
Tracking stopped firing.
Nobody noticed.
Everything looked fine because the dashboard still contained numbers.
Tracking should therefore be treated as infrastructure.
Critical conversions should ideally have monitoring around:
Sudden volume drops.
Sudden volume increases.
Missing parameters.
Unexpected domains.
Revenue anomalies.
Event duplication.
Consent changes.
Tagging changes.
Website releases.
Tracking health is not simply an analytics responsibility.
It is part of the technical reliability of the marketing ecosystem.
The real future is hybrid measurement
The future of tracking is unlikely to be fully manual. It is also unlikely to be completely automatic.
It will and should be hybrid.
Automatic collection will handle increasingly standardised behaviour.
Consent-aware modelling will help address gaps in observable behaviour. Google already uses consent signals and modelling approaches where appropriate within Consent Mode implementations.
Server-side infrastructure will give organisations more control over how data is processed and distributed. First-party data will increasingly supplement browser-based measurement. Advertising platforms will continue improving automatic matching and conversion recovery.
AI will almost certainly help identify tracking anomalies and generate implementation recommendations.
But somebody still needs to answer:
What are we actually trying to measure?
Because there is no universal automatic answer. A bank's conversion is different from a car manufacturer's. A dealership lead is different from a vehicle configurator completion. A B2B enquiry is different from an ecommerce checkout. A 5,000 unit sales-qualified opportunity is not equivalent to a newsletter signup, despite both potentially involving a form.
Technology can track interactions.
Businesses assign value to them.
That distinction is where human-in-the-loop measurement remains indispensable.
Automation Gives Us Scale. Humans Give It Meaning.
Automatic tracking is one of the best developments in digital measurement.
It allows organisations to collect useful information faster, reduces repetitive implementation and makes sophisticated measurement accessible to considerably more businesses.
We should absolutely use it.
But we should not confuse convenience with correctness.
The strongest measurement ecosystems increasingly combine:
Automatic collection.
Structured technical implementation.
First-party data.
Server-side control.
Consent-aware measurement.
Automated monitoring.
And human oversight.
The human-in-the-loop is not there because the technology is incapable.
The human is there because technology cannot know what your business intended unless somebody tells it.
And that may ultimately be the most important principle in tracking:
Data appearing in a dashboard is not proof that measurement is working.
It is merely proof that data arrived.
Someone still needs to make sure it was the right data, collected at the right moment, with the right context, under the right consent, attributed to the right source and interpreted in the right way.
Automatic tracking can make measurement easier.
Human-in-the-loop tracking makes it trustworthy.
And when those measurements are being used to allocate millions in media spend, calculate ROI, optimise bidding algorithms and inform business decisions, trustworthy remains rather important.
A mouthful this one, but so important,
Onward and upwards
P.S Here is the short version of all of the above in a checklist:
The Practical Human-in-the-Loop Tracking Checklist
Before considering a tracking implementation finished, ask:
Measurement
Have the business outcomes been defined before the events?
Are we tracking successful outcomes rather than merely clicks?
Are recommended events being used where appropriate?
Do important events contain useful parameters?
Technical implementation
Is there a deliberate data layer?
Are events firing exactly once?
Are values and currencies correct?
Are transaction IDs unique and populated?
Are SPA and dynamic interactions tested?
Have mobile and desktop journeys both been tested?
Domains and attribution
Does the journey cross multiple domains?
Is cross-domain tracking configured correctly?
Are payment gateways creating referrals?
Are campaign parameters surviving the journey?
Privacy and consent
Do tags behave correctly before consent?
Are consent updates firing correctly?
Is personally identifiable information excluded from inappropriate analytics collection?
Has behaviour been tested after acceptance, rejection and preference changes?
Advertising
Are primary and secondary conversions deliberately classified?
Are advertising platforms optimising towards actual business outcomes?
Is enhanced conversion or first-party data implementation appropriate?
Are browser and server events deduplicated where applicable?
Validation
Has somebody tested the entire customer journey?
Have Realtime and debugging tools been used?
Have values been reconciled against backend systems?
Has tracking been tested after deployment rather than only in staging?
Governance
Who owns the tracking implementation?
Who approves measurement changes?
Are GTM changes documented?
Are tracking requirements included in website release processes?
Is somebody alerted if critical conversions suddenly disappear?
If nobody can answer the last few questions, you probably do not have a tracking insight generation system. You have some tags firing some data to a place where it can either be seen or stored.
