Forward events to your analytics

Living Page keeps its own read analytics. But if you already run your own analytics, you can have your flipbooks’ reader events land there too — in your own property, under your own domain, next to the rest of your funnel.

This is an Agency plan and up feature.

Supported analytics

The connector forwards to any of these — whichever you already have on the page:

Service	Custom properties
Google Analytics 4 (gtag.js)	✅ Yes
Google Tag Manager (dataLayer)	✅ Yes
Plausible	✅ Yes
Piqo	✅ Yes
Segment	✅ Yes
Umami	✅ Yes
Fathom	⚠️ Event name only — Fathom’s one extra field is a revenue value (in cents), so the flipbook_* details can’t be attached

And your ad pixels, so a flipbook read can become an audience:

Pixel	How events arrive
Meta (Facebook/Instagram)	Custom events, via fbq('trackCustom', …)
TikTok	Custom events, via ttq.track(…)
Pinterest	Custom events, via pintrk('track', …)

See Retarget readers with ads for turning those into an audience.

LinkedIn, X and Google Ads conversions aren’t auto-detected: each needs an id only you have (a conversion id, an event id, a send_to), and firing the wrong one in your ad account would be worse than not firing at all. Use Tag Manager for those — the events reach your dataLayer.

Running something else? The events are also available as a raw postMessage, so any script on your page can read them — see Advanced: the raw events.

How it works

When someone reads a flipbook you’ve embedded on your site, the reader (inside the iframe) announces each event to the page around it. A small connector script you paste on your site listens for those announcements and forwards them into whatever analytics you already have loaded.

Because the connector calls your existing analytics — your gtag, your plausible, your Tag Manager — the events arrive as first-party hits on your own domain. There are no IDs to copy and nothing to keep in sync. One script covers every flipbook you embed, now and later.

Forwarding applies to embeds — flipbooks inside an iframe on your site. A standalone share link opens on read.livingpage.app with no page of yours around it, so those reads stay in Living Page’s own analytics.

Turn it on

1. Go to Settings → Integrations and switch on Analytics forwarding.
2. Copy the connector script and paste it once onto your site, alongside your existing analytics tag. Site-wide (in your <head> or footer) is ideal — it then covers every embed.

<script async src="https://client-connect.livingpage.app/v1/connector.js"></script>

That’s the whole setup. The connector detects the analytics already on each page and forwards to it — GA4, Plausible, Piqo, Tag Manager, Segment, Umami or Fathom — so there’s nothing to configure and nothing to pick.

Already added it, or not sure? Enter your site’s address under Check your site and we’ll tell you whether the connector is present and which analytics we detected on the page — so you can confirm the pairing, or skip the paste step if it’s already there. (If you installed it through Tag Manager it won’t show in your page source, but it still works once your container is published.)

Multiple clients on different tools?

Because the connector reads whatever analytics is on each page, one script is safe to reuse across every client site even when they run different tools — nothing to tailor per site.

Pinning a specific tool (optional)

If a site runs two analytics tools and you want events to go to only one, add a data-provider attribute — ga4, plausible, piqo, gtm, segment, umami, fathom, meta, tiktok or pinterest. This is also how you keep flipbook events out of a tool: pin the one you want and, as long as it’s on the page, nothing else receives them.

<script async src="https://client-connect.livingpage.app/v1/connector.js" data-provider="ga4"></script>

It stays safe: if that tool isn’t on a given page, the connector falls back to whatever is there (and notes the swap in the browser console), so it never silently drops events.

The events you’ll receive

Four events, with stable names — the flipbook’s identity travels in the event’s properties, not the name:

Event	Fires when	Extra properties
flipbook_view	the flipbook is opened	—
flipbook_page_view	each new page is reached	flipbook_page
flipbook_read_time	the reader leaves, or switches tab	flipbook_read_seconds
flipbook_link_click	a link on a page is clicked	flipbook_link_target, flipbook_link_kind, flipbook_page

Read time adds up

