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.

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.

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

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.

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.

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.

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.

Updated on: 24/09/2026