> 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/peakcommerce/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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.