flipbook_read_time can fire more than once in a read — it fires whenever the reader leaves or switches away, and reading only counts while the tab is actually visible. Each one carries the seconds since the last one, so a total is a plain sum: a reader who spends 11 seconds, switches tab, comes back for 5 and leaves sends 11 and then 5.

That makes “total read time” and “average read time” work in any tool without you doing anything. It also means you shouldn’t take a maximum and treat it as the session length.

What a link click reports

flipbook_link_target is the destination, normalised so one link is one row rather than one row per visitor: a web link reports its host and path with no query string, an in-document jump reports page 12, and an email link reports only its domain — never the address. flipbook_link_kind tells you which of the three it was (url, page, email).

Every event also carries:

• flipbook_title — the flipbook’s name
• flipbook_slug — its stable slug
• flipbook_id — its id
• flipbook_client — the client workspace it belongs to (if any), so a multi-client agency can break down “views by client” in one account

Seeing the properties in reports

Both GA4 and Plausible collect custom properties straight away, but won’t show them in reports until you register them once:

• GA4 — register flipbook_title, flipbook_page and the rest as custom dimensions (Admin → Custom definitions). Paste the connector below your GA4 tag.
• Plausible — add the flipbook_* keys under your site’s Custom properties. Paste the connector after your Plausible script.
• Piqo — paste the connector after your Piqo script; events arrive via piqo(name, { props }) with the flipbook_* keys attached, the same as Plausible.
• Google Tag Manager — add the connector as a Custom HTML tag. Events are pushed to the dataLayer as flipbook_view / flipbook_page_view / flipbook_read_time, ready for your own triggers and tags.
• Segment — paste the connector after your analytics.js snippet; events arrive via analytics.track.
• Umami — paste the connector after your Umami script; the flipbook_* keys arrive as event data via umami.track.
• Fathom — paste the connector after your Fathom script. Fathom’s only extra event field is a revenue _value (in cents), which doesn’t apply to a reader event — so you’ll get flipbook_view / flipbook_page_view / flipbook_read_time counts via fathom.trackEvent, without the per-flipbook breakdown.

Advanced: the raw events

Under the hood, the embedded reader posts each event to the parent window. The connector is just a small listener on top of it — if your tool isn’t in the list above, any script on your page can listen for the same messages:

window.addEventListener('message', (e) => {
  if (e.origin !== 'https://embed.livingpage.app') return;
  const m = e.data;
  if (!m || m.source !== 'livingpage') return;
  // m.event  → 'flipbook_view' | 'flipbook_page_view' | 'flipbook_read_time' | 'flipbook_link_click'
  // m.props  → { flipbook_title, flipbook_slug, flipbook_id, flipbook_client,
  //              flipbook_page, flipbook_read_seconds, flipbook_link_target, flipbook_link_kind }
  // and, only with enhanced matching and a reader's consent: flipbook_lead_sha256
  yourAnalytics.track(m.event, m.props);
});

Always check e.origin is https://embed.livingpage.app before trusting a message.

What’s shared

Only what’s needed to identify the flipbook: its title, slug, id, the page number, the read time, the link clicked, and the client name. Reads are anonymous and cookieless — the connector forwards the same events Living Page measures, into a tool you control.

Two things are deliberately not sent:

• A reader’s identity. Nothing in these events names, numbers or tracks the person reading. The one exception is opt-in on both sides — see enhanced matching, where a reader who unlocks a document with their email address can agree to a scrambled (hashed) copy going to your ad provider. Off unless you switch it on and they agree.
• An email address from your own document. If a page links to hello@yourcompany.com, the forwarded event carries yourcompany.com and not the address. It’s personal data, it identifies you rather than the reader, and it has no business in a third party’s analytics. Your own Living Page reports keep the full address, so per-link reporting is unaffected.

What your analytics does with the events is governed by your own setup and privacy policy — you’re the data controller there.

Next

• Retarget readers with ads — turning reads into an audience, and enhanced matching.
• Read analytics — what Living Page measures on every plan, and what stays private.