> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/settings/developer-tools/tracking-scripts.md).

# Tracking Scripts

**Settings → Tracking Scripts** installs your analytics and tag-manager snippets — Google Tag Manager, GA4, VWO, Heap, and similar tools — on the pages your visitors see, with no engineering change and no theme edit. Paste the snippet once and PeakCommerce injects it into your public pages and journeys.

Find it under the **user menu (bottom-left) → Settings → Tracking Scripts**, in the *Developer Tools* section.

## Why it matters

Marketing and analytics teams usually queue behind engineering to get a tag-manager container installed or updated. Tracking Scripts removes that dependency: a system administrator pastes the vendor's snippet, saves, and it is live across the public buying experience — while the platform enforces the guardrails (who can author scripts, which surfaces run them, and which never do) so self-service doesn't become a security or privacy gap.

The page is restricted to **system administrators** by design: whatever is pasted here executes verbatim in your visitors' browsers, so authoring access *is* the security boundary.

## Head scripts vs. body-start scripts

The page has two fields, matching how analytics vendors split their install code:

* **Head scripts** — injected as high in the page `<head>` as possible (right after the charset declaration), which is what tag managers ask for. This is where the main `<script>` loader goes.
* **Body-start scripts** — injected immediately after the opening `<body>` tag. This is the placement for `<noscript>` fallbacks such as Google Tag Manager's iframe.

If your tool only provides one snippet, the head field alone is fine.

## One environment at a time

Each environment — sandbox and production — holds its **own** snippets, and the page always edits the environment you're signed in to (the card on the page names it). Your sandbox site and your production site are separate deployments with separate data, so a snippet saved on one can never run on the other.

In practice: paste your **live container on production** and a **test container on sandbox** (for example a GTM *Environments* snippet). That separation is what keeps UAT and test traffic out of your production dashboards — sandbox never falls back to production values.

## Where the scripts run

Tenant-wide snippets run on your **public** pages: the storefront, signup, payment, and login pages, and public journeys.

Pages and journeys can carry their own snippets on top of the tenant default:

* **Per page** — the page editor's **Tracking** panel.
* **Per journey** — the journey editor's **Settings** tab (loads once when the journey starts).
* **Per step** — the step editor's **Tracking scripts** section (fires when a visitor reaches that step — the building block for funnel goals).

Overrides **extend** the tenant default — your main container keeps running everywhere — unless you switch on **Suppress tenant default** for that page or journey, for the conflicting-tool or sensitive-page case.

## Customer portal tracking

Behind-login pages are different: by default, **no scripts run on the signed-in customer portal** — not even your tenant-wide default. If you want product analytics on the portal experience, enable the **Customer portal tracking** switch on this page.

Treat that as a deliberate decision. Trackers on authenticated pages observe *identified* customer activity, and your organization owns the corresponding privacy disclosure to your customers. Until the switch is on, the portal runs no tenant, page, or journey snippets at all.

## Guardrails

* **Staff screens never run your scripts.** Admin, CSR, and operator sessions never execute tenant tracking scripts — only visitors and (when opted in) signed-in customers do. Remember this when testing: verify as a visitor, not from an admin session.
* **Scripts are injected verbatim.** PeakCommerce does not rewrite or sandbox the snippet — a malformed or malicious snippet can break or compromise *your own* page experience. Only paste snippets from tools you trust, copied directly from the vendor.
* **Size cap.** Each field accepts up to 20,000 characters — room for several stacked tool loaders, while rejecting pasted application bundles.
* **Changes are audited.** Every save (tenant-wide, page, journey, or step) is recorded with who changed what, before and after.

For a step-by-step walkthrough — including keeping sandbox traffic out of your production analytics and firing per-step funnel goals inside a multi-step journey — see [Guide: Installing Analytics and Tag Manager Scripts](https://gitlab.com/peak-hercules/peak-help-docs/-/tree/main/guides/administration-guides/guide-installing-analytics-and-tag-manager-scripts.md). Related: [Widget Embed](/product/settings/developer-tools/widget-embed.md) for embedding a buying experience in a site you already instrument.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/product/settings/developer-tools/tracking-scripts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
