> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://docs.intractive.app/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Meta - Story events with Google Tag Manager

# Story events with Google Tag Manager
UTM tracking tells the destination page where a visitor came from. But it says nothing about what happened *inside* your story: how far someone got, what they answered, whether they clicked through. That's what Google Tag Manager is for.

This article explains what Google Tag Manager does, where to add it to your project, and exactly which events a story sends out. No technical background needed.

| 💡 In one sentence: Google Tag Manager is a container you add to your project once, and afterwards you can send story events to any analytics or advertising tool without ever changing anything in Intractive again.

# Tag Manager is a delivery van, not a destination

This is the part that confuses almost everyone the first time, so it's worth getting straight before you start.
Google Tag Manager has no reports. You will never open it to find out how many people finished a story. Its only job is to sit on the story page, watch what happens, and forward that information to the tools that *do* have reports.

| Tool | ID looks like | What it is |
| ---- | ---- | ---- |
| Google Tag Manager | `GTM-XXXXXXX` | The **van**. Runs on the story page and decides what gets sent where. Stores nothing, reports nothing. |
| Google Analytics 4 | `G-XXXXXXXXXX` | An **address**. Stores the data and gives you reports, funnels and audiences. |
| Meta pixel | `1234567890123456` | Another **address**. Powers retargeting and campaign optimisation. |
| So a Tag Manager ID on its own does nothing visible. It needs at least one destination before any data appears anywhere. |  |  |

| 💡 Why Intractive uses Tag Manager instead of an Analytics field. A project has one tracking field. If that field held a Google Analytics ID, Analytics would be the only thing you could ever send to. With Tag Manager in it you get a socket instead of a hard-wired appliance: Analytics, Meta, LinkedIn or anything else gets added inside Tag Manager afterwards, with no change in Intractive and no new release.

# Where to add your Tag Manager ID
The Tag Manager ID is set per **project**, so every project can point at its own container. All stories in that project will use it.

1. Open your project and go to **Project settings**
2. Scroll to the **Tracking & scripts** section
3. Paste your container ID into **Google Tag Manager ID**
4. Save

|| ⚠️ The Tracking & scripts section is only visible to users with an admin role. If you can't see it, ask an admin in your organisation to add the ID for you.


Because the setting sits on the project, the natural model is **one client, one project, one container** — their Tag Manager, their Analytics, their pixel, their data. You never proxy anyone else's tracking.

## Header and footer scripts
The same section has **Header scripts** and **Footer scripts**. These inject code into the published story page directly, before or after the page renders. Use them only for tools that genuinely cannot run through Tag Manager — a consent banner is the usual example, because it has to load before Tag Manager does.

For everything else, Tag Manager is the better place: it's easier to change, easier to test, and you can switch things off without touching Intractive.
# What a story sends out
Once a container is running, the story pushes events into something called the **data layer** — a small message queue that Tag Manager listens to. There are three events, and everything you build downstream is made from these.

| Event name | Information included | When it happens |
| ---- | ---- | ---- |
| `intractiveStoryProgress` | `storyId` |  |
| `sessionId` |  |  |
| `progress` |  |  |
| `depth` |  |  |
| `total` | When the story loads, and again whenever the viewer's progress changes |  |
| `intractiveVariablesUpdated` | `variables` | Whenever a story variable changes — this is how answers and choices reach your analytics |
| `intractiveOutboundLink` | `storyId` |  |
| `sessionId` |  |  |
| `url` | When the viewer clicks a link that takes them out of the story |  |

## What the progress fields mean
* `depth` — which content block the viewer is on, counting from 1. The first message is always `depth: 1`, which makes it a reliable signal that someone **started** the story.
* `total` — how many content blocks the story's main line has.
* `progress` — a percentage from 0 to 100, based on how many blocks have been completed. It reaches `100` when the story finishes, which makes it a reliable **completed** signal.

|| ⚠️ progress and depth describe the main line of the story, not its branches. In a linear story that walks people through blocks one after another, they map neatly onto how far someone got. In a menu-style story where viewers pick a topic and come back to a hub, the main line is short and progress will jump to 100 very quickly. That isn't a fault, it just means progress is the wrong thing to measure in that kind of story. See Meta pixel and campaign tracking strategies for how to pick events that match your story's shape.

## Capturing answers and choices
The three events above are fixed. But `intractiveVariablesUpdated` carries whatever is in your **story variables**, which means you decide what ends up in your analytics.

If a story has no variables, that event never fires and you'll see progress and outbound clicks only. If you want to know *which* option someone picked, the story has to write that choice into a variable.

A few habits that make variables genuinely useful later:
* **One variable per meaningful decision**, not per interaction. Role, intent, timeline, region — the things that separate a serious visitor from a curious one.
* **Use short fixed values, not free text.** `timeline: 0-3m` works as a filter; a typed sentence does not.
* **Set the variable at the moment of the tap**, not at the end of the story, so the signal still arrives if someone leaves early.
* **Use the same names across a client's stories**, so you can compare them and build one audience across all of them.

|| ⚠️ Never put personal data in a variable that flows into analytics. Names, email addresses and phone numbers must not be sent to Google Analytics — it's against Google's own terms and it creates a privacy problem. When you send variables onward, list the specific ones you want by name rather than passing everything at once.

# Stories embedded on your own website
When a story runs inside an iframe on your own site, your Tag Manager container is on the parent page and can't see inside the frame. The story solves this by also posting each event out to the surrounding page, so your existing container can pick it up.

* Code for the parent page (for your developer)
Add this to the page that embeds the story. It listens for the story's events and puts them into the page's own data layer, where your existing Tag Manager setup will treat them like any other event.

```
<script>
window.addEventListener('message', function (e) {
  if (e.origin !== '<https://web.intractive.app>') return;
  var m = e.data;
  if (!m || m.type !== 'intractive.dataLayer' || !m.payload) return;
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push(m.payload);
});
</script>

```
Keep the origin check on the third line. Without it the page would accept messages from any embedded frame, which is a security risk.

Embedding has a second advantage: because the story runs on your own domain, your existing cookie banner already covers it and visitors aren't asked for consent twice.
# One page view per story
A story is a single page that changes as the viewer moves through it. The web address doesn't change from block to block, so analytics tools record exactly **one page view** for an entire story.

This means every report you build has to be based on events, not pages. Don't expect a useful "most viewed pages" report, and don't build funnels on page paths.

✅ **Quick checklist**
* Tag Manager is the van, Analytics and Meta are the addresses. You need both.
* The Tag Manager ID goes in **Project settings → Tracking & scripts**, and needs an admin.
* One client, one project, one container.
* Three events are available: progress, variables updated, and outbound link.
* Answers only reach analytics if the story writes them into variables.
* Never send names, emails or phone numbers to Google Analytics.
* Build reports on events, not on pages.