What a New Agency Client Needs Before You Install Another Tracking Script

A new client wants better reporting, and your agency has a tracking script ready to install. Before adding it, establish what already runs on the site and what the client expects the new information to change.

An unfamiliar tag manager, an inherited consent setup or a booking page owned by another supplier can affect the result. Adding a script without that context can create another report nobody knows how to reconcile.

Make the first deliverable a clear inventory and a set of agreed decisions. That gives the installation a purpose, an owner and a way to demonstrate whether it worked.

Agree on the business question

Ask the client which decision the current reporting fails to support. Do they need to understand campaign quality, investigate a form problem or connect enquiries with sales outcomes?

Choose a useful first question and define the evidence needed to answer it. “Track everything” does not tell the agency which observations matter or what the client will do with them.

Write the intended outcome in the onboarding record. Keep a distinction between website activity, identified contacts, accepted enquiries and opportunities.

For an agency working with visitor information, the value discussion starts here. The client needs an explanation of what the information can support, not simply another tool on the invoice.

Map the full path the client controls

List the domains and pages involved in the visitor's task. Include campaign landing pages, the main website, forms, booking pages, checkout and confirmation destinations where relevant.

Record who controls each step. The client may manage its website while a separate supplier manages booking or payments. Do not assume that access to one page provides authority to change another.

Mark the environment for each destination. Keep test sites, staging pages and live customer paths distinguishable in the record.

Decide which path belongs in the first implementation. A small, complete route can be easier to evaluate than partial coverage across every domain.

Inventory what runs before adding more

Ask the responsible owner to document the existing scripts, tag managers and embedded tools on the chosen path.

For each item, record:

• Its purpose and the business team using it.
• Where it is installed and how it is loaded.
• The person who can explain or change its configuration.
• The information it handles and the destination receiving it.
• The consent conditions or other applicable requirements governing its behavior.
• Any known overlap with the proposed tool.
• The current test or evidence showing that it works.

Include tools introduced through a tag manager or embedded component. A list of visible scripts in one page template may not explain everything that loads during the task.

Keep the inventory usable. The goal is to understand responsibilities and information flow, not to copy sensitive configuration or access credentials into a shared presentation.

Resolve overlap as a separate decision

Two tools may observe similar events for different reasons. Find out which team uses each report before recommending a replacement.

In a fictional onboarding example, a client has analytics in its website template and another installation in a tag manager. The agency suspects duplicate purchase events. That suspicion should become a controlled investigation, not an instruction to remove whichever script is easiest to find.

Identify the event, inspect an appropriate test and ask the owners which installation is intended. Record the proposed correction and its effect on reporting.

Keep removal and replacement decisions explicit. The new script should not silently take ownership of a workflow the client still depends on.

Assign the consent and data decisions

The person installing a tag should know who decides how it may behave. Agree on that responsibility before configuration begins.

Document the choices the visitor sees, the expected tool behavior in each relevant state and how a changed choice should affect later activity. Include return visits and navigation to other parts of the agreed path.

Review the consent setup with the client's responsible owner. Confirm the actual requirements for the client's markets and uses rather than assuming a single banner configuration fits every situation.

Also decide who can access the resulting records, where correction requests go and what retention process applies. Keep unnecessary personal details out of general event labels and campaign links.

Define the report before connecting the fields

Write a short measurement agreement that names the unit and outcome.

If the first question is campaign quality, define an eligible visit, a successful enquiry, a distinct contact and the sales-acceptance rule. State the timezone, reporting cutoff and treatment of duplicates, tests and existing customers.

Keep unknown-source outcomes visible. Decide which attribution view the client wants and what that view does not prove.

If historical reports used different definitions, preserve the distinction. A new tool should not make a before-and-after comparison look consistent when its population or measurement basis changed.

Describe the handoff to the receiving team

Identify where useful information should go and who will act on it. The client may need a CRM record, a page-improvement task or an account-manager review.

Keep the required context short: relevant source, stated request, relationship, owner and next action. Record what can remain unknown without blocking a useful enquiry.

Review the integrations supporting the handoff against those requirements. A list of available connections is the start of a discussion; the test is whether the receiving person gets the information needed for the agreed task.

Include failure ownership. Someone should know where to investigate when the source records a successful action but the destination has no corresponding record.

Agree on the test and the acceptance evidence

Use the approved environment and controlled test details. State which scenarios the agency will inspect before calling the work complete.

A practical first set can include a fresh visit, the relevant consent choices, a successful form or booking, a repeated submission and a visit from a known test contact. Add the failure states the implementation is expected to handle.

For each scenario, define the expected observation, receiving record and owner. Keep internal tests identifiable and excluded from customer performance totals.

Do not use real visitors' sensitive field contents to prove a tracking path. The acceptance evidence should show the intended behavior with the minimum appropriate information.

Leave an operating record the client can use

Finish the onboarding packet with the inventory, scope, decision owners, reporting definitions, test results and the route for requesting a change.

Record the implementation date and any known limitations. Explain which results can be compared with earlier reporting and which need a new baseline.

Give the client a clear next review question. That might be whether the accepted enquiry reaches its owner with the right context or whether a product page now has enough evidence for a useful inspection.

Connecting website activity to a practical action works best when that operating record exists. Before the next script goes live, establish what it is for, where it belongs and how both agency and client will know that it helped.