Analytics implementation that starts with a measurement plan
Broken analytics is rarely a tool problem. It is a definition problem, because nobody wrote down what counts as a lead, so three systems produce three answers. We settle that first, then build it in Google Tag Manager.
What is analytics implementation?
Analytics Implementation is the planning and engineering work that decides what an organisation measures, names every event, specifies the data layer and verifies the numbers before anyone opens a report. It suits Australian businesses whose systems disagree about the same figure, or who are rebuilding and want tracking designed deliberately rather than bolted on afterwards.
Get a fixed written quote- Typical timeline
- 2 to 6 weeks
- What drives cost
- The number of distinct events, whether a data layer already exists or has to be built, how many systems must reconcile against each other.
- Best for
- Organisations whose reported numbers disagree, or who are about to rebuild
- You own
- The plan, the containers, the properties and every account credential
- Built with
- Measurement plans, event taxonomies, data layer specifications, QA scripts
Your handover
What a measurement plan actually contains
A measurement plan is a short document stating what the business is trying to learn, which actions indicate progress toward it, and exactly how each of those actions will be recorded. It is written so that a marketing manager and a developer can both argue with it. Without one, tracking requests arrive individually, somebody adds a tag on a Thursday, and two years later there are four events that appear to mean the same thing and nobody can say which one the board report uses.
- 01Audit of existing tags, properties and reports
- 02Written measurement plan with definitions and owners
- 03Event taxonomy and naming guide
- 04Data layer specification for your developers
- 05Implemented events with debug verification
- 06Reconciliation against back end or CRM records
- Privacy review of what is collected and retained
- Documentation and a handover session
- A QA checklist to re run after each release
The full list
We start from decisions, not from data. If no one would act differently depending on the answer, the metric does not go in the plan. For a professional services firm the list is usually short: qualified enquiry, call from a mobile handset, proposal requested, proposal accepted. For a retailer it runs longer because the funnel genuinely has more steps. Either way each line records a plain English definition, a named owner, the system of record and an accepted margin of error, because a number nobody owns is a number nobody defends in a meeting.
- The commercial questions the data has to answer, written before any tool is opened
- A definition of a conversion that sales and marketing have both signed off
- Every event with its name, trigger condition, parameters and owner
- The system of record for each metric, so disagreements have a tiebreaker
- What is deliberately not tracked, and why
- A QA checklist that can be re run after any site release
Better instrumentation does not create curiosity, and a beautifully tracked site with no one reviewing it is an expense with no return.
Why event naming decides how long your tracking survives
An event taxonomy is a naming convention plus the rules for extending it. Ours is unglamorous: lower case, underscores, a verb and a noun, and a strong bias toward describing the user action rather than the marketing campaign that prompted it. A click on a phone number is one event with parameters for placement and page type. It is not eleven events named after eleven page templates, which is what you get when tracking is added one request at a time.
Parameters scale, event names do not
The reason to be strict is that platforms impose limits on how many distinct events and custom dimensions you can register, and those limits are reached surprisingly quickly by teams who create a new event per button. Parameters scale, event names do not. A disciplined taxonomy also lets the same vocabulary run through your ad platforms and your CRM, so a lead recorded on the site can be matched to a lead in the pipeline. That matching is what turns reporting into something a finance team will accept.
How the engagement runs
How an analytics implementation runs
The sequence matters. Almost every failed setup we are asked to repair was built in the reverse order, with tags installed first and definitions negotiated afterwards, at which point the definitions have to bend around whatever was already collected.
- 01AuditInventory every tag, property, pixel and report currently in use, and note which ones anybody actually reads
- 02InterviewsSit with sales, service and finance to find the decisions the data is meant to inform
- 03Measurement planDefinitions, owners, systems of record and the metrics we are deliberately dropping
- 04Event designThe taxonomy, parameters and the data layer specification handed to developers as a written contract
- 05BuildImplementation in the tag container and in site code where a tag cannot see what it needs
- 06VerificationDebug mode, a test matrix across devices, and a reconciliation of event counts against server-side records
- 07HandoverDocumentation, a naming guide for future events and training for whoever adds the next tag
Two decisions on your side that keep the project moving
We work in short stages with a working session at the end of each, because the useful disagreements about what a lead is only surface when someone from sales is in the room. Expect to spend more of your own time in the first fortnight than in the last, which is the opposite of how most technical projects feel.
The data layer is a contract between your site and your tags
A data layer is a structured object your website publishes describing what is on the page and what just happened. Product identifier, category, price band, logged in status, form name, error message. Tags then read from that object rather than scraping the page. It sounds like an implementation detail and it is the single biggest determinant of whether your tracking still works after the next redesign.
A data layer moves the dependency to something intentional and version controlled
Tags that depend on class names or the position of a button break silently the moment a developer tidies the markup. Nobody notices for six weeks, then a quarterly report shows enquiries falling off a cliff and someone spends a day proving it was never real. A data layer moves the dependency to something intentional and version controlled. We write the specification, review it with your developers, and include it in the definition of done for future releases so tracking is tested alongside the feature rather than after it. If we are also doing the build, this is wired during development instead of retrofitted.
What the Privacy Act means for what you collect
The Privacy Act 1988 and the Australian Privacy Principles apply to information about an identifiable individual, and a surprising amount of casual tracking drifts into that territory without anyone deciding to. Email addresses appended to URLs after a form submission. Full search queries containing a patient name. Free text fields captured wholesale into an analytics event. Once that data is in a third party platform it is difficult to remove and it is now your disclosure to explain.
The rest of the answer
So we treat collection as a decision with consequences. Personal information is stripped or hashed before it leaves the browser, query parameters are filtered at the container level, and the plan records what is collected, why, where it is stored and how long it is kept. Your privacy policy should describe the tracking in terms a reader can follow rather than in boilerplate. Practices bound by additional obligations, such as clinics working under AHPRA rules, need tighter settings again, and we scope those alongside their wider practice requirements.
When you should not pay for an analytics implementation
If your site has one page, one form and forty visitors a month, a formal implementation is machinery you do not need. Install the basic tag, watch the form submissions, and spend the money on getting more of the right people to the page. We would rather say that in a scoping call than invoice for a measurement plan that measures almost nothing.
In that case the first step is agreeing who owns which number and when they will look at it
It is also the wrong purchase if the honest problem is that nobody looks at reports. Better instrumentation does not create curiosity, and a beautifully tracked site with no one reviewing it is an expense with no return. In that case the first step is agreeing who owns which number and when they will look at it. Similarly, if you already know your enquiry pages convert poorly, you can act on that today through conversion rate optimisation without waiting for a perfect dataset. Measurement earns its keep when a real decision is waiting on it.
How we scope it
Four ways to scope your Analytics Implementation project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Analytics Setup
Tracking that is correct, so the rest is worth reading
Fixed written quote, agreed before work starts
- Audit of existing tags, properties and reports
- Written measurement plan with definitions and owners
- Event taxonomy and naming guide
Measurement build
The measurement your decisions actually depend on
Fixed written quote, agreed before work starts
- Everything in Analytics Setup
- Data layer specification for your developers
- Implemented events with debug verification
- Reconciliation against back end or CRM records
Analytics Full stack
Warehouse, pipelines and reporting across the business
Fixed written quote, agreed before work starts
- Everything in Measurement build
- Privacy review of what is collected and retained
- Documentation and a handover session
- A QA checklist to re run after each release
Analytics Ongoing
Keeping it accurate as the site and the tools change
Rolling monthly, quoted in writing
- Tracking checked after every site or tool change
- A named person who knows the account
- Reports maintained as the questions change
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How is analytics implementation different from just setting up GA4?
A GA4 setup configures one platform: the property, its key events, audiences and reports. Analytics implementation is the layer above that. It decides what the business needs to know, names the events, specifies the data layer and defines which system is authoritative when two numbers disagree. The GA4 work then becomes straightforward, because someone already decided what it is supposed to show.
How long does it take to get trustworthy numbers?
Two to six weeks for the implementation itself, depending on how many events you need and how quickly your developers can publish the data layer. Add a further two to four weeks before the reporting is genuinely useful, because you need enough collected data to spot anomalies. We verify each event as it goes live rather than waiting until the end, so problems surface while context is fresh.
What drives the cost of this work?
Four things: the number of distinct events, whether a data layer already exists or has to be built, how many systems must reconcile against each other, and how many stakeholder groups need to agree on definitions. The last one is often the largest and it is rarely the one clients expect. We scope it in a short discovery call and send a fixed written quote.
Who owns the accounts and the configuration?
You do. Properties, containers and any warehouse project are created under your organisation with your billing details, and Our access is collaborator level and you can revoke it whenever you like. The measurement plan, event taxonomy and data layer specification are written for your team and handed over as editable documents, so another agency can pick up the work without a discovery project.
Our data disagrees with our CRM. Can you find out why?
Usually, yes, and it is one of the most common reasons people call us. The causes are predictable: different definitions of a qualified lead, duplicate form submissions counted twice, spam entries reaching one system and not the other, or attribution windows that differ between platforms. We reconcile a sample period record by record and report what each gap is worth, then fix the ones that change a decision.
What happens when we redesign the site later?
The data layer specification and QA checklist are written so tracking is part of the release process rather than a retrofit. Before a redesign goes live we run the checklist against staging, compare event counts to the current site and flag anything missing. Clients who skip that step generally lose several weeks of data on their most important pages and only notice at the end of the quarter.
Related services
Find out what your data is actually telling you
Send us your site and a list of the numbers you do not trust. Inside a business day you get a straight assessment, and a fixed written quote if it makes sense.