Google Analytics and Tag Manager

On the Google side sit two distinct things that are often spoken of as one. Analytics is a measurement product: it collects events from your pages, attributes them to traffic sources using its own rules, and reports on funnels and audiences. Tag Manager is a container: a single script you install once, which then loads and configures every other tag (Analytics, ad pixels, chat widgets, heatmaps) without further code changes, governed by triggers and variables you define.

On the AppBO side sit funnels, landing pages, order and booking pages, forms, and the platform's own tracking, which captures source parameters into contact fields and is the basis of the attribution reporting your CRM shows. The two measurement systems overlap but do not agree, and understanding why is most of the work: Analytics attributes sessions by its own model, while the platform attributes a contact by what was on the URL when that contact was created.

You add Analytics and Tag Manager because they answer questions the CRM cannot: how many people reached step two and abandoned, what a visitor did before converting, which page the drop-off is on. You do it carefully because the standard ways of installing them break the thing you already have. A redirect that strips query parameters, a consent banner that blocks the platform's own script, a tag that rewrites links, and the symptom is attribution quietly going blank rather than an error anybody sees.

1. Decide what each system is for before installing anything. Analytics answers behavioral questions about traffic and pages; the platform's own attribution answers who a contact came from. Write down which one is authoritative for which report, because they will disagree and someone will ask.
2. Create or identify the Analytics property and note its measurement identifier. Create a Tag Manager container for the site and note its container identifier. Keep them separate in your notes, because mixing the two identifiers is a common and confusing error.
3. Decide where Analytics is loaded from. Installing it through Tag Manager rather than directly is the better pattern: one script to manage, and consent controls in one place.
4. Install the Tag Manager container in the sub-account's tracking-code settings so it applies to every funnel and page, rather than pasting it page by page. Where the platform offers a head and body code area, place each snippet in the area Google's own instructions specify.
5. Add the container to the website too if the website is separate, using the same container so one data model covers the whole journey.
6. Configure the Analytics tag inside Tag Manager with the measurement identifier, firing on all pages, and publish the container version. An unpublished container does nothing, which is the single most common reason a correct setup appears broken.
7. Protect the query parameters. Check every redirect, canonical rule and funnel step for anything that drops the URL query string, because that is where the campaign and click identifiers live. A redirect that strips them destroys both platform attribution and ad-platform conversion import at once.
8. Confirm the platform's own tracking still captures source, medium, campaign and the ad click identifiers into contact fields after the container is live. Submit a test form with parameters on the URL and inspect the contact record.
9. Define the events worth measuring: funnel step views, form starts, form submissions, booking completions, order completions. Decide which are Analytics conversions.
10. Implement those events through Tag Manager triggers. Prefer triggers based on the platform's own form-submission or page-view signals over fragile selectors tied to a particular layout, and document which is which.
11. Set up cross-domain measurement if the journey spans a website domain and a funnel domain. Without it, a visitor crossing domains starts a new session and Analytics attributes the conversion to a referral from your own site.
12. Exclude internal traffic in Analytics, and exclude any payment-processor or booking-tool domains from the referral exclusion list so a return from checkout does not look like new traffic.
13. Handle consent properly. If you use a consent banner, configure the consent settings in Tag Manager so tags fire according to the choice made, and verify the platform's own essential tracking still works when marketing consent is declined: test both the accept and the decline path.
14. Decide whether any personally identifying data could reach Analytics. Query parameters that carry an email address, and form values pushed into the data layer, are the usual culprits; sending them breaches Analytics policy, so strip or hash before they reach a tag.
15. Verify with Tag Manager's preview mode: walk the whole funnel and confirm each tag fires once, on the right trigger, with the right values, and not on the wrong pages.
16. Verify in Analytics' real-time view that the events arrive with the expected names and parameters.
17. Reconcile deliberately after a week: compare Analytics conversions with contacts created in the platform. Expect a difference, understand each cause (consent, blockers, bots, attribution model, session timeouts) and write the explanation down so nobody rediscovers it quarterly.
18. Keep a change log of container versions. A published version is a deployment, and the ability to say what changed on the day the numbers moved is worth the small discipline.

Platform pages to Google

• Page-view events from every funnel step, landing page and website page carrying the container.
• Custom events you configure: form starts and submissions, booking completions, order completions, button and link clicks, scroll and engagement signals.
• Event parameters such as the funnel name, step name, product or service, and value where you choose to send it.
• Data-layer values the page exposes, which is what Tag Manager triggers and variables read.
• Consent state, where a consent platform is wired into Tag Manager.
• Any other tag the container loads: ad platform pixels, heatmaps, chat widgets.

Google to the platform

• Nothing, in the ordinary configuration. Analytics is a measurement destination, not a source; it does not write to contact records.
• Where your platform version offers an Analytics reporting connection, aggregate figures can be read back for dashboards. That is reporting, not attribution, and it will not match the CRM's own numbers.

What the platform's own tracking handles instead

• Campaign parameters and ad click identifiers captured from the URL into contact fields at first touch.
• The attribution shown on a contact and on CRM reports.
• The identifiers used for conversion import back to the ad platforms.

What does not move

• Personally identifying data. Email addresses, phone numbers and names must not be sent to Analytics, as a matter of its own policy as well as good practice.
• Individual visitor identity in either direction. Analytics will not tell you which contact a session belonged to.
• Historical data when a property or container is replaced. A new property starts empty, and nothing backfills.
• Server-side events the platform generates with no browser involved, such as a pipeline stage change, unless you deliberately send them server-side.
• Agreement between the two systems. The counts will differ, and the difference is not a bug to be fixed.

