Retarget readers with ads

Someone who read eleven pages of your brochure is a better prospect than someone who bounced off your homepage. If you embed your flipbooks and run event forwarding, you can advertise to them.

This is an Agency plan and up feature, and it applies to embedded flipbooks — the kind inside an iframe on your own site.

How it works, in one paragraph

The connector script runs on your page, not inside the flipbook. So when it hands a flipbook event to your Meta pixel or your Google tag, that’s your own tag firing on your own domain, in your own first-party context — exactly as if the reader had clicked a button on your site. Your ad platform builds the audience; we never see it, and you never give us an ad account.

Build an audience

Nothing to configure first: once forwarding is on and the connector is pasted, the events arrive at any ad pixel already on the page.

Meta (Facebook and Instagram)

Events arrive as custom events named flipbook_view, flipbook_page_view, flipbook_read_time and flipbook_link_click.

1. In Events Manager, confirm the custom events are arriving (open a page with your flipbook and turn a few pages).
2. In Audiences → Create audience → Custom audience → Website, choose your pixel.
3. Pick the event, then narrow it with a property — for example flipbook_page greater than 5, or flipbook_title containing Spring Collection.

TikTok

Events arrive through ttq.track as custom events. Create the audience under Assets → Audiences → Create → Website traffic, and filter on the event name.

Pinterest

Events arrive through pintrk('track', …). Build the audience from Audiences → Create audience → Visitors, filtered by event.

Google Ads

There’s no separate Google Ads sink — if your Google tag (gtag.js) is on the page, it already receives the events, so build a remarketing audience from the event in Google Ads or GA4. For a conversion you need your own send_to value, which only you have: use Tag Manager and trigger your conversion tag off the dataLayer event.

LinkedIn and X

Not auto-detected, for the same reason: both want an id that belongs to your account (a conversion id, an event id), and firing the wrong one would put the wrong numbers in your ad account. Use Tag Manager, where the events reach your dataLayer and your own tags decide what to do.

Audience ideas that actually segment

The events carry enough to be specific, which is the difference between a useful audience and “everyone who visited”:

Audience	Filter
Engaged readers	flipbook_page_view where flipbook_page > 5
Finished the brochure	flipbook_page_view where flipbook_page is your last page
Dwelled, didn’t act	flipbook_read_time where flipbook_read_seconds > 60
Clicked through to pricing	flipbook_link_click where flipbook_link_target contains /pricing
One client’s catalogue only	any event where flipbook_client is that client

Remember that flipbook_read_seconds is incremental — each event carries the seconds since the last one, so build “time spent” rules on a sum rather than a single event’s value. See read time adds up.

Enhanced matching

Everything above is anonymous: it works through your own pixel’s cookie, and no reader is identified to anybody. Enhanced matching (Meta calls it advanced matching) is the opposite — it’s how a platform recognises the reader as a person, so a conversion can be attributed to them days later on another device.

That needs the reader’s own email address, so it only applies where a reader has actually given you one: a document behind an email gate.

What happens

1. A reader opens a gated document and types their email address to get in.
2. The gate tells them what happens to it: you may also use the address to measure and target advertising, and a scrambled (hashed) copy goes to your advertising provider.
3. The address is scrambled with SHA-256 in their browser and only the scramble travels. We never send the address itself to an ad platform.
4. The connector hands that scramble to your platform’s identity channel — gtag('set', 'user_data', …) for Google, ttq.identify(…) for TikTok — never as an event property.

Turning it on

Settings → Integrations → Analytics forwarding → Enhanced matching. It needs forwarding to be on, and switching forwarding off switches matching off with it.

For Meta, switch on Automatic Advanced Matching in Events Manager instead. Meta only honours matching data supplied inside your pixel’s own setup, which would mean us handling your pixel id — so we don’t, and Meta’s own switch does the job without any code.

What you’re agreeing to

You are the data controller for this, and we’re processing on your instruction. Practically:

• The consent lives on your site, not on our gate. We only ever hand the hash to an advertising tag your page has already loaded — which, if you run a consent banner properly, happens only after that visitor agreed to advertising. Obtaining and recording that agreement is yours, and your advertising provider’s terms require it of you independently of us.
• Your privacy policy needs to say that an address collected at the gate may be shared, hashed, with your advertising provider.
• Hashing is not anonymising. A hashed address is still personal data — matching works precisely because the platform can recompute the same hash from an address it already holds.
• If you do not run a consent banner, or your banner does not cover advertising, switch this off. The anonymous audiences above work without it.

What is never matched

• Page turns, read time, link clicks, searches and Ask questions. All anonymous, on every plan, whatever your settings.
• Reads of documents without an email gate. There is no address to match.
• A mailto: address printed in your own document. That identifies you, not the reader — the forwarded event carries only its domain.
• Standalone share links. Matching rides on the connector, which runs on your page; a share link has no page of yours around it.

Next

Forward events to your analytics — the full event and property reference.