Scenario: an agency adds Analytics and Tag Manager to a client's funnel and discovers it has been breaking attribution for weeks.

1. The client reports that CRM attribution shows most leads as direct, despite heavy paid spend. The agency starts by checking the funnel rather than the ad platforms.
2. A Tag Manager container is created and installed in the sub-account's tracking settings so it covers every funnel and page. The Analytics tag is configured inside it with the measurement identifier and set to fire on all pages, and the container version is published.
3. Preview mode is opened and the funnel walked from a test ad click. The container fires on step one, and then the page redirects to step two, and the query string is gone.
4. The redirect, added months earlier to force a trailing slash, is stripping the query string. That is why the platform's tracking never captured the campaign parameters or the click identifier, and why every lead looked direct.
5. The redirect is rewritten to preserve the query string. A fresh test click now carries the parameters through to step two, and the resulting test contact shows the campaign, medium and click identifier on its record.
6. With attribution restored, the behavioral measurement is built: funnel step view events for each step, a form-start event, and a form-submission event configured as an Analytics conversion.
7. The triggers are built on the platform's own form-submission signal rather than a CSS selector, so a later design change will not silently break them.
8. Cross-domain measurement is configured, because the client's website and funnel sit on different domains and Analytics had been treating the crossing as a new referred session.
9. The payment processor's domain is added to the referral exclusion list, so returning from checkout no longer starts a new session credited to the processor.
10. The consent banner is wired into Tag Manager's consent settings. Both paths are tested: on accept, Analytics and the ad pixels fire; on decline, they do not, and the platform's essential form handling still works.
11. A week later the numbers are reconciled. Analytics reports fewer conversions than the platform reports contacts; the differences are traced to declined consent, ad blockers, and one page where a bot was submitting the form.
12. A bot-filter rule and a honeypot field are added, and the remaining gap is documented so the client understands why the two dashboards differ and which one to use for which question.
13. Funnel reporting now shows a large drop-off between step two and step three. The step is rewritten, and the next two weeks's data shows the drop-off halved. A question the CRM alone could never have answered.
14. The container version history is used a month later when conversions suddenly double: a colleague had added a second Analytics tag. The version diff shows it in a minute, and it is removed.

Rate limiting

Client-side collection is not rate limited in the way an API is, but Analytics does apply cardinality and collection limits. Caps on the number of distinct event names, parameters and custom dimensions, and thresholds above which reports aggregate values into an other bucket. A container that sends an event name containing a unique identifier will exhaust cardinality and ruin the reports. The reporting API has its own quotas where you read data back. Check Google's current published limits for your property type rather than assuming, and keep event and parameter names to a small controlled vocabulary.

Retries and idempotency

There is no idempotency in client-side measurement, and that is the whole problem: a tag that fires twice counts twice. The usual causes are a container installed both through the sub-account's global setting and again on an individual page, two Analytics tags in one container, a trigger that fires on both a page view and a history change in a single-page flow, and a thank-you page a visitor can reload or revisit. Fire conversion tags on a trigger that happens once, deduplicate with a transaction or event identifier where the tag supports it, and use preview mode to count fires rather than assuming.

Field-mapping traps

Event and parameter names are case-sensitive, and a near-miss creates a second event nobody is reporting on. Parameters must be registered as custom dimensions before they appear in reports, and registration is not retroactive, so a parameter sent for a month before registration is invisible for that month. A value sent as text where a number is expected will not aggregate. Triggers built on CSS selectors break whenever a page is redesigned, and the breakage is silent. The gravest mapping trap is sending personally identifying data into a parameter, which breaches Analytics policy and can put the property at risk.

Duplicate creation

Duplicates here are duplicate measurements rather than duplicate records, and they are the commonest cause of a dashboard nobody trusts: double-installed containers, double Analytics tags, a conversion tag firing on page load of a reloadable confirmation page. Separately, a visitor who crosses between the website domain and the funnel domain without cross-domain measurement is counted as two users on two sessions, which inflates user counts and destroys source attribution.

Sandbox versus live

Tag Manager's preview mode and Analytics' real-time and debug views are a genuinely good sandbox: you can see every tag, trigger and variable evaluate before publishing. Use a separate container environment or a test property for substantial changes, and never test a new conversion tag against the production property during a reporting period you intend to use. Remember that preview mode proves firing, not reporting, processing delays mean a correctly firing tag can take hours to appear in standard reports.

Authentication expiry

The client-side container needs no token and keeps working indefinitely, which is both the convenience and the risk: nothing expires, so nothing prompts a review, and a container can go on loading a tag for a tool the business stopped using two years ago. Where you have connected Analytics for reporting into a dashboard, that connection is a normal OAuth grant and breaks with the usual causes. Audit container contents on a schedule rather than waiting for a failure.

What commonly breaks

• A redirect or canonical rule stripping the URL query string, which destroys both platform attribution and ad-platform conversion import at once. The single most damaging fault in this area.
• A container created but never published, so nothing fires at all.
• A consent banner blocking the platform's own tracking along with the marketing tags, so attribution disappears for everyone who declines.
• Cross-domain measurement never configured, with self-referrals accounting for most of the traffic.
• Double-counted conversions from a duplicated container or a second Analytics tag.
• Triggers tied to page markup that a redesign quietly breaks.
• Email addresses reaching Analytics in a page URL or a data-layer value.
• Analytics figures and CRM figures compared as if they should match, with the gap treated as a fault.
• Payment or booking domains left out of the referral exclusion list, crediting conversions to the processor.
• A container used as a dumping ground for every script anyone ever asked for, slowing pages and loading tags nobody can account for.